[RFC] Global USE=gui

classic Classic list List threaded Threaded
76 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[RFC] Global USE=gui

Mart Raudsepp-2
Hello,

So here's something more simple wrt GUI USE flags.

Global USE=gui for
gui - enable an optional graphics user interface or extra GUI tool

(wording improvements welcome, once it's in principle agreed; but no
point in bikeshed painting description wording till it is)

Local USE flag description overrides to specify exactly what extra tool
is built and installed with the flag are encouraged.


This is meant to cover the cases where a package has an optional GUI,
as a user facing graphical application, whichever the toolkit.

It is meant as a feature based USE flag, as opposed to the "extra dep"
based USE flags we've been using for this.
There are a lot of those with USE=gtk right now. In many cases it's
some little add-on graphical utility for a library, or some graphical
configuration GUI in addition to command line, or some bigger cases in
more modular packages that provide multiple frontends, and not all of
them are graphical, but CLI or TUI (TUI meaning ncurses-based or
similar).
Also there are various with USE=X where it's also about that, but X
isn't the only way to do GUI these days (any gtk3 app that doesn't
directly use libX11/libxcb/etc themselves natively supports wayland,
for example).

Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
available in only one toolkit version. So hence feature based flag, not
dependency-based.

http://tinyurl.com/gtk-use was an old analysis of USE=gtk usage in tree
by Gilles over a year ago. That suggests that at least 80+ USE flags
should be then USE=gui instead of USE=gtk out of that analyzed USE=gtk
subset alone, not counting USE=X and others.

There are some other things in the ideas pipeline for when there are
multiple toolkit choices, but that's something for a different thread,
a different day and more controversial.


Mart

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

NP-Hardass-2
On 06/01/2016 10:29 AM, Mart Raudsepp wrote:

> Hello,
>
> So here's something more simple wrt GUI USE flags.
>
> Global USE=gui for
> gui - enable an optional graphics user interface or extra GUI tool
>
> Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
> of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
> available in only one toolkit version. So hence feature based flag, not
> dependency-based.
>
I know that it was previously mentioned that there was discussion about
this long ago, but I'm not familiar with those discussions. Is someone
more familiar with those discussions able to bring up the talking points?

One issue that springs to mind though is, let's say a pkg supports only
qt4 for a gui, you'd have the gui flag. Upstream adds qt5 support.  Do
you keep the gui flag and make qt4 and qt5 dependent on it, or do you
remove the gui flag?  I feel like the latter might lead to confusion,
while the former suggests that the flag should be used more generally
than just one toolkit/version being available.
>
> Mart
>

--
NP-Hardass


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

Damien Levac

On 2016-06-01 11:19 AM, NP-Hardass wrote:

> On 06/01/2016 10:29 AM, Mart Raudsepp wrote:
>> Hello,
>>
>> So here's something more simple wrt GUI USE flags.
>>
>> Global USE=gui for
>> gui - enable an optional graphics user interface or extra GUI tool
>>
>> Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
>> of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
>> available in only one toolkit version. So hence feature based flag, not
>> dependency-based.
>>
> I know that it was previously mentioned that there was discussion about
> this long ago, but I'm not familiar with those discussions. Is someone
> more familiar with those discussions able to bring up the talking points?
>
> One issue that springs to mind though is, let's say a pkg supports only
> qt4 for a gui, you'd have the gui flag. Upstream adds qt5 support.  Do
> you keep the gui flag and make qt4 and qt5 dependent on it, or do you
> remove the gui flag?
The way I understand it, the 'gui' flag guarantees a GUI to be built,
not which one. I assume it would default to upstream recommendation or
the gentoo dev's judgement.
> I feel like the latter might lead to confusion,
> while the former suggests that the flag should be used more generally
> than just one toolkit/version being available.
>> Mart
>>


Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

Daniel Campbell (zlg)
In reply to this post by Mart Raudsepp-2
On June 1, 2016 7:29:55 AM PDT, Mart Raudsepp <[hidden email]> wrote:

