WayVNC 0.7 Released As VNC Server For Wlroots-Based Wayland Compositors

[fitzie]

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/GOVERNANCE.md

2.2. Protocol inclusion requirements
is a worth while read.



Horrible as it sounds the static on one screen but not on the other screen the is a feature scientific applications that really do use absolute position.
==Then we get into the rare to see out side scientific usage the multi application multi window with central layout system over the lot but it not done like chrome they are true independent windows.==
These nightmares. Some of these are true nightmares not only are they placing windows on screens they are altering what screen mirrors what other screen on the fly. Fun of having software altering screen layout dynamically.

That basic 3 step you just wrote fitzie is not suitable for the advanced scientific applications. Yes these applications are also know for breaking x11 and Windows and Mac OS setups.

fitzie you need to carefully take note of what coming out of the parties who develop advanced scientific applications and what is Wayland developers trying to think up solutions that don't break. There requirements are a level of horrible. There requirements are really good at causing some quite nasty stuff ups with virtual image absolute position due to moving screens around so much.

Advanced scientific applications on X11, Windows and Mac OS are not the most stable thing. If something better can be come up with these applications could be more stable for end users.



Stop right there. The Khronos Group Inc the ones behind opengl and vulkan have governance rules like Wayland protocol. Wayland does not prevent independent compositors having their own custom protocols inside the limitations of law(where to look for this will be latter).

wlroots, kde and gnome have there own custom wayland protocols for lots of things these are not include in the Wayland core protocol.. So yes different interests can bring own custom versions of Wayland to market without the core wayland project approval. Not having the core wayland project approval does mean you are less likely to have all the Wayland compositors implement the feature. Same thing happens with opengl and vulkan.

Reality you have to do extra steps to get a opengl or vulkan extension into something that a version number. Same with CSS in fact. Yes main Wayland protocol no different in requirements really than getting something into opengl or vulkan. Yes AMD/Intel/ARM/Nvidia can all individually nack something out from being added to opengl/vulkan protocols and you have to deal with their issues..

Yes there is gatekeeper and bikeshedding with css, opengl and vulkan. This is all part of normal protocol development. So you have gone off with assume not based in reality.


That is not true.

https://github.com/varmd/wayward

You just ignored wayward users that is weston based. Weston is the reference implementation and people could choose to use weston to implement a full DE if they want to. Yes wayward developers want to. Also weston is used by Microsoft in WSL2 for graphical applications. So a little more commonly deployed than one would think.

This is where the assumes are horrible wrong. If something is part of core wayland protocol it has to be implemented in weston so that those implementing compositors have something to check their implementation against. So if weston cannot implement the feature then the feature cannot be part of the core Wayland protocol this is not a unique rule. Yes this explains why weston has nack ability.

x.org X11 server is also the X11 reference implementation for the X11 protocol. Over time progressively everything else died out bar the reference implementation in common usage with the X11 protocol. Yes if x.org X11 server could not implement something then the core X11 protocol could not have that feature as well. This is the same rule.

I remember the time Microsoft end up in court over the SMB protocol and found out Microsoft extensions were illegal because they had not submit and implemented them Samba and those changes were causing incompatibilities between implementations. The Samba project that is the reference implementation of that protocol. There is a legal risk implement you own thing and not put it in the reference implementation when it exists for a protocol. This is also why gnome, kde and wlroots are only willing to go so far without the Wayland protocol extension going though the process of getting into Wayland protocols.

There are legal rules that limit how far Wayland compositors can fragment before they come illegal under law(yes the fair competition/anti monopoly requirements in law). We hope things don't get that messy.

there are no legal rules. microsoft was under antitrust orders, not going to apply to wayland compositors. the wayland cabal aren't the ones trying to thing how scientific applications can be supported, they are the ones ignore them entirely except for the week it takes to discuss this proposal. they will go back to ignoring them again.

the point is that whether other gpu vendors browsers pick up another browsers standards, is that the market is allowed to weigh in. the issue with wayland, is that people who control the market have some stated incompatible vision of what the desktop should be.

my issue isnt' with the gnome cabal. time will prove them wrong. it's with everyone buying into their excuses and vision. being told that weston is a serious desktop and mirroring a window onto two screens under different positioning is a non toy usecase has brought my contribution to this conversation to an end. have a good day. see ya next time

[oiaohm]

there are no legal rules. microsoft was under antitrust orders, not going to apply to wayland compositors. the wayland cabal aren't the ones trying to thing how scientific applications can be supported, they are the ones ignore them entirely except for the week it takes to discuss this proposal. they will go back to ignoring them again.

As a reason for absolute positioning until now the scientific applications have never been brought up. The reality is the proposals were never ignored but inside a week the reason for the proposal would be totally ripped apart then the Wayland developers lost interest after they had spent time looking at it.

tthe point is that whether other gpu vendors browsers pick up another browsers standards, is that the market is allowed to weigh in. the issue with wayland, is that people who control the market have some stated incompatible vision of what the desktop should be.

Like the market could weigh in if their was enough people will to. Wayland group does not forbid this. Issue who is going to fund items like arcan to have another option.

The reality if some party does not see the problem large enough to fund competition the competition will not exist this is not just a wayland thing..

There has been a repeating problem.

Wayland does not do X feature we can use X11 mind set. This means parties put forwards not solid proposals to wayland and when they get shot down as they should always be they don't go though the effort to make them solid proposals and use these non solid proposals as reasons to use X11.

Take the idea that porting majority of 3rd party applications would be effected argument that those pushing absolute position support in Wayland have attempted to say over and over again. When you do look into that 90% in these code base is relative position compatible.

Proposals to a standard board be Wayland or not get shot down because they contain a falsehood.

Now that X11 is being dropped by Redhat fully we are now seeing parties wake up they will not be able to keep on going back to X11 so now have to do solid proposals.

[ssokolow]

If programmers don't understand or care about their user's needs, they should not design GUI applications, much less window manager protocols.
Desktop users run complex applications, resize several windows (of same or different applications) to specific sizes and positions to optimize their workflow.
They just want either the same situation of open windows and applications, or being able to quickly switch between setups. Not 20 mouse clicks and drags just to customize the desktop every time they open a program.

The approach being explored is extending the session-saving protocol so that, instead of applications manually saving and restoring absolute window geometry, flinging windows around willy-nilly, they can request that the compositor take and restore snapshots of where the user placed their windows.

I don't know about you, but I'd take that over having to use KWin's Window Rules to lock out buggy application-reinvented geometry memory/restoration code any day of the week.

It's similar to how Wayland doesn't allow untrusted applications to crash and leave your desktop at 640x480, because it has a "please fullscreen this window" API, not a "please make arbitrary changes to the video mode" API that leaves the WM/DE guessing whether to update its stored window and icon positions. (Spoiler alert: That's never worked for me, so I lock down xrandr to a single display configuration so games can't scramble my desktop on first run by defaulting to mode-changing fullscreen.)

[maztheman]

Sounds like we need a W11 fork that is more forward thinking on protocols.