After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 168633 - Encourages violation of the Session Management Protocol
Encourages violation of the Session Management Protocol
Status: RESOLVED DUPLICATE of bug 424949
Product: libgnome
Classification: Deprecated
Component: general
2.8.x
Other All
: Normal normal
: future
Assigned To: libgnome maintainer
libgnome maintainer
Depends on:
Blocks:
 
 
Reported: 2005-02-27 03:56 UTC by Daniel Burrows
Modified: 2007-05-05 14:51 UTC
See Also:
GNOME target: ---
GNOME version: 2.7/2.8



Description Daniel Burrows 2005-02-27 03:56:23 UTC
Please describe the problem:
Apparently, the X Session Management Protocol requires that the "Program"
property of a client point at the client's executable:

Program

The name of the program that is running. On POSIX systems this should be the
first parameter passed to execve and should be of type ARRAY8.


Here's what seems to be happening: libgnomeui, or maybe libgnome (I'm not quite
sure) sets the Program attribute to what was passed as "app-id" to gnome.init
(or the equivalent in your favorite language).  However, the Gnome documentation
recommends setting "app-id" to the "name" of the program.  If the program
happens to be run from $PATH and the "name" happens to be the same as the
executable filename, then everything is OK, but if it's run from a non-$PATH
directory, the result is likely to be bad.  In the case that got me looking into
this, the program failed to restore (and in fact crashed xsm, but that's a bug
in xsm).


I don't know what else app_id is used for, so I don't know what the proper fix
is.  I would guess that probably the appropriate thing to do is to decouple it
from the Program session management property (ie, always set Program to
argv[0]), but presumably you folks know better than I.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Elijah Newren 2005-02-27 04:23:56 UTC
I believe libgnome is more likely to be right; especially after a couple quick
greps, so I'm going to refile there.
Comment 2 Kjartan Maraas 2005-02-28 14:05:03 UTC
Looks like gnome_program_init() should be called with g_get_prgname() as the
first argument in all cases? Then we wouldn't have any problems if the binary is
renamed etc? I checked a few cases and it's clear that many of the programs
calling gnome_program_init() are not using the name of the executable as the
first arg to that function...
Comment 3 Christian Persch 2006-04-02 18:49:22 UTC
The first arg of gnome_program_init() should be the app identifier, not the name of the executable, because it's used to locate files (e.g. help files).
Comment 4 Kjartan Maraas 2006-10-23 11:02:59 UTC
Christian, is there a bug here then? Are we doing things differently from what the session management spec says?
Comment 5 Christian Persch 2007-01-12 12:23:49 UTC
I haven't read the session mgmt spec, so I can't comment on that. See bug 82943 comment 5 for what the APPID is used for; changing what's passed in as APPID to gnome_program_init is not an option because that will cause loss of user configuration.
Comment 6 Dan Winship 2007-05-05 14:51:39 UTC
Already fixed, on trunk and gnome-2-18:

2007-04-01  Matthias Clasen  <mclasen@redhat.com>

        * libgnome/gnome-program.c (gnome_program_preinit): Set
        the program name to the basename of argv[0]. This is
        expected by other parts of the stack, and e.g. makes bug-buddy
        work for applets again.  (#424949)


*** This bug has been marked as a duplicate of 424949 ***