>Hello,
>
>So here's something more simple wrt GUI USE flags.
>
>Global USE=gui for
>gui - enable an optional graphics user interface or extra GUI tool
>
>(wording improvements welcome, once it's in principle agreed; but no
>point in bikeshed painting description wording till it is)
>
>Local USE flag description overrides to specify exactly what extra tool
>is built and installed with the flag are encouraged.
>
>
>This is meant to cover the cases where a package has an optional GUI,
>as a user facing graphical application, whichever the toolkit.
>
>It is meant as a feature based USE flag, as opposed to the "extra dep"
>based USE flags we've been using for this.
>There are a lot of those with USE=gtk right now. In many cases it's
>some little add-on graphical utility for a library, or some graphical
>configuration GUI in addition to command line, or some bigger cases in
>more modular packages that provide multiple frontends, and not all of
>them are graphical, but CLI or TUI (TUI meaning ncurses-based or
>similar).
>Also there are various with USE=X where it's also about that, but X
>isn't the only way to do GUI these days (any gtk3 app that doesn't
>directly use libX11/libxcb/etc themselves natively supports wayland,
>for example).
>
>Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
>of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
>available in only one toolkit version. So hence feature based flag, not
>dependency-based.
>
>http://tinyurl.com/gtk-use was an old analysis of USE=gtk usage in tree
>by Gilles over a year ago. That suggests that at least 80+ USE flags
>should be then USE=gui instead of USE=gtk out of that analyzed USE=gtk
>subset alone, not counting USE=X and others.
>
>There are some other things in the ideas pipeline for when there are
>multiple toolkit choices, but that's something for a different thread,
>a different day and more controversial.
>
>
>Mart

This idea is solid imo, but only in the case where there's a single (optional) GUI to use. We've discussed the finer points of this on IRC and, as you noted, the specifics need some more input and refinement, but in essence I like and support this idea.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

Michał Górny-5
In reply to this post by Mart Raudsepp-2
On Wed, 01 Jun 2016 17:29:55 +0300
Mart Raudsepp <[hidden email]> wrote:

> Hello,
>
> So here's something more simple wrt GUI USE flags.
>
> Global USE=gui for
> gui - enable an optional graphics user interface or extra GUI tool
>
> (wording improvements welcome, once it's in principle agreed; but no
> point in bikeshed painting description wording till it is)

How about:

gui - Enable an optional graphics user interface. If multiple variants
of the GUI are available, additional flags may provide a more
fine-grained choice of them.

--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

NP-Hardass-2
On 06/01/2016 12:21 PM, Michał Górny wrote:

> On Wed, 01 Jun 2016 17:29:55 +0300
> Mart Raudsepp <[hidden email]> wrote:
>
>> Hello,
>>
>> So here's something more simple wrt GUI USE flags.
>>
>> Global USE=gui for
>> gui - enable an optional graphics user interface or extra GUI tool
>>
>> (wording improvements welcome, once it's in principle agreed; but no
>> point in bikeshed painting description wording till it is)
>
> How about:
>
> gui - Enable an optional graphics user interface. If multiple variants
> of the GUI are available, additional flags may provide a more
> fine-grained choice of them.
>
This resolves the question in my previous post.  So, if using the
premise that it'd apply for all gui selection, and specific gui
libs/flags are dependent on the gui flag via REQUIRED_USE or another
means, then that SGTM.

--
NP-Hardass


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

Ian Stakenvicius-2
In reply to this post by NP-Hardass-2
On 01/06/16 11:19 AM, NP-Hardass wrote:

