XWayland 24.1 Planned For Release Next Month With Explicit Sync & Other Features

[caligula]

The popularity of Electron based apps is a mystery to me. I try to avoid it whenever I can.

Outside the Linux world almost no developer writes native GUI apps anymore. Everything uses React / Vue / Svelte / Flutter. The developers simply don't have any experience writing native non-web apps.

[mSparks]

Outside the Linux world almost no developer writes native GUI apps anymore. Everything uses React / Vue / Svelte / Flutter. The developers simply don't have any experience writing native non-web apps.

pretty much,

imho its not just a lack of experience writing native guis though, its that the tooling and functionality offered by native apps accross the OS ecosystem falls far short of that necessary.

exceptions are android and ios, which both have their own rock solid gui development toolchain, and subsequently only make light use of HTML5 for their guis (native support for which ships with both ios and android, rather than having to bundle a CEF install like you do for macos/windows/linux)

closest competitor/alternative seems to be Qt, and besides being insanely expensive that is so chock full of bugs on wayland it is unusable (as seen recently with PCSX2 dumping their wayland backend in part due to the lack of Qt stability).

[oiaohm]

closest competitor/alternative seems to be Qt, and besides being insanely expensive that is so chock full of bugs on wayland it is unusable (as seen recently with PCSX2 dumping their wayland backend in part due to the lack of Qt stability).

Really you need to stop posting garbage.

https://github.com/PCSX2/pcsx2/pull/10179

The issue with PCSX2 is not in fact Qt stability. The largest issue causing all forms of hell with PCSX2 is that it is in fact a multi application program so it find Wayland protocol missing feature coming from failure to agree how to-do those features.

• Inability to position windows => window position saving doesn't work, log window attaching (not merged yet) doesn't work
• Hacks in render-to-main because WL craps itself otherwise

These two issues the PCSX2 developer list link to the same thing of being a multi process application.

mSparks do remember all KDE applications are Qt applications and they do work stability under Wayland. There is a catch of course none of your KDE applications are multi process application design.

[mSparks]

Really you need to stop posting garbage.

https://github.com/PCSX2/pcsx2/pull/10179

The issue with PCSX2 is not in fact Qt stability. The largest issue causing all forms of hell with PCSX2 is that it is in fact a multi application program so it find Wayland protocol missing feature coming from failure to agree how to-do those features.

• Inability to position windows => window position saving doesn't work, log window attaching (not merged yet) doesn't work
• Hacks in render-to-main because WL craps itself otherwise

These two issues the PCSX2 developer list link to the same thing of being a multi process application.

mSparks do remember all KDE applications are Qt applications and they do work stability under Wayland. There is a catch of course none of your KDE applications are multi process application design.

maybe just learn to read, and do some before shooting your mouth off.

I was referring to this exact quote in the link you just posted:

-> It causes issues, most of which are caused by QtWayland

personally I'm inclined to recommend taking the word of a proven wayland developer rather than some random phoronix poster that is incapable of reading a github issue, and has proven time and again they dont have the slightest clue what they are talking about.

[oiaohm]

It causes issues, most of which are caused by QtWayland, some are caused by the protocol itself.

Notice how mSparks did not quote the full line. Some he could identify as cased by the protocol.

Next question did you look at the issues he posted against QtWayland and what they were resolved to. The answer is no you did not.

personally I'm inclined to recommend taking the word of a proven wayland developer rather than some random phoronix poster that is incapable of reading a github issue, and has proven time and again they dont have the slightest clue what they are talking about.

Is the pcsx2 developer a qt core developer or a Wayland protocol developer the answer is no he is not. So the pcsx2 developers option on what is the issues with QtWayland does not very much meaning.

This is the problem when you look at the QtWayland bugs the pcsx2 developer submitted and what the resolve to they resolve to Wayland protocol limitations most of the time.

Remember all the KDE applications also use QtWayland and that working without issue. So this brings back to what is so special about the pcsx2 case that it hits these problems so much.

Over 98% of applications on the desktop are not designed the way PCSX2 is.

Of course there is another bit that is important that you would have ignored.

KDE isn't too buggy, GNOME is a complete disaster.

So the most complete Wayland implementation causes Pcsx2 the least trouble.

mSparks you really do need to stop posting garbage based on of posts from people who really many not be qualified enough to tell what the real issue is. Remember QtWayland giving a developer trouble this can be a fault in QtWayland or a fault caused by a particular feature being missing from Wayland protocol that QtWayland trys to use no operation code for that end up causing issues. Yes the are quite a few cases where its the no operation code being used so that a function does not error just because Wayland protocol does not have a feature yet.

[anda_skoa]

mSparks do remember all KDE applications are Qt applications and they do work stability under Wayland.

Qt + Wayland is also used a lot on embedded devices. Often event the compositor is written with Qt Wayland Compositor.

There is a catch of course none of your KDE applications are multi process application design.

I guess it depends on how one would define "multi process application"

Quite some KDE applications are split into a service and a UI process.

Kontact is essentially a single process variant of a multi process setup of the respective applications.
Their shared backend is multiple processes as well.

Kate, and likely a number of other applications, can delegate work to external tools, usually run as separate processes.

Plasma is essentially also a set of orchestrated processes (services and UI) with at least Plasma Shell, KWin and KRunner contributing to the overall UI.

[mSparks]

Notice how mSparks did not quote the full line. Some he could identify as cased by the protocol.

The full quote is:

" I was the one who implemented Wayland support in the first place, this isn't some "anti wayland" crusade. It causes issues, most of which are caused by QtWayland, some are caused by the protocol itself. I want nothing more than to see Wayland succeed, but at the moment, it is unusable for a majority of users."

Its very clear, no ambiguity there, doesn't matter which way you cut it or how many strawmen you build.

Is the pcsx2 developer a qt core developer or a Wayland protocol developer the answer is no he is not.

Seems you, me and him are all agreed, anybody who is not a qt core developer or a Wayland protocol developer should forget about wayland for a few decades until/if they get their shit together.

In the meantime, everyone will keep using React / Vue / Svelte / Flutter etc. with a healthy does of X11 for HPC on linux, swift on ios, android studio for android and even some directX for those microsofties who can stomach winblows

[oiaohm]

I guess it depends on how one would define "multi process application"

I should be more clear.

Seems you, me and him are all agreed, anybody who is not a qt core developer or a Wayland protocol developer should forget about wayland for a few decades until/if they get their shit together.

No I don't agree. Many parties using QtWayland without any issues. What is unique about pcsx2 is something horrible. When I say multi progesses application. I mean multi progress GUI application in a very particular way that not common.

You click on a button in pcsx2 and popup appears. You have a 80% that the popup that has just appeared is from a different progress to the button you clicked. Now what is the odds of this in 98%+ of all applications out there. That right this does not happen at all. PCSX2 GUI design in it code is a true odd ball.

Quite some KDE applications are split into a service and a UI process.

Yes I was not referring to service/ui process multi process or . I am referring to multi process inside the UI part with pcsx2 this makes is very different to all the KDE applications.

mSparks when something is having trouble it takes two to tango as they say. There are things about pcsx2 that make it not a common application design it hits a lot of corner cases that are not well supported at this stage.

Fixed link this is a 2020 presentation that was given in a few different conferences.

https://elinux.org/images/6/61/Oct_27_Graphical_User_Interface_Using_Flutter_in_Embedded_Systems_Hidenori_Matsubayashi.pdf

Flutter + Wayland is the best practice in embedded systems using Linux

Yes that is 2020 and in 2020 we were already seeing new soc chips released for embedded without X11 support.

https://github.com/sony/flutter-embedded-linux

And it gets more fun mSparks
Display backend support

Wayland
Direct rendering module (DRM)
Generic Buffer Management (GBM)
EGLStream for NVIDIA devices

That right for embedded usage the current version of flutter does not support X11 at all(yes it use to). Yes flutter has weston integration as it own shell/window manager.

Users of flutter in embedded they don't have a healthy dose of X11 for quite a few years now.

mSparks like it or not there are a lot of use cases where wayland and weston are perfectly fine where X11 use to be but X11 in those use cases is no more.

mSparks wounder how many other things that you claim everyone uses also turn out to be like flutter use to support X11 but today does not support X11 at all. This is part of why upstream X11 on bare metal is running out of developers.

[Quackdoc]

...

Your link is broken for the PDF. but I would very much disagree with flutter + wayland being best practice for embedded. Well flutter at all. Flutter is great don't get me wrong, I love flutters flexibility, relatively good performance and ease of development. However Flutter is still a lot heavier on drawing then a lot of other toolkits. This is fine for things like modern phones, even low end ones, but they still have, in relation ship to other "embedded devices" a quite powerful gpu. They also sit heavier on ram as well.

Flutter is only a good option on the more powerful end of the embedded spectrum. Even on android I'm not the biggest fan of flutter applications on super low end phones.

[anda_skoa]

I should be more clear.

Lot's of different possibilities how processes interact

When I say multi progesses application. I mean multi progress GUI application in a very particular way that not common.

I wonder why they are not using a more common approach then.

You click on a button in pcsx2 and popup appears. You have a 80% that the popup that has just appeared is from a different progress to the button you clicked. Now what is the odds of this in 98%+ of all applications out there.

While it might not be super wide spread, it is something you will have with KDE's PIM applications, when the user creates a new "connector".

For example when you are in Kmail and create a new IMAP account, the backend service will create another IMAP handler.
And Kmail will then ask (via D-Bus) that handler process to show its configuration UI.

That UI appears to the user as a dialog of Kmail, because the two processes have exchanged the information necessary to associate the "foreign" window to be "transient to" Kmail's main window.

Outside of Qt we have basically all web browsers which launch one process per tab and integrate their buffers into their own UI.

That right this does not happen at all. PCSX2 GUI design in it code is a true odd ball.

I am somewhat curious how they are approaching their "foreign" process integration, but I guess I don't really want to spend that much time understanding a code base I am not used to

Yes I was not referring to service/ui process multi process or . I am referring to multi process inside the UI part with pcsx2 this makes is very different to all the KDE applications.

There could still be similarities, see above