Weston Might Move To 4 Month Releases While Wayland's Maturity May Stop Timed Cycles

[oiaohm]

You know, calling it "accessibility" doesn't somehow make it sound like only a minority of handicapped people are going to use it. As if names matter. This is about power users who want to customize and enhance their desktop experience, as that's what AutoHotkey is mostly used for. The point is that such features being unavailable only in Wayland truly speaks volumes about how crappy it actually is designed.

Disable accessibility completely under windows and Autohotkey does not work more. Really you are clueless how autohotkey is designed under windows. Basically its called accessibility be it windows or linux.

So the feature is available under a wayland compositor/desktop. Its not part of the wayland protocol because it service by a different protocol. This is simply not doing duplication.

Wayland is full of dumb decisions made my incompetents. Look at client-sided decorations as another example. Literally no other system that's worth its salt has chosen that route. Not Windows, not Linux with Xorg/X11, not even macOS. But Wayland has to be different because clearly everyone else is wrong right?

Containing false statements. Client-sided decorations is a X11/wayland term.
https://stackoverflow.com/questions/...-windows-forms
Reality is windows uses libraries those libraries from the application code create the window boarder. So like it or not Windows is 100 percent client side decorations just it not called that Microsoft calls it API rendered same thing different name. This is why a Windows under ms window can stuff up badly when the application event loop stalls. Even Mac os has another name for it. So MacOS and Windows both do it. xorg/X11 was not doing it.

I can understand you getting banned when you just keep on getting things wrong.

[Weasel]

Dude, I said the name does not matter, I didn't say it's not called accessibility, what is your point? I said just because it's called accessibility DOES NOT mean that it is ONLY for accessibility (i.e. people with disabilities). It is USED (and in fact that's WHY autohotkey was written in the first place!) by power users who'd like to customize their experience. Despite the name, it's far from only being about hotkeys too, are you aware how powerful ahk is in terms of managing windows? It can even create GUIs that interact with windows of other apps. What part of that is "accessibility"? None. The fact is that these features are missing from Wayland.

Really what is the difference between automating tasks with bash scripts compared to autohotkey? It's similar, ahk is like "bash for GUIs and windows". In fact, winetricks even uses ahk to automate some installs of their tricks. It's all about automation and power use, not accessibility.

And yes Windows is not client sided, because the libraries are part of the SYSTEM. They are part of the API itself, the protocol if you wish. They have a well designed spec, not left to other people to implement it. Wayland delegates this to 3rd party libs, effectively inviting fragmentation to your doorstep, THAT IS THE PROBLEM DUDE. It delegates to toolkits like GTK or Qt (for decoration), which is WRONG. Because this will result in fragmentation and libs that won't implement all needed features.

[oiaohm]

Dude, I said the name does not matter, I didn't say it's not called accessibility, what is your point? I said just because it's called accessibility DOES NOT mean that it is ONLY for accessibility (i.e. people with disabilities). It is USED (and in fact that's WHY autohotkey was written in the first place!) by power users who'd like to customize their experience. Despite the name, it's far from only being about hotkeys too, are you aware how powerful ahk is in terms of managing windows? It can even create GUIs that interact with windows of other apps. What part of that is "accessibility"? None. The fact is that these features are missing from Wayland.

https://gitlab.com/dogtail/dogtail

Well aware but Linux application used for the same things dogtail does not give a rats if the system is running wayland or X11 only that the applications support at-api the accessibility interfaces. Everything auto-hotkey does is required functionality to support disabilities. What is the difference between power user customising experience and customising experience for someone with a physical disability the answer is basic nothing because the person with the physical disability can be a power user as well.

Really what is the difference between automating tasks with bash scripts compared to autohotkey? It's similar, ahk is like "bash for GUIs and windows". In fact, winetricks even uses ahk to automate some installs of their tricks. It's all about automation and power use, not accessibility.

This shows you are clueless on the topic because you have never looked at how Linux GUI power users in fact do it. We don't need autohotkey we have dogtail. Compare to bash just showed you are clueless. Autohotkey vs dogtail it should have been.

