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