> On 06/01/2016 10:29 AM, Mart Raudsepp wrote:
>> Hello,
>>
>> So here's something more simple wrt GUI USE flags.
>>
>> Global USE=gui for
>> gui - enable an optional graphics user interface or extra GUI tool
>>
>> Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
>> of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
>> available in only one toolkit version. So hence feature based flag, not
>> dependency-based.
>>
> I know that it was previously mentioned that there was discussion about
> this long ago, but I'm not familiar with those discussions. Is someone
> more familiar with those discussions able to bring up the talking points?
>
> One issue that springs to mind though is, let's say a pkg supports only
> qt4 for a gui, you'd have the gui flag. Upstream adds qt5 support.  Do
> you keep the gui flag and make qt4 and qt5 dependent on it, or do you
> remove the gui flag?  I feel like the latter might lead to confusion,
> while the former suggests that the flag should be used more generally
> than just one toolkit/version being available.
This would be the:

>> There are some other things in the ideas pipeline for when there are
>> multiple toolkit choices, but that's something for a different thread,
>> a different day and more controversial.

...portion. :)



signature.asc (220 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

Daniel Campbell (zlg)
In reply to this post by Michał Górny-5
On 06/01/2016 09:21 AM, Michał Górny wrote:

> On Wed, 01 Jun 2016 17:29:55 +0300
> Mart Raudsepp <[hidden email]> wrote:
>
>> Hello,
>>
>> So here's something more simple wrt GUI USE flags.
>>
>> Global USE=gui for
>> gui - enable an optional graphics user interface or extra GUI tool
>>
>> (wording improvements welcome, once it's in principle agreed; but no
>> point in bikeshed painting description wording till it is)
>
> How about:
>
> gui - Enable an optional graphics user interface. If multiple variants
> of the GUI are available, additional flags may provide a more
> fine-grained choice of them.
>
Pretty much nailed it as far as I'm concerned.

--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

NP-Hardass-2
In reply to this post by Ian Stakenvicius-2
On 06/01/2016 12:52 PM, Ian Stakenvicius wrote:

> On 01/06/16 11:19 AM, NP-Hardass wrote:
>> On 06/01/2016 10:29 AM, Mart Raudsepp wrote:
>>> Hello,
>>>
>>> So here's something more simple wrt GUI USE flags.
>>>
>>> Global USE=gui for
>>> gui - enable an optional graphics user interface or extra GUI tool
>>>
>>> Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
>>> of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
>>> available in only one toolkit version. So hence feature based flag, not
>>> dependency-based.
>>>
>> I know that it was previously mentioned that there was discussion about
>> this long ago, but I'm not familiar with those discussions. Is someone
>> more familiar with those discussions able to bring up the talking points?
>>
>> One issue that springs to mind though is, let's say a pkg supports only
>> qt4 for a gui, you'd have the gui flag. Upstream adds qt5 support.  Do
>> you keep the gui flag and make qt4 and qt5 dependent on it, or do you
>> remove the gui flag?  I feel like the latter might lead to confusion,
>> while the former suggests that the flag should be used more generally
>> than just one toolkit/version being available.
>
> This would be the:
>
>>> There are some other things in the ideas pipeline for when there are
>>> multiple toolkit choices, but that's something for a different thread,
>>> a different day and more controversial.
>
> ...portion. :)
>
>
Ah :)

--
NP-Hardass


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

Raymond Jennings
What about a global "default gui" somewhere in make.conf that says what GUI to use if a package provides multiple?

Relatedly, I also like having a general "qt" USE flag to select any/the best version of qt, and then having "qtX' for each version of qt...ditto for gtk and gtkX

On Wed, Jun 1, 2016 at 9:59 AM, NP-Hardass <[hidden email]> wrote:
On 06/01/2016 12:52 PM, Ian Stakenvicius wrote:
> On 01/06/16 11:19 AM, NP-Hardass wrote:
>> On 06/01/2016 10:29 AM, Mart Raudsepp wrote:
>>> Hello,
>>>
>>> So here's something more simple wrt GUI USE flags.
>>>
>>> Global USE=gui for
>>> gui - enable an optional graphics user interface or extra GUI tool
>>>
>>> Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
>>> of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
>>> available in only one toolkit version. So hence feature based flag, not
>>> dependency-based.
>>>
>> I know that it was previously mentioned that there was discussion about
>> this long ago, but I'm not familiar with those discussions. Is someone
>> more familiar with those discussions able to bring up the talking points?
>>
>> One issue that springs to mind though is, let's say a pkg supports only
>> qt4 for a gui, you'd have the gui flag. Upstream adds qt5 support.  Do
>> you keep the gui flag and make qt4 and qt5 dependent on it, or do you
>> remove the gui flag?  I feel like the latter might lead to confusion,
>> while the former suggests that the flag should be used more generally
>> than just one toolkit/version being available.
>
> This would be the:
>
>>> There are some other things in the ideas pipeline for when there are
>>> multiple toolkit choices, but that's something for a different thread,
>>> a different day and more controversial.
>
> ...portion. :)
>
>
Ah :)

