Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 277361 - gnome-base/gnome-panel workspace_switcher loses workspace names
Summary: gnome-base/gnome-panel workspace_switcher loses workspace names
Status: VERIFIED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] GNOME (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-10 22:09 UTC by Robert Bradbury
Modified: 2010-10-18 09:33 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
Emerge --info and version info (EmrgInfo.lst,3.95 KB, text/plain)
2009-07-11 16:58 UTC, Robert Bradbury
Details
.gnomerc-errors (Gnome-errors.txt,10.68 KB, text/plain)
2009-07-11 17:09 UTC, Robert Bradbury
Details
Partial metacity log -- seting Workspace names correctly (MetacityLog100-197.lst,5.32 KB, text/plain)
2009-08-04 16:29 UTC, Robert Bradbury
Details
Later portion of metacity log indicating part of the problem (MetacityLog511-591.lst,4.75 KB, text/plain)
2009-08-04 16:40 UTC, Robert Bradbury
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Bradbury 2009-07-10 22:09:12 UTC
It would appear that recent gnome / metacity upgrades have lost the ability to retain assigned workspace names across sessions.  I can assign workspace names during a session and they are retained.  But if I logout and log back in again or reboot the system (without logging out) they appear to revert to their "default" state (e.g. Workspace 1, Workspace 2, Workspace 3, etc.).

This presumably involves the file:
~/.gconf/apps/metacity/workspace_names/%gconf.xml
which appears to be where the names are kept.  My current working theory is that a gnome/metacity startup (e.g. from a login) clobbers this file with the default names rather than reuse the assigned names.

Reproducible: Always

Steps to Reproduce:
1. Change the workspace names (or add more workspaces and assign new names to them).
2. Wait a few minutes and check to make sure the workspace_names/%gconf.xml file has been changed (I think a daemon of some kind manages this).
3. Logout and log back again again; or; reboot the system (without logging out) and log back in.

Actual Results:  
Workspace names revert to "Workspace #".

Expected Results:  
Workspace names should be maintained from previous sessions.

If this bug is filed with Gnome, please reference that bug here.

The bug may vary in that I think I've seen it revert only "new" workspace names (e.g. change # of workspaces from 4 to 5, change the name on #5, logout, login, names of 1-4 are changed but #5 reverts to "Workspace 5") at other times it appears to change all workspace names back to the default.

I am not sure but I believe I've tried this both using and not using gnome-session-save before starting a new session and that doesn't appear to change anything.
Comment 1 Gilles Dartiguelongue gentoo-dev 2009-07-11 13:22:07 UTC
Please provide emerge --info, emerge -pv gnome-panel metacity gconf.

Ftr, this works just fine here. Do you have a complete gnome desktop or some gnome-light variant ?
Comment 2 Robert Bradbury 2009-07-11 16:58:26 UTC
Created attachment 197571 [details]
Emerge --info and version info

Versions:
 gnome-base/gnome-panel-2.26.3 +doc +eds
 x11-wm/metacity-2.26.0-r1 +debug
Comment 3 Robert Bradbury 2009-07-11 17:09:50 UTC
Created attachment 197572 [details]
.gnomerc-errors

The .gnomerc-errors file from a session which has the "losing workspace-name" problem.

Note, I suspect there are multiple problems involved in the log.  If anybody has any solutions for any of them I'm all ears.  The system itself is in a state of trying to stay trying to stay very close to the cutting edge (even development) releases of many packages, as such I often trip over problems before people who stick to only use the "production" packages.

It is worth noting that this is a new problem (arising in ~Q2 2009) and that prior to that it was not a problem.  Given the gnome-panel (segfaults in many new applications being added to the panel) problems I suspect the gnome developers have been playing with the architecture and not testing it well.
Comment 4 Gilles Dartiguelongue gentoo-dev 2009-07-12 07:26:07 UTC
you missed gconf.
Comment 5 Robert Bradbury 2009-07-13 08:28:48 UTC
Sorry.  Here is emerge -pv gconf:
[ebuild   R   ] gnome-base/gconf-2.26.2-r1  USE="doc ldap -debug -policykit" 1,441 kB

As mentioned, this has not been a problem over several years and has only recently become a problem.
Comment 6 Robert Bradbury 2009-08-04 16:29:04 UTC
Created attachment 200165 [details]
Partial metacity log -- seting Workspace names correctly

Here is part of a metacity log, which suggests that it is managing to set the workspace names correctly, e.g. "Active Work", "SysStat", etc.

It should be noted that the problem is that following login the workspace names revert to their numbered defaults, e.g. "workspace #".  One can modify the names using the "Workspace Switcher Preferences" option and they will be retained throughout the session.  And even be updated in the .gconf file.  But logout and log back in again and they will have been "lost".
Comment 7 Robert Bradbury 2009-08-04 16:40:58 UTC
Created attachment 200169 [details]
Later portion of metacity log indicating part of the problem

This is a later portion of the metacity log suggesting that the names have reverted to their numbered alternatives.

I tried debugging this but the code appears to be relatively complex.  It appears that what is happening is some interaction between metacity and gnome-panel (or the workspace switcher), perhaps with the involvement of gconf.  Metacity is able to process the name changes once, but loses them and doesn't inform the switcher (or whomever maintains the "in-memory" workspace name state) that they have been "lost".

I even took the extreme step of changing the ownership of the directory ~/.gconf/apps/metacity/workspace_names and the file %gconf.xml to root after the names had been correctly set [1].  Metacity would *still* not pick them up (or retain them for long) upon login (as a non-root user), though it would retain them during the session if they were reset.

1. In theory metacity shouldn't be able to modify the configured workspace names or should issue some kind of error if it doesn't like the file ownership.
Comment 8 Robert Bradbury 2009-08-04 17:13:37 UTC
See also related problems with Bug #280340 which make diagnosing this problem somewhat difficult.

This may need to be bumped up to Gnome Bugs.  If so, please add the Gnome Bug Reference here.
Comment 9 Gilles Dartiguelongue gentoo-dev 2009-08-04 23:08:29 UTC
you've still not answered my question on bug #280329. How do you start gnome ?

You seem to be the only one on bugzilla or forums with these kind of problems and it's difficult to tell what's to blame as there seem to be great confusion yet little useful information.
Comment 10 Pacho Ramos gentoo-dev 2010-06-13 17:57:01 UTC
(In reply to comment #9)
> you've still not answered my question on bug #280329. How do you start gnome ?
> 
> You seem to be the only one on bugzilla or forums with these kind of problems
> and it's difficult to tell what's to blame as there seem to be great confusion
> yet little useful information.
> 

Closing as NEEDINFO

Also please check on a new created user account with upcoming Gnome 2.30, that should appear in the tree in some hours
Comment 11 Gilles Dartiguelongue gentoo-dev 2010-10-18 09:33:08 UTC
Thanks for taking the time to report this bug, however, since it has not been updated to provide the request information, we cannot help in resolving your issue.