Red Hat Bugzilla – Bug 444135
openbox sessions don't respect workspace configuration after GDM
Last modified: 2009-08-27 13:08:42 EDT
Description of problem:
The window manager only has one workspace titled "Workspace 1" if logged in
through GDM using the Openbox or GNOME/Openbox sessions. Openbox won't respect
the number of workspaces or their names in ~/.config/openbox/rc.xml.
Version-Release number of selected component (if applicable):
How reproducible: 100%
Steps to Reproduce:
1. Boot into run level 5 and GDM
2. Choose Openbox or GNOME/Openbox session
Actual results: One workspace titled "Workspace 1"
Expected results: Four workspaces configured with names "1", "2", "3", and "4".
Openbox and gnome-openbox-session WILL configure the workspaces as described in
~/.config/openbox/rc.xml if the user logs in from run level 3 and does 'startx'
with the appropriate session in their .xinitrc.
Running 'openbox --replace' in a terminal after logging in through GDM into an
openbox session will print the following:
(openbox:2908): Openbox-WARNING **: Openbox is configured for 4 desktops, but
the current session has 1. Overriding the Openbox configuration.
This problem probably happens because of some setting set by GDM.
These (latest) versions reproduce the problem:
This is caused by metacity started in gdm which sets the number of desktops to 1.
I'll ask upstream about forcing openbox to change it even when set before.
Didn't get a response from openbox maintainers. Let's see if removing
_NET_NUMBER_OF_DESKTOPS property in gdm is a good idea.
You could simply do xprop -root -remove _NET_NUMBER_OF_DESKTOPS in your session
script before starting openbox.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
That wouldn't work for users that have $HOME/.xsession script.
I guess it's easier to force openbox to change the property. If gdm should clean
up the property, we can remove the patch later.
The code's in screen_startup, found in openbox/screen.c.
BTW, the xprop workaround didn't fix the workspace names.
Hm, there are other properties causing troubles, like _NET_DESKTOP_NAMES and
Ignoring _NET_CURRENT_DESKTOP in wm is probably a bad idea, so I'm reassigning
this back to gdm.
Its really not the job of gdm to clean this up, imo.
If openbox has a configuration for the number of workspaces, it is its
responsibility to sync the property to its configuration at startup.
openbox-22.214.171.124-3 removes the three properties in session scripts.
This doesn't fix the problem for users with their own session script, so it
still would be nice to see this fixed in gdm. If the properties were ignored in
openbox, they wouldn't be preserved across openbox restarts and that would be
openbox-126.96.36.199-3.fc9 has been submitted as an update for Fedora 9
openbox-188.8.131.52-3.fc9, obconf-2.0.3-2.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update openbox obconf'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-5198
openbox-184.108.40.206-3.fc9, obconf-2.0.3-2.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #13)
> openbox-220.127.116.11-3.fc9, obconf-2.0.3-2.fc9 has been pushed to the Fedora 9
> stable repository. If problems still persist, please make note of it in this
> bug report.
this problem persists.
on a fc8 install, this problem does _not_ exist with basically the same configuration but with the following packages installed (latest f8 updates):
Are you executing openbox in $HOME/.xsession script? If yes, try replacing openbox with openbox-session or add the following command to the script.
xprop -root -remove _NET_NUMBER_OF_DESKTOPS -remove _NET_DESKTOP_NAMES -remove _NET_CURRENT_DESKTOP
i should have been more specific - i'm running from GDM as in the original report. i've tried with both the Gnome and Gnome/Openbox sessions from the base F9 GDM install with the same results.
i can add workspaces interactively via openbox but after i logout and back in again it reverts back to the single workspace. and yes, all session information is being saved for the restart.
as mentioned in comment #14, the same config and setup works just fine in f8.
Any chance that xorg-x11-utils package containing the xprop utility isn't installed on the system?
(In reply to comment #17)
> Any chance that xorg-x11-utils package containing the xprop utility isn't
> installed on the system?
its installed too:
Well, it's working fine here, with the same package versions as you have installed.
Can you try another user account to see if it's not caused by a gnome setting?
Also it would be interesting to see the output of "xprop -root > /tmp/xprop.out" added before the exec line in /usr/bin/openbox-gnome-session.
FYI I have submitted this upstream, based on seeing exactly the same issue with a SUSE system:
The problem persistant for fedora 10 as well
If gdm is doing something that could effect other clients later, then it is the natural responsibility for THAT PROGRAM to clean up after itself.
That is standard programming practice, and brushing it under the rug, is NOT a solution!
I think I had the same problem. I just reloaded metacity to stop anything else from interfering such as compiz with 'metacity --replace'. Then I ran 'openbox --replace' and I no longer get that error.