--
NP-Hardass


Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

Walter Dnes
In reply to this post by Mart Raudsepp-2
On Wed, Jun 01, 2016 at 05:29:55PM +0300, Mart Raudsepp wrote

> It is meant as a feature based USE flag, as opposed to the "extra dep"
> based USE flags we've been using for this.
> There are a lot of those with USE=gtk right now. In many cases it's
> some little add-on graphical utility for a library, or some graphical
> configuration GUI in addition to command line, or some bigger cases in
> more modular packages that provide multiple frontends, and not all of
> them are graphical, but CLI or TUI (TUI meaning ncurses-based or
> similar).
> Also there are various with USE=X where it's also about that, but X
> isn't the only way to do GUI these days (any gtk3 app that doesn't
> directly use libX11/libxcb/etc themselves natively supports wayland,
> for example).
>
> Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
> of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
> available in only one toolkit version. So hence feature based flag, not
> dependency-based.

  I see this as at least a redundancy, if not a problem.  First, let's
look at the general case.  An optional "UI" (User Interface) is also
selected...
* via the "tools" useflag 78 times in use.local.desc
* via the "ncurses" useflag 10 times in use.local.desc.
* for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
  does "ncurses" show up in use.local.desc ???)

 There is no need for an additional "TUI" (Text User Interface) use flag
for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
"GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
thing they have in common is a hard-coded dependancy on graphics libs.
"GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
Using any of them tells you enough.  What do we accomplish by requiring
one more USE flag?  This will also make dependancy resolution of ebuilds
more complex, i.e. slower.  Why?

--
Walter Dnes <[hidden email]>
I don't run "desktop environments"; I run useful applications

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

Michał Górny-5
On Wed, 1 Jun 2016 13:53:31 -0400
[hidden email] wrote:

> On Wed, Jun 01, 2016 at 05:29:55PM +0300, Mart Raudsepp wrote
>
> > It is meant as a feature based USE flag, as opposed to the "extra dep"
> > based USE flags we've been using for this.
> > There are a lot of those with USE=gtk right now. In many cases it's
> > some little add-on graphical utility for a library, or some graphical
> > configuration GUI in addition to command line, or some bigger cases in
> > more modular packages that provide multiple frontends, and not all of
> > them are graphical, but CLI or TUI (TUI meaning ncurses-based or
> > similar).
> > Also there are various with USE=X where it's also about that, but X
> > isn't the only way to do GUI these days (any gtk3 app that doesn't
> > directly use libX11/libxcb/etc themselves natively supports wayland,
> > for example).
> >
> > Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
> > of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
> > available in only one toolkit version. So hence feature based flag, not
> > dependency-based.  
>
>   I see this as at least a redundancy, if not a problem.  First, let's
> look at the general case.  An optional "UI" (User Interface) is also
> selected...
> * via the "tools" useflag 78 times in use.local.desc
> * via the "ncurses" useflag 10 times in use.local.desc.
> * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
>   does "ncurses" show up in use.local.desc ???)
>
>  There is no need for an additional "TUI" (Text User Interface) use flag
> for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
> "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
> thing they have in common is a hard-coded dependancy on graphics libs.
> "GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
> Using any of them tells you enough.  What do we accomplish by requiring
> one more USE flag?  This will also make dependancy resolution of ebuilds
> more complex, i.e. slower.  Why?
Simple regular users don't want to be concerned with choice of toolkit
for every single package, as long as a GUI is provided. Furthermore,
this matches the recommended USE flag design where the more important
flags are provided as feature flags, while specific dependency choice
flags are minor.

