On Thu, 2011-04-07 at 20:26 -0400, Jorge O. Castro wrote: > >> 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). > > How would this affect application authors, would they need to go update again? > what do you mean?
> >> Another candidate for that could be the launchpad integration patches, > >> which are present in many more packages than the appindicators ones. I'm > >> sure we can find a way to have that in GTK itself, so that whenever a > >> Help menu is created, and given we have the name of the app, it could > >> just create the LPI entries. > > This would be great, do you think GTK upstream would be keen on this? > maybe, but if not, we would just need to carry 1 distro patch, not dozens of them > > +100 for this topic. The amount of patches we carry is a huge but > > mostly silent overhead. I'd like to make a website like versions [1] > > that shows our diff against vanilla GNOME to make this more visible. > > I would like to also +100 even though I'm not on the desktop team. :p > > The 3.x transition this is the time to get this out of the way before > we find ourselves in LTS-crunch with too large a delta. When we're > ready I'd like to see us approach d-d-l as soon as possible and start > talking to module maintainers and start working on this. Even if we > don't get them all if we could at least do a frontloaded approach for > O and catch the remainder in P that would be great. > right, that's why those patch upstreaming/cleaning days would be useful -- ubuntu-desktop mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
