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
categories:
- backends: gtk+/gtkmm, cairo, weston, eventd, SDL, cogl, clutter
- some prefer "platform": mesa, libva
- helper libs or tool: libxkbcommon, gdk-pixbuf, dbus, ffmpeg,
pulseaudio
- 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
_______________________________________________
Exherbo-dev mailing list
[email protected]
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
