GNOME Bugzilla – Bug 525056
Make nautilus work nicely with gnome-session
Last modified: 2008-07-30 09:46:17 UTC
The new gnome-session requires default session modules (gnome-settings-daemon, gnome-panel, nautilus, metacity, etc) to install their desktop files in the default session directory ($datadir/gnome/default-session).
Created attachment 108250 [details] [review] This patch basically installs a new .desktop in the cited directory. This .desktop file have some additional necessary keys and runs nautilus with --no-default-window.
I'm not sure if nautilus-desktop.desktop is a good name for the new .desktop file. Feel free to suggest some other name. Maybe nautilus-session.desktop is better?
Confirming. It sounds a bit odd to install two identical files for one application, one for the SM and one for the application DB. After all, $datadir/applications is the central repository for all applications. A symlink might be better, if the specs and implementations of the session management code do allow this. I also wonder whether applications are supposed to register themselves. Maybe gnome-session should install a set of symlinks when installing? On the other hand, symlinks have the disadvantage of not offering some sort of path list. For instance, assuming one installs in /usr and /opt/foo, and wants /opt/foo/share/applications' entries to override /usr/share/applications, the symlink /usr/share/gnome/default-session cannot be updated. The same issue is valid for your proposed approach (i.e. installing the nautilus.desktop file twice). CCing gnome-session-maint to get some opinions. So maybe the session should rather be a flat text file [like ~/.gnome2/session], containing the basenames of desktop files (i.e. application names)? Reading through http://live.gnome.org/SessionManagement/NewGnomeSession suggests that we should by any means add a X-GNOME-Autostart-Phase=Desktop key to nautilus.desktop.
One last idea: Instead of a text file we can of course also use a GConf key, with a string list data type.
Hey, (In reply to comment #3) > Confirming. > > It sounds a bit odd to install two identical files for one application, one for > the SM and one for the application DB. After all, $datadir/applications is the > central repository for all applications. IIUC, to start Nautilus on the session startup, we need to run it with --no-default-window option only and I haven't seen any .desktop files with the "Exec" key matching that. Hence, the new .desktop file is not identical to the existing ones. If it's possible to just reuse some of the existing ones, great. :-) > A symlink might be better, if the specs and implementations of the session > management code do allow this. Yes, that's possible. gnome-panel and metacity are doing that. > I also wonder whether applications are supposed to register themselves. Maybe > gnome-session should install a set of symlinks when installing? In an ideal setup, gnome-session shouldn't care about specific session applications. It only cares about required apps which provides the basic functionalities (windowmanager, panel and filemanager) on certain phases. But which app provides those functionalities may vary and this shouldn't be hardcoded in any way. > On the other hand, symlinks have the disadvantage of not offering some sort of > path list. For instance, assuming one installs in /usr and /opt/foo, and wants > /opt/foo/share/applications' entries to override /usr/share/applications, the > symlink /usr/share/gnome/default-session cannot be updated. The same issue is > valid for your proposed approach (i.e. installing the nautilus.desktop file > twice). In general, .desktop files don't have full paths in the Exec key. This means that those files tend to be identical in /opt/foo/share/applications and /usr/share/applications. This means that it's all about the current PATH you have set. There are exceptions, of course. > CCing gnome-session-maint to get some opinions. Ok. > So maybe the session should rather be a flat text file [like > ~/.gnome2/session], containing the basenames of desktop files (i.e. application > names)? Hmmm, I still don't see the point of doing that. Could you elaborate? > Reading through http://live.gnome.org/SessionManagement/NewGnomeSession > suggests that we should by any means add a > > X-GNOME-Autostart-Phase=Desktop > > key to nautilus.desktop. Yes. You should add "X-GNOME-Provides=filemanager" and "X-GNOME-Autostart-Notify=true" as well.
I agree with Christian. See also bug 525157 where I suggested basically exactly the same thing. (In Lucas's defense, this was all my bad idea originally, not his :-) > In an ideal setup, gnome-session shouldn't care about specific session > applications. It only cares about required apps which provides the basic > functionalities (windowmanager, panel and filemanager) on certain phases. But > which app provides those functionalities may vary and this shouldn't be > hardcoded in any way. While I agree that ideall gnome-session wouldn't know this, as mentioned in that other bug, I think it's more ideal for gnome-session to know than it is for the apps themselves to know; Under the current plan, if we wanted to make nautilus not be the default file manager any more, we'd have to put out a new release of nautilus to have it stop installing the default-session/nautilus.desktop file... Perhaps ideally, there'd be a very very small package "gnome-default-session" that contained just the default-session information. But practically, it's probably easier to just put it in gnome-session... > > So maybe the session should rather be a flat text file [like > > ~/.gnome2/session], containing the basenames of desktop files (i.e. > > application names)? > > Hmmm, I still don't see the point of doing that. Could you elaborate? It saves us from having to worry about dangling symlinks and the like; gnome-session would just find each named .desktop file using the ordinary desktop-file search paths. > IIUC, to start Nautilus on the session startup, we need to run it with > --no-default-window option only and I haven't seen any .desktop files with the > "Exec" key matching that. Hence, the new .desktop file is not identical to the > existing ones. If it's possible to just reuse some of the existing ones, > great. :-) FWIW, this is one of the things I envisioned using AutostartNotify for; if Nautilus sets "X-GNOME-Autostart-Notify=true" in its .desktop file, then it can check at startup if $DESKTOP_AUTOSTART_ID is set, and if so, it knows it's being run at startup and can adjust its behavior accordingly. (Note that you have to check the variable *before* calling gnome_program_init though, because gnome_program_init will clear it to keep you from accidentally passing it on to a child process. Probably GnomeClient/EggSMClient should have a method you can call to check if DESKTOP_AUTOSTART_ID had been set, so you don't have to check it so early.)
Hey, (In reply to comment #6) > I agree with Christian. See also bug 525157 where I suggested basically exactly > the same thing. Hmm, that reminds me that I need to watch gnome-session-maint@gnome.bugs... > (In Lucas's defense, this was all my bad idea originally, not his :-) Yeah, shame on you! :-P > > In an ideal setup, gnome-session shouldn't care about specific session > > applications. It only cares about required apps which provides the basic > > functionalities (windowmanager, panel and filemanager) on certain phases. But > > which app provides those functionalities may vary and this shouldn't be > > hardcoded in any way. > > While I agree that ideall gnome-session wouldn't know this, as mentioned in > that other bug, I think it's more ideal for gnome-session to know than it is > for the apps themselves to know; Under the current plan, if we wanted to make > nautilus not be the default file manager any more, we'd have to put out a new > release of nautilus to have it stop installing the > default-session/nautilus.desktop file... > > Perhaps ideally, there'd be a very very small package "gnome-default-session" > that contained just the default-session information. But practically, it's > probably easier to just put it in gnome-session... > > > > So maybe the session should rather be a flat text file [like > > > ~/.gnome2/session], containing the basenames of desktop files (i.e. > > > application names)? > > > > Hmmm, I still don't see the point of doing that. Could you elaborate? > > It saves us from having to worry about dangling symlinks and the like; > gnome-session would just find each named .desktop file using the ordinary > desktop-file search paths. Now with your comments I got the point and yes, the current plan indeed has some drawbacks (maybe I didn't understand it before because I read the bug report comments at 3h am :-P). Having a default session file or a gconf key (instead of a directory) might be a good idea. Let's continue this specific discussion on bug #525157 where you've posted an interesting comment about this already. > > IIUC, to start Nautilus on the session startup, we need to run it with > > --no-default-window option only and I haven't seen any .desktop files with the > > "Exec" key matching that. Hence, the new .desktop file is not identical to the > > existing ones. If it's possible to just reuse some of the existing ones, > > great. :-) > > FWIW, this is one of the things I envisioned using AutostartNotify for; if > Nautilus sets "X-GNOME-Autostart-Notify=true" in its .desktop file, then it can > check at startup if $DESKTOP_AUTOSTART_ID is set, and if so, it knows it's > being run at startup and can adjust its behavior accordingly. (Note that you > have to check the variable *before* calling gnome_program_init though, because > gnome_program_init will clear it to keep you from accidentally passing it on to > a child process. Probably GnomeClient/EggSMClient should have a method you can > call to check if DESKTOP_AUTOSTART_ID had been set, so you don't have to check > it so early.) Nice idea, this might be useful for other modules too. Christian, what do you think? Anyway, the part of the patch that adds the special keys to the .desktop file is still valid. We could just add it to nautilus.desktop (in case nautilus behaves as expected if DESKTOP_AUTOSTART_ID is set).
Created attachment 109622 [details] [review] Updated patch. So, here's a new and simplified patch. It basically adds the special gnome-session keys to nautilus' .desktop file and adapts the startup options in case nautilus is being launched by gnome-session (with the DESKTOP_AUTOSTART_ID).
It's a litle bit late but I would be nice to have this patch in for 2.23.1.
> It's a litle bit late but I would be nice to have this patch in for 2.23.1. Thanks, committed. Closing.
The patch that has been committed adds X-GNOME-Provides=desktop to the desktop file. But gnome-session looks for the "filemanager", not "desktop"
Thanks, fixed in trunk: http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14426 Closing.