[gentoo-dev] Choosing GUI toolkits from multiple choices

[gentoo-dev] Choosing GUI toolkits from multiple choices

[Mart Raudsepp]

Ühel kenal päeval, R, 03.06.2016 kell 22:40, kirjutas Daniel Campbell:
> You touched on the part that I'm most concerned about: choosing. If
> the
> 'GUI' USE_EXPAND gets in, do we maintainers check that variable and
> if
> there's no preference just build whatever? Will we not be expected to
> emit an ewarn or something similar to clarify *why* the package is
> being
> built a certain way? Granted, if a user has a problem and reports a
> bug,
> their make.conf's GUI variable should be present in emerge -v output,
> easily explaining the issue.

Said 'GUI' USE_EXPAND is outside the intended scope of the USE=gui
thread, but anticipating discussion will happen regardless now, I've
cut the thread and named it something else.
Many discussions have happened on IRC on this as well, which is where
Daniel got this from.


I think it's actually a rather corner-case to have an optional GUI, and
then that GUI being buildable against a selection of toolkits. Arguably
in some of those cases it might be more ideal to have the GUI parts in
a separate package too, but usually upstream sources aren't so
accommodating to our source-based case (while binary distributions
split it up into multiple binary packages, built from one source in one
go).
In most cases when there's a choice, a GUI imho isn't usually optional.
You choose e.g qt4 or qt5, or gtk3 or qt5 and having both shipped is
not so common from the same package. Transmission is an example where
it is, because they have a multiple frontend system (arguably it would
be neat to have these in separate transmission-qt, transmission-gtk and
so on packages), and one of these can be a web service UI instead of a
dedicated graphics toolkit.

USE=gui would replace a ton of USE=gtk's at least, where it's mostly
about simple extra GUI tools added with a gtk2 dep, but I've seen it in
other toolkit cases too, but I don't know how common it is there.
Ideally USE=gui can be agreed upon while ignoring the corner-case of
multiple choices; in some of these cases it might make sense to ignore
USE=gui at the start, until the multiple choice case gets some
resolution though, e.g emacs and perhaps transmission could just keep
the current way until we agree how to express multiple choice cases
universally.

I drafted that mentioned USE_EXPAND idea as a means to get some 'design
from the scratch' discussion going and flesh out this way of
potentially doing it (such a USE_EXPAND was idly mentioned at start by
others as something that was deemed too crazy, but I didn't find any
references). It is currently still as a draft over at
http://piratepad.net/iwvgjB1P5d -  but I didn't want the original
USE=gui thread to discuss this, as it's a separate and much more
complex matter really, and would work in tandem with USE=gui when
appropriate.

> It's the implementation that gets me here, not the idea. The idea
> could
> be neat and make Gentoo management easier at the expense of some
> (hopefully) minor ebuild bloat. Another issue that hasn't been
> covered
> well yet is how are we going to select DEPENDs? I was told DEPEND
> doesn't support exactly-one-of, and we don't want extraneous
> dependencies.

The part of it being not clear (due to the intentional lack of
REQUIRED_USE usage in that design) what is getting built is probably
the main drawback of that drafted idea, and some QA members tell me
this would be outright vetoed as a QA violation.

This uncertainty also echoes in the need for these complex DEPEND atoms
as well then, based on maintainer chosen preference, combined with user
set flags.

So it isn't ideal at all indeed, and we'd need to really do the
suggested EAPI/package manager improvements first, to express this
maintainer order of preference to the user and filter the flags somehow
to what will actually be chosen then before the DEPEND atoms get
processed, which would make the *DEPENDs feasible, as you could
simplify the conditionals, because the unused (but set by user) USE
flags are already filtered out then (or one added when user didn't have
any, and one would be chosen by default).

I ruled out REQUIRED_USE because I don't like it at all when it is used
together with common global USE flags, as opposed to just some local
flags. In my opinion it tends to results in users disabling or enabling
something globally, instead of locally for the package in question. And
with that having made the choice unknowingly for a ton of future
packages to be installed as well. pkg_pretend is a bit better, because
you can customize the error message to be readable, but it's still
something that takes away my choice of not having to care.. just give
me a GUI, preferably a gtk3 one, ok? thx.

> Transmission is a good example: supports gtk3, qt4, qt5. Let's say
> the
> maintainer prefers the qt5 version. Would we do this?:
> 
> DEPEND="gui_qt5? ( dev-qt/qtcore:5 ) gui_qt4? ( dev-qt/qtcore:4 )
> gui_gtk3? ( x11-libs/gtk+:3 )"
> 
> or this?:
> 
> DEPEND="gui_qt5? ( !gui_qt4? ( !gui_gtk3? ( dev-qt/qtcore:5 ) ) )"
> 
> (snipping because I don't feel like writing it all out)

Transmissions is a good example indeed, but not in the way you describe
here, because transmission can be built with gtk and qt in parallel. So
it's a good example of what a hypothetical EAPI-next markup for
describing this order of choices would have to support. qt4 or qt5 or
neither is one choice. gtk2 or gtk3 or neither another. And none of
them have to be there, so if USE=-gui, GUI="..." is ignored, but with
USE=gui and GUI="<empty>" a qt5 choice would be made.
I wonder if the same syntax as REQUIRED_USE can be used for expressing
this, sans order of priority (unless it can be implicit from the order
of things listed).

If we had some way to express this, similar to REQUIRED_USE, that part
could take care of simplifying the DEPEND to
"gui? (
 gui_qt5? ( dev-qt/qtgui:5 )
 gui_qt4? ( dev-qt/qtgui:4 )
 gui_gtk3? ( x11-libs/gtk+:3 )
 gui_gtk2? ( x11-libs/gtk+:2 ) )"
if it would override the flags to what will be chosen for us already at
this point via some markup like
GUI_PREFS="gui? ( || ( ?? ( gui_qt5 gui_qt4 )  ?? ( gui_gtk3 gui_gtk2 )
) )"
if we can default to the first of each branch of choice, or something
more complex to sequence these choices.

This could also probably be achieved one way or another via an eclass
(or maybe not - the rules of global variables like *DEPEND are rather
strict and I'm not sure you can influence them sufficiently via an
eclass), but that doesn't solve the issues of package manager not
really knowing what happened (apparently bad for binary packages), and
the user not knowing what's going on without reading the ebuild.

Brainstorming welcome on this, but a medium like IRC might be more
constructive at this point for that purpose.


Mart

Re: [gentoo-dev] Choosing GUI toolkits from multiple choices

[Mart Raudsepp]

> I drafted that mentioned USE_EXPAND idea as a means to get some
> 'design from the scratch' discussion going and flesh out this way of
> potentially doing it (such a USE_EXPAND was idly mentioned at start
> by
> others as something that was deemed too crazy, but I didn't find any
> references). It is currently still as a draft over at
> http://piratepad.net/iwvgjB1P5d

For the javascript restricted and for purposes of in-line quoted
replies, here's the current state of my braindump there copied to e-
mail here:


The following draft concerns only applications.
Libraries should continue using qt4 and qt5 USE flags when they are
about libraries (linking against qt4 or qt5), where it's mostly a
matter of USE depends by consumer apps or higher level libraries, not
user choice for applications.
For gtk case, we would use IUSE="gtk2" and IUSE="gtk3" in this case,
but ideally they would be in separate slots or packages. In gtk case,
this is for things like avahi, gtk-vnc, caribou, libcanberra - things
that provide a library or module that links against given gtk SLOT or
implements a gtk module for that SLOT with the given IUSE.
The remainder concerns only applications, as we don't like to use the
same flag name for different concepts (library support vs application
toolkit version choice), and USE="gtk" might be something we could
perhaps get rid of, in favor of moving gtk2 libraries to IUSE="gtk2"
and application choice to IUSE="gui" or the proposed GUI USE_EXPAND.



use.desc:

gui - Enable an optional GUI

use.desc/gui.desc:

athena - Choose the MIT Athena widget set
gtk - Build a <pkg>x11-libs/gtk+</pkg> based GUI
motif - Build a <x11-libs/motif> toolkit based GUI
sdl - ...
qt4 - Build a Qt4 toolkit based GUI
qt5 - Build a Qt5 toolkit based GUI
wxwidgets - Build a wxWidgets based GUI
Xaw3d - Build a 3d athena widget set based GUI


Many of current IUSE=gtk should move to IUSE=gui when it's about
application GUIs.
Some of IUSE=gtk will move to version specific IUSE=gtk2 and IUSE=gtk3
when it's about libraries.
Not sure if anything will remain then. If it does, we'll need to think
about it then, or figure it out of the masses of IUSE=gtk users
beforehand.
An old mapping was partially conducted a while ago on https://docs.goog
le.com/spreadsheets/d/19sJuupspkY65FrU6b4U7gEWKiOgFGQwyXYdPCAvPqBo/edit
#gid=0

In no circumstance is a REQUIRED_USE or an equivalent pkg_pretend
limitation allowed when dealing with gui USE_EXPAND.

- A package has optional support for a GUI, written in any GUI toolkit
(but only one)
-- IUSE="gui" and depend and build against the toolkit it uses. No
toolkit specific USE_EXPAND should exist, as there's nothing to choose.
Example: wicd. USE="gui" shall build the gtk based GUI

- A package has optional support for a GUI, and that GUI can be chosen
to be either gtk, qt4 or qt5 based, but only one of them
-- IUSE="gui gui_gtk gui_qt4 gui_qt5". If user has USE="gui" disabled
for the package, don't build any GUI. If it's enabled, have a
maintainer chosen preferred order of toolkit to use, then choose
whichever highest priority toolkit flag is enabled by user. If no
supported toolkit flag is chosen, choose the highest priority one.
Example: ???

- A package has a required GUI, but the GUI can be chosen to be either
gtk, qt4 or qt5 based, but only one of them
-- Same as previous, but no IUSE="gui" as a GUI is not optional
Example: ???

- A package has optional GUI frontends in a way that multiple can be
built and shipped at once.
-- IUSE="gui" to have any GUI at all, if user hasn't it set, gui_*
values do not matter - no GUI will be built at all. If user has
USE="gui" set, all of the user enabled gui_* frontends will be built.
If user has no gui_* enabled at all that this package implements, but
USE="gui" is set, then a maintainer chosen first choice GUI is built.
Example: transmission with IUSE="gui gui_gtk gui_qt"

- Same case as previous, but some toolkits are exclusive, e.g one can
build both a gtk frontend and a qt frontend, but not both qt4 and qt5
frontend.
-- Same USE="gui" behaviour. If multiple exclusive flags are set, they
have an independent priority order, similar to when only one can be
built. So with GUI="gtk qt4 qt5", a gtk and a qt5 frontend would be
built when both qt4 and qt5 can't be. To choose qt4 frontend, qt5 has
to be disabled by user for this package.

- Same as prior 2 cases but a GUI is not optional (e.g lack of frontend
doesn't make sense)
-- Same, but no IUSE="gui"



Suggestions for users approach of the GUI="" setting in make.conf:

* If you don't care which toolkit is used, but rather would have the
preferred one chosen for you, don't set it at all, but keep it empty.
Do set USE="gui" if you want a GUI for where it's optional.
* If you strongly prefer a given toolkit or toolkits, set that/those in
GUI="..."; it will be then chosen whenever possible (if multiple, a
maintainer decided preference will be chosen, if only one toolkit
frontend is available; otherwise all of them will be built). If the
program doesn't support building against that toolkit, a different
choice will automatically be made for you. If you want to tweak that
choice (e.g it pulls in a toolkit you want to avoid completely), tweak
the flags in package.use

Raised concerns:

* With gui as the USE_EXPAND, a GUI variable from make.conf will
apparently be exported to all ebuild environments, even if not used,
which might mean something for the build environment of the given
package.
* The dependency conditionals can get very messy with the priority list
of toolkits

Possible future improvement ideas:

* Make USE_EXPAND able to declare a priority list at ebuild level with
some syntax, so that it would express it once, and then unset the GUI
choices that won't be used due to exclusivety for DEPEND parsing, to
make this clearer. Then this priority can be expressed to the user
somehow by PM.
* Record the filtered choices made in VDB (or similar for other PMs),
so the package manager would know which toolkit was actually chosen.
* Allow giving a priority for users as well, e.g GUI="1|gtk 2|qt4
2|qt5" or some different syntax, which would then influence that
priority when possible (in this case prioritize gtk over others, and
qt4/qt5 have equal priority over that - as they are equal, the ebuild
priority between them counts instead).

This might then morph it into something other than USE_EXPAND in
terminology, but till then, USE_EXPAND allows us to group the choices
into one logical block.