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