>> 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? >> 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? > +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. -- ubuntu-desktop mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
