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