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.
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 ?
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
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.
you missed gconf.
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.
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".
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.
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.
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.
(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
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.