And yes Windows is not client sided, because the libraries are part of the SYSTEM. They are part of the API itself, the protocol if you wish. They have a well designed spec, not left to other people to implement it. Wayland delegates this to 3rd party libs, effectively inviting fragmentation to your doorstep, THAT IS THE PROBLEM DUDE. It delegates to toolkits like GTK or Qt (for decoration), which is WRONG. Because this will result in fragmentation and libs that won't implement all needed features.

Under windows a toolkit can also decide to draw its own windows boarders.

The last version of windows with true server side decorations and X11/Wayland people would call it is windows 3.11. It was windows 9x and matching NT that introduced client side decoration method to windows. This is why in 9x time frame you see some developers go nuts and release round application windows.

Did the fragmentation toolkit issue already exist under X11 yes it did. Having to support firefox and chrome drawing their own boards because this is what they do on Windows and OS X meant toolkit under X11 could already go their own direction and draw own boarder.

Basically claim windows is not client side decoration is just you not following the facts.

1) Windows provides a default toolkit.
2) Windows application don't have to use default toolkit common examples firefox and chrome.
3) Windows is 100 percent client side decoration.

So really what you want is either a default toolkit as option 1 as option 2 default theme system that all toolkit use.

X11 protocol with WM does not state how windows boarders will be done. If you ever run X11 without a WM loaded you will notice X11 was design for client side decorations in the first place and WM support was added on latter. Some of the oldest X11 applications are client side decoration.

Why so much force to attempt to have toolkit do it. It called memory usage. The toolkit library is creating all the toolbars and everything else so this has to have a buffer. Server side decorations mandate you have an extra buffer to draw the boarder. Well done client side decorations 1 buffer is used for the complete window output this is lower memory usage. The early systems that X11 run on did not have enough memory to waste on server side decorations. Wayland targeting embedded usage cannot be wasting memory either.

Besides a KDE application on gnome or a gnome application on kde using server side decorations still looks out of place. Toolkits have need come to table on unified theme solution.

[Weasel]

Wasn't aware of dogtail, and I've had too many issues with any many "autohotkey" replacements on Linux to know that it's probably a failure and can only do basic stuff. Funny that ahk in wine works much better than anything natively Linux huh? (and yes, Wine runs on X11, there has been plenty of complaints about Wayland lacking necessary features from Windows APIs)

Can dogtail create GUIs that interact with application windows? Take pixel values and other information from the app window? Scan for specific patterns in the windows? Send commands to apps? This is very important, not just the "hotkey" part. Whether you use it or not is beyond the point.

As for the toolkits, you're completely wrong, read @renox's second link at the beginning of this page (4), it is a mistake and INEFFICIENT to do it client sided especially due to shadows. You realize the "buffer" of toolkit is duplicated in each application while a central server handling it would be only one instance right? Not to mention it has to request larger window sizes to accommodate for possible shadows, even if there aren't any.

In Windows, a central place controls your decorations. Yes you can draw without decorations, but guess what that needs to be sent to the system to specifically REQUEST that, which means it's not client sided. It's not the client's job to decorate the window with the "system theme" in Windows. There's on theme on the entire system, not one per toolkit or even application, wtf?

The ability to choose to draw your own decorations is not bad, if you specifically request it (which can also be done on X11). Why Wayland sucks and fails is because this is the ONLY option, i.e. it removes the other option to have a central theme and for apps which don't give a shit about decorating themselves and don't pick a toolkit. It's a massive pain and inefficient.


Patches are not going to save Wayland, ever, so it's impossible to contribute. It's rotten at the core of the DESIGN, so it's forever going to suck.

I can understand that X11 has many areas where it is horrible, but it is OLD. Wayland, being new, should not make such stupid design decisions, it is unacceptable, and in many ways it's even worse than Xorg, or any other major OS for that matter.

[oiaohm]

(and yes, Wine runs on X11, there has been plenty of complaints about Wayland lacking necessary features from Windows APIs)

The Wayland location will be no different to android for wine. So autohotkey controlling wayland applications basically not going to happen.

Can dogtail create GUIs that interact with application windows? Take pixel values and other information from the app window? Scan for specific patterns in the windows? Send commands to apps? This is very important, not just the "hotkey" part. Whether you use it or not is beyond the point.

