1 |
On 05/27/2016 07:21 AM, Mart Raudsepp wrote: |
2 |
> Hello, |
3 |
> |
4 |
> Despite it being 2016 and gtk2 pretty much dead, buried and forgotten |
5 |
> upstream, many applications still support only gtk2, have subtle issues |
6 |
> with their gtk3 port, or support both, with some of our userbase |
7 |
> clinging to gtk2 for dubious political or aesthetical reasons. |
8 |
> |
9 |
> For the latter cases, despite GNOME teams policy and strong preference |
10 |
> on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's |
11 |
> working as good as gtk2), some cases exist where the maintainers want |
12 |
> to provide such choice. In some cases it is understandable for a short |
13 |
> while during transition, e.g firefox. In other cases, it is purely for |
14 |
> the sake of providing the choice of working with a deprecated toolkit, |
15 |
> apparently. |
16 |
> |
17 |
> My highly biased essay aside, we need to finally globally agree on what |
18 |
> we do in this situation. If we allow this choice at all, only for |
19 |
> special cases, or widespread. And if this choice is provided, how do we |
20 |
> name the USE flag. |
21 |
> |
22 |
> Historically, for very good reasons in past and present GNOME team |
23 |
> members opinion, USE=gtk has always meant to mean to provide support |
24 |
> for gtk in general, not any particular version. This is opposite to |
25 |
> what the Qt team has been doing. |
26 |
> In our opinion, in a perfect world, only USE=gtk would exist, and no |
27 |
> USE=gtk2 or USE=gtk3 would be necessary. But as we don't live in a |
28 |
> perfect world, we have made use of USE=gtk3 for providing gtk3 support |
29 |
> from library packages to mean to build gtk3 support. Sadly that |
30 |
> overloads USE=gtk in many cases to then mean to build gtk2 support. |
31 |
> This would ideally not be needed, as the package would instead be |
32 |
> slotted and parallel installable for gtk2 and gtk3, which should be |
33 |
> theoretically possible in all cases, because gtk2 and gtk3 may not live |
34 |
> in the same process, so not the same library either. |
35 |
> Due to some packages needing too much manpower effort to do such a |
36 |
> split, USE flags are used in such a case. |
37 |
> Good examples of such slot splits existing are for example the |
38 |
> libappindicator stack. This used to be the case with almost all GNOME |
39 |
> libraries as well, but most of them only provide gtk3 now, as gtk2 is, |
40 |
> well, dead. |
41 |
> Bad examples would be e.g avahi and gtk-vnc, which deemed too hard to |
42 |
> split up into separate SLOTs. In some cases it might have been meant as |
43 |
> a transitional thing, until all consumers are ported to gtk3, but it |
44 |
> has been lingering on due to consumer apps not being ported or we |
45 |
> haven't yet noticed to remove the gtk2 support in the library package. |
46 |
> |
47 |
> Now these are libraries, and despite some USE flag confusion, it's not |
48 |
> a huge issue, because consumers are USE depending on what is required. |
49 |
> This all is written out in |
50 |
> https://wiki.gentoo.org/wiki/Project:GNOME/Gnome_Team_Ebuild_Policies#gtk3 |
51 |
> since the GNOME project pages moving to wiki, and also long before that |
52 |
> in GuideXML era, and we've pointed people towards that. |
53 |
> |
54 |
> And then we have applications that support building against either gtk2 |
55 |
> or gtk3. |
56 |
> In most cases, any requests to provide the choice to have an |
57 |
> application use gtk2 instead of gtk3 gets instantly marked as duplicate |
58 |
> of https://bugs.gentoo.org/374057 but in some cases the maintainer has |
59 |
> chosen to provide this choice for now, and here is the problem - we |
60 |
> don't really have a good agreed on way to name such a choice in USE |
61 |
> flags, if we should provide such a choice at all. |
62 |
> |
63 |
> USE=gtk2 is not good, due to the confusion issues with USE=gtk3 and |
64 |
> USE=gtk and it being problematic. The GNOME team shall probably veto |
65 |
> such USE flag usage if we are deemed to have such an authority as gtk+ |
66 |
> maintainers, unless we rework it all in expectations of gtk2 corpse |
67 |
> being carried around for a decade as well... I have quite a few bugs |
68 |
> against packages to file already for this, afair. |
69 |
> |
70 |
> I kind of like what firefox did there, going in the spirit of the |
71 |
> force-openrc flag we have for avoiding systemd dependency, even if it |
72 |
> currently means worse user experience. So if we provide such a choice |
73 |
> for apps at all, I might agree to USE=force-gtk2 for this for apps. And |
74 |
> we would like to eventually (or immediately) p.use.mask this and once |
75 |
> it's 2017 and gtk2 truly dead and buried and full of known security |
76 |
> holes, get rid of it again. |
77 |
> But this highlighted the inconsistency we are having, ending up with QA |
78 |
> initiated bug https://bugs.gentoo.org/581662 |
79 |
> |
80 |
> tl;dr and my proposal would be the following: |
81 |
> |
82 |
> * USE=gtk means providing support for GTK+; because we don't have a |
83 |
> USE=gui, this also means "provide a GUI version built on top of gtk+" |
84 |
> for packages where a GUI is optional. |
85 |
> |
86 |
> * USE=gtk3 may be used only for controlling extra libraries to be |
87 |
> shipped for gtk3 support (the extra library file will link to gtk3), |
88 |
> _in addition_ to gtk2 version. This is a temporarily measure until gtk2 |
89 |
> support can be dropped and it will only ship gtk3 version of the |
90 |
> library. This gives a flag to be able to USE depend on by gtk3 apps. |
91 |
> This leaves the question about the opposite open, however. This is why |
92 |
> USE=gtk2 would be bad for apps, maybe we need to use it for this |
93 |
> library case, when gtk3 version is primary and we just have 1 app |
94 |
> remaining that needs the gtk2 version or something. |
95 |
> The concept of library is broad here, covering also gtk theme engines |
96 |
> (x11-themes/gtk-engine-*, but they shouldn't be hard to split) and |
97 |
> modules (e.g caribou, libcanberra) |
98 |
> |
99 |
> * Applications may only use a gtk2 based stack or gtk3 based stack in a |
100 |
> given version/revision. gtk3 is strongly preferred when it is deemed to |
101 |
> not have any regressions compared to gtk2 build, but the choice is |
102 |
> ultimately with the maintainer. Once the application converts to using |
103 |
> gtk3 in our distribution, it should try hard to stay that way in |
104 |
> upcoming versions as well. |
105 |
> |
106 |
> * Some exceptions to the above may exist under heavy consideration, |
107 |
> especially in cases where the toolkit usage is complex and may have |
108 |
> some issues for some, but in general gtk3 support is deemed good by |
109 |
> upstream. Most notable here would be browsers like firefox and |
110 |
> chromium, which are using gtk dependency more for emulating the theme |
111 |
> it uses, rather than using it as its real toolkit. If such exceptions |
112 |
> are allowed, the USE flag naming here must be consistent amongst the |
113 |
> exceptions. My proposal would be USE=force-gtk2 then, as I have no |
114 |
> better ideas without stomping on the USE=gtk{2,3} historical meaning. |
115 |
> |
116 |
> |
117 |
> When arguing in favor of supporting gtk2 builds more for apps, please |
118 |
> do keep in mind that gtk2 really is pretty much dead. And no, MATE, |
119 |
> XFCE and others are NOT continuing its support; they are just slow in |
120 |
> fully converting to gtk3, but they are doing so and I expect both of |
121 |
> those to be fully done this year, around autumn. |
122 |
> If the issue is political or just a general gnome3 or gtk3 hate, then I |
123 |
> would ask you to keep your political opinions or hate outside this |
124 |
> thread and go contemplate on more important life issues. |
125 |
> If the issue is lack of themes, then I would like you to help package |
126 |
> more gtk3 themes. gtk3.20 now has a stable CSS based theme API and |
127 |
> themes shouldn't be breaking anymore beyond this point, theoretically. |
128 |
> And gtk3 theme packages should pretty much just be CSS files and some |
129 |
> metadata. Though we have yet to get over that bumpy thing yet (a main |
130 |
> reason gtk3.20 isn't in main tree yet). |
131 |
> |
132 |
> Thoughts? Agreements? Suggestions? |
133 |
> I'm particularly interested in QA opinion here. I believe WilliamH |
134 |
> wanted to spearhead this from their side. |
135 |
> |
136 |
> |
137 |
> Regards, |
138 |
> Mart Raudsepp |
139 |
> Gentoo developer, GNOME team |
140 |
> |
141 |
As far as I'm concerned, if any package I maintain offers both gtk2 and |
142 |
gtk3 support, it would be irresponsible for me to *not* offer that |
143 |
choice. Gentoo is about flexibility and giving power to the user. Choice |
144 |
is a central part of that, and basically *the* reason I switched to |
145 |
Gentoo or bothered to become a developer. |
146 |
|
147 |
GTK3 might be fine for some, or in some applications. In my experience, |
148 |
the theme is terrible (and a, frankly, half-assed promise from upstream |
149 |
that they'll keep the API stable is not reassuring given their history |
150 |
of quicksand APIs), scrollbars resize and disappear, the file choosing |
151 |
dialog is worse, and some features from GTK2 were dropped altogether. If |
152 |
GTK3 was largely a superset of what GTK2 offered, had better theming, |
153 |
was more stable, etc, I don't think any of us would be debating much |
154 |
about it. The fact of the matter is GTK3 has been handled poorly by |
155 |
upstream. That's evidenced by the sheer amount of pushback they've |
156 |
received from both users and developers, and the fact that yet again |
157 |
we're having a discussion about dropping GTK2. Some projects that used |
158 |
to use GTK are also switching to Qt due to the ever-changing APIs. The |
159 |
LXDE team is one such team as they are working on LXQt. |
160 |
|
161 |
You mentioned that there are security concerns that haven't been fixed |
162 |
in GTK2. Can you link to some? If they're so bad, why haven't we seen |
163 |
GLSAs about them? |
164 |
|
165 |
You also mentioned that Mate and XFCE won't be supporting GTK2. Got any |
166 |
links there? |
167 |
|
168 |
Ultimately I don't care about the USE-flag naming problem. I'm in favor |
169 |
of USE="gtk" meaning "support the latest gtk version". That's sane and |
170 |
fair behavior. Using "gtk2" and "gtk3" for library support makes sense, |
171 |
just like qt4 and qt5. Changing "gtk2" to "force-gtk2" in library |
172 |
consumers is fine, too. As long as we don't get people telling others |
173 |
that their choices, as developers or users, aren't important and |
174 |
attempting to get GTK2 dropped from the tree altogether. If it compiles |
175 |
and it works, there's no good reason to drop it yet. |
176 |
|
177 |
I will maintain GTK2 compatibility in any package I maintain until GTK2 |
178 |
simply stops working altogether. It's what the users deserve and is most |
179 |
representative of my upstreams. If you want to discuss USE flag name |
180 |
changes, I'm all eyes. As long as we agree on something tree-wide. |
181 |
|
182 |
Lastly... |
183 |
|
184 |
> Some exceptions to the above may exist under heavy consideration, |
185 |
> especially in cases where the toolkit usage is complex and may have |
186 |
> some issues for some, but in general gtk3 support is deemed good by |
187 |
> upstream. |
188 |
|
189 |
Of course upstream is going to say support is good. Consider the source. |
190 |
If they only write the toolkit and don't build real-world applications, |
191 |
with real users, around it, how can their opinion be trusted? Also |
192 |
consider said source's history. No upstream that I've spoken with has |
193 |
relished working with GTK3. Maybe that will change with 3.20, if it's as |
194 |
good as GNOME upstream is claiming. I'll be part of the group that sits |
195 |
and waits. Results matter to me more than empty promises. |
196 |
|
197 |
Just my two cents. |
198 |
|
199 |
~zlg |
200 |
|
201 |
-- |
202 |
Daniel Campbell - Gentoo Developer |
203 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
204 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |