Ubuntu
xfce4-terminal package

Xubuntu-Dapper Drake (AMD64): Missing Terminal RC File

Bug #41791 reported by davemac on 2006-04-27

Affects		Status	Importance	Assigned to	Milestone
	xfce4-terminal (Ubuntu)	Fix Released	Medium	Unassigned

Bug Description

Symptom:

When attempting to modify Terminal Attributes for the console terminal under Xfce-4 (such as turning off menubar), the dialog responds, but the change doesn't take.

Probable Cause:

There should be a Terminal subdirectory under ".config" in a user's workspace, in which a "terminalrc" file resides which is essentially the xml describing the terminal attributes. I did not find one using Dapper Drake Beta Text Install. If you copy a terminalrc from another Xfce-4 based machine (such as Zen <slackware derivative>) the problem disappears.

Side Effects:

It probably exists in x86, and PPC versions as well as it is a configuration file issue, not machine-specific code

Potential Fix:

I suspect there needs to be a Terminal subdirectory under /etc/xdg with a corresponding terminalrc file, so that the Terminal subnode and default terminalrc file are created. (unconfirmed yet)

Package:

Probably Xfce4-Terminal, but it may be a larger configuration issue

Revision history for this message

davemac (davemac) wrote on 2006-04-28:

04/28/2006: I've confirmed that building a Terminal subnode, and terminalrc file under /etc/xdg, solves the problem for new users - dmc

Revision history for this message

Jani Monoses (jani) wrote on 2006-05-17:

even if there's no terminalrc in /etc/xdg modifying your settings should be places in .config and used later on.I sthat not the case? It works fine for me.

Revision history for this message

davemac (davemac) wrote on 2006-05-17: Re: [Bug 41791] Re: Xubuntu-Dapper Drake (AMD64): Missing Terminal RC File

Jani Monoses wrote:

>even if there's no terminalrc in /etc/xdg modifying your settings should
>be places in .config and used later on.I sthat not the case? It works
>fine for me.
>
>
>
Thanks Jani.

That was not my experience with the version of Xubuntu-64, at the time
of the report. Since I "fixed" the problem for that machine, I haven't
paid any attention to it. What I just did was the following steps:

renamed my makeshift Terminal directory in /etc/xdg to oldTerminal
(sudo mv /etc/xdg/Terminal /etc/xdg/oldTerminal)

    created a new user - using adduser in a term window and accepting
all the defaults
    logout
    logged back in as the new user
    open a terminal window
    navigate through menubar to edit-preferences-appearance
    uncheck display menubar in new windows
    close terminal preferences dialog
    close old terminal window
    open a new terminal window

The menu bar is there, and if you navigate through menubar to
edit-preferences-appearance, the box has reverted to being checked.

I've confirmed that the behavior is the same if I run an SMP kernel, or
a regular kernel on the X64 machine.

I also just confirmed the behavior on the x86 version of Xubuntu on my
laptop. Radically different machine architecture - Transmeta Efficieon CPU.

I know how frustrating it is when it's one of those "but it works on my
machine" bugs. Had I not been able to reproduce the problem on my
laptop, I would have blown it off as a download or installation "glitch"

Please let me know if there is any other information I can provide...I
can do screen captures, but I didn't see how that could really help.

I've been pretty regular about updating both machines daily using
Synaptic, and religiously reloading-marking-all-updates, etc.

You guys have done a terrific job with Xubuntu...I do appreciate it.
Let me know how I can help.

davemac

P.S. For more bug finding joy - try opening help, and clicking on panel
on the help page that comes up...I think this one's an "upstream"
problem (happens on my Zen box too)

Jani Monoses wrote:

>even if there's no terminalrc in /etc/xdg modifying your settings should
>be places in .config and used later on.I sthat not the case? It works
>fine for me.
>
>  
>
Thanks Jani.

That was not my experience with the version of Xubuntu-64, at the time 
of the report.  Since I "fixed" the problem for that machine, I haven't 
paid any attention to it.  What I just did was the following steps:

renamed my makeshift Terminal directory in /etc/xdg to oldTerminal
    (sudo mv /etc/xdg/Terminal /etc/xdg/oldTerminal)

created a new user - using adduser in a term window and accepting 
all the defaults
    logout
    logged back in as the new user
    open a terminal window
    navigate through menubar to edit-preferences-appearance
    uncheck display menubar in new windows
    close terminal preferences dialog
    close old terminal window
    open a new terminal window

The menu bar is there, and if you navigate through menubar to 
edit-preferences-appearance, the box has reverted to being checked.

I've confirmed that the behavior is the same if I run an SMP kernel, or 
a regular kernel on the X64 machine.

I also just confirmed the behavior on the x86 version of Xubuntu on my 
laptop.  Radically different machine architecture - Transmeta Efficieon CPU.

I know how frustrating it is when it's one of those "but it works on my 
machine" bugs.  Had I not been able to reproduce the problem on my 
laptop, I would have blown it off as a download or installation "glitch"

Please let me know if there is any other information I can provide...I 
can do screen captures, but I didn't see how that could really help.

I've been pretty regular about updating both machines daily using 
Synaptic, and religiously reloading-marking-all-updates, etc.

You guys have done a terrific job with Xubuntu...I do appreciate it.  
Let me know how I can help.

davemac

P.S.  For more bug finding joy - try opening help, and clicking on panel 
on the help page that comes up...I think this one's an "upstream" 
problem (happens on my Zen box too)

Revision history for this message

Jani Monoses (jani) wrote on 2006-05-17:

1)Hmm what does not persist here is the state of the toggles accesible in the View Menu of the main menubar. However setting it in edit->preferences->appearance makes it live thoughout invocations.
Look for the state of MiscMenubarDefault in ~/.config/Terminal/terminalrc
do this in the terminal then go to the dialog and toggle that check
$ watch -n 1 grep Menubar /home/jani/.config/Terminal/terminalrc
it should change in the file as well

2) panel help yes I know, it even provides xfce 4.2 help since upstream has not updated to 4.4 yet.

3) how do you find zen compared to xubuntu (wrt performance, selection of apps and whatever other criteria you find important?)

Revision history for this message

davemac (davemac) wrote on 2006-05-18:

Download full text (5.7 KiB)

Thanks for getting back so quickly...see comments below.

Jani Monoses wrote:

>1)Hmm what does not persist here is the state of the toggles accesible in the View Menu of the main menubar. However setting it in edit->preferences->appearance makes it live thoughout invocations.
>Look for the state of MiscMenubarDefault in ~/.config/Terminal/terminalrc
>do this in the terminal then go to the dialog and toggle that check
>$ watch -n 1 grep Menubar /home/jani/.config/Terminal/terminalrc
>it should change in the file as well
>
>
I agree with you a lot, but disagree with you a little (I think...have
patience with me - I'm older and slower). For a new user, there is no
.config/Terminal/terminalrc, so the watch line doesn't really work.
(That's the little bit of disagreement)

However, the following things do happen. If I open a terminal window
(as a new user), and from it, tell it to turn off the menu
(edit->preferences->appearance->etc), and *leave the original window
open* any other terminal instances I open will not have a menu showing.
However, if I close all open terminal instances, and then re-open a new
terminal instance, it will not honor the "no menu directive" and sure
enough the checkbox is checked. I believe the difference in the
behaviors has to do with Xfce4 caching its working data, and as long as
there is an instance in memory, it doesn't need to go to disk. Once
you've closed out the last Terminal instance, there are no settings in
cache, so when you start a new instance, it goes looking for terminalrc
under Terminal. You can play with this by starting terminal instances
from a terminal and changing states of the menu bar on and off, as long
as you have at least one instance open the state persists. Once the
last instance is gone...no state persistence.

Listing the contents of .config in this case reveals still no Terminal
directory, and no terminalrc within the directory. (again for a new
user....one quick fix that I've determined works is to mkdir
.config/Terminal, touch .config/Terminal/terminalrc which of course
gives a zero byte terminalrc file, but because it's there, that's
sufficient for the file to get updated to real values.

So I think it's a question of one-of-two adjustments. Either Terminal
must be made smart enough to create ".config/Terminal/terminalrc" if it
doesn't exist (even if it's by the cheap touch technique above), or the
default first time user scripts must be sure to do the creation. I
think the discrepency between Zen behavior (the expected behavior - you
make a change and it "sticks"), and Xubuntu behavior lies in the default
configuration. When I create a new user in Zen, I get a Terminal
directory, and a terminalrc file underneath it. When I create a new
user under Xubuntu neither the Terminal directory, nor the corresponding
terminalrc exist.

>2) panel help yes I know, it even provides xfce 4.2 help since upstream
>has not updated to 4.4 yet.
>
>
Yeah, it's that way with Zen too. I suspect Jasper Huijsmans (if he is
still the developer), just hasn't gotten around to it...I can relate to
that.

