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

Re: Fwd: Wayland design principles (Re: wayland and gambas)

In His link the Wayland guy (Pekka PAalenen) clearly says he is against what he proposed, and just put it there so he could point people to it when they ask why can't you do "x" or "y" (which has been good enough for over 30years of GUI) in Wayland, it would seem because they are afraid that people will use the "legacy support" if added, and not change to the "wayland" way of thinking.   We might have more luck getting all the compositors to add the missing positional support, or alternatively maybe XWayland provides enough to do what is needed?. 
regards, Tim

On 29/04/2024 16:09, Jorge Carrión wrote:
Well... X11 for ever, I guess... I just hope that all this doesn't evolve in the same direction that happened with Ubuntu and gnome 2, when everybody was happy with all its pretty little things about the cube, the woobly windows and all that clasic stuff, the bars up and down... that suddenly became obsolete and "Now Unity, yes or yes"... and gnome 3 saying that "Ah, ok, but now things are like this yes or yes too... and everyone contributes their reasons... and nothing is ever the same again.In Spain we have a saying: "Entre todos la mataron y ella sola se murió", which translates as: They all killed her and she died by herself. Nobody is guilty... but she is died, more or less... 

Best regards.
El lun, 29 abr 2024 a las 16:16, Brian G (<brian@xxxxxxxxxxxxxxxx>) escribió: 

    I am not sure I completely understand, Did he say basically

    Our why or the highway, and not our problem in one single response.

    And period, too bad.

    On 4/29/24 05:50, Bruce Steers wrote:

    I got this reply on the wayland developers list if anyone fancies
    a read....

    ---------- Forwarded message ---------
    From: *Pekka Paalanen* <pekka.paalanen@xxxxxxxxxxxxx>
    Date: Mon, 29 Apr 2024 at 13:43
    Subject: Wayland design principles (Re: wayland and gambas)
    To: Bruce Steers <bsteers4@xxxxxxxxx>,
    <wayland-devel@xxxxxxxxxxxxxxxxxxxxx>


    On Sat, 27 Apr 2024 08:28:00 +0100
    Bruce Steers <bsteers4@xxxxxxxxx> wrote:

    > Hello
    > I am a gambas basic developer and would like to report some wayland
    > problems. (major issues) that we hear of on the gambas mailing
    list all the
    > time.
    >
    > The attitude towards wayland with gambas coders at present is
    ,, ditch
    > wayland it sucks, use x11.
    >
    > All gambas users are used to having window X and Y properties
    to get/set
    > window position and with wayland it is not possible.
    >
    > So any custom home made widgets cannot work as expected.
    > My own desktop has 3 running programs from startup that all
    have their own
    > position set and do not work with wayland as they are
    borderless (no
    > titlebar) or tray icons and wayland is functionally
    limited/restrictive.
    >
    > Other things not working with gambas in wayland but okay on X
    >
    > SystemTray icons do not work
    > Form.Sticky (show window on all workspaces) does not work.
    > Form.SkipTaskbar , not working.
    >
    > Like I say due to all these problems our current attitude
    towards wayland
    > that we have to tell everyone is "get rid of wayland because of the
    > limitations, many things it is lacking"
    >
    > Are there no plans to change any of this?
    > Is waylands attitude towards window positioning just forget it,
    you are no
    > longer in control.
    > Because if yes then it will NEVER be the system of choice (or
    little choice
    > as the case may be) for many of us.
    >
    > Could any wayland developers join the gambas mailing list to
    possibly help
    > us work through some of the issues wayland introduces?
    >
    > gambas is pretty popular and by far the best UI IDE available for
    > freedesktop so please help us work out some of the major
    problems that come
    > with wayland and the wayland limited non-functionality.
    >
    > It would be nice to say "wayland is okay"  but that's not what
    we are
    > saying at all because wayland just causes many problems. So we
    say "get rid
    > of wayland limited and use X11" and have to explain how
    restricted wayland
    > is for gambas.

    Hi Bruce,

    I'm sorry, but at least I do not expect the situation to change much
    from the Wayland side. This is a question of fundamental design
    principles being incompatible, especially for the window positioning
    with x,y coordinates topic. The system tray case I am not familiar
    with, so I cannot say anything about that.

    I will explain these principles here the best I can, because to my
    knowledge, they still have not been properly documented. Perhaps this
    email could serve as a basis for the Wayland community to document
    them. Sorry for the wall of text, but this for everyone rather than
    just a reply to you. Maybe this explains why the Wayland project
    seems
    so "stubborn".


    Wayland's fundamental design principles on the desktop have been
    crystallised to "descriptive, not prescriptive". In other words,
    regular desktop applications are expected to describe their windows
    with enough detail, purpose and intent to let a window system server
    (any of the desktop compositor projects) do the right thing and
    present
    them the way the end user wants them. This is very much the
    opposite of
    prescriptive design, where the server does what applications tell
    it to
    without knowing the intentions or limitations. In other words, in
    Wayland, desktop applications say "here is what I have", not "do as I
    say".

    This applies to "regular" desktop applications that are expected to
    work on a very wide range of (desktop) systems, regardless of the
    shape, size, resolution, and number of screens a display system might
    have, or even bringing desktop applications into virtual or augmented
    reality where screens might not even exist.

    This might not apply to desktop environment components, and it might
    not apply to non-desktop environments: in-vehicle-entertainment,
    digital signage, set-top boxes, or special equipment displays for
    example. Special programs often use special protocol extensions,
    Wayland or other, to do what they cannot do with just the common
    set of
    public Wayland interfaces. These special extensions may not be widely
    supported, and they may require special privileges. However, even
    though the Wayland principles may not fully apply, they do make
    system
    integration easier when they do apply.

    The descriptive design principle has allowed a set of protocol
    extensions (xdg) to arise that cater for many kinds of environments
    without actually needing environment-specific extensions. An
    application
    developed with these principles can work well on a normal
    desktop, in a
    TV/set-top box, and in a kiosk machine without needing much or any
    tailoring. The kiosk environment makes the active application
    top-level window always fullscreen or maximized, for instance.

    As another example, not defining a global coordinate system like X11
    has, has allowed HiDPI display support to be designed in a way
    that can
    accommodate also mixed-DPI multi-display systems. I believe it would
    have been much harder if not impossible to do if a global coordinate
    system had been defined. For better or worse, this also means
    there is
    no coordinate system for placing windows, either.

    Another related thing is that Wayland attempts to keep applications
    isolated from each by default, for security reasons. It is much
    easier
    to carefully open access for specific purposes than it is to try to
    secure an open-by-default design. A consequence of this is that
    applications do not know what else is on screen and where, which
    means
    that applications cannot know everything that could be needed to
    position windows nicely. Only the compositor has the full picture.

    These are the main advantages of the Wayland design principles:
    Desktop
    environments can develop more freely, applications are more widely
    fitting in, and overall policy is where it is (should be) the easiest
    for an end user to customise: in the display server. All in all, more
    power to the window manager (a part of the display server a.k.a
    compositor), which unfortunately also means less power to the
    application developers to decide on the behaviour. The idea is
    that the
    window manager is in the best position to implement window management
    behaviour the end user wants. End users can pick and choose their DE,
    and they can tune its window management behaviour. Application
    developers can avoid worrying about it, and applications avoid
    imposing
    window management behaviour that might not always be wanted.

    The disadvantage is that the design principles carry a revolutionary
    idea. Roughly nothing worked like this before Wayland. Porting
    to Wayland requires re-designing applications to stop explicitly
    managing their windows, and toolkits have it even worse. I'm sure
    there
    are still many use cases that just don't work yet, because there
    is no
    protocol extension to deliver a suitable description.

    Yet, somehow Wayland has become popular enough that people are
    increasingly bumping into it, whether they wanted to or not. I
    doubt we
    would be in this situation if there was no significant merit in
    Wayland's design principles as well. Hence it is very difficult to
    justify letting those principles go. On the other hand, the Linux
    desktop has always been special: it is rare to be able to choose
    between multiple desktop environments on the same operating system.

    I recently wrote up
    https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/194
    in a search for a compromise between Wayland and applications
    that will
    not be re-designed according to the Wayland principles and would
    remain
    crippled. The basic idea there is to introduce "legacy compatibility
    extensions" as a stop-gap measure and eventually stop using them for
    those cases where both the application and the toolkits it uses are
    still actively developed. It was met with justified criticism, and it
    was not intended as a future proof solution for any application
    in the
    first place.

    I believe the discussion in that issue is still on-going (it is very
    fresh), and that it would be worth to read through.

    Lastly, and I know this is controversial: maybe people should
    agree to
    disagree? If there is a community that really wants a prescriptive
    window system protocol and wants a more modern approach than X11,
    then
    maybe they should start on their own thing. It is much more feasible
    today than it was when first thoughts of Wayland appeared. Perhaps
    because of Wayland, the software stacks around Wayland have massively
    developed towards allowing multiple window systems and multiple
    display
    servers to co-exist. Hardware drivers are no longer tied to a
    specific
    window system protocol. One would also have Wayland to look at: what
    works and what doesn't. Besides, translating from descriptive to
    prescriptive API is easier than the opposite, so a prescriptive
    window
    system should have no problems supporting Wayland applications
    through
    a compatibility layer.


    Thanks,
    pq
-- ~~~~ Brian