| 1 |
On Mon, Sep 4, 2017 at 12:48 AM, Kent Fredric <kentnl@g.o> wrote: |
| 2 |
> I'm tempted to suggest something like "ux-", which conceptually |
| 3 |
> encompasses GUI/UI/Display concerns, and having an "x" gives a nod to |
| 4 |
> its legacy as being "x" without it being part of the definition :) |
| 5 |
> |
| 6 |
|
| 7 |
UX is overly broad, as I could, for example, design a CLI user |
| 8 |
experience. Nothing says I need to use images or a mouse. There is |
| 9 |
also the unrelated concern of mine that UX is a fake term that people |
| 10 |
made up so that they could charge consulting fees to people who don't |
| 11 |
know any better. |
| 12 |
|
| 13 |
Inasmuch as my membership to this list makes my opinion valid, I think |
| 14 |
"desktop-*" is a very good solution. A desktop is a paradigm that some |
| 15 |
would say is intrinsically linked to a graphical user interface. |
| 16 |
People who use tiling or other experimental window managers might see |
| 17 |
a desktop as something a graphical input system can implement, in |
| 18 |
which case "gui-*" could be the most technically generic term. I see |
| 19 |
no problem with putting programs like `xset` into "gui-tools/*". |
| 20 |
|
| 21 |
There may not be any reason to change, as the distinctions in place |
| 22 |
seem to already be quite arbitrary. Having nested package namespaces |
| 23 |
might make things better because then you are forced to define the |
| 24 |
logical relationships between namespaces in a way that is not open to |
| 25 |
as much interpretation. |
| 26 |
|
| 27 |
Respectfully, |
| 28 |
R0b0t1 |
Archives