1 |
I stopped reading after you reminded me it was 2016 |
2 |
On May 27, 2016 9:21 AM, "Mart Raudsepp" <leio@g.o> wrote: |
3 |
|
4 |
> Hello, |
5 |
> |
6 |
> Despite it being 2016 and gtk2 pretty much dead, buried and forgotten |
7 |
> upstream, many applications still support only gtk2, have subtle issues |
8 |
> with their gtk3 port, or support both, with some of our userbase |
9 |
> clinging to gtk2 for dubious political or aesthetical reasons. |
10 |
> |
11 |
> For the latter cases, despite GNOME teams policy and strong preference |
12 |
> on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's |
13 |
> working as good as gtk2), some cases exist where the maintainers want |
14 |
> to provide such choice. In some cases it is understandable for a short |
15 |
> while during transition, e.g firefox. In other cases, it is purely for |
16 |
> the sake of providing the choice of working with a deprecated toolkit, |
17 |
> apparently. |
18 |
> |
19 |
> My highly biased essay aside, we need to finally globally agree on what |
20 |
> we do in this situation. If we allow this choice at all, only for |
21 |
> special cases, or widespread. And if this choice is provided, how do we |
22 |
> name the USE flag. |
23 |
> |
24 |
> Historically, for very good reasons in past and present GNOME team |
25 |
> members opinion, USE=gtk has always meant to mean to provide support |
26 |
> for gtk in general, not any particular version. This is opposite to |
27 |
> what the Qt team has been doing. |
28 |
> In our opinion, in a perfect world, only USE=gtk would exist, and no |
29 |
> USE=gtk2 or USE=gtk3 would be necessary. But as we don't live in a |
30 |
> perfect world, we have made use of USE=gtk3 for providing gtk3 support |
31 |
> from library packages to mean to build gtk3 support. Sadly that |
32 |
> overloads USE=gtk in many cases to then mean to build gtk2 support. |
33 |
> This would ideally not be needed, as the package would instead be |
34 |
> slotted and parallel installable for gtk2 and gtk3, which should be |
35 |
> theoretically possible in all cases, because gtk2 and gtk3 may not live |
36 |
> in the same process, so not the same library either. |
37 |
> Due to some packages needing too much manpower effort to do such a |
38 |
> split, USE flags are used in such a case. |
39 |
> Good examples of such slot splits existing are for example the |
40 |
> libappindicator stack. This used to be the case with almost all GNOME |
41 |
> libraries as well, but most of them only provide gtk3 now, as gtk2 is, |
42 |
> well, dead. |
43 |
> Bad examples would be e.g avahi and gtk-vnc, which deemed too hard to |
44 |
> split up into separate SLOTs. In some cases it might have been meant as |
45 |
> a transitional thing, until all consumers are ported to gtk3, but it |
46 |
> has been lingering on due to consumer apps not being ported or we |
47 |
> haven't yet noticed to remove the gtk2 support in the library package. |
48 |
> |
49 |
> Now these are libraries, and despite some USE flag confusion, it's not |
50 |
> a huge issue, because consumers are USE depending on what is required. |
51 |
> This all is written out in |
52 |
> https://wiki.gentoo.org/wiki/Project:GNOME/Gnome_Team_Ebuild_Policies#gtk3 |
53 |
> since the GNOME project pages moving to wiki, and also long before that |
54 |
> in GuideXML era, and we've pointed people towards that. |
55 |
> |
56 |
> And then we have applications that support building against either gtk2 |
57 |
> or gtk3. |
58 |
> In most cases, any requests to provide the choice to have an |
59 |
> application use gtk2 instead of gtk3 gets instantly marked as duplicate |
60 |
> of https://bugs.gentoo.org/374057 but in some cases the maintainer has |
61 |
> chosen to provide this choice for now, and here is the problem - we |
62 |
> don't really have a good agreed on way to name such a choice in USE |
63 |
> flags, if we should provide such a choice at all. |
64 |
> |
65 |
> USE=gtk2 is not good, due to the confusion issues with USE=gtk3 and |
66 |
> USE=gtk and it being problematic. The GNOME team shall probably veto |
67 |
> such USE flag usage if we are deemed to have such an authority as gtk+ |
68 |
> maintainers, unless we rework it all in expectations of gtk2 corpse |
69 |
> being carried around for a decade as well... I have quite a few bugs |
70 |
> against packages to file already for this, afair. |
71 |
> |
72 |
> I kind of like what firefox did there, going in the spirit of the |
73 |
> force-openrc flag we have for avoiding systemd dependency, even if it |
74 |
> currently means worse user experience. So if we provide such a choice |
75 |
> for apps at all, I might agree to USE=force-gtk2 for this for apps. And |
76 |
> we would like to eventually (or immediately) p.use.mask this and once |
77 |
> it's 2017 and gtk2 truly dead and buried and full of known security |
78 |
> holes, get rid of it again. |
79 |
> But this highlighted the inconsistency we are having, ending up with QA |
80 |
> initiated bug https://bugs.gentoo.org/581662 |
81 |
> |
82 |
> tl;dr and my proposal would be the following: |
83 |
> |
84 |
> * USE=gtk means providing support for GTK+; because we don't have a |
85 |
> USE=gui, this also means "provide a GUI version built on top of gtk+" |
86 |
> for packages where a GUI is optional. |
87 |
> |
88 |
> * USE=gtk3 may be used only for controlling extra libraries to be |
89 |
> shipped for gtk3 support (the extra library file will link to gtk3), |
90 |
> _in addition_ to gtk2 version. This is a temporarily measure until gtk2 |
91 |
> support can be dropped and it will only ship gtk3 version of the |
92 |
> library. This gives a flag to be able to USE depend on by gtk3 apps. |
93 |
> This leaves the question about the opposite open, however. This is why |
94 |
> USE=gtk2 would be bad for apps, maybe we need to use it for this |
95 |
> library case, when gtk3 version is primary and we just have 1 app |
96 |
> remaining that needs the gtk2 version or something. |
97 |
> The concept of library is broad here, covering also gtk theme engines |
98 |
> (x11-themes/gtk-engine-*, but they shouldn't be hard to split) and |
99 |
> modules (e.g caribou, libcanberra) |
100 |
> |
101 |
> * Applications may only use a gtk2 based stack or gtk3 based stack in a |
102 |
> given version/revision. gtk3 is strongly preferred when it is deemed to |
103 |
> not have any regressions compared to gtk2 build, but the choice is |
104 |
> ultimately with the maintainer. Once the application converts to using |
105 |
> gtk3 in our distribution, it should try hard to stay that way in |
106 |
> upcoming versions as well. |
107 |
> |
108 |
> * Some exceptions to the above may exist under heavy consideration, |
109 |
> especially in cases where the toolkit usage is complex and may have |
110 |
> some issues for some, but in general gtk3 support is deemed good by |
111 |
> upstream. Most notable here would be browsers like firefox and |
112 |
> chromium, which are using gtk dependency more for emulating the theme |
113 |
> it uses, rather than using it as its real toolkit. If such exceptions |
114 |
> are allowed, the USE flag naming here must be consistent amongst the |
115 |
> exceptions. My proposal would be USE=force-gtk2 then, as I have no |
116 |
> better ideas without stomping on the USE=gtk{2,3} historical meaning. |
117 |
> |
118 |
> |
119 |
> When arguing in favor of supporting gtk2 builds more for apps, please |
120 |
> do keep in mind that gtk2 really is pretty much dead. And no, MATE, |
121 |
> XFCE and others are NOT continuing its support; they are just slow in |
122 |
> fully converting to gtk3, but they are doing so and I expect both of |
123 |
> those to be fully done this year, around autumn. |
124 |
> If the issue is political or just a general gnome3 or gtk3 hate, then I |
125 |
> would ask you to keep your political opinions or hate outside this |
126 |
> thread and go contemplate on more important life issues. |
127 |
> If the issue is lack of themes, then I would like you to help package |
128 |
> more gtk3 themes. gtk3.20 now has a stable CSS based theme API and |
129 |
> themes shouldn't be breaking anymore beyond this point, theoretically. |
130 |
> And gtk3 theme packages should pretty much just be CSS files and some |
131 |
> metadata. Though we have yet to get over that bumpy thing yet (a main |
132 |
> reason gtk3.20 isn't in main tree yet). |
133 |
> |
134 |
> Thoughts? Agreements? Suggestions? |
135 |
> I'm particularly interested in QA opinion here. I believe WilliamH |
136 |
> wanted to spearhead this from their side. |
137 |
> |
138 |
> |
139 |
> Regards, |
140 |
> Mart Raudsepp |
141 |
> Gentoo developer, GNOME team |
142 |
> |
143 |
> |