Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • mSparks
    replied
    Originally posted by oiaohm View Post

    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.

    Originally posted by oiaohm View Post
    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
    Last edited by mSparks; 14 April 2024, 04:14 AM.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by oiaohm View Post
    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.

    Originally posted by oiaohm View Post
    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.

    Leave a comment:


  • oiaohm
    replied
    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.

    Originally posted by mSparks View Post
    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.






    Leave a comment:


  • mSparks
    replied
    Originally posted by oiaohm View Post

    Really you need to stop posting garbage.

    For those picking up on this as "news", please read the following list: PCSX2 still supports Wayland. It just prefers the XCB/XWayland platform by default. You can set the I_WANT_A_BROKEN_WAYLAND_...


    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.
    Last edited by mSparks; 13 April 2024, 11:57 PM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by mSparks View Post
    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.

    For those picking up on this as "news", please read the following list: PCSX2 still supports Wayland. It just prefers the XCB/XWayland platform by default. You can set the I_WANT_A_BROKEN_WAYLAND_...


    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.

    Leave a comment:


  • mSparks
    replied
    Originally posted by caligula View Post

    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).

    Leave a comment:


  • caligula
    replied
    Originally posted by Joe2021 View Post

    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.

    Leave a comment:


  • user1
    replied
    Originally posted by Myownfriend View Post

    There's an interesting thing going on with Electron/Chromium-based apps where even if they launch as Wayland apps, XWayland launches, and if you kill XWayland it also closes the app. But if you prevent XWayland from launching to begin with, the app launches and runs just fine.
    I've noticed something similar with an SDL2 based game (Red Eclipse). If I launch it with SDL_VIDEODRIVER=wayland , for some reason XWayland still launches with the game. Interestingly, XWayland doesn't launch with other SDL2 based games.

    Leave a comment:


  • Kjell
    replied
    Originally posted by joaquinvacas View Post

    So I use the Flatpak version of Steam and all the 32bit parts are just confined onto those Flatpak dependencies that don't interfere or mess up with the whole OS ones.
    I run Steam in "native mode" since I want to use my system libraries which are both newer and compiled against march=native

    WOW64 works really well, haven't had issues with any of my games which I run through Bottles

    Leave a comment:


  • joaquinvacas
    replied
    Originally posted by Kjell View Post

    32bit lib requirement doesn't exist in Steam's MacOS version. Now we just need it removed in Linux.

    Spread the word!!
    macOS doesn't run 32bit software, CPUs are pure 64bit and can't run directly 32bit games and that's why. I think there is some work being done to do a WoW64 like functionality under pure 64bit CPUs.

    Anyhow, I use Arch (btw) and have all 32bit libraries disabled (repos, I mean, so don't have any multilib package installed)

    So I use the Flatpak version of Steam and all the 32bit parts are just confined onto those Flatpak dependencies that don't interfere or mess up with the whole OS ones.

    Leave a comment:

Working...
X