Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 185114 - Trying to start multiple xterm's from session-propeties "startup programs" results in only one
Summary: Trying to start multiple xterm's from session-propeties "startup programs" re...
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-session
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
Depends On:
Blocks: FC7Target FC6Update
TreeView+ depends on / blocked
Reported: 2006-03-10 19:03 UTC by Hans de Goede
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-07-27 08:14:26 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
GNOME Bugzilla 341286 None None None Never

Description Hans de Goede 2006-03-10 19:03:31 UTC
I want my session to start with 3 xterm's thus I've had 3 xterm's in the
"startup programs" tab of gnome-session-properties for ages and this has always

With the current rawhide gnome 2 of the 3 xterms used to disappear from the tab
and I couldn't get them to stay.

I'm happy to report that with the latest rawhide update I can get 3 xterm
commands (each with a different -geo argument) in the "startup programs" tab.
But for some reason gnome-session still only starts one.

Comment 1 Olivier Baudron 2006-03-30 11:55:21 UTC
Same problem here. Looking in the source, I found that:
This is not a bug but a feature (TM).

A patch against FC5 (gnome-session-2.14.0-1) follows:

--- gnome-session-2.14.0/gnome-session/save.c 2006-03-28 20:20:44 +0200
+++ gnome-session-2.14.0/gnome-session/save.c 2006-03-30 13:41:21 +0200
@@ -788,7 +788,8 @@
   if (list)
     session->client_list = g_slist_concat (session->client_list, list);
-  session->client_list = remove_duplicated_clients (session->client_list);
+  /* Allow same program to be started multiple times (xterm, ...) */
+  /* session->client_list = remove_duplicated_clients (session->client_list); */
   return session;

Comment 2 Hans de Goede 2006-03-30 12:01:10 UTC
Well I concider this a bug, if this duplicated clients check should be done at
all it should be done while adding clients to the list, now a user who wants
duplicate entries in the start list can create them but they won't work. That is
a bug and notting else!

Also in my case the clients are not duplicate, they all have different args,
which makes them very much not duplicate. So even if a duplicate check was done
when adding entries to the list (if there are duplicate entries in the list they
should be honored, principal of least surprise) this check should not be
triggered in my case, so thats bug 2.

Last if a check on add was added it should warn and ask the user, not plain
disallow, so make that bug 3.

Comment 3 Karl Czajkowski 2007-05-01 07:56:47 UTC
Yes, I also think it is a bug. I first encountered this in FC5 or FC6 and just
confirmed that it still exists in FC7test4.  The fact that XFCE handles this
properly in its session save is the reason I refuse to use GNOME on Fedora,
except as an initial test after installing a new Fedora release.

I must have my dozens of xterms open automatically in my virtual desktops, as it
has always done for nearly a decade with every session manager.  The idea that
you can only have one instance of an application is a perverse limitation of
certain apps and not something to be forced on the X session as a whole!

Comment 4 Hans de Goede 2007-05-01 09:52:32 UTC

I think it would be best to take this bug upstream, could you do the honors? And
could you also add me to the CC please (same email as for RH).

Comment 5 Karl Czajkowski 2007-05-01 10:22:03 UTC
Sure. I have entered this in the GNOME bugzilla as bug 434842.

Comment 6 Hans de Goede 2007-05-01 10:43:39 UTC
Thanks, I've just added that bug as external reference, and I'm closing this one
as being handled upstream.

Comment 7 Hans de Goede 2007-05-11 13:18:31 UTC
Changing ext reference, because the bug it points to now has been marked as a

Comment 8 Hans de Goede 2007-05-11 18:23:02 UTC

Upstream's bug already contained a detailed comment how this could be fixed, it
just needed the fix to be written. So I've written a patch for this, which has
just been accepted, for the patch see:

Ray, I wouldn't mind if you put this in the next scheduled update :)

Comment 9 Hans de Goede 2007-07-27 08:14:26 UTC
My patch has found its way into rawhide through upstream, closing.

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