On Sun, 3 Sep 2017 23:37:34 +0000 (UTC) Duncan <1i5t5.dun...@cox.net> wrote:
> Vague/generic agreed in general. I'm not sure enough what you meant > by double-dipping (tho I have a couple ideas) to say I agree there. Yeah. To an extent these days its just "app" practically *implies* a GUI. It doesn't, strictly, speaking, but its just such a generic term I have a hard time imagining somebody using it as a classifier. > How many of these xorg-suite apps have-been/will-be actually ported to > wayland? I was under the impression that most of them will not be > ported, and it'll be the up to whatever compositor and accompanying > toolkit you choose to provide that functionality, as they generally > already do... to a point. Certainly the compositor (aka > super-window-manager) is the only app allowed to control/delegate many > of the functions xset, xrandr, etc, set for xorg in common, for > security reasons, because wayland simply doesn't let one app mess with > and spy on another app's input stream, for instance, as X does. If > only the compositor and/or apps it specifically authenticates for the > purpose are allowed to do such settings, it quickly becomes a > toolkit/DE function, and generic versions don't make a lot of sense > as they simply won't work. Well, in this case it was more an example of "a tool that has some desktop mechanics, but does not in fact have any Graphical User Interface". "xset" augments *the environment itself* And I simply reasoned that, this, being Unix, we'd likely have equivalent, GUI-less applications that perform various display related services, like xbacklight, or transset, or xrandr. I'm not saying those binaries would literally be ported, only that their utility is such that I'd expect to see equivalents/analogues emerge for wayland. ( intel-gpu-tools for example have neither GUI, or really X specific behaviour aside from its gpu-overlay ) > > In which case, keeping the "legacy" x11-* names for such x-specific > apps, the better to eventually deprecate, mask, and send off to the > user-maintained "X-sunset" overlay, may make the most sense and will > almost certainly be less trouble. > > And where there is a port, as presumably there is or will be for > many of the x11-libs, does it make sense to keep separate x11-* > and wayland-* categories where they differ, or throw them all together > in a heap? Right, there's going to be plenty of examples of things that aren't portable, and will need to stay in perpetuity in x11-* . x11-drivers are probably a good example. Though I'm in no hurry to deprecate X11, wayland will take even longer than systemd for me to go "Ok, yes, now we should switch everyone to this" > Meanwhile, the objection to "desktop-*" is that it may well look about > as relevant in a few years as "mainframe-*" would look today, due to > mobile, wearables, and possibly ultimately injectibles. > > > IDK. > > > > I'm not committed to anything I've said here, just food for > > thought. > > Same here. My biggest concern is simply avoiding, if possible, > setting up new categories now, only to have to redo them in 2-5 when > hindsight makes them look stupid. It may not be possible, but to the > extent it is... Other than that, I've no particular shed color > preference, other than don't make it 50 characters long or something > so exotic we have to refer to it as "the category formerly known as > x11-*." =:^) > Yeah. At this point there's not much value in a switch. And I'm not entirely happy with either "gui-" or "desktop-". "x11-" is, for all its warts, more useful than either of those still. I'm tempted to suggest something like "ux-", which conceptually encompasses GUI/UI/Display concerns, and having an "x" gives a nod to its legacy as being "x" without it being part of the definition :) Its also nice to keep the sort ordering reasonably close: sys-* virtual www-* x11-* xfce-* Becomes sys-* ux-* virtual www-* xfce-* Which should help anyone confused why the category they're looking for isn't in /usr/portage any more when they throw an `ls` down there.
pgphnMgsEgXUg.pgp
Description: OpenPGP digital signature
