Re: Collaboration on standard Wayland protocol extensions


On 29 March 2016 at 13:24, Drew DeVault <sir cmpwn com> wrote:
On 2016-03-29 11:45 AM, Daniel Stone wrote:
is a cliché, but the spirit of free software is empowering people to
make the change they want to see, rather than requiring the entire
world be perfectly isolated and abstracted along inter-module
boundaries, freely mix-and-matchable.

I should rephrase: it's against the spirit of Unix. Simple, composable
tools, that Do One Thing And Do It Well, is the Unix way. Our desktop
environments needn't and shouldn't be much different.

And yet the existence and dominant popularity of large integrated
environments (historically beginning with Emacs) suggests that the
pithy summary is either wrong, or no longer applicable. Ditto the
relative successes of Plan 9 and microkernels compared to other OSes.

Secondly, you talk about introducing all these concepts and protocols
as avoiding complexity. Nothing could be further from the case. That
X11 emulates this model means that it has Xinerama, XRandR,
XF86VidMode, the ICCCM, and NetWM/EWMH, as well as all the various
core protocols. You're not avoiding complexity, but simultaneously
shifting and avoiding it. You're not avoiding policy to create
mechanism; the structure and design of the mechanism is a policy in

I disagree. I think this is just a fundamental difference of opinion.

I really do not see how you can look at ICCM/EWMH and declare it to be
a victory for simplicity, and ease of implementation.

Thirdly, it's important to take a step back. 'Wayland doesn't support
middle-button primary selections' is a feature gap compared to X11;
'Wayland doesn't have XRandR' is not. Sometimes it seems like you miss
the forest of user-visible behaviour for the trees of creating

I think you're missing what users are actually using. You'd be surprised
at how many power users are comfortable working with tools like xrandr
and scripting their environments. This is about more than just
xrandr-like support, too. There's definitely a forest of people using
screen capture for live streaming, for instance.

Yes, screen capture is vital to have.

Providing some of the functionality (application fullscreening,
including to potentially different sizes/modes than are currently set;
user display control) that RandR does, is also vital. Providing an
exact clone of XRandR ('let's provide one protocol that allows any
arbitrary application to do what it likes'), much less so.

I also posit that anyone suggesting that providing the full XRandR
suite to arbitrary users makes implementation more simple, has never
been on the sharp end of that implementation.

Fourthly, I think you misunderstand the role of what we do. If you
want to design and deploy a modular framework for Legoing your own
environment together, by all means, please do that. Give it a go, see
what falls out, see if people creating arbitrary external panels and
so find it useful, and then see if you can convince the others to
adopt it. But this isn't really the place for top-down design where we
dictate how all environments based on Wayland shall behave.

I've already seen this. It's been around for a long time. I don't know
if you live in a "desktop environment bubble", but there's a LOT of this
already in practice in the lightweight WM world. Many, many users, are
using software like i3 and xmonad and herbstluftwm and openbox and so on
with composable desktop tools like dmenu and i3bar and lemonbar and so
on _today_.

Yes I know, as a former long-term Awesome/OpenBox/etc etc etc etc etc user.

This isn't some radical experiment in making a composable
desktop. It's already a well proven idea, and it works great.

Again, I don't know in what parallel universe ICCCM+EWMH are 'great', but OK.

I would
guess that the sum of people who are using a desktop like this
perhaps outnumbers the total users of, say, enlightenment. I'm just
bringing the needs of this group forward.

I would suggest the total number of users of these 'power'
environments allowing full flexibility and arbitrary external control
(but still via entirely standardised protocols), is several orders of
magnitude than the combined total of Unity, GNOME and KDE, but I don't
think this thread really needs any more value judgements.

My point is that there is no solution for this existing _on Wayland_
today, something which I would've thought to be pretty inarguable,
since that's what this entire thread is ostensibly about. I know full
well that this exists on X11, and that there are users of the same,
but again, you are talking about creating the same functionality as a
generic Wayland protocol, so it's pretty obvious that it doesn't exist

What I was trying to get at, before this devolved into angrily trying
to create division based on preference was - well, look at the EWMH
author list here:

How many of those people are core X11 developers?

The EWMH evolved from a group of desktop developers who banded
together around common needs, and in large part standardised the
support they already had for composed environments, and also built on
the existing standard of the ICCCM. In this case, there is no relevant
ICCCM to build on, and you're attempting to reverse the EWMH process:
to build a top-down protocol and enforce it as 'this is how Wayland
works and everyone will love it', rather than building something up
which works for multiple implementations and attempting to share that
a bit more widely. For bonus points, this entire thread has already
been more pointlessly adverserial than the entire EWMH process.

Trying to do this under the general Wayland umbrella won't really fly.
xdg_shell was essentially developed as a separate project, by the
people who were very much involved in desktop development, and you'd
need to do the same for the various ideas of yours which aren't
strictly core Wayland, and build upwards from there.

Some of your email is just griping about the long life of this thread,
and you're right. I think I've got most of what I wanted from this
thread, I'm going to start proposing some protocols in new threads next.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]