GNOME Bugzilla – Bug 555406
Removal of --choose-session argument breaks other window managers
Last modified: 2012-06-04 22:44:35 UTC
Openbox has GNOME integration, which depends on the --choose-session argument to gnome-session to function. During the 2.23 development cycle, that argument was removed. It appears to have been replaced with a --default-session-key argument, but that requires the other window manager to actually utilize gconf, which many alternatives do not. Openbox's session starts using this command: exec gnome-session --choose-session=openbox-session "$@" I am sure other alternative window managers depend on such functionality, so I see this as a regression with no path forward. I have also filed a report with openbox, you can see that here: http://bugzilla.icculus.org/show_bug.cgi?id=3788
What exactly gets run when using "openbox with gnome integration"? Is it "everything in a normal GNOME session, except with openbox instead of metacity"? Without knowing the details of what you're trying to do, it's hard to suggest a solution to the problem. And why can't you use gconf? This wouldn't require the openbox core to be making gconf calls, it would just require the openbox-gnome-integration piece to install a gconf schema at install time to define a new session key. And if you don't want to do that because you want to ship everything in a single package, you could still cheat and just have the openbox-gnome-session script use gconftool-2 to poke some values into gconf to create the alternative session immediately before it execs gnome-session. At any rate, complaining that gnome-session does not cater to the needs of people who don't want to use GNOME seems a little silly, doesn't it? :-) You also might be able to do what you want by using the --autostart option, to create an alternative set of autostart directories to load things from. (You can pass --autostart multiple times to add multiple directories.) So you'd create a directory with .desktop files for the things you want to launch, and then point gnome-session at that. It looks like doing this also disables the gconf stuff altogether, so you wouldn't get any of the GNOME default apps, unless there were launchers for them in the autostart directories you were using.
I don't actually use openbox, just relaying an issue from a user (i am a distributor). I initially filed it with openbox, but they refuse to change how they implemented it. I just don't know how many other openboxes there are out there, that depend on such functionality. From what I can tell, openbox-gnome launches a full gnome session with openbox as the window manager. But I really know very little about openbox.
Openbox has its own xsession desktop file that shows up in GDM labeled GNOME/Openbox for logging in to a GNOME session using Openbox instead of Metacity (There is also a similar option for KDE). With 2.24.0, gnome-session no longer respects the WINDOW_MANAGER environment variable, preventing openbox's previous method of hooking into gnome-session. Now, the only way to get gnome-session to launch openbox instead of metacity is to modify the /desktop/gnome/session/required_components/windowmanager key, which is a rather all-or-nothing approach that prevents the GNOME and GNOME/Openbox sessions from launching two different window managers. In addition, the remainder of the required_components list is highly wm-specific. I keep /apps/nautilus/preferences/show_desktop set to false, so the filemanager required_component pops up a Nautilus window on each login, and other openbox users may prefer pypanel or lxpanel when using Openbox but gnome-panel in pure gnome mode. If gnome-session had a --with-session-root parameter that it used to derive the paths to sessions and the required components these issues could be alleviated; i.e: gnome-session --with-session-root /desktop/openbox/session --default-session-key foobar would use /desktop/openbox/session/foobar for the session information, get the list of required components from /desktop/openbox/session/required_components_list and /desktop/openbox/session/required_components/*
downstream report: https://bugzilla.redhat.com/show_bug.cgi?id=474143
I think this is doable with the current infrastructure. Here's a comment I posted on the downstream report mentioned in comment 4: --8<-- I think the way this works (Jon correct me if I'm wrong) is: 1) openbox should put in the desktop file X-GNOME-Provides=windowmanager This tells gnome-session that it satisfies the "windowmanager" component requirement. 2) invoke gnome-session with different default-session using the --default-session-key argument. This is the list of things to start automatically and is normally just [gnome-settings-daemon]. This list doesn't normally include the required components (windowmanager, filemanager, and panel), since defaults for these are implicitly added if an override isn't explicitly given. In your case you want to override windowmanager, so you would add your desktop file to this list. Since it now has X-GNOME-Provides=windowmanager, it will satisify the "windowmanager" requirement and the default windowmanager won't get implicitly started. -->8-- (untested though)
I just noticed I closed this bug INCOMPLETE when posting the last comment. Didn't mean to do that. It might make sense to close it NOTGNOME though.
What if openbox's desktop file was referenced in the required_components list instead of the session? (what's the difference between the session components and "required" components?) Is there documentation about how a component (panel, windowmanager, or desktop) gets involved in the equation? My feeling is this is more of an API/documentation problem. --choose-session was the way things worked before, but I haven't seen an obvious documented alternative. The openbox documentation at http://openbox.org/wiki/Help:GNOME/Openbox hasn't figured out the "right" way to do this. Ubuntu's bug for this is open https://bugs.launchpad.net/ubuntu/+source/openbox/+bug/272418 since they can't figure it out. Some kind of documentation of a method to get "into the club" without getting kicked out in the next gnome release would be very helpful.
Openbox deals with this properly in version 3.4.9 in a manner similar to comment #5. There isn't any need to mess with any files. The 'required_components_list' key tells gnome-session what types of programs must be loaded for every session. The entry in '/desktop/gnome/session/required_components/windowmanager' tells what window manager to load by default if no other window manager is specified in the session list. With an openbox.desktop containing "X-GNOME-Provides=windowmanager", openbox-gnome-session creates a 'openbox_session' key which includes 'openbox' in the session list, and everything just works. openbox 3.4.9 also respects the DESKTOP_AUTOSTART_ID environment variable, which allows Openbox to signal to gnome-session when it is started, informing it when it is safe to launch the other programs in the session. Just upgrade to openbox 3.4.9 or 3.4.10 and things should work automatically.