>3) how do you find zen compared to xubuntu (wrt performance,...

Thanks for getting back so quickly...see comments below.

Jani Monoses wrote:

>1)Hmm what does not persist here is the state of the toggles accesible in the View Menu of the main menubar. However setting it in edit->preferences->appearance makes it live thoughout invocations.
>Look for the state of MiscMenubarDefault in ~/.config/Terminal/terminalrc
>do this in the terminal then go to the dialog and toggle that check
>$ watch -n 1 grep Menubar /home/jani/.config/Terminal/terminalrc
>it should change in the file as well
>  
>
I agree with you a lot, but disagree with you a little (I think...have 
patience with me - I'm older and slower).  For a new user, there is no 
.config/Terminal/terminalrc, so the watch line doesn't really work. 
(That's the little bit of disagreement)

However, the following things do happen.  If I open a terminal window 
(as a new user), and from it, tell it to turn off the menu 
(edit->preferences->appearance->etc), and *leave the original window 
open* any other terminal instances I open will not have a menu showing.
However, if I close all open terminal instances, and then re-open a new 
terminal instance, it will not honor the "no menu directive" and sure 
enough the checkbox is checked.  I believe the difference in the 
behaviors has to do with Xfce4 caching its working data, and as long as 
there is an instance in memory, it doesn't need to go to disk.  Once 
you've closed out the last Terminal instance, there are no settings in 
cache, so when you start a new instance, it goes looking for terminalrc 
under Terminal.  You can play with this by starting terminal instances 
from a terminal and changing states of the menu bar on and off, as long 
as you have at least one instance open the state persists.  Once the 
last instance is gone...no state persistence.

Listing the contents of .config in this case reveals still no Terminal 
directory, and no terminalrc within the directory. (again for a new 
user....one quick fix that I've determined works is to mkdir 
.config/Terminal, touch .config/Terminal/terminalrc which of course 
gives a zero byte terminalrc file, but because it's there, that's 
sufficient for the file to get updated to real values.

So I think it's a question of one-of-two adjustments.  Either Terminal 
must be made smart enough to create ".config/Terminal/terminalrc" if it 
doesn't exist (even if it's by the cheap touch technique above), or the 
default first time user scripts must be sure to do the creation.  I 
think the discrepency between Zen behavior (the expected behavior - you 
make a change and it "sticks"), and Xubuntu behavior lies in the default 
configuration.  When I create a new user in Zen, I get a Terminal 
directory, and a terminalrc file underneath it.  When I create a new 
user under Xubuntu neither the Terminal directory, nor the corresponding 
terminalrc exist.

>2) panel help yes I know, it even provides xfce 4.2 help since upstream
>has not updated to 4.4 yet.
>  
>
Yeah, it's that way with Zen too.  I suspect Jasper Huijsmans (if he is 
still the developer), just hasn't gotten around to it...I can relate to 
that.