Dogtail is insanely good at sending commands to apps. https://wiki.ubuntu.com/Testing/Auto...ogtailTutorial You have the smart that you can hit exact interface buttons. You also have the pure raw https://fedorapeople.org/~vhumpa/dog...ut-module.html. Dogtail is python so you can put a GUI on top. All you control messages to applications can be implemented in dogtail using at-spi.

Orca the screen reader also does a fairly good job using at-spi. Going the at-spi interfaces avoids having to scan for as many patterns. When doing automated testing of applications you do a hell of a lot using at-spi. Some ways capturing window output would make sense to be a feature of at-spi.

Only thing that you have to worry about is window output capture. Screen capture support was implemented in weston. Gnome and other have decide to go own route doing something different to the reference and not submitting it to reference..

As for the toolkits, you're completely wrong, read @renox's second link at the beginning of this page (4), it is a mistake and INEFFICIENT to do it client sided especially due to shadows. You realize the "buffer" of toolkit is duplicated in each application while a central server handling it would be only one instance right? Not to mention it has to request larger window sizes to accommodate for possible shadows, even if there aren't any.

This is clueless when toolkit creates its toolbars/menus... it create a buffer owning the application. Putting the boarder in this in fact adds nothing that much in overhead. Toolkits do their own shadows around buttons and the like as well.

Please note lots of themes for windows boarders don't use shadows. Server side decorations support in wayland has been done by kwin. But you have to be aware doing shadows has overhead.

What you missed is simple. If server side is doing decorations. Toolkit still has to request buffer for the inside of window. Now that buffer has to be copied into another buffer to put the decorations on with the server side. Yes kwin does show overhead doing server side. All examples doing server side show overhead.

So if you are using a theme that does not need shadow effects doing it CSD reduces memory that has to be allocated. So the means to say Client Side decorations or server side decorations makes sense. Complex you might want server side. Basic you may want to save the ram and use client side decorations.

In Windows, a central place controls your decorations.

<<< Yes the entries in the registry applications dll files read when they run.

How bad you logic can be wrong. Still clueless how does UXtheme under windows apply the application decorate windows. It overrides the libraries the application uses. UXtheming came in Windows 95 and also show that its clearly client side. You need send a message so that library overrides are not being used.

Its not central controlled place the uxtheme.dll in the directory with the application under windows that renders a different theme to the system the application will be rendered differently. Reality is client side like it or not. If it was server side altering a library application uses cannot have this effect.

The ability to choose to draw your own decorations is not bad, if you specifically request it (which can also be done on X11). Why Wayland sucks and fails is because this is the ONLY option, i.e. it removes the other option to have a central theme and for apps which don't give a shit about decorating themselves and don't pick a toolkit. It's a massive pain and inefficient.

Reality here is a proper central theme should be made. X11 protocol provide a central theme file. Guess how many current toolkits use it absolutely zero. DWM in windows does not support drawing decorations. DWM is just as limited as the wayland protocol on theming. Windows theming is client side with a shared central store in the registry for theme.

Removing wm does not mean a central theme is not possible. It is insane that gtk, qt... can use the central theme on windows and OS X to blend in but they cannot agree to use a central theme on Linux, BSD.... Gtk and QT application under windows can be told to ignore the central windows theme. They don't have to send a message to say don't render as they are drawing themselves and ignore the UXtheme overrides.

The lack of central theme support is why buttons, checkboxs, window colors.... all don't line up under X11. Wayland is just attempt to hack around the issue. We really need the toolkit makers to be locked in a room until there is either only 1 left or they agree on central theme system.

Basically central theme with toolkits supporting client side possible falling back to a single toolkit. Here is a good question why can not the toolkits agree to create a single shared library to do CSD. See the problem here. How in heck do you get the toolkit people to work with each other.

[Weasel]

Sigh. You don't get it. The "central theme" is *exactly* what should have been part of the protocol. I don't care if it's technically client side or not, the point is it has to be defined into ONE place. Toolkit devs agreeing with each other and coming up with 1 solution is not gonna cut it, because this is not part of protocol, so what if someone forks the toolkit but decides to go his own way with theming? At least if it was part of Wayland protocol, they'd be unable to claim they SUPPORT WAYLAND properly. In Windows it's part of the system. There's NO windows system that does NOT have that central theme. This is unlike in Wayland because it refuses to add those as "required to comply with Wayland" which forces people hand.

