nybble41 · HackerTrans

vor 6 Jahrendiscuss

> It's not that Red Hat is trying to lock anybody into a particular desktop out of some nefarious political agenda, it's that we don't have the resources to do things twice. … What would you have us do?

I appreciate the work that is going into the Wayland desktop ecosystem, really, but I would wonder why you would put all this general-purpose desktop environment implementation effort into Gnome specifically and not a common library like wlroots, with the Gnome compositor as a layer on top, so that all compositors would benefit. (I would ask the KDE team the same question.) It feels like what we are losing most with the transition from X11 to Wayland is commonality of implementation for the various system services other than input or presentation which were formerly handled by the X server, and which are now handled either by the compositor itself (Gnome and KDE) or by a shared library (Sway and any other wlroots-based compositors).

It is good that we at least have standardization at the protocol level, but just the same in my opinion it is … unfortunate … that the two largest desktop environments chose to forge their own paths in terms of the implementations of those protocols, with various desktop-specific extensions.

nybble41

vor 6 Jahrendiscuss

> Seems to me that if there's a necessary 50k LoC that every compositor needs, it should actually be a part of Wayland.

Wayland is an IPC mechanism and a set of core protocols for input (passing keyboard, mouse, etc. events to applications) and presentation (communicating rendered surfaces back to the compositor), not a compositor or a desktop environment in its own right. There is a Wayland library but its only concern is implementing the IPC system. Those 50k lines of code would be out of scope.

The wlroots library implements low-level input processing and rendering functions and various other protocols and standards which are common to all desktop environments; you can think of those 50k lines as a replacement for the parts of the X server which are not directly concerned with input and presentation, such as clipboard support, screen recording, the system tray, negotiation of window roles, and much more. On top of wlroots (or its equivalent) you have the actual compositors, like Sway, which perform the function of an X11 window manager and determine the high-level look & feel of the desktop as a whole.

As part of the transition some of the roles have shifted between the various components, usually for good reason. For example, security is much more of a concern now than it was when the X11 protocol was designed, which is where most of the issues relating to screen recording, mouse/keyboard grabbing, and primary selection (middle-click paste) originate. These things could be implemented just as they are in X11, but the inherent security issues of e.g. any application being able to observe what is displayed or selected in another application are difficult to mitigate without impacting the user experience. The Wayland-adjacent project developers involved are attempting to come up with solutions that actually improve the status quo, not just copy forward all the issues that were present in X11. At the same time I believe it is well understood that simply eliminating screen casting or global key bindings is not on the table; we need to be able to accomplish the same goals even if we have to do it a slightly different way.

nybble41

vor 7 Jahrendiscuss

According to C99, section 7.1.3:

    If the program declares or defines an identifier in a context in
    which it is reserved (other than as allowed by 7.1.4), or defines
    a reserved identifier as a macro name, the behavior is undefined.

It doesn't matter what the macro would expand to; simply defining the reserved identifier as a macro triggers undefined behavior. That doesn't mean it won't work, for some specific combination of standard headers, compiler, and program source code. It just isn't a strictly conforming program. A conforming implementation is allowed to flag this as an error, ignore the definition, or simply generate nonsense output.

nybble41

vor 7 Jahrendiscuss

Thank you for the recommendation; that was a very interesting read. I find that I can't quite agree with the last "nontrivial goto" example, though. This version without explicit gotos is actually shorter, and IMHO not really any more difficult to follow:

    int parse(void)
    {   
      Token tok;
      while ((tok = gettoken()) != END)
      {   
        while (!shift(tok))
          if (!reduce(tok))
            return ERROR;
      }
      return ACCEPT;
    }

I will say that any language without goto, or where the use of goto is discouraged, should at least provide guaranteed tail-call elimination as an alternative. In this case the gotos could easily be converted into loops, but not every algorithm is so accommodating.

nybble41

vor 7 Jahrendiscuss

> It's a common social technique among adults with authority to frame requests as a question-- "Could you please....?" or "Would you like to....?". This is gentler and shows a degree of deference and courtesy from the person with authority to the other person.

Does it really? While the first version is clearly a request, I would interpret the second case not as deference or courtesy but as an attempt to emphasize the power one holds over the other person. "Rather than just telling you what I want you to do, I'm just going to hint at what I want and expect you to lie about your own preferences to keep me happy." If you intend to show deference and courtesy, don't ask whether someone would like to do something unless you're genuinely interested in an honest answer.

For those on the receiving side, I would suggest not answering the question at all. Consider it rhetorical. Instead, just say you will do it and ask where it fits in the current list of priorities, or else explain why you can't reasonably take on that task.

comments