I stopped reading after you reminded me it was 2016 On May 27, 2016 9:21 AM, "Mart Raudsepp" <l...@gentoo.org> wrote:
> Hello, > > Despite it being 2016 and gtk2 pretty much dead, buried and forgotten > upstream, many applications still support only gtk2, have subtle issues > with their gtk3 port, or support both, with some of our userbase > clinging to gtk2 for dubious political or aesthetical reasons. > > For the latter cases, despite GNOME teams policy and strong preference > on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's > working as good as gtk2), some cases exist where the maintainers want > to provide such choice. In some cases it is understandable for a short > while during transition, e.g firefox. In other cases, it is purely for > the sake of providing the choice of working with a deprecated toolkit, > apparently. > > My highly biased essay aside, we need to finally globally agree on what > we do in this situation. If we allow this choice at all, only for > special cases, or widespread. And if this choice is provided, how do we > name the USE flag. > > Historically, for very good reasons in past and present GNOME team > members opinion, USE=gtk has always meant to mean to provide support > for gtk in general, not any particular version. This is opposite to > what the Qt team has been doing. > In our opinion, in a perfect world, only USE=gtk would exist, and no > USE=gtk2 or USE=gtk3 would be necessary. But as we don't live in a > perfect world, we have made use of USE=gtk3 for providing gtk3 support > from library packages to mean to build gtk3 support. Sadly that > overloads USE=gtk in many cases to then mean to build gtk2 support. > This would ideally not be needed, as the package would instead be > slotted and parallel installable for gtk2 and gtk3, which should be > theoretically possible in all cases, because gtk2 and gtk3 may not live > in the same process, so not the same library either. > Due to some packages needing too much manpower effort to do such a > split, USE flags are used in such a case. > Good examples of such slot splits existing are for example the > libappindicator stack. This used to be the case with almost all GNOME > libraries as well, but most of them only provide gtk3 now, as gtk2 is, > well, dead. > Bad examples would be e.g avahi and gtk-vnc, which deemed too hard to > split up into separate SLOTs. In some cases it might have been meant as > a transitional thing, until all consumers are ported to gtk3, but it > has been lingering on due to consumer apps not being ported or we > haven't yet noticed to remove the gtk2 support in the library package. > > Now these are libraries, and despite some USE flag confusion, it's not > a huge issue, because consumers are USE depending on what is required. > This all is written out in > https://wiki.gentoo.org/wiki/Project:GNOME/Gnome_Team_Ebuild_Policies#gtk3 > since the GNOME project pages moving to wiki, and also long before that > in GuideXML era, and we've pointed people towards that. > > And then we have applications that support building against either gtk2 > or gtk3. > In most cases, any requests to provide the choice to have an > application use gtk2 instead of gtk3 gets instantly marked as duplicate > of https://bugs.gentoo.org/374057 but in some cases the maintainer has > chosen to provide this choice for now, and here is the problem - we > don't really have a good agreed on way to name such a choice in USE > flags, if we should provide such a choice at all. > > USE=gtk2 is not good, due to the confusion issues with USE=gtk3 and > USE=gtk and it being problematic. The GNOME team shall probably veto > such USE flag usage if we are deemed to have such an authority as gtk+ > maintainers, unless we rework it all in expectations of gtk2 corpse > being carried around for a decade as well... I have quite a few bugs > against packages to file already for this, afair. > > I kind of like what firefox did there, going in the spirit of the > force-openrc flag we have for avoiding systemd dependency, even if it > currently means worse user experience. So if we provide such a choice > for apps at all, I might agree to USE=force-gtk2 for this for apps. And > we would like to eventually (or immediately) p.use.mask this and once > it's 2017 and gtk2 truly dead and buried and full of known security > holes, get rid of it again. > But this highlighted the inconsistency we are having, ending up with QA > initiated bug https://bugs.gentoo.org/581662 > > tl;dr and my proposal would be the following: > > * USE=gtk means providing support for GTK+; because we don't have a > USE=gui, this also means "provide a GUI version built on top of gtk+" > for packages where a GUI is optional. > > * USE=gtk3 may be used only for controlling extra libraries to be > shipped for gtk3 support (the extra library file will link to gtk3), > _in addition_ to gtk2 version. This is a temporarily measure until gtk2 > support can be dropped and it will only ship gtk3 version of the > library. This gives a flag to be able to USE depend on by gtk3 apps. > This leaves the question about the opposite open, however. This is why > USE=gtk2 would be bad for apps, maybe we need to use it for this > library case, when gtk3 version is primary and we just have 1 app > remaining that needs the gtk2 version or something. > The concept of library is broad here, covering also gtk theme engines > (x11-themes/gtk-engine-*, but they shouldn't be hard to split) and > modules (e.g caribou, libcanberra) > > * Applications may only use a gtk2 based stack or gtk3 based stack in a > given version/revision. gtk3 is strongly preferred when it is deemed to > not have any regressions compared to gtk2 build, but the choice is > ultimately with the maintainer. Once the application converts to using > gtk3 in our distribution, it should try hard to stay that way in > upcoming versions as well. > > * Some exceptions to the above may exist under heavy consideration, > especially in cases where the toolkit usage is complex and may have > some issues for some, but in general gtk3 support is deemed good by > upstream. Most notable here would be browsers like firefox and > chromium, which are using gtk dependency more for emulating the theme > it uses, rather than using it as its real toolkit. If such exceptions > are allowed, the USE flag naming here must be consistent amongst the > exceptions. My proposal would be USE=force-gtk2 then, as I have no > better ideas without stomping on the USE=gtk{2,3} historical meaning. > > > When arguing in favor of supporting gtk2 builds more for apps, please > do keep in mind that gtk2 really is pretty much dead. And no, MATE, > XFCE and others are NOT continuing its support; they are just slow in > fully converting to gtk3, but they are doing so and I expect both of > those to be fully done this year, around autumn. > If the issue is political or just a general gnome3 or gtk3 hate, then I > would ask you to keep your political opinions or hate outside this > thread and go contemplate on more important life issues. > If the issue is lack of themes, then I would like you to help package > more gtk3 themes. gtk3.20 now has a stable CSS based theme API and > themes shouldn't be breaking anymore beyond this point, theoretically. > And gtk3 theme packages should pretty much just be CSS files and some > metadata. Though we have yet to get over that bumpy thing yet (a main > reason gtk3.20 isn't in main tree yet). > > Thoughts? Agreements? Suggestions? > I'm particularly interested in QA opinion here. I believe WilliamH > wanted to spearhead this from their side. > > > Regards, > Mart Raudsepp > Gentoo developer, GNOME team > >