That's exactly what fragmentation is about.

Lack of standard definition in one place due to fear of becoming bloated like Xorg is why Wayland ecosystem will always be fragmented compared to Xorg and limited, because now the essential features will depend on "people agreeing to a common solution", which is a retarded prospect.

Weston might implement those features but they're not part of protocol so another compositor is NOT REQUIRED to implement them to support Wayland, this is THE BIG PROBLEM. Not being part of the spec/protocol means they're not forced to add it.

Also I don't even want to use or consider toolkits. Wine doesn't even use any toolkits, nor should an app be forced if it wants to avoid thousands of boilerplate, so you see why Xorg is simply easier to use than the mess that Wayland is.

[oiaohm]

Sigh. You don't get it. The "central theme" is *exactly* what should have been part of the protocol. I don't care if it's technically client side or not, the point is it has to be defined into ONE place. Toolkit devs agreeing with each other and coming up with 1 solution is not gonna cut it, because this is not part of protocol, so what if someone forks the toolkit but decides to go his own way with theming? At least if it was part of Wayland protocol, they'd be unable to claim they SUPPORT WAYLAND properly. In Windows it's part of the system. There's NO windows system that does NOT have that central theme. This is unlike in Wayland because it refuses to add those as "required to comply with Wayland" which forces people hand..

History here. X11 protocol provided theming but that did not stop applications and toolkits from totally ignoring it. Really there is a place where central theme should be and its not wayland.

https://www.freedesktop.org/wiki/Specifications/
Right in this list.
https://specifications.freedesktop.o...-spec-0.5.html
And when you read the draft you go you have to be kidding. They did not even define names for basic set of colours.

That's exactly what fragmentation is about.

Really this is not looking close. You swap windows manager under X11 can you keep the same windows decoration theme the answer is maybe. Because its not defined in a common format. So its already fragmented to hell and the standard for prevent that have been totally ignored. If there was a proper central theme going to client side decorations would not cause as much trouble.

Lack of standard definition in one place due to fear of becoming bloated like Xorg is why Wayland ecosystem will always be fragmented compared to Xorg and limited, because now the essential features will depend on "people agreeing to a common solution", which is a retarded prospect.

Putting everything in the X11 standard did not stop people from ignoring it. Wayland protocol is not include stuff that should be in other protocols. Theme define should not care if you are using X11, Wayland, Framebuffer...

Weston might implement those features but they're not part of protocol so another compositor is NOT REQUIRED to implement them to support Wayland, this is THE BIG PROBLEM. Not being part of the spec/protocol means they're not forced to add it.

We are already seeing feature like crash resistance that is part of the Wayland protocol not being implemented by GTK/Gnome.

Also I don't even want to use or consider toolkits. Wine doesn't even use any toolkits, nor should an app be forced if it wants to avoid thousands of boilerplate, so you see why Xorg is simply easier to use than the mess that Wayland is.

But wine is using a toolkit https://en.wikipedia.org/wiki/XCB Wine is not talking raw X11 display protocol. For some reason using xlib or xcb people don't class as a toolkit when it is.

Base toolkits in wayland.

https://wayland.freedesktop.org/docs/html/apb.html
libwayland-server
libwayland-client

Now could client side decorations in theory be done in libwayland-client yes it could. But they are not going to unless there is some agreement on standard. Really I totally agree with wayland force client side decorations.

Those attempt to port windows managers are finding they cannot have common look in windows boarders. What about all the other theme issues they have been ignoring like applications with miss matched fonts/colours everyone else in window. Fairly much client side decorations says you have to implement common theme. If common theme existed wine project would in fact pull default from it. Remember even if you don't have client side decorations of the window you still have client side decorations of all the buttons, menu.....

To be truthful I more suspect that flatpak will fix issues more than toolkit/windows manager developers. Flatpak portals are starting to provide ways for applications to use the same common dialogues and a system for this has been completely missing from the toolkits so each full toolkit provided it own unique common dialogues. Flatpak has to deal with the theming problem as well and this problem is not just when running on wayland its when running on X11 as well. I think flatpak will pull them kicking and screaming.

