Red Hat Bugzilla – Bug 142260
XFCE not the default desktop without KDE/Gnome
Last modified: 2014-03-16 22:51:06 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
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
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):
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.
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
if [ -x "$SWITCHDESKPATH/Xclients.$1" ]; then
exec -l $SHELL -c "$SWITCHDESKPATH/Xclients.$1";
case "$1" in
exec -l $SHELL -c "xterm -geometry 80x24-0-0"
exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH gnome-session"
exec -l $SHELL -c "$SSH_AGENT $DBUS_LAUNCH $SWITCHDESKPATH/Xclients.kde"
# 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"
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
+if [ -d "$XSESSION_D" -a "$#" -eq 1 -a -x "$XSESSION_D/Xsession.$1"]; then
+ exec -l $SHELL -c "$XSESSION_D/Xsession.$1"
# now, we see if xdm/gdm/kdm has asked for a specific environment
case $# in
@@ -65,6 +70,7 @@
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.
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"
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.
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.
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
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
-rwxr-xr-x 1 root root 205 2008-02-22 11:30 Xclients.wmx.sh
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"
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?
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.