Announcement

Collapse
No announcement yet.

X.Org Server: 1,047 Warnings Reduced To Zero

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

  • #21
    Originally posted by dee. View Post
    Where do you get that idea from?

    Wayland has been written from the ground up to be versatile and support many use cases. It's not limited to just desktop and phones. There's IVI systems, smart tv's, web kiosks, redridgerators and other such embedded use... Wayland will be advantageous in many cases, where there is limited hardware power or memory, because it's a much smaller and leaner codebase than X.
    True, but from what I've heard, some servers require network transparency, and Wayland does not aim to provide this (although AFAIK this could be provided by a toolkit using Wayland). I'm not a servers person, so I might be AWFULLY wrong.

    This is true though. X.org will live on as a compatibility layer. It's not going away in the near future anyway, and there's no point in stopping development just because it'll eventually be replaced - by that logic, we could just stop development of everything right now...
    At least we agree on something

    Comment


    • #22
      Originally posted by mrugiero View Post
      True, but from what I've heard, some servers require network transparency, and Wayland does not aim to provide this (although AFAIK this could be provided by a toolkit using Wayland). I'm not a servers person, so I might be AWFULLY wrong.
      That's wrong. Wayland is perfectly capable of network transparency, it's just not hardcoded in to the core protocol. And apart from that, X isn't really network transparent either, apart from core X, ie. if you're using motif-based software... any modern toolkit (gtk, qt) is not network transparent via X since they do direct rendering.

      At least we agree on something
      Yes, let's have a party.

      Comment


      • #23
        That's quite good news. Cleaning and checking code is always a good thing, even though it does consume time and might sound a bit exhausting. Kudos to Keith.

        I shall now start looking over dev's shoulders and start commenting on the many compiler warnings I see when I emerge stuff on Gentoo. Maybe that will help a lot of things.

        Comment


        • #24
          Originally posted by dee. View Post
          And apart from that, X isn't really network transparent either, apart from core X, ie. if you're using motif-based software... any modern toolkit (gtk, qt) is not network transparent via X since they do direct rendering.
          I was already aware of this part. I just kind of assume that if someone really needs network transparency, he will avoid this toolkits and use core X11 (or a specialized toolkit, if they exist).

          Comment


          • #25
            Originally posted by dee. View Post
            And apart from that, X isn't really network transparent either, apart from core X, ie. if you're using motif-based software... any modern toolkit (gtk, qt) is not network transparent via X since they do direct rendering.
            Not true... can't speak for Qt, but Gtk+ apps handle network transparency just fine... just ssh to another machine, and run them. Individual applications sometimes have issues (usually because they assume they can talk to other parts of the desktop via a local dbus instance), but the toolkit itself has no problems with transparency.

            Comment


            • #26
              Originally posted by Delgarde View Post
              Not true... can't speak for Qt, but Gtk+ apps handle network transparency just fine... just ssh to another machine, and run them. Individual applications sometimes have issues (usually because they assume they can talk to other parts of the desktop via a local dbus instance), but the toolkit itself has no problems with transparency.
              Are you sure you aren't just receiving rendered buffers? When we talk about network transparency, AFAIK, we talk about sending rendering commands over the network and rendering on the receiving end.

              Comment


              • #27
                Originally posted by CTown View Post
                It says a lot about Keith. A ninja must be swift and quiet, no one should see him coming. Just imagine a ninja who gets caught 1047 times and loudly told about it Therefore, I conclude that Keith must be an awesome ninja coder!
                I believe fixing warnings is the last step before we start seeing git commits from Keith starting with:

                # All work and no play makes Keith go........

                Comment


                • #28
                  Originally posted by Delgarde View Post
                  Not true... can't speak for Qt, but Gtk+ apps handle network transparency just fine... just ssh to another machine, and run them. Individual applications sometimes have issues (usually because they assume they can talk to other parts of the desktop via a local dbus instance), but the toolkit itself has no problems with transparency.
                  Only it's not real network transparency, it's just direct rendering sent on a wire, and there's no reason the same can't be done with Wayland.

                  Comment


                  • #29
                    Originally posted by mrugiero View Post
                    I was already aware of this part. I just kind of assume that if someone really needs network transparency, he will avoid this toolkits and use core X11 (or a specialized toolkit, if they exist).
                    But if someone really needs that network transparency, they can just use html5 interfaces in their apps in the first place. Why use core x11, when we already have browser engines that do the job much more efficiently.

                    Comment


                    • #30
                      as a high-level software developer, I'm not sure what warnings mean in low-level languages.

                      In high-level languages (C#/Java for example) those warnings usually mean that you named a variable wrong (for example instead of using camelCase you used UpperCase) or that a variable was declared but never used (which isn't that bad, aside from cluttering your code...but if you declare a typed array with a starting size of 9000 while the type is int64 or something similiar you will waste some RAM which, generally speaking, is bad.). Or that you used a deprecated method.

                      If it's the same for low-level languages, I've to say three things:

                      First: Respect to Keith for pulling through with fixing those warnings!
                      Second: That may reduce the memory footprint of the X server but aside from that, at least for the end user, it won't do much.
                      Third: May god (if there is one) have mercy on the poor soul that'll commit the first thing that introduces a warning into the new codebase...because Keith won't have any. (at least I wouldn't after fixing over 1000 warnings)

                      Comment

                      Working...
                      X