Announcement

Collapse
No announcement yet.

If Or When Will X12 Actually Materialize?

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

  • #31
    What I see as the main complaint, is that there are many things in X that are duplicated elsewhere. Network support through plain X is not used anymore, xrender replaces other things in X11, randr replaces more, etc.

    Comment


    • #32
      From a programmer's point of view, X is not nice to work with. When I write something in the win32 API, or Cocoa, or the older Carbon, and then come to X it looks so alien. There are no widgets, to start with; one has to decide between Gtk and Qt. There's no "native X" look&feel.

      If I can write native GUIs for win32 and Cocoa/Carbon apps, why can't I write native GUIs for X apps? I can understand why 23 years back X might have not wanted to provide a theme-able look&feel and let Motif do the work. But now it's 2010 and look at what happened to Motif... And look at what happens to people who run Gtk apps on KDE, or run 32-bit apps in 64-bit Gtk. Or everything of that vice versa.

      IMO, toolkits should be there to make it easier to write GUIs and access the low level system widgets, not to implement that stuff from scratch. Because if they do (and they do) there's fragmentation which results in applications not following a common GUI.

      And I don't think Wayland addresses this either.

      Comment


      • #33
        Originally posted by jrch2k8 View Post
        well i agree in the part of keep the network transparent part, but no the actual code. maybe something between vnc and freenx ...
        Isn't NX just protocol-specific compression and security on the standard X protocol?

        Comment


        • #34
          Originally posted by KellyClowers View Post
          Isn't NX just protocol-specific compression and security on the standard X protocol?
          It is. People sometimes confuse it with VNC.

          Comment


          • #35
            There's a chicken-and-egg problem here - framework developers and specific user groups want the ability to implement competing desktop solutions, but end users and app developers want the kind of "clarity", maturity and polish that normally only comes with a dictatorial "this is the only way" approach to managing the "product".

            Today we have lots of competing solutions for everything, all surprisingly good but very few are sufficiently polished that users can even agree on which solution should be the standard. Depending on who you are and who you ask, this fragmentation is either the greatest strength of open source OSes or the greatest weakness.

            Once we see agreement on that last question (is fragmentation the solution or the problem ?), everything else will fall into place

            Comment


            • #36
              Originally posted by bridgman View Post
              Once we see agreement on that last question (is fragmentation the solution or the problem ?), everything else will fall into place
              if you have limited resources then its a problem if you ask me

              there are so much "antagonizing" "products" in oss that makes it painful

              how many web browsers or mail clients do we need

              but maybe it isn't as important in apps as it is in infrastructure (ie classic drivers vs gallium drivers this multimedia framework vs that multimedia framework etc etc)

              Comment


              • #37
                Originally posted by bridgman View Post
                There's a chicken-and-egg problem here - framework developers and specific user groups want the ability to implement competing desktop solutions, but end users and app developers want the kind of "clarity", maturity and polish that normally only comes with a dictatorial "this is the only way" approach to managing the "product".
                The problem I described is more basic though. Gnome for example would, if X would allow for that, implement its look by simply providing an X theme. All the Gnome apps (written with Gtk) would use X, and the X theme would provide the looks.

                Now, when you run KDE instead, and fire up a Gtk app, it would use KDE's X theme. There you go, Gtk apps using Oxygen, because Oxygen would be implemented as an X theme.

                All the other systems can do that. Why not X?

                Comment


                • #38
                  Originally posted by RealNC View Post
                  Now, when you run KDE instead, and fire up a Gtk app, it would use KDE's X theme. There you go, Gtk apps using Oxygen, because Oxygen would be implemented as an X theme.
                  Or any X app, for that matter, even X apps using the X API directly without any toolkit in between.

                  Comment


                  • #39
                    Originally posted by RealNC View Post
                    IMO, toolkits should be there to make it easier to write GUIs and access the low level system widgets, not to implement that stuff from scratch. Because if they do (and they do) there's fragmentation which results in applications not following a common GUI.
                    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.

                    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.

                    Comment


                    • #40
                      I think X is fine where it is right now, as a lower level than GUI toolkits. You don't need to shoehorn a(nother) widget engine into X to merge the widget engines of GTK+ and Qt. You need to actually merge the widget engines of GTK+ and Qt. And that won't happen for a long long time.

                      Comment


                      • #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

                                Working...
                                X