Announcement

Collapse
No announcement yet.

Valve Engineer Mike Blumenkrantz Hoping To Accelerate Wayland Protocol Development

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

  • Artim
    replied
    Originally posted by billyswong View Post

    It is a joke that all your praises of Wayland security disappear conveniently for whenever functionalities that happen to be not used by you.
    The only thing here being a joke is your lack of basic common sense...

    Moving a window is supposed to be a job of the window compositor. It should be functional no matter the user application is hanging or not. A program hangs and looks like the user needs to wait it a while until it finishes its job. So the user moves it to a convenient spot outside the center of focus. This is a simple workflow. Nothing fancy.
    Exactly. But for that, I can guarantee you, nobody is that retarded that they want to move the frozen window to a different place. Instead they'll just put whatever they want to work on in front of it and call it a day. The whole UX philosophy of Gnome is to always have only one program window visible, preferably full-screen so everything else can't distract you. But that old common knowlegde is just above you.



    In an SSD application, the "Always on Top" button is provided by the compositor. No security sandbox breaking. In a CSD application, the "Always on Top" button is provided by the application itself.
    Wrong. The context menu is always provided by the compositor. The only thing the app must provide is a header bar. That's why that won't be available e.g. in Firefox.or Chromium browsers. But every app that doesn't remove the header bar get that option. The app itself has to provide nothing, rendering the rest of your argument completely wrong and irrelevant.

    Painting any inconvenient truth that you refuse to face as "bs rants", wow.
    Nope, you have yet to speak the truth. But for that you would have to be able to understand it, which you clearly don't.

    Leave a comment:


  • Artim
    replied
    Originally posted by Espionage724 View Post
    What do people think about this? https://stopthemingmy.app/ I saw it on GNOME Resources GitHub.

    I think it sounds reasonable and would probably put that on my app out-the-box (can't guarantee what anyone other than Fedora with default upstream GNOME does)
    That one is very old already and it's the main reason why Gnome-devs built libadwaita. While you can still theme libadwaita apps, you can't change as much anymore and thus have a smaller chance of breaking an apps UX.

    Leave a comment:


  • billyswong
    replied
    Originally posted by Artim View Post
    Maybe, but your refusal to give any reason why this in fact should be a feature only proves me right. A frozen window shouldn't be interacted with, a frozen window should notify the compositor so it can ask the user if it should wait or kill the app.
    It is a joke that all your praises of Wayland security disappear conveniently for whenever functionalities that happen to be not used by you. Moving a window is supposed to be a job of the window compositor. It should be functional no matter the user application is hanging or not. A program hangs and looks like the user needs to wait it a while until it finishes its job. So the user moves it to a convenient spot outside the center of focus. This is a simple workflow. Nothing fancy.

    Originally posted by Artim View Post
    How much more obvious do you want to make it that you are only out for Gnome bashing and so red-hot with rage that you can't even think? It is a big security issue when windows can just decide on their own to rise to the top-most level or worse forcing themselves to stay there, but if the user decides he wants a window to do exatcly that, it simply isn't a risc anymore, as the window does what the user expects, it doesn't do the unexpected. Jesus, just think before you write for once in your life!
    In an SSD application, the "Always on Top" button is provided by the compositor. No security sandbox breaking. In a CSD application, the "Always on Top" button is provided by the application itself. What magic does Gnome know, such that Mutter can differentiate between user clicking on that button within the CSD application, and the application pretending such button has been pressed by user? Sorry, if such magic is possible, all the rationale of restricting Wayland protocol functionality will be moot.

    Please, just admit that allowing CSD applications to contain an "Always on Top" button is sandbox breaking. Stop act as if Gnome is always right and "think before you write".

    Originally posted by Artim View Post
    ​Unless you learn to think and actually reason, there is no place for your bs rants. Come back when you learned some basic common sense and logic!
    Painting any inconvenient truth that you refuse to face as "bs rants", wow.

    p.s. I agree with Gnome standpoint of not giving applications a mean to place their windows in arbitrary absolute coordinate without sanitization. A broken clock is correct twice a day.
    Last edited by billyswong; 27 September 2024, 10:21 PM.

    Leave a comment:


  • Espionage724
    replied
    What do people think about this? https://stopthemingmy.app/ I saw it on GNOME Resources GitHub.

    I think it sounds reasonable and would probably put that on my app out-the-box (can't guarantee what anyone other than Fedora with default upstream GNOME does)
    Last edited by Espionage724; 27 September 2024, 08:27 PM.

    Leave a comment:


  • WileEPyote
    replied
    Originally posted by Artim View Post

    Who the fuck do you think will read that wall of text? Get a life...
    lol. Can't stand being wrong, eh?

    Leave a comment:


  • WileEPyote
    replied
    Originally posted by access View Post

    Windows color management and HDR is a mess. What is landing in Wayland sure looks to be better and might even compete with the way Apple does things. But these things are seriously hard to get right and without unlimited funds it takes time 'cause the whole stack needs to support it from the kernel to the compositor… all the while hearding cats/foss developers.
    It's the herding of devs that's the problem. Would've had support a lot sooner if not for egos.

    Leave a comment:


  • Artim
    replied
    Originally posted by ahrs View Post

    Worked on where? Because https://gitlab.gnome.org/GNOME/gtk/-...3#note_1865439 is a KDE developer and his branch has zero chance of being merged if the GTK developers don't like it.
    What on earth are you smoking? He's not "a KDE developer". He's a developer period. He has worked a lot on KDE stuff, but also on a lot of other stuff, including lots of GTK stuff. There is absolutely no proof for what you say. In fact, only one Gnome developer ever spoke out against the idea, and if you where capable of reading the comments of the MR your even linked yourself, you would have noticed that he's alone with that opinion.

    Leave a comment:


  • Artim
    replied
    Originally posted by billyswong View Post

    You sound like you are in "I don't use feature A thus feature A must be useless" mindset. This is selfish.
    Maybe, but your refusal to give any reason why this in fact should be a feature only proves me right. A frozen window shouldn't be interacted with, a frozen window should notify the compositor so it can ask the user if it should wait or kill the app.


    Let me give a more mainstream example. GTK CSD applications currently provide a "Always on Top" option in header bar pop ups. But this feature is not standardized in Wayland and probably never will because of the security ideology of Wayland, which you are merrily appreciating right now. If Wayland provide such feature, it would allow software in background steal attention without user consent. Thus no it won't get implemented ever.
    And I'm very thankful that it will never be. That's a design flaw in Windows that should never be replicated anywhere else. In fact I would go as far as prohibiting any window from ever rising to the top-most level so it can't just interfere with input. No idea if that's already the case, but at least these dialogs like "wait or kill" only put themselves on top of the program they belong to, not to the top-most level. At least not in Gnome.

    But that doesn't change anything I already said. All legitimate use cases that aren't just giant security issues will eventually be enables, but the more obscure and niche they are, the longer it will take.

    So what is happening in those GTK CSD applications? They are doing an abstraction leak and bypassing the Wayland protocol, talking to Mutter in Wayland via a private method without cross-DE compatibility. Please pull your head out of the sand. Gnome/GTK is using the security card when they want to ban a feature they aren't interested in, then ignore security and cross-compatibility when it is a feature they like. All these are just arbitrary selfish decisions.
    How much more obvious do you want to make it that you are only out for Gnome bashing and so red-hot with rage that you can't even think? It is a big security issue when windows can just decide on their own to rise to the top-most level or worse forcing themselves to stay there, but if the user decides he wants a window to do exatcly that, it simply isn't a risc anymore, as the window does what the user expects, it doesn't do the unexpected. Jesus, just think before you write for once in your life!


    [cutting nonsensical rants]
    Unless you learn to think and actually reason, there is no place for your bs rants. Come back when you learned some basic common sense and logic!

    Leave a comment:


  • ahrs
    replied
    Originally posted by Artim View Post

    It is still worked on, so your comment of Gnome never supporting it has already been proven a lie.
    Worked on where? Because https://gitlab.gnome.org/GNOME/gtk/-...3#note_1865439 is a KDE developer and his branch has zero chance of being merged if the GTK developers don't like it.

    Leave a comment:


  • Artim
    replied
    Originally posted by ahrs View Post

    It's not merged. Until it gets merged then that support is not in place.
    It is still worked on, so your comment of Gnome never supporting it has already been proven a lie.

    Leave a comment:

Working...
X