[Oneiric-Topic] Reducing number of patches in our packages

[Rodrigo Moya]

On Thu, 2011-04-07 at 08:30 -0400, Mathieu Trudel-Lapierre wrote:
> On Thu, Apr 7, 2011 at 7:23 AM, Rodrigo Moya <rodrigo.moya at canonical.com> wrote:
> [...]
> > So, for next cycle, I would suggest a "small" goal of trying to do patch
> > upstreaming/cleaning days, maybe once a week or every 2 weeks.
> 
> Great idea :)
> 
> > Also, some Ubuntu-specific patches, like the appindicators ones are
> > duplicated in lots of packages, so it would be good if we could find a
> > better way to make upstream apps use them, like, for instance, patching
> > gtk_status_icon_* in GTK itself to use the indicators when available,
> > instead of having to patch dozens of apps (and keep those patches
> > up-to-date and working for every major version upgrade).
> >
> 
> Due to the complexity of keeping an UX that makes sense between using
> a standard menu and context menu, against having only one menu to use
> in indicators (to just name one constraint), I think it would be
> rather difficult to make patching GTK itself to handle indicators work
> properly.. and especially in a way that looks good.
> 
I don't understand what you mean here, could you explain please? If
GTK's status icon is patched to use the indicators instead of the
upstream thing (when the indicator-applet is available), the difference
of having one context menu per status icon vs one menu for all
indicators is all taken care by the actual implementation (normal status
icons would have their own context menu vs indicator-applet would work
as it does now)

> I certainly believe that indicator patches are upstreamable in many
> cases, and already know that Dan in open to including my indicator
> patch in nm-applet; I think we're getting close to that being
> completed too ;)
> 
well, most appindicators patches were rejected upstream because of that
functionality making more sense in GTK itself than in a separate
library, so while some of them have been applied (or are going to)
upstream (I myself pushed the patch to gnome-control-center), we're
still left with many apps that don't get the patch upstream, so more
work for us :-)

About putting it in GTK, I don't know of all the appindicators patches,
but most of the ones I've seen, more or less, are just a bunch of:

#ifdef INDICATORS
app_indicator_whatever...
#else
gtk_status_icon_whatever...
#endif

so I was talking about those. If there are other uses we would need to
have, then why not push the stuff we need to GTK's GtkStatusIcon itself
upstream? Then, we could just patch GTK to use the indicators when
available, but apps would all use the same API (ie no need for us to
write specific patches for each app)