Hi! A number of changes to Bluetile. See below:
On Sat, Jun 19, 2010 at 10:19:58PM +0200, Joachim Breitner wrote: > Maybe the bluetile-gnome.desktop file can be modified such that is > ignored if /usr/bin/gnome-session is not present. I think there is a > field for that... You could play with "TryExec", see > http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html > > The second question is how to make gnome use bluetile for just this > session. Possibly by starting bluetile, which then starts gnome-session > and somehow prevents metacity from starting? But sounds not very clean > to me. I found out that one way is to set the environment variable WINDOW_MANAGER before invoking gnome-session. I created a solution based on this approach. A gnome-bluetile desktop file which invokes a binary called 'gnome-bluetile-session' which sets the WINDOW_MANAGER variable and execs gnome-session. I decided to make gnome-bluetile-session a small binary so that I can compile in the correct path to Bluetile. I already created a man page for that new binary. The desktop file is in the repository as misc/gnome-bluetile-session.desktop. I played aroung with TryExec and included it in the gnome-bluetile desktop file. It sort of seems to work. GDM displays 'GNOME + Bluetile' when the TryExec binary is found. If it's not found it just shows 'gnome-bluetile.desktop' instead - the name of the desktop file. So there is _some_ effect, but obviously it should hide the entry completely. Should I file a bug against GDM? I moved your desktop files into the Bluetile repository. I hope you don't mind? They might be helpful for other distributions as well. I would think that both the Bluetile standalone as well as the GNOME + Bluetile option could be included in the package, right? So in summary, the following desktop files are now in Bluetile's repository: misc/bluetile.desktop misc/bluetile-session.desktop install as /usr/share/xsessions/bluetile.desktop (as the package does currently) misc/gnome-bluetile-session.desktop install as /usr/share/xsessions/gnome-bluetile.desktop I hope this solution is acceptable for the Debian package. > Maybe best would be to remove the session entry again and give > bluetile’s welcome screen the option to set (and unset) itself as the > default window manager – similar to how web browsers have been doing it > for a long time now. I can’t tell you the “proper” way of setting the > default GNOME window manager these days. Probably a GConf key. I might do that at one point. Right now I don't want to open that can. Indeed, one can set a GConf key. But it only works if a desktop file is installed that tells GNOME that Bluetile is a window manager. This would work in Debian's case, but I will need to take extra steps to make this work for people that use 'cabal install'. Learning from bug #586284 I also improved the documentation a little bit. The repository now contains a README file. Maybe that can go into /usr/share/doc/bluetile. And finally I extended my Cabal hooks to also run if 'cabal copy' is used and move the binaries to libexec in that case as well. I would be interested to know if that works for you and makes moving the binaries manually by the Debian package unnecessary. Side note: I originally had hoped to be able to just hook into postCopy, because I figured 'cabal install' is just register + copy (as the documentation claims). But it turns out that the postCopy hook _only_ runs when you invoke 'cabal copy' and the postInstall hook _only_ runs when you invoke 'cabal install'. So to make this work both for people installing with cabal as well as distributions using 'cabal copy' I had to create two hooks now. I find this highly confusing. I might file a bug against Cabal later - at least as a note to others. All the changes above are available as Bluetile 0.4.2 in this tar file: http://code.haskell.org/~jav/releases/bluetile-0.4.2.tar.gz One question here: I created a new version now, but If I do changes like that which are targeted at making distribution easier, I would like to run them by you, Joachim, to see if anything else needs changing before actually creating a new release. So I don't have to run through version numbers unnessary just for small fixes. How would I do that so that it's most convenient for you? Create a release candidate tarball? or just let you know that you can pull from the darcs repository? Cheers! Jan -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