Common dialogues with flatpak have to be used or you don't get permission to read/write files. This is the force required to get common dialogues now you need to apply equally hard force to get the other stuff that should be common as common. Client side decorations in wayland is applying pressure only way to get back to what you had is implement common theme this time cover all the client side decorations not just window boarders.

[Weasel]

History doesn't matter since Xorg is old, it is allowed to have a flawed history (what matters is how it is used these days). Wayland is not. You know, repeating past mistakes isn't exactly a feat.

Really this is not looking close. You swap windows manager under X11 can you keep the same windows decoration theme the answer is maybe. Because its not defined in a common format. So its already fragmented to hell and the standard for prevent that have been totally ignored. If there was a proper central theme going to client side decorations would not cause as much trouble.

The Window Manager *is* centralized. Most applications don't have to care about it. They'll all have to end up using it, no matter the toolkit. The point is that you have to do it in ONE place instead of leaving it to the decision of EVERY APP.

If Xorg is a corrupt democracy where people (apps) at least have a common leader to follow (but they can avoid it), Wayland is like anarchy, which is much worse.

We are already seeing feature like crash resistance that is part of the Wayland protocol not being implemented by GTK/Gnome.

Yeah, but then it's not Wayland's fault for causing the fragmentation, it's Gnome and gtk's issue. This is very important.

You don't justify broken apps not implementing an API properly or a full protocol. On the other hand if the API or protocol is deliberately vague or leaves it undefined, then you end up with a mess and it is impossible to point finger at anyone, except the originator for leaving it undefined.

I don't know about flatpak, never used it, personally it seems over-engineered for such a simple problem (application distribution).

I don't really understand why is it so difficult to just bundle every damn library with an application, and to efficiently share resources, hard link the damn libraries automatically if same minor version (automatically update it if it's a larger *minor* version, which means the ABI should be perfectly stable and compatible). Then you don't even *need* to provide an uninstaller, just literally remove the entire app's folder with all its libraries. Since it's hard linked, the library will only get removed if all other uses of it are not installed in flatpak. Each app would have all libraries it depends on bundled within its own directory, and they would be hard linked if compatible based on naming scheme which already works. Removing is as simple as rm -rf /app/dir only installation requires simple hard linking checks (even a shell script could do it).

But I guess RH have to make everything complex to intentionally have holes they can screw with users later. But that's off topic lol.

[oiaohm]

The Window Manager *is* centralized. Most applications don't have to care about it. They'll all have to end up using it, no matter the toolkit. The point is that you have to do it in ONE place instead of leaving it to the decision of EVERY APP.

xcb and xlib both allow you to by pass the windows manager control by pretending be the windows manager. xmms media player did that early on. My point is the central place does not have to be a Window Manager or part of the protocol about rendering to screen. If you are copying windows you would put in default window decorations the libwayland-client library and have all applications use that.

Wayland is the name of the protocol for compositing and rendering the windows. Its not the name of the protocol that should be in charge of theme that is Xsettings.

Its like people wanting to remote control applications asking for at-spi stuff to be in wayland protocol itself.

Yeah, but then it's not Wayland's fault for causing the fragmentation, it's Gnome and gtk's issue. This is very important.

But its the same with lack of central theme. You are seeing all these groups attempt to fix the problem without working on the reference implementation or submitting to the standard and worse taking standards like xsettings extending and not up-streaming features.

The reality there was a standard to create a central theme that desktop environments on Linux/FreeBSD have either ignored or use modified version that is incompatible with everything else. Putting something like that in the wayland standard would still be wrong.

You don't justify broken apps not implementing an API properly or a full protocol. On the other hand if the API or protocol is deliberately vague or leaves it undefined, then you end up with a mess and it is impossible to point finger at anyone, except the originator for leaving it undefined.

Its also wrong for protocol/standard to duplicate another protocol/standard when both protocol/standard should operate next to each other without issue. Think about it proper central theme you could have X11 programs and Wayland programs using the same theme data so matching with each other. Yes X11 applications running in Xwayland would match up normal Wayland applications if this was done.

I don't know about flatpak, never used it, personally it seems over-engineered for such a simple problem (application distribution).

