From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Description of problem: Installed FC3 with just xorg-X11 and XFCE as the window manager. Not sure which package actually handles this is it the XFCE package's responsibility? On the default login screen, when you log in you get TWM by default! Even though XFCE is installed. You can use the switchdesk or switchdesk-gui to change to XFCE. Although by default switchdesk-gui is not installed, just switchdesk. XFCE is one of the 3 Window Mangers presented on the installer in FC3. When I install that from that menu it should be the default window manager if you don't have Gnome or KDE installed. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Install FC3 with only xorg-X11 and XFCE. Actual Results: When you log in the graphical login, you get TWM as your window manager. Expected Results: You should get XFCE as your default window manager if KDE and Gnome are not installed and XFCE is. Additional info:
This is because of the code in Xclients.
This sounds related to bug #139285
xfce should drop in files to work with switchdesk et al. Xclients.xfce or whatever switchdesk uses currently. I'm considering making a generic solution to xinitrc that is not switchdesk specific, which any wm rpm can drop in say Xclients.$wm into a foo.d dir and have it work. Ultimately tho, each wm package needs to drop in files to just work, or we edit xinitrc for the next 200 years to handle all new wm's, etc.
Ok, I've reviewed this issue, and I have a proposed solution for the problem, but I'd like to hear some feedback from others before I go ahead and commit the changes to xinitrc in rawhide. Currently, Xsession hard codes some stuff for KDE, GNOME, twm and the like, which ultimately should be removed and replaced with generic functionality, and then have the gnome, KDE, Xorg rpm packages provide dropin files to have their appropriate environment start up. Here is some of the existing code in Xsession: case $# in 1) if [ -x "$SWITCHDESKPATH/Xclients.$1" ]; then exec -l $SHELL -c "$SWITCHDESKPATH/Xclients.$1"; fi; case "$1" in failsafe) exec -l $SHELL -c "xterm -geometry 80x24-0-0" ;; gnome) exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH gnome-session" ;; kde|kde1|kde2) exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH $SWITCHDESKPATH/Xclients.kde" ;; twm) # fall back to twm exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH $SWITCHDESKPATH/Xclients.twm" ;; *) # GDM provies either a command line as the first argument or # provides 'failsafe', 'default' or 'custom'. KDM will do the # same at some point if [ "$1" != "default" -a "$1" != "custom" ]; then exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH $1" fi ;; esac esac What I'm thinking of doing, is the following: --- Xsession.orig 2005-03-22 06:05:12.000000000 -0500 +++ Xsession 2005-03-22 06:18:14.000000000 -0500 @@ -34,6 +34,11 @@ # Xsession and xinitrc scripts which has been factored out to avoid duplication . /etc/X11/xinit/xinitrc-common +# +XSESSION_D=/etc/X11/xinit/Xsession.d +if [ -d "$XSESSION_D" -a "$#" -eq 1 -a -x "$XSESSION_D/Xsession.$1"]; then + exec -l $SHELL -c "$XSESSION_D/Xsession.$1" +else # now, we see if xdm/gdm/kdm has asked for a specific environment case $# in 1) @@ -65,6 +70,7 @@ ;; esac esac +fi With this change, Xsession would now prefer first and foremost a script of the name /etc/X11/xinit/Xsession.d/Xsession.$windowmanager or whatever. If a window manager package has dropped such script into this directory, then things will "just work" magically. Otherwise, Xsession will fall back to previously existing switchdesk and failsafe methods. Over time, as more and more window manager packages convert to the Xsession.d mechanism, we can eventually remove the hard coded stuff. Feedback appreciated. If people think this sounds like a good solution, then I'll commit it, and then do some whitespace and other code cleanups to the result, and build a new rpm in rawhide.
In addition to the above patch, ssh-agent and dbus support needs to be added to the exec line I added, so they both continue to work properly with the new framework.
XSESSION_D=/etc/X11/xinit/Xsession.d if [ -d "$XSESSION_D" -a "$#" -eq 1 -a -x "$XSESSION_D/Xsession.$1"]; then exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH $XSESSION_D/Xsession.$1" else
This patch theoretically solves bug #112478 as well, and probably a great many others that are open and previously closed too. The more feedback we can get about this the better. Thanks in advance!
See also bug #122941 which contains a patch similar to yours.
And see bug #144554 too.
Bug #144554 is an enhancement, but not 100% related to solving the switchdesk related problems. I would prefer to treat that issue separately. It's not currently an FC4Target bug BTW.
This should use the desktop infrastructure used by the display managers, as opposed to a separate infrastructure.
Bill, can you expand upon your last comment a bit? I don't quite follow what you're suggesting. TIA
Desktops, such as KDE, gnome, XFCE, are supported in the display managers by dropping a desktop file (and perhaps some other) metadata in a specific directory. It would make sense for xinitrc to use the same framework, rather than having a duplicate framework for the same info. CC'ing GDM maintainer.
Hi, the desktop files are stored in /usr/share/xsessions I believe. The relevent line in each desktop file is the line that starts with Exec= in the [Desktop Entry] group.
I've investigated the .desktop file stuff, and believe it does not seem to be the best solution to use for this problem. It is more complicated than what I propose above IMHO. It's easier for a given window manager to drop in a simple one liner shell script or even a symlink into the Xclients.d directory, or even a more complex script if desired. This is much more flexible, and is just standard shell scripting. It avoids writing a .desktop file parser, and it also works both with startx initiated X sessions, and xdm/gdm/kdm initiated sessions. Note that xdm doesn't grok .desktop files either. ;) I'll be applying a patch to the next xinitrc release to implement the Xclients.d solution, and will add a comment here once it's built and ready for testing, etc. Thanks for all the great suggestions, and references to other bugs everyone, it was quite helpful to determine a solution.
I've implemented a generic Xclients.d solution for this problem, and various similar bugs reported in bugzilla. It will be present in xinitrc-4.0.16-1 and later in rawhide. It will allow window managers to drop in scripts for themselves, without any dependancy on switchdesk. Once I can confirm there is no more need for switchdesk, I'll remove the Requires: from the spec file also. Please test and provide feedback. Setting status to RAWHIDE.
I am trying to launch matchbox-window-manager (alien rpm) from /usr/bin/startx and found out about your new Xclients.d facility. Looking around a bit I can't seem to find a way to get this facility working with startx. The default /etc/X11/xinit/Xclients script does not source /etc/X11/xinit/Xclients.d/Xclients.mb.sh like /etc/X11/xinit/Xsession does. could you please advise? Thanks and regards.
I'm on F9 RC or so and am looking to see what wms I should see on my login menu, and came across this. [summer@potoroo ~]$ ls -l /etc/X11/xinit/Xclients.d total 4 -rwxr-xr-x 1 root root 205 2008-02-22 11:30 Xclients.wmx.sh [summer@potoroo ~]$ I have gnome, kde, fluxbox, openbox (and friends), fvwm, ratpoison, xfce4 and likely some others installed. Mike's not keen on parsing the .desktop files, but perhaps it could be done at postinstall/preuninstall time, to create the files Mike's using? Seems to me that the same script might serve all comers, with one or two arguments, and _not_ require changes to upstream packages.
I'm trying to understand how *users* get to choose their own Xclients and window manager with this new scheme. Shouldn't if [ -x "$HOME/.xsession" ]; then exec -l $SHELL -c "$SSH_AGENT $HOME/.xsession" fi be *first*, not the failsafe option?
For the record, the scheme mentioned isn't new, it's legacy at this point. desktop files in /usr/share/xsessions are the way to go.
> For the record, the scheme mentioned isn't new, it's legacy at this point. desktop files in /usr/share/xsessions are the way to go. Was that supposed to be an answer to my question? Until I installed F9, a user could control his/her own desktop using $HOME/.xsession. That no longer seems to be the case; that's why I called the "desktop files" scheme new. I'm not saying that "desktop files" aren't the way to go; I just want to know how to configure an F9 system so the user rather than the admin decides what goes on the user's desktop. Are we so far into Windows/Mac emulation that users can't make such decisions? Why is there no xsession.desktop file provided by default?
Hi, ah, I understand what you're saying now. I didn't realize you were using F9. The solution is to install the xorg-x11-xinit-session package. See the release notes for details.
Thanks. I did finally find it at the end of the section on the GNOME display manager. For the record, here are all "the details": ~/.Xclients and ~/.xsession are no longer read automatically at login time. If you use either of these files, install the xorg-x11-xinit-session package. Perhaps there should be a special section of the release notes for legacy people :+)
*** Bug 254068 has been marked as a duplicate of this bug. ***
*** Bug 447910 has been marked as a duplicate of this bug. ***
Wow! I just installed Fedora 9, and suddenly my .xsession, which has been working since I started using xdm rougly 16 years ago (!), stopped working. I see in this bug (which is, by the way, an unrelated bug from 4 years ago), in comment 25, the solution. But really, give me a break - why do we need this bizarre solution anyway??? Where's the logic of ignoring people's .xsession when they explicitly put that file in? After all, it's not like someone will accidentally create this file? I think this is an major error in judgement from Fedora, and one that needs to be reversed. No amount of documentation in the release notes (which I obviously missed...) can "explain" this bug away. There's simply no reason to have this bug, and it can be easily fixed (just do what that new package does - always).
The file '/etc/X11/xinit/Xsession' still references this bug; See [http://www.spinics.net/lists/fedora-devel/msg192614.html Fedora Mailing list] for an up-to-date explanation on the ongoing developments and plans.