Re: [gnome-flashback] ANNOUNCE: gnome-panel and gnome-flashback-session 3.8.0 release

[Balló György <ballogyor gmail com>]

2013/9/29 Philipp Kaluza <floss ghostroute eu>:
> Hi Balló,
>
> Am 29.09.2013 09:28, schrieb Balló György:
> > Great to see a new release, but I have some questions about the future:
> >
> > 1. gnome-panel is just one component of the session. Is there any plan
> > with gnome-applets, gnome-screensaver, metacity, notification-daemon
> > and polkit-gnome? All of these are required to run a full Flashback
> > session, but none of them are actively maintained.
> Well, it depends what you mean by "actively maintained". On most of
> these components, I don't expect there to be any new development, unless
> somebody comes along with new ideas for them (e.g. the metacity port to
> GTK+ 3). But of course, we can develop and commit bug fixes, and if the
> previous maintainers were to be MIA, also roll tarballs.
>
> So the plan is "keep it working as well as possible". :)

Just check my first mail that I sent to this mailing list:
https://mail.gnome.org/archives/gnome-flashback-list/2013-April/msg00001.html

I proposed some patches for metacity, notification-daemon and
polkit-gnome, but none of them are reviewed or accepted. Some fixes
were applied to gnome-applets, but there is no new upstream release.

> > 2. Is there any plan to reimplement background, media keys and
> > automount handling feature which was dropped from
> > gnome-settings-daemon 3.8?
> For background we have two options:
> - force nautilus to take over the desktop
> - resurrect the plugin.
>
> Everybody, preferences ?

Nautilus is not an option, because its desktop background rendering
feature has been removed with nautilus>=3.8. It just draws a
transparent root-window with the desktop icons, see these commits:
https://git.gnome.org/browse/nautilus/commit/?id=f0f36c876e4810b190a82e3a953d9263c106447f
https://git.gnome.org/browse/nautilus/commit/?id=372c60d3f8590280df23f457a67652adec369697

And even if you resurrect the GSD plugin, it requires a compositing
window manager (can be enabled in metacity) to handle the
transparency, otherwise the background remains black if nautilus
desktop icons are enabled.

> The media-keys plugin is still in the codebase, and actively maintained.
> Maybe it's not built on your system ?

The key grabbing functionality and the OSD have moved from
gnome-settings-daemon 3.8 to gnome-shell 3.8, therefore the media keys
plugin is useless outside of gnome-shell, because it's never grab the
keypresses:
https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=1c9ded7b9dad1e5b5b6f62b2e78c221e99dc5eb1
https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=50e3b5b4ea2b5fede8390baf8a19b33dbf047cc1

> Automount seems to work fine for me - could you elaborate ?

The mount helper (which used by GNOME fallback mode) has been removed
from gnome-settings-daemon 3.8. This was used to display a dialog when
a new media inserted, and the users can choose which application
should be launched:
https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=77a29fde9204a80ad3960fc6d50a733261fbfbfe
https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=99da10fa1c771bd692bf00b6c4ccf2a5c1818bdb

> > Is there any cooperation between the Gnome
> > Flashback team and gnome-settings-daemon/gnome-session maintainers?
> There should be more, unfortunately we're on completely different
> schedules (flashback team: cleaning up the fallout of the 3.8 release,
> g-s-d: starting the 3.12 cycle). Feel free to CC them by the way. :)
>
>
> > Would you consider to fork these components,
> Where possible, we'll avoid forks, otherwise we'll end up in a mate-like
> situation.

I agree to avoid forks, but it requires intense cooperation with
gnome-settings-daemon and gnome-session maintainers to avoid breakage
on every six months.

> > or do you plan to keep full compatibility with their latest releases?
> No, only with the release that we are targeting. That's 3.8 at the
> moment, but we have a branch open for 3.10 development also.

This is horrible for a rolling release distribution like Arch Linux.
We usually put the latest stable releases to the stable repositories
really soon, therefore we can't distribute projects which are not
compatible with the latest stable releases of other projects.

--
György Balló
Arch Linux Trusted User