GNOME Bugzilla – Bug 109640
Move ownership of the desktop layout from the pager to the WM ?
Last modified: 2020-11-06 20:23:02 UTC
Working with the gnome-panel workspace switcher is proving very frustrating for me. Every time I load it up, it reverts to one row of workspaces, even though I repeatedly configure it to have 2. It appears that the 'set' call is getting to the gconfd-2 process, and from thence to the filesystem (via whatever other stuff) and it being set properly. However, if I quit and reload the applet, it reverts to one row. (This applies to log out/in also) It seems that it is being given a different UID for use in the /apps/panel/profiles/default/applets/.... namespace every time it is run. This seems rather wrong. I did my best to trace it, but got lost as the source of this key passed into Bonobo (I don't yet understand bonobo enough to trace it further) Hopefully this is enough information for you to reproduce this. If there's anything I can get for you, strace's ltrace's etc, let me know
Umm, it's version 2.2.1 of the panel (Debian package 2.2.1-1) (if that helps at all)
Ouch, does this happen for all applets ? e.g. if you change some preferences for the clock applet and log out and back in again are you reverted back to the defaults ?
The clock manages to retain settings across a login/logout, but if I remove the clock from the panel and re-add it, it loses its settings.
I'm just writing this comment to note that version 2.2.2-1 didn't fix the issue, and it is really quite an urgent issue because I can't expect to log into my machine and be able to use it without lots of fiddling first.
I could not simulate this problem. Just re-stating the steps so that i just got the problem right :) a) add workspace switcher to the panel. b) set the num of rows to 2 c) logout and login d) the num of rows of the switcher is 1 Is this right ?
Well, perhaps simpler.. 1) open workspace switcher panel applet 2) preferences 3) set rows to 2 4) close preferences 5) quit switcher applet 6) open workspace switcher applet **Now you'll be back to one row** If it makes a difference, I have 10 workspaces, and they've all got names.
Applets are per instance configurable. ie when multiple instances of the same applet exist, each of them can be configured differently. In the case of workspace switcher,the preferences can be classified as a) configure the number of workspaces and the names of the desktop. This data is not specific per instance. They are per display b) configure the applet itself.ie how you would want your applet to appear on the panel. The number of rows,show only current workspace,show workspace names are per instance.
*** Bug 110534 has been marked as a duplicate of this bug. ***
a typo above. s/names of desktop/names of workspaces
Well that's a bug in the classification of the row-count information as a per-instance configurable then. It is plainly a global configuration option because it affects the navigation around my workspaces. I have two rows of five workspaces. The top row labelled "email,irc,web,editor,misc" and the lower row labelled "below email, below irc......" This plainly makes no sense if the workspaces end up in a long line rather than as two rows. Now if that configuration goes away if I open the workspace switcher applet again (or for that matter log out/back-in) then it's plainly losing configuration which shouldn't be lost. What happens to how my desktop navigation works, if I have two instances of the switcher open with different row counts in each?
> Now if that configuration goes away if I open the workspace switcher > applet again (or for that matter log out/back-in) Daniel: I understand your problem. But your are confusing things here a bit :) Does your workspace applet change settings after login and logout ? If you meant, "I add the applet, change prefs,remove the applet, logout, login, add the applet again,my prefs are gone", well, it's the same thing as removing the applet and adding it back again without logging out. However, on logging out if you had the applet on the panel with your preferences and then on logging in you see that the applet prefs are changed for that instance, that's a bug. Calum,Seth,Mark: "setting row count global", your thoughts ?
I've just tested it, and it seems that if I leave a switcher on the panel and log out/in then it retains the two-rows setting. Sorry for muddying the waters with that. As a comment, having 'global row count' means that that value does need to be applied on login (however you do that) so that as I navigate workspaces with the keyboard I get the rows as I want.
Daniel: thanks for clarifying. Closing
Arvind: I feel that closing with 'Not a bug' is kinda premature. We need to actually clarify the issue here. When I configure a workspace switcher applet to have two rows, it signals to the windowmanager so that ctrl+alt+arrows move me around two rows of desktops. When I quit the applet, it doesn't reconfigure the window manager to have only one row of desktops (as it was before the applet was loaded) If I log out/log in, then I only have one row of desktops (unless I have a 2-row applet installed on my panel wasting space all the time) I have a laptop, my laptop has limited screen real-estate -- I cannot waste the room on the panel needed for a switcher applet because of my reduced screen resolution and the fact that I can't get the menu panel to auto-hide. Also, consider the following scenario: You have one workspace switcher open, you configure it to be two rows, your window manager agrees. Then you open another switcher applet, which configures itself (by default to one row) -- now what should your window manager do? Obey the two-row configuration of the first applet, or the one-row of the second? Given this, it seems quite plain that any configuration item which so blatantly affects things outside of the applet instance's scope should be shared between all instances, and more importantly, should be something which gets remembered by everything affected by it. If this is actually a bug that metacity isn't remembering how many desktops it was configured to have, then reassign the bug over to metacity, but don't just close it please.
Daniel: okay, let me summarize what's left here, do correct if they are off target. a) row details are not remembered on adding a new instance.(ie if it was changed by the user previously for another instance) b) when there are 2 pagers with different row combinations, metacity respects the row combination of the former while navigating workspaces through keyboard.(atleast that's what I see on my desktop) For (b) please file a bug against metacity. Havoc will surely let you know his views. For (a), honestly, I don't have an opinion at the moment. Updating the summary to reflect the scope of this bug and reducing the priority.
I'm reducing the severity. There is an obvious work-around. For me this comes down to the problem that as is currently designed, the workspace layout is defined by the current pager configuration rather than making the workspace layout configuration a global setting and making the pager display the workspace layout according to the _NET_DESKTOP_LAYOUT hint which would be Metacity. Its the only thing that makes sense to me. Havoc, what do you think ?
This is a window manager spec issue. Right now the layout comes from the pager, as the pager is the only thing that cares (the layout is purely a visual thing). My take on this bug is that it will be fixed when we close that other bug about taking the values for new applet instances from the last applet instance. i.e. add/remove of an applet should not lose the applet prefs. I seem to remember a bug about that.
Yeah, I'd imagine fixing the generic applet defaults bug would lessen the effect of this bug but ... I don't understand why you think its "purely a visual thing". If I have a 2x2 grid of workspaces, switching between them without using the pager is completely different depending on the layout. i.e. the pager isn't the only place which cares about the layout - the window manager cares too for switching with the keyboard ...
Yeah, that's true. I don't remember the wm-spec-list conversation in any detail. In any case, it's fairly hard to change at this point.
Just because it's hard to change, doesn't mean we shouldn't. If there's no chance of this being done before 2.4, then it *MUST* be scheduled for 2.5/2.6 -- this is a severe design issue and it's wrong to leave it uncorrected.
There's no scheduling, this is an open source project. Things happen when they reach the top of the personal priority queue of an individual contributor. If you want to be sure it happens, become an individual contributor and put this at the top of your queue. ;-)
Okay, so what we could do is move the "num_rows" key to metacity and make the WM the owner of the selection. Then make the pager not display or change the preference if it doesn't own the selection. And finally, make sure the pager works okay even when it doesn't own the selection (i.e. it shows the layout from the property). I think the only issue we'll have is how to migrate the preference - but you could just release note it.
yeah, a release-note would do. People would more than likely go "Oh, it forgot my preferences again, how irritating" then set it, and never have to worry again.
*** Bug 111463 has been marked as a duplicate of this bug. ***
*** Bug 123217 has been marked as a duplicate of this bug. ***
Mass changing: milestone 2.12.x => milestone 2.14.x
*** Bug 386306 has been marked as a duplicate of this bug. ***
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.