--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

Walter Dnes
On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote

> [hidden email] wrote:
>
> >   I see this as at least a redundancy, if not a problem.  First, let's
> > look at the general case.  An optional "UI" (User Interface) is also
> > selected...
> > * via the "tools" useflag 78 times in use.local.desc
> > * via the "ncurses" useflag 10 times in use.local.desc.
> > * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
> >   does "ncurses" show up in use.local.desc ???)
> >
> >  There is no need for an additional "TUI" (Text User Interface) use flag
> > for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
> > "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
> > thing they have in common is a hard-coded dependancy on graphics libs.
> > "GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
> > Using any of them tells you enough.  What do we accomplish by requiring
> > one more USE flag?  This will also make dependancy resolution of ebuilds
> > more complex, i.e. slower.  Why?
>
> Simple regular users don't want to be concerned with choice of toolkit
> for every single package, as long as a GUI is provided.

  Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
make.conf.  This will *FORCE* a gui where applicable.

> Furthermore, this matches the recommended USE flag design where the
> more important flags are provided as feature flags, while specific
> dependency choice flags are minor.

  This is going to require *THREE* levels of flags, with the first one
being totally unnecessary...

Level 1) GUI

Level 2) X or xorg or Wayland or Mir

Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk

  Let me re-phrase my question... is there *ANY* set of circumstances
under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
can be set for a package *WITHOUT* requiring a gui?  I can see any of X
or xorg or Wayland or Mir being a requirement for any of
qt4/qt5/gtk2/gtk3/fltk.  But any of the Level 2 or Level 3 flags *FORCES*
a GUI of one sort or another.

  I repeat, requiring a "GUI" use flag for GUI apps makes as much sense
as requiring a "TUI" flag for commandline apps.  I hope I'm not giving
people ideas the wrong way.  No I don't want a "TUI" flag either.

--
Walter Dnes <[hidden email]>
I don't run "desktop environments"; I run useful applications

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

Michał Górny-5
On Wed, 1 Jun 2016 22:13:24 -0400
[hidden email] wrote:

> On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote
>
> > [hidden email] wrote:
> >  
> > >   I see this as at least a redundancy, if not a problem.  First, let's
> > > look at the general case.  An optional "UI" (User Interface) is also
> > > selected...
> > > * via the "tools" useflag 78 times in use.local.desc
> > > * via the "ncurses" useflag 10 times in use.local.desc.
> > > * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
> > >   does "ncurses" show up in use.local.desc ???)
> > >
> > >  There is no need for an additional "TUI" (Text User Interface) use flag
> > > for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
> > > "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
> > > thing they have in common is a hard-coded dependancy on graphics libs.
> > > "GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
> > > Using any of them tells you enough.  What do we accomplish by requiring
> > > one more USE flag?  This will also make dependancy resolution of ebuilds
> > > more complex, i.e. slower.  Why?  
> >
> > Simple regular users don't want to be concerned with choice of toolkit
> > for every single package, as long as a GUI is provided.  
>
>   Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
> make.conf.  This will *FORCE* a gui where applicable.
And also a dozen random things, and USE flag conflicts where multiple
GUIs are applicable.

> > Furthermore, this matches the recommended USE flag design where the
> > more important flags are provided as feature flags, while specific
> > dependency choice flags are minor.  
>
>   This is going to require *THREE* levels of flags, with the first one
> being totally unnecessary...
>
> Level 1) GUI
>
> Level 2) X or xorg or Wayland or Mir
>
> Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk
>
>   Let me re-phrase my question... is there *ANY* set of circumstances
> under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> can be set for a package *WITHOUT* requiring a gui?  I can see any of X
> or xorg or Wayland or Mir being a requirement for any of
> qt4/qt5/gtk2/gtk3/fltk.  But any of the Level 2 or Level 3 flags *FORCES*
> a GUI of one sort or another.
>
>   I repeat, requiring a "GUI" use flag for GUI apps makes as much sense
> as requiring a "TUI" flag for commandline apps.  I hope I'm not giving
> people ideas the wrong way.  No I don't want a "TUI" flag either.
That's your opinion, and that is how far it goes as I'm concerned. Next
thing you complain, that USE=ssl doesn't mean 'openssl only'.

--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

Graham Murray
In reply to this post by Walter Dnes
[hidden email] writes:

>   Let me re-phrase my question... is there *ANY* set of circumstances
> under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> can be set for a package *WITHOUT* requiring a gui?

Yes. X/xorg could be needed to incorporate the X Client libraries so
that X servers can connect to it but not itself have a gui. This
could, for example, be on a headless server.

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

Damien Levac
In reply to this post by Walter Dnes


On 2016-06-01 10:13 PM, [hidden email] wrote:

> On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote
>
>> [hidden email] wrote:
>>
>>>    I see this as at least a redundancy, if not a problem.  First, let's
>>> look at the general case.  An optional "UI" (User Interface) is also
>>> selected...
>>> * via the "tools" useflag 78 times in use.local.desc
>>> * via the "ncurses" useflag 10 times in use.local.desc.
>>> * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
>>>    does "ncurses" show up in use.local.desc ???)
>>>
>>>   There is no need for an additional "TUI" (Text User Interface) use flag
>>> for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
>>> "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
>>> thing they have in common is a hard-coded dependancy on graphics libs.
>>> "GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
>>> Using any of them tells you enough.  What do we accomplish by requiring
>>> one more USE flag?  This will also make dependancy resolution of ebuilds
>>> more complex, i.e. slower.  Why?
>> Simple regular users don't want to be concerned with choice of toolkit
>> for every single package, as long as a GUI is provided.
>    Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
> make.conf.  This will *FORCE* a gui where applicable.
>
>> Furthermore, this matches the recommended USE flag design where the
>> more important flags are provided as feature flags, while specific
>> dependency choice flags are minor.
>    This is going to require *THREE* levels of flags, with the first one
> being totally unnecessary...
>
> Level 1) GUI
>
> Level 2) X or xorg or Wayland or Mir
>
> Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk
>    Let me re-phrase my question... is there *ANY* set of circumstances
> under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> can be set for a package *WITHOUT* requiring a gui?  I can see any of X
> or xorg or Wayland or Mir being a requirement for any of
> qt4/qt5/gtk2/gtk3/fltk.  But any of the Level 2 or Level 3 flags *FORCES*
> a GUI of one sort or another.
IMHO, you see this in reverse. the 'gui' useflag would be useful for
users who don't want to care about X/wayland/mir and do not want to care
about gtk/qt, they just want windows to be drawn for the applications
they install -- without, if possible, pulling useless dependencies.
>
>    I repeat, requiring a "GUI" use flag for GUI apps makes as much sense
> as requiring a "TUI" flag for commandline apps.  I hope I'm not giving
> people ideas the wrong way.  No I don't want a "TUI" flag either.
>


Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

Ian Stakenvicius-2
In reply to this post by Walter Dnes
On 01/06/16 10:13 PM, [hidden email] wrote:

> On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote
>
>> [hidden email] wrote:
>>
>>>   I see this as at least a redundancy, if not a problem.  First, let's
>>> look at the general case.  An optional "UI" (User Interface) is also
>>> selected...
>>> * via the "tools" useflag 78 times in use.local.desc
>>> * via the "ncurses" useflag 10 times in use.local.desc.
>>> * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
>>>   does "ncurses" show up in use.local.desc ???)
>>>
>>>  There is no need for an additional "TUI" (Text User Interface) use flag
>>> for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
>>> "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
>>> thing they have in common is a hard-coded dependancy on graphics libs.
>>> "GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
>>> Using any of them tells you enough.  What do we accomplish by requiring
>>> one more USE flag?  This will also make dependancy resolution of ebuilds
>>> more complex, i.e. slower.  Why?
>>
>> Simple regular users don't want to be concerned with choice of toolkit
>> for every single package, as long as a GUI is provided.
>
>   Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
> make.conf.  This will *FORCE* a gui where applicable.
>