>3) how do you find zen compared to xubuntu (wrt performance, selection
>of apps and  whatever other criteria you find important?)
>  
>
Kernel:

If I'm only dealing x86, the nod goes to Zen.  In general the Slackware 
kernel system just seems to kick butt...however Zen *only* supports x86 
not AMD-64.  So if we are talking non-x86, then clearly Xubuntu has the 
edge.  What brought me into the Ubuntu fold was the AMD-64 support.

Platform:

Hands down, Xubuntu.  I can load Xubuntu onto my laptop, my generic x86 
boxes, and by X64's.  Your laptop support has gotten *enormously* 
better.  Zen's is non-existent.  Same for X64.

Bootup:

Hands down, Zen. Sorry, but the Debian way is the somewhat tedious way.  
I can hand trim the startup to make it a much better horserace, but it 
takes a fair amount of work...undoing the splash nonsense, etc.  I've 
also just always found the Slackware init scripts easier to understand, 
and a lot more straightforward.  I think that makes me just a 
grumpy-old-timer.

Xubuntu could improve here, by making some assumptions that would have 
to be tested with the community.  Just about everyone (I think) that is 
looking for a lean, mean desktop, is also looking for a lean, mean 
startup, and doesn't need the splash stuff, or anything else that gets 
in the way of boot, login, and rock-n-roll.

Package Management:

Hands down, Xubuntu.  Nothing out there is like apt-get/synaptic, 
period; not perfect, but definitely the best out there IMHO.

Package Availability:

Hands down, Xubuntu.  Thank-you Debian.

Installation:

Hands down, Xubuntu.  You have to jump through hoops on Zen to install 
from anything other than a vanilla IDE drive.

Wireless Support:

Hands down, Xubuntu, although I'd like to see wi-fi radar become part of 
the Xubuntu standard distribution (in lieu of the cruft associated with 
the gnome-network-manager)

Overall Performance:

The nod goes to Zen, but it's very subjective.  It might just be worth 
trying some representative benchmarks and objectify my feelings (well, 
there goes a night this week)

Programming Development:

Several answers here:

As initially installed: Zen  ( I can compile right out of the chute)
    Python:                     Xubuntu  ( I do a lot of C-stuff with 
Python Wrappers / Apps )
    Kernel:                     Zen ( Don't need all the Debian cruft to 
make a kernel )
    Java:                         Zen ( It's at least marginally less 
painful with Zen, both are hard )
    C-development:       Initially Zen, but as you need more support 
libraries, Xubuntu

Sorry it took so long to get this back to you...one of those days when 
life got in the way of computing; it happens sometimes.

hope this helps,

davemac

Revision history for this message

Jani Monoses (jani) wrote on 2006-05-18:

thanks for patiently explaining it again, I can now reproduce it here as well.
Toggling some options (show toolbar) leads to the creation of the rc file, toggling some others doesn't.

Revision history for this message

davemac (davemac) wrote on 2006-05-18:

Jani Monoses wrote:

>thanks for patiently explaining it again, I can now reproduce it here as well.
>Toggling some options (show toolbar) leads to the creation of the rc file, toggling some others doesn't.
>
>
>
Excellent! It's now 95% solved, I'm sure. Thanks for your persistence.

davemac

Revision history for this message

Jani Monoses (jani) wrote on 2006-05-20:

applied patch from upstream which fixes this. Should be more than 95% solved now ;)

Changed in xfce4-terminal:
status:	Unconfirmed → Fix Released

Revision history for this message

davemac (davemac) wrote on 2006-05-21:

Jani:

Did my updates this morning (California), and I've confirmed the problem
is now solved.
Good work, and thanks for taking the time to do the fix for such a minor
problem.

davemac

Jani Monoses wrote:

>applied patch from upstream which fixes this. Should be more than 95%
>solved now ;)
>
>** Changed in: xfce4-terminal (Ubuntu)
> Status: Unconfirmed => Fix Released
>
>
>