Announcement

Collapse
No announcement yet.

If Or When Will X12 Actually Materialize?

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

  • #91
    So Xlib is the only true, large and irreplavable legacy cruft? Good! E17 is maturing as a desktop shell and I recently found out that E17|EFL works on Xcb.

    So in order for me to respond I first need a deeper underatanding of the architecture. But are you saying that the complexity is something from the past and that the complaints from the critics are all at least largely adressed? Because I remember going through LFS and found that without the automated buildsystem it is quite hellish. So is the complexity adressed at the code level too?

    Comment


    • #92
      Originally posted by V!NCENT View Post
      So Xlib is the only true, large and irreplavable legacy cruft? Good! E17 is maturing as a desktop shell and I recently found out that E17|EFL works on Xcb.

      So in order for me to respond I first need a deeper underatanding of the architecture. But are you saying that the complexity is something from the past and that the complaints from the critics are all at least largely adressed? Because I remember going through LFS and found that without the automated buildsystem it is quite hellish. So is the complexity adressed at the code level too?
      Honestly, I'm not sure what you're talking about. And yes, without automation, complicated things are difficult. Film at 11.

      Comment


      • #93
        Originally posted by siride View Post
        Honestly, I'm not sure what you're talking about. And yes, without automation, complicated things are difficult. Film at 11.
        I am talking about the legacy cruft and everything that's asociated with that.

        And about the build process; it isn't about whether or not it's complex with or without it, but about the fact that the source code is spread among a gazillion files.

        Comment


        • #94
          Originally posted by V!NCENT View Post
          I am talking about the legacy cruft and everything that's asociated with that.
          These parts being? I have a sense that a lot of X and what it does is not legacy. There is definitely legacy cruft, but I don't think the X server is spending a huge amount of time dealing with it.

          And about the build process; it isn't about whether or not it's complex with or without it, but about the fact that the source code is spread among a gazillion files.
          There's nothing non-standard about the build process. It's a collection of auto-tooled packages. The only annoying thing is the dependencies between the packages. That has been solved by a plethora of build scripts (and may further be solved by merging all the proto packages into one and possibly also the drivers back into the X server). I myself have used jhbuild. Others use build.sh. If you are bothering to build X from source and aren't using Gentoo, you should be able to handle jhbuild or build.sh. In any case, considering the scope of X, it's not surprising that it is a bit complex in terms of dependencies among packages. A desktop environment is similarly, if not more, complex.

          Comment


          • #95
            Originally posted by siride View Post
            These parts being? I have a sense that a lot of X and what it does is not legacy. There is definitely legacy cruft, but I don't think the X server is spending a huge amount of time dealing with it.
            No... there's no use of Xlib at all for example >.<

            There's nothing non-standard about the build process. It's a collection of auto-tooled packages. The only annoying thing is the dependencies between the packages. That has been solved by a plethora of build scripts (and may further be solved by merging all the proto packages into one and possibly also the drivers back into the X server). I myself have used jhbuild. Others use build.sh. If you are bothering to build X from source and aren't using Gentoo, you should be able to handle jhbuild or build.sh. In any case, considering the scope of X, it's not surprising that it is a bit complex in terms of dependencies among packages. A desktop environment is similarly, if not more, complex.
            Braindead... THE FILES!!! TWO HUNDRED AND NINTY THREE >.<
            You know... sourcy cody... little bitty study... complexy taking lots of timey? Get it?

            Comment


            • #96
              PS: nevermind...

              Comment


              • #97
                The xorg xserver and it's related libraries makes up an entire graphics stack. As siride mentioned, it's not akin a single application, it's more on the scale of gnome or kde. So yes, it has a lot of files, it also supports a lot of functionality. So while there is some cruft there most of those files are needed.

                Comment


                • #98
                  @agd5f,
                  What are all these files, actually? Are there lots of extentions that each have their own file/header? Or is it just overly modular, or... ?

                  Comment


                  • #99
                    Originally posted by V!NCENT View Post
                    @agd5f,
                    What are all these files, actually? Are there lots of extentions that each have their own file/header? Or is it just overly modular, or... ?
                    Which files are you talking about, exactly? Do you mean the packages? Or do you mean files in the X server source code?

                    Comment


                    • Originally posted by siride View Post
                      Which files are you talking about, exactly? Do you mean the packages? Or do you mean files in the X server source code?
                      The music files on my MP3 player.

                      Comment


                      • Originally posted by siride View Post
                        People must have forgotten about X Toolkit Intrinsics. It's basically what everyone here is proposing (common toolkit with policy and themes implemented by GTK/Qt/etc). It was only used by Motif and maybe Athena widgets. Obviously, it failed.

                        People must remember that X is equivalent to GDI on Windows. The toolkits + the window manager is equivalent to USER on Windows (basic window management and input demultiplexing are done in USER on Windows, but X on Linux, so that is a key difference). Since Windows presents a little bit more of a unified API and only one toolkit that comes with the system, it appears as though it works differently from X. It doesn't really. And Linux could have chosen to have one toolkit and then this entire discussion would be moot.

                        I really think the one-piece-at-a-time folks have it right. The overall structure of X is fine. Cruft from the protocol should be removed. Newer, but standard, features should be moved into the core protocol. Xlib should go away. And so on. A total rewrite would be stupid. Even the Windows world has kept the same basic API around for longer than X has been around, despite changes in the rendering system. GDI and USER are still here, even though there is also DWM and WPF. The best path is to provide a way forward and push new software and toolkits to be based on the new features and deprecate the old.

                        The only thing X really needs right now is man-power. Unfortunately, it seems like it's not top priority. It'd be nice if Canonical, for example, hired a few devs to work just on X. But I doubt that's going to happen. They can barely contribute to the kernel as it is.
                        Thank you. I was just about to remind everyone about Xt. It was a failure and we should learn from them.

                        Comment


                        • There's the xserver itself, the protocol headers, the client libs, mesa, input and output drivers, fonts, apps, and utils needed for building (libpciaccess, libpixman, etc.). In addition certain parts have external dependencies as well. You only need certain parts depending on what you are building. So if you look at http://cgit.freedesktop.org/ you can see how the xorg related bits are organized. Repos prefixed with /xorg/app are demo X apps that provide various functionality. They are not required to build the xserver. In most cases, the versions installed on your system are fine. Repos prefixed /xorg/font are the old font packages. In general there's no need for these as well. /xorg/util are various utilities used for building and maintaining the code and making releases. The macros package is the most important as it includes the latest m4 macros needed to build the xserver and related things like the drivers. /xorg/driver are the input (mouse, keyboard, etc.) drivers and output (video; ati, intel, s3, etc.) drivers. The input driver provide special handling and options for input hardware. The output provide gpu specific acceleration and in some cases modesetting code. /xorg/lib are the client libraries. Applications that want to use X or a certain extension (Xv, XvMC, Xfixes, etc.) need to have the client libs available. Note that you don't really have to update the client libs to build a newer xserver. /xorg/proto are the protocol headers. These are needed by the xserver and the client libs as they define the protocol for X11 and extensions. /xorg/xserver is the xserver itself. And finally xcb is the new X C binding.

                          As to the xserver source itself (http://cgit.freedesktop.org/xorg/xserver/tree/), you have the server side implementations of various extensions (Xv, xrandr, render, glx, record, composite, damage, etc.), the rendering code, the input handling code, the acceleration infrastructures (XAA and EXA), common code for modesetting and display handling (edid parsing, i2c) and code for parsing config files and loading drivers.

                          Comment


                          • @agd5f,

                            Thanks!
                            *Edited and archived* (documenting various graphic related stuff for myself)

                            Comment


                            • Yeah, X11 has a lot of cruft for today's code, but that today's code *can* run on it's a nice thing and actually validates the original design.

                              Comment

                              Working...
                              X