Re: Bluetile package
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
Reply to: