1 |
On Sun, 3 Sep 2017 23:37:34 +0000 (UTC) |
2 |
Duncan <1i5t5.duncan@×××.net> wrote: |
3 |
|
4 |
|
5 |
> Vague/generic agreed in general. I'm not sure enough what you meant |
6 |
> by double-dipping (tho I have a couple ideas) to say I agree there. |
7 |
|
8 |
Yeah. To an extent these days its just "app" practically *implies* a |
9 |
GUI. |
10 |
|
11 |
It doesn't, strictly, speaking, but its just such a generic term I have |
12 |
a hard time imagining somebody using it as a classifier. |
13 |
|
14 |
|
15 |
> How many of these xorg-suite apps have-been/will-be actually ported to |
16 |
> wayland? I was under the impression that most of them will not be |
17 |
> ported, and it'll be the up to whatever compositor and accompanying |
18 |
> toolkit you choose to provide that functionality, as they generally |
19 |
> already do... to a point. Certainly the compositor (aka |
20 |
> super-window-manager) is the only app allowed to control/delegate many |
21 |
> of the functions xset, xrandr, etc, set for xorg in common, for |
22 |
> security reasons, because wayland simply doesn't let one app mess with |
23 |
> and spy on another app's input stream, for instance, as X does. If |
24 |
> only the compositor and/or apps it specifically authenticates for the |
25 |
> purpose are allowed to do such settings, it quickly becomes a |
26 |
> toolkit/DE function, and generic versions don't make a lot of sense |
27 |
> as they simply won't work. |
28 |
|
29 |
Well, in this case it was more an example of "a tool that has some |
30 |
desktop mechanics, but does not in fact have any Graphical User |
31 |
Interface". |
32 |
|
33 |
"xset" augments *the environment itself* |
34 |
|
35 |
And I simply reasoned that, this, being Unix, we'd likely have |
36 |
equivalent, GUI-less applications that perform various display related |
37 |
services, like xbacklight, or transset, or xrandr. |
38 |
|
39 |
I'm not saying those binaries would literally be ported, only that |
40 |
their utility is such that I'd expect to see equivalents/analogues |
41 |
emerge for wayland. |
42 |
|
43 |
( intel-gpu-tools for example have neither GUI, or really X specific |
44 |
behaviour aside from its gpu-overlay ) |
45 |
> |
46 |
> In which case, keeping the "legacy" x11-* names for such x-specific |
47 |
> apps, the better to eventually deprecate, mask, and send off to the |
48 |
> user-maintained "X-sunset" overlay, may make the most sense and will |
49 |
> almost certainly be less trouble. |
50 |
> |
51 |
> And where there is a port, as presumably there is or will be for |
52 |
> many of the x11-libs, does it make sense to keep separate x11-* |
53 |
> and wayland-* categories where they differ, or throw them all together |
54 |
> in a heap? |
55 |
|
56 |
Right, there's going to be plenty of examples of things that aren't |
57 |
portable, and will need to stay in perpetuity in x11-* . x11-drivers |
58 |
are probably a good example. Though I'm in no hurry to deprecate X11, |
59 |
wayland will take even longer than systemd for me to go "Ok, yes, now |
60 |
we should switch everyone to this" |
61 |
|
62 |
> Meanwhile, the objection to "desktop-*" is that it may well look about |
63 |
> as relevant in a few years as "mainframe-*" would look today, due to |
64 |
> mobile, wearables, and possibly ultimately injectibles. |
65 |
> |
66 |
> > IDK. |
67 |
> > |
68 |
> > I'm not committed to anything I've said here, just food for |
69 |
> > thought. |
70 |
> |
71 |
> Same here. My biggest concern is simply avoiding, if possible, |
72 |
> setting up new categories now, only to have to redo them in 2-5 when |
73 |
> hindsight makes them look stupid. It may not be possible, but to the |
74 |
> extent it is... Other than that, I've no particular shed color |
75 |
> preference, other than don't make it 50 characters long or something |
76 |
> so exotic we have to refer to it as "the category formerly known as |
77 |
> x11-*." =:^) |
78 |
> |
79 |
|
80 |
Yeah. At this point there's not much value in a switch. And I'm not |
81 |
entirely happy with either "gui-" or "desktop-". "x11-" is, for all its |
82 |
warts, more useful than either of those still. |
83 |
|
84 |
I'm tempted to suggest something like "ux-", which conceptually |
85 |
encompasses GUI/UI/Display concerns, and having an "x" gives a nod to |
86 |
its legacy as being "x" without it being part of the definition :) |
87 |
|
88 |
Its also nice to keep the sort ordering reasonably close: |
89 |
|
90 |
sys-* |
91 |
virtual |
92 |
www-* |
93 |
x11-* |
94 |
xfce-* |
95 |
|
96 |
Becomes |
97 |
|
98 |
sys-* |
99 |
ux-* |
100 |
virtual |
101 |
www-* |
102 |
xfce-* |
103 |
|
104 |
Which should help anyone confused why the category they're looking for |
105 |
isn't in /usr/portage any more when they throw an `ls` down there. |