GNOME Bugzilla – Bug 74904
WSA displays 4 workspaces regardless of the number of workspaces specified in the properties dialog
Last modified: 2009-08-16 15:13:28 UTC
WSA displays 4 workspaces regardless of the number of workspaces specified in the properties dialog.
Weird. This used to work for me, but definitely does not now. Dave, can you please search for a duplicate on this one? I definitely think that this is a duplicate but if possible I'd like to spend my time elsewhere today :) Thanks...
with sawfish version 2.0.pre1(1.22) 1)Alt <Fx> keys do not create or switch between workspaces. 2)Changing workspace name from properties not reflected. I remember seeing them work with previous versions, but can't find the version number. Changing the workspace names and incrementing or decrementing the number of workspaces in the properties dialog are reflected in .gconf/desktop/gnome/applications/window_manager/%gconf.xml I am not very sure if the problem reported in the bug is also related with the sawfish problems. Mark has already noted bug 75272 is due to sawfish. Apart from these there could be few issues regarding decrementing the number of workspaces from the properties dialog a)if user decrements, which workspace should be deleted b)and what happens to the applications in that workspace c)if user want to delete the third workspace but has five how does he delete it.
Okay, so here's the way it works ... The pager changes /desktop/gnome/applications/window_manager/number_of_workspaces gnome-settings daemon responds by by changing the _NET_NUMBER_OF_DESKTOPS property sawfish is free (according to the spec) to honour or reject this ... At the moment it seems to be rejecting it ... jsh: is that correct?
From the source code: ((_NET_NUMBER_OF_DESKTOPS _NET_DESKTOP_GEOMETRY) ;; XXX these conflict with user preferences ) so yes, that's right. The problem is that these settings are stored in the user configuration, and so imho should only be changed by the user. Sawfish has no way of verifying that the user really did want those things changed (i.e. it's not just some fucking annoying application trying to add workspaces) It seems inherently broken to me that this setting is stored in two places now. I don't know what to do..
cc'ing mark again so that maybe he can provide a coherent response to that last question; I can't. :/
I replied here http://lists.eazel.com/pipermail/sawfish/2002-April/002908.html
Mark's response: My response would be that, sure, this is a wm user preference, just like the desktop name scould be, but why not use the _NET_NUMBER_OF_DESKTOPS message be another way of allowing the use to change this preference as opposed to another place that this preference is stored. So below[1] is a patch that I did before reading the response ... may I commit ? -- I need to think about this. Intuitively I feel this is wrong, but I'm not sure if I'm not just being puritanical..
some random comments: - the patch doesn't correctly implement _NET_NUMBER_OF_DESKTOPS (changing workspace-geometry doesn't actually add or remove any workspaces, all it does is possibly alter the number of extra empty workspaces sawfish tells the pager about) - I still don't like the idea of there being a way for (possibly external) clients to be able to cause sawfish to write to the disk by sending properties to the root window - I still don't think this should be stored by both the panel and the wm (e.g. it's an obvious source of race conditions if one is ever run without the other) One option I guess may work is for sawfish to accept this message, but not store it anywhere, just use it to affect how it sets the _NET_NUMBER_OF_DESKTOPS property in the future.. or perhaps even get rid of the workspaces part of sawfish's workspace-geometry variable..
*** Bug 73281 has been marked as a duplicate of this bug. ***
John there are millions of things a malicious client could do, e.g. XGrabServer()... how is this one different? Mark, if we can't get the Sawfish patch in we can just have xsettings daemon propagate the setting over to sawfish config files. (Or have it run sawfish-client or whatever is correct.) xsettings daemon is basically where all the propagate-gconf-to-other-things hacks live.
Oh man, you would really start writing into ~/.sawfish/custom? I really hope you're kidding.. that's a recipe for disaster.. the thing that makes this different is that it writes to my disk but I think my main objection was that the preference would be stored in two places.. changes that I recently made to sawfish may go some way to removing that problem (the default number of workspaces now comes from the number of workspace names you give, not from a variable), so I think this client message could just affect the number of workspaces that sawfish shows you in the pager or something. i.e. it wouldn't cause any persisten configuration changes or writes to disk
fixed on HEAD
Thanks John, thats great :-)
Tested. It's works fine. Can we close this bug ?