I don't really understand why is it so difficult to just bundle every damn library with an application, and to efficiently share resources, hard link the damn libraries automatically if same minor version (automatically update it if it's a larger *minor* version, which means the ABI should be perfectly stable and compatible). Then you don't even *need* to provide an uninstaller, just literally remove the entire app's folder with all its libraries. Since it's hard linked, the library will only get removed if all other uses of it are not installed in flatpak. Each app would have all libraries it depends on bundled within its own directory, and they would be hard linked if compatible based on naming scheme which already works. Removing is as simple as rm -rf /app/dir only installation requires simple hard linking checks (even a shell script could do it).

This is being clueless flatpak is designed with a sandbox because it kind of required. Appimage and other solutions also started providing option to sandbox due to the horrible of like third party application creating something on dbus it needs and directly conflicting with something host applications needs and all hell breaking lose due to this run time stuff not being compatible.

Also wishful thinking. There are libraries that minor version number change is ABI breakage. Shipping applications is fairly straight forwards making sure they all get along with each other when running is another problem completely. You want dependable third party application install without sending stuff to hell you need something as complex as flatpak. Even windows third party application install end up with application conflicting with other applications.

Flatpak design comes out of looking at all the way people attempted to ship third party applications and how those caused failures.

Wayland looks like a mess until you start seeing what standards should be used with each other.

So a good compositor/desktop environment by law should have at-spi support and that is fully at-spi support because discrimination against people with disability is a crime so part implementing can be punished by the courts.

Also you are not thinking for people who are colour blind and the like central theme support could be put under accessibility. Accessibility feature are interface neutral and backed by law.

Basically I don't get what the problem is with wayland to do most of the display work wayland has everything it needs. My point of view at-spi is lacking. Lets use the one that we can hit developers with fines and other punishments for not implementing correctly.

I guess you never though that a wayland compositor need to be implementing at-spi as well to be legal. Only stuff in accessibility frameworks can be enforced by court of law on developers.

[Weasel]

xcb and xlib both allow you to by pass the windows manager control by pretending be the windows manager. xmms media player did that early on. My point is the central place does not have to be a Window Manager or part of the protocol about rendering to screen. If you are copying windows you would put in default window decorations the libwayland-client library and have all applications use that.

Wayland is the name of the protocol for compositing and rendering the windows. Its not the name of the protocol that should be in charge of theme that is Xsettings.

Its like people wanting to remote control applications asking for at-spi stuff to be in wayland protocol itself.

The more stuff in Wayland the better, because then people wouldn't devise different solutions for the same features. I mean Wayland is a protocol not a product so it's ok to be bloated.

You said that Weston, the "reference" implementation, implemented screen capture. But gnome did not follow in the same way. This means that "screen capture" is NOT PART of the spec, which is THE WHOLE PROBLEM man. Wake up.

How the fuck is something a "reference" implementation if it implements extra features? Reference implementations are supposed to implement only the API or protocol or format itself, not "extensions" because then it's not a reference implementation anymore.

The fact that Weston had to implement features outside the Wayland protocol speaks volumes about Wayland's design.

But its the same with lack of central theme. You are seeing all these groups attempt to fix the problem without working on the reference implementation or submitting to the standard and worse taking standards like xsettings extending and not up-streaming features.

The reality there was a standard to create a central theme that desktop environments on Linux/FreeBSD have either ignored or use modified version that is incompatible with everything else. Putting something like that in the wayland standard would still be wrong.

Its also wrong for protocol/standard to duplicate another protocol/standard when both protocol/standard should operate next to each other without issue. Think about it proper central theme you could have X11 programs and Wayland programs using the same theme data so matching with each other. Yes X11 applications running in Xwayland would match up normal Wayland applications if this was done.

They don't have to use the same theme from the same place. It just has to be DEFINED instead of leaving it off to 3rd parties.

This is being clueless flatpak is designed with a sandbox because it kind of required.

Nah it's not "kind of required", it's not required at all. If you want a sandbox then use dedicated software for it, not an application distribution. Obviously Wayland is also limited on purpose in features for "sandboxing" bullshit (aka tablet use of computer).

Let me tell you something, lack of features is way worse than bad security. I mean if it wasn't, then go plug off your internet completely. Then you're 100% secure, who cares you lost access to the internet right? Features and usability don't matter, only pseudo-security does. /sarcasm