[Pkg-xfce-devel] Analysis of the gnome3 transitions
On mer., 2011-04-13 at 15:03 +0200, Mehdi Dogguy wrote:
> Sorry for the late reply, and thanks for this detailed analysis. It's very
> helpful!
>
> On 0, Josselin Mouette <joss at debian.org> wrote:
> > 1. libnotify
> > Once gtk3 is here, we can upload libnotify 0.6. This version is
> > binary-compatible with 0.5.0, except that it doesn?t depend on a
> > specific version of GTK+. This is the easy part, but it can be
> > skipped, since anyway we need a transition:
> > libnotify1?libnotify4.
> >
> > Many packages will not build without source changes since
> > functions were removed, however the source changes are
> > independent from the GTK+ version. So we only need to ensure
> > this transition is handled independently from the rest - and
> > before the rest, since it is a prerequisite for most of the
> > others.
> >
>
> This has been requested and is tracked as #622363. As mentioned in the
> bugreport, we will try to get Xfce before (asked earlier and seems to
> simplify the transition a bit).
Yup.
> > 9. gnome-panel
> > Theoretically, this one should be done with the big gnome3
> > transition (see below). However it sounds insane to couple it,
> > since it breaks all existing panel applets.
> >
> > Updating it without updating the rest of GNOME implies making
> > sure that it can be a drop-in replacement for gnome-panel 2.
> > First of all the applet setup will be ditched upon upgrade, but
> > I don?t see this as a real problem. However interaction with the
> > old gnome-session (especially with saved sessions) could be.
> > This implies a lot of testing if we want to keep this transition
> > separate.
> >
> > It also requires dropping python-gnomeapplet from
> > gnome-python-desktop.
> >
> > I can think of two approaches here.
> > * I?d prefer to get entirely rid of libpanel-applet2-0 and
> > all applets that depend on it. We migrate the new panel
> > to testing, remove them all and re-add them if their
> > upstreams port them to the new API.
> > * We can keep the old API in a different source package
> > that would remain around for some time. However it would
> > mean users could install applets that don?t actually
> > work with the panel, but only with e.g. Xfce. It?s less
> > breakage but more confusion.
> > I?d appreciate the input of the release team on this topic.
> >
>
> The second approach also means same number of applets for Xfce users.
> So, maybe an input from Xfce maintainers would be helpful here.
>
> I personally don't have a preference. We can choose the first approach
> if Xfce maintainers agree too. (Adding them in CC:). Will Xfce 4.8 provide
> a new implementation for deperecated applets?, or its own new set of applets?
> Which applets are not ported yet? (libpanel-applet2-dev has quite some number
> of reverse dependencies).
We only have one plugin which uses gnome-panel, xfce4-xfapplets-plugin
which is actually an xfce panel plugin wrapping gnome applets (so one
can add a gnome 2 applet to an xfce4 panel).
I'm not sure much people use it, so there's no point in keeping the old
API just for that (I don't think it's really maintained upstream). On
the other hand, if it helps people badly needing gnome2 applets when
there's no gnome2 panel, then it might make sense.
Not sure if it's really helpful, but my position is: if
xfce4-xfapplets-plugin is helpful in that transition we can keep it as a
fallback, if not then we can get rid of it.
Regards,
--
Yves-Alexis
Reply to: