Bug 142260 - XFCE not the default desktop without KDE/Gnome
XFCE not the default desktop without KDE/Gnome
Product: Fedora
Classification: Fedora
Component: xinitrc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Bill Nottingham
: Reopened, Triaged
: 254068 447910 (view as bug list)
Depends On:
Blocks: FC4Target 139285 478821
  Show dependency treegraph
Reported: 2004-12-08 11:52 EST by Michael Best
Modified: 2018-04-11 04:32 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-30 06:26:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael Best 2004-12-08 11:52:05 EST
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):

How reproducible:

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:
Comment 2 Bill Nottingham 2004-12-08 13:08:27 EST
This is because of the code in Xclients.
Comment 3 Sitsofe Wheeler 2004-12-10 05:05:37 EST
This sounds related to bug #139285
Comment 4 Mike A. Harris 2004-12-22 23:57:00 EST
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.

Comment 6 Mike A. Harris 2005-03-22 06:21:44 EST
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
 . /etc/X11/xinit/xinitrc-common

+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.
Comment 7 Mike A. Harris 2005-03-22 06:45:16 EST
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.
Comment 8 Mike A. Harris 2005-03-22 06:46:33 EST
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"
Comment 9 Mike A. Harris 2005-03-22 07:18:56 EST
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!
Comment 10 Rex Dieter 2005-03-22 08:18:20 EST
See also bug #122941 which contains a patch similar to yours.
Comment 11 Colin Walters 2005-03-22 08:50:13 EST
And see bug #144554 too.
Comment 12 Mike A. Harris 2005-03-22 10:03:50 EST
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.
Comment 13 Bill Nottingham 2005-03-22 23:16:40 EST
This should use the desktop infrastructure used by the display managers, as
opposed to a separate infrastructure.
Comment 14 Mike A. Harris 2005-03-23 04:54:51 EST
Bill, can you expand upon your last comment a bit?  I don't quite
follow what you're suggesting.

Comment 15 Bill Nottingham 2005-03-23 12:12:37 EST
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.
Comment 16 Ray Strode [halfline] 2005-03-24 14:27:11 EST
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.
Comment 17 Mike A. Harris 2005-04-05 07:52:23 EDT
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.

Comment 18 Mike A. Harris 2005-04-05 09:04:27 EDT
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.
Comment 19 Eric Moret 2006-08-28 14:11:00 EDT
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.
Comment 20 John Summerfield 2008-05-12 08:01:15 EDT
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.
Comment 21 Bob T. 2008-05-15 11:55:31 EDT
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?  
Comment 22 Ray Strode [halfline] 2008-05-15 13:59:48 EDT
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.
Comment 23 Bob T. 2008-05-15 14:28:32 EDT
> 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?
Comment 24 Ray Strode [halfline] 2008-05-15 15:57:47 EDT

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.
Comment 25 Bob T. 2008-05-15 16:56:09 EDT
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 :+)
Comment 26 Matěj Cepl 2008-05-16 10:52:50 EDT
*** Bug 254068 has been marked as a duplicate of this bug. ***
Comment 27 Ray Strode [halfline] 2008-05-22 13:31:32 EDT
*** Bug 447910 has been marked as a duplicate of this bug. ***
Comment 28 Nadav Har'El 2008-08-05 16:47:07 EDT
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).
Comment 29 ILMostro 2014-01-22 23:18:54 EST
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.

Note You need to log in before you can comment on or make changes to this bug.