[Exherbo-dev] GUI option standards

Quentin Glidic sardemff7 at exherbo.org
Tue Apr 12 09:29:55 UTC 2016

On 11/04/2016 19:36, Bernd Steinhauser wrote:
> Hi Kylie, thanks for bringing this up.
> On 11/04/16 18:32, Kylie McClain wrote:
>> Hi everyone,
>> I was working on making some changes to sys-devel/cmake, and I got
>> to thinking about the inconsistency we seem to have when it comes
>> to representing options for GUIs. We have some packages which have
>> just [providers:{gtk2,gtk3,qt4,qt5}], packages which have `X? ( (
>> providers: ... ) )`, packages with just [qt4], [gtk3], and so on,
>> andd the lack of consistency is kinda stupid.
> Not sure providers would be appropriate. One would maybe conclude
> that they all do the same, which is not necessarily the case.

Providers make sense for application wanting “a toolkit” to display
their windows on screen ; so gtk2/gtk3/qt4/qt5 are fine as providers.
But providers should not be used to enable a feature, IMO, they should
[[ requires = gui ]] if the option is there.

>> It is my opinion that we should unify these using a new option:
>> [gui], and then provide the setting of the toolkit of choice (if
>> there is an option) via providers: suboptions.
> Yeah, that was my proposal a few years ago. Due to laziness (or
> something else), we didn't come to a conclusion back then. The main
> question is: How do you handle different purposes of the option? Most
> of them would fit in gui:, but some won't. e.g. if it builds
> libraries that will enable support for the toolkit (bindings or
> similar).
>> This would replace the [X] option's usage as a way to decide if
>> graphical interfaces should be built into programs, and would
>> prepare us for whenever The Year of the Wayland desktop is here
>> again.
> The X option sucks and it always did. That's an artifact we took
> over from Gentoo and it's a bad one. Since it's a global option (and
> thus nobody sets a package-specific description), nobody really knows
> what it will do if enabled. Sometimes it will build some kind of gui,
> sometimes it will enable some weird libX11 thing, sometimes it's just
> some weird X-related library it uses etc, or even support for a
> different toolkit, that just happens to run under X.

On my "*/* -X" system, I enable X on some packages.
 From that list and some I happen to know about, most fit in three 
- backends: gtk+/gtkmm, cairo, weston, eventd, SDL, cogl, clutter
     - some prefer "platform": mesa, libva
- helper libs or tool: libxkbcommon, gdk-pixbuf, dbus, ffmpeg,
- gui

I pushed to Gerrit[1] the addition of a "backends:" suboption for the 
first group to use. For some of them, we could split the "X" backend to 
Xlib and xcb, but I am not sure it is worth the effort.

The second group could keep the "X" option, IMO. Maybe a rename for some 
of them, like ffmpeg, where the feature is more specific.

The third group should use the new gui option.

> Unfortunately, there was noone so far to just step forward and kill
> the damn thing.
> Or to summarize that in a different way: We have the possibility to
> easily define local options and local option descriptions. We should
> make use of that *way* more often and *only* use global option
> descriptions where it really makes sense and in case of the X option,
> it just does not.

I agree that the global "X" description should die.
We can probably keep global description for the toolkit providers though.
As for backends, I am not sure. Local descriptions are probably better, 
but at least half the cases (toolkits) would use the same.

Do we have any QA tool to detect missing descriptions?

A quick cave-foo[2] gives me a list of 54 packages[3] having the X 
option. It is not that much, and we know most of them from the top of 
our heads, making it easy to tag them in one of the three groups.

[1] <https://galileo.mailstation.de/gerrit/#/c/5787/>
[2] cave print-ids -m '*/*[.MYOPTIONS<X]' -f '%c/%p\n'|sort -u
[3] <http://paste.pound-python.org/raw/USpIaaviG1Gh5eQNZT0y/>


Quentin “Sardem FF7” Glidic

More information about the Exherbo-dev mailing list