The whole point of USE=gui is to get away from needing to do that.
Those flags should be used to choose -which- gui toolkit users want
when one is available, not to choose IF a gui should be built or not.
Take my example into account, i don't want anything qt based if I can
avoid it, but i definitely want wpa-gui.  Right now I only get wpa-gui
if I enable USE=qt4 (or USE=qt5 presumably) on wpa_supplicant.  I'm
not going to set that globally though because I don't want to choose
qt4 based front-ends for anything else, and having to guess for every
random package when i don't care so that I can set a package.use entry
for it is annoying.


>> Furthermore, this matches the recommended USE flag design where the
>> more important flags are provided as feature flags, while specific
>> dependency choice flags are minor.
>
>   This is going to require *THREE* levels of flags, with the first one
> being totally unnecessary...
>
> Level 1) GUI
>
> Level 2) X or xorg or Wayland or Mir
>
> Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk

1 - USE=gui is for optional gui-or-no-gui, so yes in this scheme its
needed.

2 - If X or Wayland or Mir support is available in a package, then yes
-- also i don't see a way that we don't need these.

3 - toolkit selection choices when a package supports multiple (but
only chooses one) is also a yes.  AND, because we're not tying any-gui
to one of these flags it means that users are free to set just the one
variant that they prefer, globally, instead of having to mess about
per-package.  It also means we can get rid of any or all of these
particular flags from profiles (except for 'gnome' or 'plasma' or the
desktop-variant-specific ones).

The point here is that if there's an app (say, wpa_supplicant as
mentioned before) that provides a gui tool but no options as to what
that tool needs in terms of toolkit etc, we can -just- have USE=gui
control whether or not it's built.  It'll pull in qt because qt is
what it needs, and if someone is dead set against having qt in their
system then they'll know from the dependency tree.  There's no need to
peg the individual toolkit to packages like this just to enable a gui.


>
>   Let me re-phrase my question... is there *ANY* set of circumstances
> under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> can be set for a package *WITHOUT* requiring a gui?  I can see any of X
> or xorg or Wayland or Mir being a requirement for any of
> qt4/qt5/gtk2/gtk3/fltk.  But any of the Level 2 or Level 3 flags *FORCES*
> a GUI of one sort or another.


Likely there is but I'd need to search.  Extending libraries mostly --
cairo, pango etc.. for X vs no-X, avahi for gtk*/qt* ...





signature.asc (220 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

Raymond Jennings
use case:  Telling a package to build a gui without deciding which one to build.  Also helps in cases where you have package A that can only build a qt gui, and package B that can build both qt and gtk, and package C that can build gtk only.  You want to have a gui for all three, but you don't want to hav epackage B build both guis and at the same time while you may prefer qt, you don't want to leave package C without a gui.

On Thu, Jun 2, 2016 at 7:20 AM, Ian Stakenvicius <[hidden email]> wrote:
On 01/06/16 10:13 PM, [hidden email] wrote:
> On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote
>
>> [hidden email] wrote:
>>
>>>   I see this as at least a redundancy, if not a problem.  First, let's
>>> look at the general case.  An optional "UI" (User Interface) is also
>>> selected...
>>> * via the "tools" useflag 78 times in use.local.desc
>>> * via the "ncurses" useflag 10 times in use.local.desc.
>>> * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
>>>   does "ncurses" show up in use.local.desc ???)
>>>
>>>  There is no need for an additional "TUI" (Text User Interface) use flag
>>> for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
>>> "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
>>> thing they have in common is a hard-coded dependancy on graphics libs.
>>> "GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
>>> Using any of them tells you enough.  What do we accomplish by requiring
>>> one more USE flag?  This will also make dependancy resolution of ebuilds
>>> more complex, i.e. slower.  Why?
>>
>> Simple regular users don't want to be concerned with choice of toolkit
>> for every single package, as long as a GUI is provided.
>
>   Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
> make.conf.  This will *FORCE* a gui where applicable.
>


