Announcement

Collapse
No announcement yet.

Years After Wayland 1.0, Will 2016 Be The Year Of The Wayland Desktop?

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

  • #61
    So sad Wayland is developed as Linux only :-(

    Comment


    • #62
      Originally posted by drSeehas View Post
      So sad Wayland is developed as Linux only :-(
      Apart from, you know, the efforts to port it to FreeBSD and others. There's nothing Linux-specific about Wayland - it requires certain functionality be available from the drivers, but it's not like the way Systemd is fundamentally built around Linux-specific APIs.

      Of course, the BSDs being chronically under-resourced, I wouldn't expect to see working Wayland/BSD desktops any time this decade...

      Comment


      • #63
        Originally posted by Delgarde View Post
        Apart from, you know, the efforts to port it to FreeBSD and others. ...
        Once upon a time software developers were proud their code runs on as many OSs as possible. They made their code to make porting as easy as possible.
        Unfortunately these times are gone.

        Comment


        • #64
          Originally posted by Scias View Post
          IIRC Pixman is CPU-accelerated while XRender does use GPU acceleration. So no wonder the performance is much lower.
          Nope. Again, that's a Poulsbo device. It doesn't have GPU acceleration to begin with.

          Comment


          • #65
            Originally posted by ileonte View Post
            You keep throwing these 'exotic' examples out but in reality all you need to think about is something like running a GNOME/GTK application under KDE for example - what happens then ? Does it have the 'native' KDE decorations ? Most likely not. Great step forward for a 'cohesive' desktop.
            Why would you ever think it wouldn't have native decorations? The compositor is KWin, and the compositor is what decorates the windows. (If the decorations are not the same, that's because of GNOME software using CSD and voluntarily breaking cohesiveness, but it has nothing to do with Wayland.)

            Comment


            • #66
              Originally posted by drSeehas View Post
              So sad Wayland is developed as Linux only :-(
              Can you give an example of something specified/required by the Wayland protocol that is Linux only?

              Cheers,
              _

              Comment


              • #67
                Originally posted by ileonte View Post
                That's exactly my point - it doesn't mandate anything.
                Isn't that the same situation on X11?

                It doesn't mandate much either, most of what desktop shells and applications use are addon specifications (e.g. extended window manager hints) or extensions (e.g. xrandr).

                Given that the need of desktop shells and applications doesn't change, I would expect there be no difference with Wayland.
                I think I've even read about this already being worked on, I think one of these extensions was called "xdg_shell" or something like that.

                Cheers,
                _

                Comment


                • #68
                  Originally posted by ileonte View Post
                  That's exactly my point - it doesn't mandate anything...
                  But why should it force a particular style of window decorations ? Neither SSDs or CSDs are ideal and flawless and I'm quite glad the Wayland design doesn't force anything there.

                  Sure with SSDs you get identical window decorations and controls across all applications but it also means an extra thing to do for the compositor(esp. syncing correctly the decoration with the window texture in resizes/moves), the application itself not having control of its own window decoration (so it can't put tabs or more information on it), and losing consistency between the decoration and the application itself (like using a non-Qt app using when under KDE/KWin).
                  So the consistency you strive so much to get is lost somewhere else anyways, and unless you run a pure Qt desktop, even with SSDs it won't be consistent anyways.

                  Yeah I get CSDs have a ton of issues too, and I surely don't want Linux to become a Windows-esque jungle with each application having their ridiculously different titlebars. But the "consistency" can't, and shouldn't be enforced by the windowing system. Today any developer can make an app using the ugly Tk toolkit with the application menus on the bottom of the window and 950px wide buttons and it won't be consistent compared to all other applications, unless you also want to force the windowing system/compositor to draw all UI elements or force a particular toolkit--oops looks like a d?j? vu...

                  You say you trust the applications you install and run on your machine, don't you trust the developers of free software to be reasonable about window decorations too ? Or to agree on some basic guidelines ?

                  Look at how OSX is often praised for having a slick and consistent UI, yet it uses CSDs...

                  Anyways I guess this question becomes more a matter of taste or even philosophical, do you consider the window titlebar to be part of the application's window or not ?
                  Last edited by Scias; 27 October 2015, 11:57 AM.

                  Comment


                  • #69
                    Originally posted by Stellarwind View Post
                    You keep saying "security", while in fact it is not even there yet. Problem is that some apps, like screenshot apps, screen recorders and readers still need to access all the input/output. They don't really know how that should really work in practice. Since there is no good answer to that, they are creating security module api that is supposed to handle that and kinda avoid that problem entirely.
                    In most cases however, this is not that big of a problem - you trust the apps you run anyway and there is much more ways to steal your input/output, LD_PRELOAD is not going anywhere.
                    If you want security, you can get Qubes OS already.
                    That's the point, I don't trust the apps I run. Because they are vulnerable. Because opening a document with pictures can trigger buffer overflow and code execution, I don't want my apps to have the full set of user level permissions all the time.

                    It's an awfull issue in desktop Linux security, and most people seem not to care:

                    I don't care if an application can get root: everything important on my desktop (why I type, where I go on the internet, what I read, my browser password database, my files, these same files atacked by a cryptoransomware, etc...) are all accessible under my user permissions. User based permission is a completely useless security model in this case.
                    It means that the system must be able to differentiate the user and the application running under its name, and authorize application actions using finer grained permissions.
                    That's what's done in SELinux or apparmor, or in any mobile OS when you install some app.
                    But for that to work, the system must be able to effectively deny an application acces to any non authorized resource, which, for input and screen access under X, you cannot.

                    Comment


                    • #70
                      End users should not care about this , X still works just fine and it should be hanging around for the foreseeable future . If the transition must happen then it should be totally transparent , seamless and not disruptive . Wayland developers now want to sell the idea that the linux desktop is insecure under X, but that is kind of silly . The Linux desktop never has been considered as insecure.

                      Comment

                      Working...
                      X