Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 46

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

  1. #21
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote 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

  2. #22
    Join Date
    Jan 2013
    Posts
    1,443

    Default

    Quote 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.

  3. #23
    Join Date
    Mar 2009
    Location
    in front of my box :p
    Posts
    768

    Default

    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.

  4. #24
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote 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).

  5. #25
    Join Date
    Apr 2010
    Posts
    702

    Default

    Quote 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.

  6. #26
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote 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.

  7. #27
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,582

    Default

    Quote 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........

  8. #28
    Join Date
    Jan 2013
    Posts
    1,443

    Default

    Quote 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.

  9. #29
    Join Date
    Jan 2013
    Posts
    1,443

    Default

    Quote 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.

  10. #30
    Join Date
    Sep 2008
    Posts
    263

    Default

    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)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •