| 1 |
On Fri, Sep 11, 2015 at 1:11 PM, Duncan <1i5t5.duncan@×××.net> wrote: |
| 2 |
> Rich Freeman posted on Fri, 11 Sep 2015 08:13:48 -0400 as excerpted: |
| 3 |
> |
| 4 |
>> USE=gui or something like that if the main effect is to have a gui or |
| 5 |
>> not. |
| 6 |
>> That is the sort of thing that SHOULD go in make.conf or in a profile. |
| 7 |
>> If disabling gtk makes it a console-only application then use the gui |
| 8 |
>> flag. |
| 9 |
> |
| 10 |
> I like the general proposal, but since it's going to council, can we try |
| 11 |
> to kill another bird with the same stone? This USE=gui helps... |
| 12 |
> |
| 13 |
> Wayland's coming, and to the extent that USE=X has previously indicated a |
| 14 |
> GUI, much like USE=gtk and USE=qt indicating the same thing, we're going |
| 15 |
> to have problems. |
| 16 |
> |
| 17 |
> Can we make USE=gui the generic policy for that, and deprecate more |
| 18 |
> specific forms for choosing /any/ gui, so they can be used for choosing |
| 19 |
> /which/ gui? |
| 20 |
|
| 21 |
That was exactly why I used "gui" and not "X". We're going to run |
| 22 |
into the exact same problem once Wayland comes along with the way |
| 23 |
things have been done so far. |
| 24 |
|
| 25 |
> |
| 26 |
> The question then remains whether ncurses, etc, should be treated as a |
| 27 |
> gui. Maybe make mention of that one way or the other in the policy as |
| 28 |
> well. |
| 29 |
> |
| 30 |
|
| 31 |
I actually was pondering that and left it out of my email. My gut |
| 32 |
feeling is that ncurses should be left alone for now. USE=-gui would |
| 33 |
mean console-only, whether that happens to include support for |
| 34 |
ncurses, aa, or whatever. |
| 35 |
|
| 36 |
Are there any applications out there which behave dramatically |
| 37 |
differently if they do/don't have ncurses support built-in? If you |
| 38 |
set TERM=dumb I imagine that software which actually supports this |
| 39 |
would just behave accordingly (ie if it is just using colors or moving |
| 40 |
progress bars or whatever it will drop the decorations). Usually |
| 41 |
though dumb terminal software tends to be somewhat dedicated (for |
| 42 |
things like editors and the like). |
| 43 |
|
| 44 |
I don't want to complicate things if nobody really cares about them. |
| 45 |
However, in theory you could treat various console-enhancing libraries |
| 46 |
in the same way. There is also svgalib and the like. |
| 47 |
|
| 48 |
-- |
| 49 |
Rich |
Archives