Toolkit USE Flags

This page Article description::summarizes main points from discussions about toolkit (GTK, QT) USE flags (gtk2, gtk3, qt4, qt5, etc.). The centithreads go back to 2005. It seems sometimes the discussion is going in circles, and it's hard to read all of the previous replies. This is an attempt to summarize the main points, pros and cons, to facilitate a more productive and informed effort towards a usable solution.

Use cases

List of use cases (i.e. scenarios people want to work, or things that happen with packages, etc):

Enable just gtk2 for just gtk2 support if available
app-i18n/uim , x11-themes/light-themes --> flag provides support for gtk3 apps, in addition to gtk(2)
gnome-base/librsvg --> flag for gtk3 libraries *and* executables
media-sound/audacious --> REQUIRED_USE="^^ ( gtk gtk3 )" with default switching from version to version (current stable is gtk, previous was gtk3)
www-client/midori --> USE=deprecated instead of USE=gtk3 in unstable
media-libs/libcanberra --> USE=gtk3 enables extra support, in addition to gtk: "Enables building of gtk+3 helper library, gtk+3 runtime sound effects and the canberra-gtk-play utility. To enable the gtk+3 sound effects add canberra-gtk-module to the colon separated list of modules in the GTK_MODULES environment variable." — very unclear: is it needed? recommended? also, why doesn't the package handle the environment variable by itself?
we need to ship webkit with gtk2 and gtk3 support
MATE desktop can be built against gtk+ 2 or gtk+ 3, and upstream supports doing both
a single process cannot load both gtk2 and gtk3 - you *will* get random crashes
only three packages (providing libs) needed exception to the rule to avoid unreasonable maintenance overhead: spice, gtk-vnc and avahi
Let's take Emacs as an example. The upstream package supports Athena widgets (both in Xaw and Xaw3d variants), Motif, GTK2, and GTK3.
You're trying to compare gtk to qt directly. They are not the same. gtk regards only the graphic library, qt is a library of utility functions too. Qt can be considered like gtk+glib, and that make things more complex.
users that currently have -qt are going to be confused when it no longer does what they expect
The gtk 'solution' forced some ugly things like masking gtk+:3, gconf:3, ... and then selecting packages based on specific -r200 / -r300 revisions. So much work to avoid regressing into gtk3!
QA has spoken out pretty clearly against unversioned gtk or qt useflags, and in favour of explicit versioned useflags.
x11-misc/spacefm supports multiple toolkits as well
I would really like a way to toggle gtk3 for testing
Suppose you want to run on an embedded system with limited RAM and the ability to choose means you can use one of the two libraries exclusively, thus eliminating the need to load the other library?

Approach	Open questions	Pros	Cons	Supporters	Opponents
gui = some toolkit (if a GUI is optional) gtk = gtk toolkit support (not for enabling/disabling the GUI itself) gtkN = gtkN support (only if multiple Ns are supported)		"just works"; most users and most profiles wouldn't need to globally set toolkit flags, desktop profile enables USE=gui	users who for some reason really hate qt5 or gtk3 won't have one single button to disable them packages where currently gtk means gtk2 will need to be updated	rich0 axs	(opponents placeholder)
gtk = any version, gtkN = gtkN support	what does "-gtk gtk2" mean? what does "gtk gtk2" mean? how to build without gtk support where possible, but when necessary prefer gtk2 over gtk1? is there a legitimate reason to use gtk1 if gtk2 support is usable? why REQUIRED_USE? A package can prefer one of the alternatives if both flags are specified	no need to globally mandate which version is default puts user in control of which version of gtk is used just telling users to set USE=qt and forget about it unless you really care seems pretty simple	may confuse users gtk2 may be pulled even with USE="-gtk2" users have to use USE='gtk gtk3' to get GUIs in random applications that support only one toolkit. And then handle REQUIRED_USE mess for packages that support choosing one of the two may create problem for distro as a whole, i.e. what flags to put in default profiles it is unreasonable to try to support two configuration where one is dying slowly due to upstream (gtk) maintainer focus being elsewhere qt3 and qt4 are both huge, so if at all possible, I'd like to not see a requirement to install both qt3 and qt4 just to get poppler-bindings support for one (which would be required with a single flag)	ferringb steev tomwij genone	tester jakub hasufell eva ssuominen
gtk = "best" gtk version support (maintainer's choice, newest gtk is recommended) gtkN = only in exceptional cases gtkN flag usually avoided via slots and package splitting	when dozens of packages in the tree have gtk3 in IUSE, does "exceptional cases" policy make sense?	slots instead of flags reduce compile time when a user needs to enable/disable a toolkit flag (important for heavy packages like webkit-gtk)	rev-separated slots instead of flags can be seen as a hack recommendation to pick one toolkit version limits maintainer choice - "I just don't think we should be in the business of saying 'no' here."	current gnome team policy	rich0
gtkN = gtkN support, no non-versioned gtk	(open questions placeholder)	if some day gtk4 comes around, we will be able to introduce support for it in the tree by simply adding USE="gtk4", without having to re-structure half the tree	policy is less precise and might bring more confusion 'qt4 qt5' may now mean either both toolkits or one of them	wired ulm creffett flameeyes truedfx kevquinn patrick	(opponents placeholder)
gtk=newest GTK version, gtkN=only for older versions	(open questions placeholder)	(pros placeholder)	what 'qt' means changes as new releases are made - if/when qt5 becomes available, it means introducing a qt4 use flag and back-fitting to existing ebuilds that used 'qt' but don't build against qt5	dberkholz	(opponents placeholder)
remove gtkN, make latest version default, possibly add USE flags or separate packages for deprecated versions	does this reflect usage of the flags in the tree? what's about maintainer wish to support both of toolkits?	(pros placeholder)	takes away control from people using gtkN correctly doesn't address packages that use gtkN legitimately	spider carlo hasufell tetromino eva tsunam caleb	robbat2 vapier
USE_QT_VERSIONS in make.conf, and single qt USE flag	(open questions placeholder)	(pros placeholder)	would require quite a bit of effort for a single special case, depending how exactly you want to implement it it's likely gonna screw up with the cache as well	beandog	genone
eselect module	(open questions placeholder)	(pros placeholder)	neglects the case where a user just wanted to say "use the best version of qt for any particular package" ; It may not make sense to have one global preference system-wide, and managing it per-package is painful that afaik isn't something that would be permitted in global scope and so RDEPEND wouldn't be changed issues with binary packages, as right now the use flag settings partly determine whether a binpkg can be applied on another system	(supporters placeholder)	(opponents placeholder)
fork Gentoo for legacy toolkit support	(open questions placeholder)	(pros placeholder)	(cons placeholder)	marduk	chriswhite

This article is issued from Gentoo. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.