Announcement

Collapse
No announcement yet.

If Or When Will X12 Actually Materialize?

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

  • #41
    Originally posted by movieman View Post
    But that _forces_ applications to 'follow a common GUI', which is even worse; particularly if one of those apps is running on my laptop with a 3GHz quad-core CPU and 6GB of RAM while the other is running on an ARM with 32MB of RAM.
    No, it doesn't force anything. Style hints are just that; hints. How it looks and how many resources it eats depends solely on your DE.

    The odd thing is that when I went from Sunview/Xview programming to Windows, I couldn't understand how anyone could stomach writing Windows software when the API was so low-level and convoluted... having to deal with processing individual messages rather than object-oriented callbacks to event functions? How primitive.
    Which is why you use a toolkit on windows too. The difference is, the toolkit doesn't invent its own look. This is a design that is followed by both Windows and the Mac. And it provides for consistency, something that can be crucial for the adoption of a system.

    Both Apple as well as MS have spend major amounts of resources (money) on this. I don't think X has.

    Comment


    • #42
      Originally posted by RealNC View Post
      And it provides for consistency, something that can be crucial for the adoption of a system.
      So do KDE and Gnome.

      The difference is that if you hate Gnome, you can just install KDE, whereas if you hate Microsoft's Windows GUI you're pretty much stuffed.

      I do agree that there's a good argument for providing some kind of common infrastructure between the two, but that should be a layer between X and the high level toolkit which provides common features to both, not forced on anyone who wants to write applications which display on an X terminal.

      Comment


      • #43
        The solution is probably: If a developer or more are willing to step up and they can work around the layers, a step at a time, then great. But let's not try to get a whole community to waste their already spare manpower.

        Very few applications target X11 directly anymore. They all use toolkits.

        Port the toolkit and you port the application.

        The only applications I can think of off the top of my head that uses X11 directly would be 'Conky' or 'Xterm'. I like Conky a lot, but with Xterm: Gnome-terminal's network performance is massively better then Xterm. (I've done benchmarks).

        And all toolkits worth giving a shit about are designed to be portable in the first place. GTK runs on Windows and OS X; natively. QT is even more portable then that.

        So the solution is not to rework the layers... it's to eliminate them.

        Just throw it all away. Get rid of everything lower then GTK/QT/etc and then have the toolkits work directly on Wayland.

        -------------------


        As far as remote desktop stuff goes... Redhat's SPICE protocol blows everything else out of the water. It lays low MS Remote desktop, destroys Citrix, and utterly annilates X11 in terms of usability and performance.

        One of the ways it does this is by compressing the desktop down to a video stream using MJPEG.

        If something similar could be done with Linux desktops using WebM or what then that would give us fantastic performance. Then you just need to establish a protocol for the client systems to send keyboard/pointer input back to the server and that's it. You could implement Wayland clients in a browser using HTML5 and Javascript and performance would decimate what we have now for any WAN link.

        Comment


        • #44
          There is no reason to not give the toolkits a common ground. You said it yourself, you can use Gtk and Qt on Windows. Guess what? They both look the same there. Consistency.

          There is no common ground in X. They both circumvent X and do a lot of crap, just like the blog post mentioned in the article says.

          If there are hints for Window Managers, there should also be hints for UI controls. With the current approach, you encourage vendor lock-in. It's either Gtk or Qt. What about new toolkits? Why limit yourself to Gtk/Qt? First, you mention that Windows is bad at this because you have no choice. But at the same time you think if X does that too then it's fine? I fail to see the logic.

          Comment


          • #45
            Originally posted by nanonyme View Post
            Meh, everyone needing encryption for remote X is tunneling X over SSH anyway. And indirect rendering with OpenGL should work remotely over X protocol as far as I've been told. Dunno of AIGLX.
            Alas, it won't work with OpenGL 2/3/4 - there's no support for shaders in the network protocol.

            Comment


            • #46
              Originally posted by Chewi View Post
              Is Zaphod mode really gone? Maybe there used to be more to it but I still use a setup where I have DISPLAY :0.0 and :0.1.
              Likewise - one runs my proper desktop, the other (smaller) usually a full-screen Windows VM. Granted, this is an RHEL5 system running a relatively old X server (1.1, I think?), but I'd be bothered if that no longer worked on a newer system. I don't *want* my two screens to act as one big one.

              Comment


              • #47
                Originally posted by MisterIO View Post
                I can't really see how anyone can still talk about a possible success of wayland! It's dead! Its repository didn't see any change since march: http://cgit.freedesktop.org/~krh/wayland

                Don't misunderstand me, if the project comes back to life, I'll be very happy, but at the moment there's nothing that can suggest that's going to happen.
                Remember that Wayland is the personal project of *one* man, working on it in his spare time - not a large full-time team. If you don't see any activity for a few months, it doesn't mean it's dead - just that that single developer is too busy to work on his pet project...

                Comment


                • #48
                  The problem with KDE is that it wastes MASSIVE ammounts of screen real estate all over the place. Perhaps that can be improved though since QT is also used in embedded devices. GTK can be wasteful too...

                  Personally I think that having X as a layer is a huge advantage. The X protocol itself is and always will be theme agnostic however that does not prevent the development of a unified theme format. Its a problem for the gnome and KDE developers to resolve not Xorg. X isn't a toolkit per say it is more like a canvas on which you use your toolkit/brush to paint what you want. And it just so happens that by using X11 as your canvas you automatically get loads of features at little cost if you use them or not.

                  X11 was originally designed to be as flexible as possible of course we now see deficiencies since hardware that did not exist at that time now does... MPX for instance. As far as X over ssh goes ... why not depreciate non compressed X make all X11 connections in future X servers compressed the compression support should be loaded as an extension I suppose so that a wide range of compression methods can be supported. From different compression formats to modifying the protocol directly ala differential compression.

                  Also gesture support at the X11 level would be much appreciated... tablets don't have keyboards and having a universal gesture to pop up a keyboard would be amazing.

                  Comment


                  • #49
                    Originally posted by drag View Post
                    As far as remote desktop stuff goes... Redhat's SPICE protocol blows everything else out of the water. It lays low MS Remote desktop, destroys Citrix, and utterly annilates X11 in terms of usability and performance.

                    One of the ways it does this is by compressing the desktop down to a video stream using MJPEG.
                    Have you looked at Nomad?

                    Comment


                    • #50
                      Personally I think that having X as a layer is a huge advantage. The X protocol itself is and always will be theme agnostic however that does not prevent the development of a unified theme format.
                      Any sort of theme'ng will happen at the toolkit/application level. X does not really enter into it anywhere.


                      X11 was originally designed to be as flexible as possible of course we now see deficiencies since hardware that did not exist at that time now does... MPX for instance. As far as X over ssh goes ... why not depreciate non compressed X make all X11 connections in future X servers compressed the compression support should be loaded as an extension I suppose so that a wide range of compression methods can be supported. From different compression formats to modifying the protocol directly ala differential compression.
                      The issue with X being slow is usually not compression, it's latency.

                      That is you're better off with X using a low-bandwidth, low-latency link then a high-bandwidth, high-latency link.

                      Gnome/GTK developers (and probably QT) have largely worked around this.

                      If you were to test something like Xterm (XLib directly) vs Gnome-terminal (toolkit level) over a SSH X link you'll find that Gnome-terminal gives much better performance.


                      Also gesture support at the X11 level would be much appreciated... tablets don't have keyboards and having a universal gesture to pop up a keyboard would be amazing.
                      Gesture support is more of a application-level thing. Xorg now supports multipoint, but it's not really that useful for advanced iphone-like touch screen interfaces without the applications being aware of gestures. Some of it needs to be attacked in the WM level, other parts in the toolkit, and other parts are going to be application specific.

                      In other words.. unless the application developers are specifically targetting multi-touch interfaces it's not going to do you much good.

                      Comment

                      Working...
                      X