The whole point of USE=gui is to get away from needing to do that.
Those flags should be used to choose -which- gui toolkit users want
when one is available, not to choose IF a gui should be built or not.
Take my example into account, i don't want anything qt based if I can
avoid it, but i definitely want wpa-gui.  Right now I only get wpa-gui
if I enable USE=qt4 (or USE=qt5 presumably) on wpa_supplicant.  I'm
not going to set that globally though because I don't want to choose
qt4 based front-ends for anything else, and having to guess for every
random package when i don't care so that I can set a package.use entry
for it is annoying.


>> Furthermore, this matches the recommended USE flag design where the
>> more important flags are provided as feature flags, while specific
>> dependency choice flags are minor.
>
>   This is going to require *THREE* levels of flags, with the first one
> being totally unnecessary...
>
> Level 1) GUI
>
> Level 2) X or xorg or Wayland or Mir
>
> Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk


1 - USE=gui is for optional gui-or-no-gui, so yes in this scheme its
needed.

2 - If X or Wayland or Mir support is available in a package, then yes
-- also i don't see a way that we don't need these.

3 - toolkit selection choices when a package supports multiple (but
only chooses one) is also a yes.  AND, because we're not tying any-gui
to one of these flags it means that users are free to set just the one
variant that they prefer, globally, instead of having to mess about
per-package.  It also means we can get rid of any or all of these
particular flags from profiles (except for 'gnome' or 'plasma' or the
desktop-variant-specific ones).

The point here is that if there's an app (say, wpa_supplicant as
mentioned before) that provides a gui tool but no options as to what
that tool needs in terms of toolkit etc, we can -just- have USE=gui
control whether or not it's built.  It'll pull in qt because qt is
what it needs, and if someone is dead set against having qt in their
system then they'll know from the dependency tree.  There's no need to
peg the individual toolkit to packages like this just to enable a gui.


>
>   Let me re-phrase my question... is there *ANY* set of circumstances
> under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> can be set for a package *WITHOUT* requiring a gui?  I can see any of X
> or xorg or Wayland or Mir being a requirement for any of
> qt4/qt5/gtk2/gtk3/fltk.  But any of the Level 2 or Level 3 flags *FORCES*
> a GUI of one sort or another.


Likely there is but I'd need to search.  Extending libraries mostly --
cairo, pango etc.. for X vs no-X, avahi for gtk*/qt* ...





Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

Walter Dnes
In reply to this post by Graham Murray
On Thu, Jun 02, 2016 at 06:50:59AM +0100, Graham Murray wrote
> [hidden email] writes:
>
> >   Let me re-phrase my question... is there *ANY* set of circumstances
> > under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> > can be set for a package *WITHOUT* requiring a gui?
>
> Yes. X/xorg could be needed to incorporate the X Client libraries so
> that X servers can connect to it but not itself have a gui. This
> could, for example, be on a headless server.

  Is it broken right now?  What improvement will we see from having to
add a "GUI" flag?

--
Walter Dnes <[hidden email]>
I don't run "desktop environments"; I run useful applications

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Global USE=gui

Walter Dnes
In reply to this post by Damien Levac
On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote
>
> IMHO, you see this in reverse. the 'gui' useflag would be useful for
> users who don't want to care about X/wayland/mir and do not want to care
> about gtk/qt, they just want windows to be drawn for the applications
> they install -- without, if possible, pulling useless dependencies.

  How, exactly, will the app draw windows without linking against one of
X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
pike?

--
Walter Dnes <[hidden email]>
I don't run "desktop environments"; I run useful applications

1234