Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
X GUI Graphics Software

freedesktop.org xlibs 1.0 Released 243

Posted by timothy from the how-long-until-etc dept.
Daniel Stone writes "A short time ago, freedesktop.org xlibs 1.0 was released. Simply put, this is the collection of libX11, libXext, and other little-used libraries that kind of power your whole desktop. The xlibs team at fd.o are now maintaining all these libraries, and more, and we're going to be making releases as part of the fd.o platform, which is far more wide-ranging, but it still forms an important part of the platform. Share and enjoy!"
This discussion has been archived. No new comments can be posted.

freedesktop.org xlibs 1.0 Released More

freedesktop.org xlibs 1.0 Released

Comments Filter:

  • Little used ? (Score:3, Informative)

    by noselasd ( 594905 ) on Sunday January 25, 2004 @01:44PM (#8082194)
    Virtually every toolkit out there uses xlib. It really isn't
    "little used", but rather key part of the whole *nix desktop.

  • Not that X is slow ... (Score:3, Insightful)

    by Space cowboy ( 13680 ) on Sunday January 25, 2004 @01:45PM (#8082195) Journal
    ... but having one group looking after all these libs would seem to offer some scope for optimisation and consolidation. Sounds like a good thing...

    What's the DBUS ? (Desktop bus ?)

    Simon

    • DBUS is something the GNOME people thought up when they saw KDE's DCOP.

      Not to badmouth it (well, I am biased), but I've heard that the KDE people plan to integrate DBUS into KDE to make GNOME apps integrate better. I'm all for it.

      • Re:Not that X is slow ... (Score:4, Informative)

        by be-fan ( 61476 ) on Sunday January 25, 2004 @02:38PM (#8082461)
        D-BUS wasn't something the GNOME people thought up. The freedesktop.org people modeled it after DCOP, but made it independent of KDE's framework so the GNOME people could use it. The plans for D-BUS in KDE seem uncertain. Some developers want to just ditch D-COP entirely and use D-BUS, since D-BUS is similar. Others want to bridge D-COP and D-BUS, and retain D-COP for intra-KDE communication, and use D-BUS for inter-desktop communication.

    • Re:Not that X is slow ... (Score:4, Funny)

      by AllUsernamesAreGone ( 688381 ) on Sunday January 25, 2004 @01:48PM (#8082214)
      What's the DBUS ?

      It's dthing you get on to go to work in when you don't want to get dcar out of dgarage mon.

      Or, put another way, I don't have a fscking clue so, in the greatest tradition of /., I said something silly instead.

    • Re:Not that X is slow ... (Score:5, Informative)

      by Carewolf ( 581105 ) * on Sunday January 25, 2004 @01:55PM (#8082248) Homepage
      D-BUS is the replacement for DCOP. "Agnostically" written in C this time to help GNOME developers swallow (not so agnostically though since Glib kept sneaking in, but fortunately got replaced in the end).

      It does have a few neat features that DCOP doesnt. Like being system-wide, and thus support signals from the kernel (implemented by HAL) and signals from other non-desktop application like Apache.

      • ...so you could say that, um, DBUS ran over DCOP? Tragic.

      • Re:Not that X is slow ... (Score:4, Interesting)

        by ajs ( 35943 ) <ajs@ajs . c om> on Sunday January 25, 2004 @02:33PM (#8082437) Homepage Journal
        IMHO, every major C project should use glib. It is fairly lightweight and provides a lot of the features that C programmers end up carrying around anyway. It's certainly not a Gnome thing in the strictest sense. You could ship glib with KDE and have no dependence on Gnome, GTK+ or anything else like that.

        Glib 2.0 also includes GObject, the core object system on which Gtk+ and Gnome are based, though again, you could write grep using these objects, they're not graphics-specific.

        • Re:Not that X is slow ... (Score:5, Insightful)

          by caseih ( 160668 ) on Sunday January 25, 2004 @02:40PM (#8082476)
          I can't agree more. I recently wrote a fairly complicated proxy server and using glib (combined with the gnet libraries) has completely saved me. The glib routines for building quick hashtables, lists, and dynamic strings (all in C) make so many aspects of my life easier. By using a glib dynamic string as my input buffer, I can easily grow it to accomodate the incoming data rather than having to do all the realloc stuff myself.

          I think glib (at least the routines for data types -- lists, hash tables, strings, etc) should be in the C standard library. The gobject stuff, while useful, should always be in a separate library.
        • KDE already ships with a glib dependency. aRts used it...

        • Re:Not that X is slow ... (Score:2, Insightful)

          by Anonymous Coward
          > IMHO, every major C project should use glib

          glib is incredibly convenient to program in because it has no error handling. Your app just goes boom if something unexpected happens, like a memory allocation failing. You can kind of prevent your program for totally blowing up, but you don't have the ability to correctly handle errors (at least in glib 1.2, don't know if 2.0 fixed this - we're talking about a nontrivial change here).

          Great for building toy programs, but absolutely terrible for building a pr

          • glib is incredibly convenient to program in because it has no error handling. Your app just goes boom if something unexpected happens, like a memory allocation failing.

            Yeah. Of course that's what most versions of the Linux kernel do as well: when they run out of memory, they just start killing processes, rather than returning NULL (with the wonderful rationale that this would break programs that don't check for malloc errors). You can change that behavior by disabling overcommit, sort of, but it's still
        • I've been really impressed with Glibmm (the c++ glib bindings) too. Glib::Module makes dlopen() et. al. a little less ugly to use (although you still have to do a little mucking with void pointers). libsigc++ also rocks. And I plan on probably using Gdkmm for something or another. It all looks so tasty!

        • IMHO, every major C project should use glib

          ..which is why DBUS should *certainly* not depend on it, if they want the C++ projects like KDE to use it. Using Glib in KDE is pointless, since you have Qt which can do everything GLib can do already, arguably better.

          • In C++, the standard library does almost everything that GLib does, and arguably better.

            While there are a few things which are not so platform-agnostic which GLib does that the C++ standard library doesn't (like handling dynamic libraries), there are a lot more things that the C++ standard library does that GLib doesn't. Just typing "sort" and letting the library optimise it depending on whether it's called on a dynamically-sized array, doubly- or singly-linked list or a funky container which you just wro

          • Re:That's the point (Score:4, Insightful)

            by ajs ( 35943 ) <ajs@ajs . c om> on Monday January 26, 2004 @12:47AM (#8085809) Homepage Journal
            A C++ program can rely on a glib-based C library just as easily (perhaps somewhat easier, due to the consistent object model) as on any other C library. There is no problem here at all.

            "Using Glib in KDE is pointless"

            Using glib in DBUS is not however, and using DBUS in KDE is not... moot point. Also keep in mind that KDE's reliance on C++ and C++'s platform difficulties (SOME of which went away with the finalization of the ANSI standard a few years back) was exactly the reason that Sun had to choose Gnome as their desktop, even though they prefered KDE at the time. They had to support two compilers though, and if you can't lock customers into a compiler, C is the only way to fly (Java is as close as it gets otherwise, and it might be ok after another decade or two to mature).

            I'm not language zeloting here... I see the value of C++ accedemically, but building software in it DOES cut you off from the rest of the world in the sense that the many, many thousands of C-based software projects and products in the world then have a hard time making any use of you at all.
      • I Can't see a problem using for C. You just end up coding similar stuff with another name in C projects. Thus creating your own bugs.
    • ... but this page [debian.org] was the third result in a search [google.com] for "D-BUS Linux."
    • Don't you think that after 15 years somebody would have gotten around to doing some "optimisation and consolidation", if there was any possible way to fix how broken X-Windows is without also breaking all the horrible client programs that use it?

      -Don

      • But its not. X is very fast. You can run benchmarks yourself. For stuff like bitblits, X is as fast as DirectDraw (quite an accomplishment for a generalized graphics system!) On my machine, X can copy around ~2GB of 100x100 pixmaps per second, which makes for a bandwidth utilization of about ~4GB/sec. That's pretty close to the maximum memory bandwidth of my graphics card, which is 6.4GB/sec.

        X has been quite fast in practice too. SGI shipped a very high-performance X implementation. The main issue is that
        • You completely miss the point by bringing up the red herring of your graphics card performance, and ignoring the distributed architecture of X-Windows, and how it was designed to be used.

          X-Windows was designed to be a distributed window system, to operate over the network.

          Yet it was foolishly not designed to support extensibility: dynamically downloading code to the server to perform local input processing, feedback and graphics, and to vastly reduce the amount of network traffic.

          If your web browser h

          • X-Windows was designed to be a distributed window system, to operate over the network.
            ---
            Yep.

            Yet it was foolishly not designed to support extensibility:
            ---
            Yes it was. Might want to clarify your definition of "extensibility."

            dynamically downloading code to the server to perform local input processing
            ---
            Input processing is handled by the application. There is no need to download code into the server to do this. You need a safe language to do this (to avoid crashing the server with bad downloaded code), and

            • Input processing is handled by the application.

              What do you mean by "is"? "Should always be in every case"? Or "X-Windows has always forced us to do it this way"?

              There is no need to download code into the server to do this.

              Says who? I certainly see a need. Would you want to run an X-Windows server on a cell phone, where you have to pay for bandwidth and wait for round trips? Nope.

              A NeWS-like architecture is much more efficient for implementing distributed applications on cell phones, because it perm

              • What do you mean by "is"? "Should always be in every case"? Or "X-Windows has always forced us to do it this way"?
                ---
                X makes you do input-processing application-side, but that doesn't really introduce an inefficiency. The data rate of a mouse/keyboard even uncompressed never approaches more than 100 bytes/second. That's really not a bottleneck for the roles X is aimed at.

                Says who? I certainly see a need. Would you want to run an X-Windows server on a cell phone, where you have to pay for bandwidth and wait

        • 4Sight (Score:3, Interesting)

          by SimHacker ( 180785 )

          "SGI shipped a very high-performance X implementation."

          You must be talking about 4Sight, SGI's window server that integrated both X11 and NeWS 1.1 (Network extensible Window System). Thanks the NeWS, clients could make efficient use of the network bandwidth by downloading PostScript programs into the server, which executed locally and only sent responses over the network when absolutely necessary.

          In 1988, I helped develop the NeWS driver for UniPress Emacs. James Gosling wrote UniPress's version of Ema

          • How would you do that in X-Windows? Please explain your approach to extending the X-Windows server to support local text selection in emacs (and local pop-up menus while you're at it), without any unnecessary network traffic?
            ---
            You most likely cannot do it in X Windows. But the needs of applications have changed a great deal since then. Consider doing text and graphics highlighting on an HTML page. HTML layout is extremely complex, and the layout data can be very large. Instead of a simple array of integers

            • You most likely cannot do it in X Windows. But the needs of applications have changed a great deal since then. Consider doing text and graphics highlighting on an HTML page.

              Which brings us back to my point, that "doing it on a web page" is using a NeWS-like architecture.

              So what possible advantage is there to have the enormously complex layer of X-Windows in there, between the web browser and the operating system?

              X-Windows is not solving any problems, if it's just introducing another huge layer that g

              • Which brings us back to my point, that "doing it on a web page" is using a NeWS-like architecture.
                ---
                Huh? I'm talking about rendering the web-page itself. Consider doing text-highlighting of an HTML page server-side. Its doable if you build-in all the logic of displaying a web-page into the server. For every application that has different display logic (word processor, spreadsheet, etc), you have to download all that display logic into the server. And you have to send large amounts of data over the wire to

              • Re:4Sight (Score:3, Insightful)

                by Daengbo ( 523424 )
                I think, right now, you're looking more like the fanatic.

  • XFree86 Has Not Merged With X.Org ?? (Score:5, Informative)

    by cyber_rigger ( 527103 ) on Sunday January 25, 2004 @01:46PM (#8082201) Homepage Journal

    XFree86 Has Not Merged With X.Org (see News)

    [23 January 2004] http://www.xfree86.org/ [xfree86.org]

    So have they merged or not merged?
    • The way I understand it, Havoc Pennington said that several X.org and XFree86 developers were working together. This was misinterpreted by journalists as the projects working together.

      Hmmm.
    • It sounds more like they forked to me.

      As in: "Somebody stuck a fork in XFree86, I think they're done." ;)

    • Re:XFree86 Has Not Merged With X.Org ?? (Score:4, Insightful)

      by haroldhunt ( 199966 ) on Sunday January 25, 2004 @04:40PM (#8083032) Homepage
      The headline that got put on the press release was misleading. The reality is that X.Org has been reformed to be more like the GNOME Foundation. There will be open elections to appoint a board. Votes will no longer be obtained through monetary contributions; in other words, any one can have a vote and be elected, no matter their affiliation. The actual information handed out by X.Org should be posted on their site in the next few days, which includes the mission statement and aims of the project.

      Some developers that have at one time or another been associated with XFree86 are participating in the reformation of X.org. How that translated into "XFree86 and X.org have mereged" in the headline is beyond me.

      Harold
  • Is there any chance of this desktop being used on a distribution small enough for a credit card sized CD? 50MB.

    From the site:

    This table represents the state of libs from XFree86 that should be brought into the Freedesktop cvs as autofooed projects. Please update these if you have any further information.

    Library current status
    GL needs to be done
    GLU FreeGlu? may be better? (don't think so, and Mesa should have the same libGLU available --EricAnholt)
    GLw
    XThrStub? would be part of libX11, but

    • Re:Any idea on the total size of the libaries? (Score:5, Informative)

      by caseih ( 160668 ) on Sunday January 25, 2004 @02:51PM (#8082542)
      The fd.o xserver is about 1 mb, and the X11 libraries to drive your apps weigh in at around 1 mb or so stripped, I think. At least on my fd.o installation they do. Also kdrive + libs + gtk2 + apps runs comfortably on a device like the Zaurus. Of course that's with no openGL stuff, or xinerama or xprint. But it does include freetype, xft, xrender, xdamage, composite, etc. The basic libraries are quite compact. If you really look at it, 1mb for kdrive, 1mb for libraries, plus maybe 5 mb for gtk2, an X11-based enbedded environment (supporting just one kind of display hardware) is very light and competitive with the Qtopia framebuffer system. Given that, I can't see any reason do use qt-embedded or gtk-fb for most things.

      Some of those things in your list are not really libraries providing an api, but rather utilities, many of which on an embedded environment aren't needed.

  • vs XFree86 ? (Score:5, Interesting)

    by noselasd ( 594905 ) on Sunday January 25, 2004 @01:51PM (#8082227)
    One more question. Whats the diffrence between the freedesktop xlibs, and the xlibs in XFree86 ? I understand they forked from XFree at one point. What did they change/improve ?

    • Re:vs XFree86 ? (Score:3, Informative)

      by CoolVibe ( 11466 )
      They got rewritten from scratch. :)

    • Re:vs XFree86 ? (Score:3, Informative)

      by dossen ( 306388 )
      If I read it correctly, they are replacing the Imake buildsystem with GNU autoconf/automake - a good thing I think. Other than that I don't know what the differences are (going to be), but they will probably try to integrate some of the other parts of the freedesktop platform.

    • Re:vs XFree86 ? (Score:5, Informative)

      by Fnord ( 1756 ) <joe@sadusk.com> on Sunday January 25, 2004 @04:09PM (#8082887) Homepage
      Mostly they've just changed the build system. Someone mentioned that they're using automake/autoconf. But that's only a minor part of it. The big thing is that they're making it so that you can compile these libraries without having the entire X11 tree. X until now was this giant monolithic source tree with tons of interdependancies so you'd have to build it all at once. Their first goal is to modularize X and that means making the Xserver, Xlibs and the basic X programs all build separately.
    • Good question. Also, how does one go about installing it? A few weeks ago I noticed these extensions in ports (fbsd). For instance:

      libXext 6.4.2, and they say:

      New port: Prerelease version of libXcomposite from freedesktop.org: X Extension library. Testing is encouraged, but please do not use these ports as dependencies until they are updated to release tarballs and the XFree86 ports have been updated to depend on them.

      So do these extensions work with regular XFree86-Server or will they use their own i

      • Xlibs are the libraries that clients use to talk to an X server. A client compiled against any version of xlibs should run on basically any X server implementation. Clients compiled against xfree's xlibs will work on xfree, fd.o's xserver, xdirectfb, etc. Clients compiled against fd.o's new xlibs should be the same in that regard.

        As for what they have actually improved, as I understand it, they are making their Xlibs more modular, more efficient, more modern, etc. Probably not anything that a user wou

  • Too many damn x's! (Score:3, Interesting)

    by joelgrimes ( 130046 ) on Sunday January 25, 2004 @01:57PM (#8082265)
    I've used linux for years, but still get confused when people bring up this subject. I can't make heads or tails of all the different X's being bandied about. Half the time I can't tell if it's a group of people or a program.

    X11, x.org, xfree86, X Consortium, X Window(s?), not to mention freedesktop.org which is commonly mentioned in the same breath - i'm sure i'm missing some.

    I'm sure there's others that would appreciate an unscrambling of the relationships between the x's

    • Re:Too many damn x's! (Score:5, Informative)

      by Narchie Troll ( 581273 ) on Sunday January 25, 2004 @02:10PM (#8082330)
      x.org == X Consortium
      X11 == X Window System 11
      X Window System == A windowing system, consisting of a client and a server that communicate via an open protocol. Many different vendors distribute X clients and servers, commercial and free.

      The X Consortium manages the X protocol and distributes a reference implementation of clients and servers. XFree86 is a fork of the X Consortium implementation that was originally intended to run on x86-class machines -- thus the name. Freedesktop.org is a loose coalition attempting to corral all the competing *nix desktop software into a cohesive whole by setting up standards. They also provide support for a project that is working on an improved client and server for X11.
      • A summary of the parent post for those that don't understand:

        xxxxxfreedesktop.orgxxxxxx

    • Re:Too many damn x's! (Score:3, Informative)

      by allanc ( 25681 )
      X11 and The X Window System (not, they stress "X Windows" because that sounds too much like MS Windows) are the same thing. Just different names for it. It's the base window system.

      The group that releases the standard X code distribution, specifications for new versions of X, etc is the X Consortium, X11 is, more fully, X11R6--X Window System version 11 release 6. If X11R7 happens, it'll come from the X Consortium. Their web site is x.org.

      XFree86 is the group that does the free version of the X Window Sys

    • Re:Too many damn x's! (Score:5, Informative)

      by be-fan ( 61476 ) on Sunday January 25, 2004 @03:04PM (#8082602)
      X11 - The protocol spoken by modern X servers.

      x.org - Formerly the X Consortium, an organization of X-using businesses, like the OpenGL ARB. They are responsible for changes to the spec.

      X Windows - Shorthand for X Window System --- refers to the whole thing, servers, libs etc.

      freedesktop.org - A new organization dedicated to making standards for the *NIX desktop. For example, they have specified a common MIME framework, common menu format, common window manager specification, etc. Many of these, (ex. the window manager specification) have already been adopted. They are also an umbrella project for other projects for improving the X desktop. For example, D-BUS which is the new messaging system developed for KDE and GNOME, is a freedesktop.org project. Keith Packard and others are also developing a new X server under the freedesktop.org umbrella. This new X server already supports complete-back buffering of windows (each window gets its own buffer, like OS X, to make moving windows smooth and free of redraw) and window compositing (for transparency, shadows, other effects). They are also restructuring the driver API to support OpenGL independent of X, so the X server can sit on top of OpenGL and use it to accelerate drawing. At the same time, they are also introducing new extensions (Xfixes, XDamage, etc) to allow applications to access the extended features for the new server, as well as working on existing extensions (XRender) to improve their implementation (add acceleration via OpenGL, for example).
      • Actually, the line about X.Org was mostly true until a few days ago. X.Org has just been reformed as a group that individuals can join and contribute too without any sort of monetary contribution. The new X.Org is essentially like the GNOME Foundation. Open elections will be held within the next coming months and anyone is free to participate in the elections and/or run for a seat. freedesktop.org is actually involved in the reformation of X.Org; there is a lot of overlap between the two projects and wh

  • weird naming (Score:3, Funny)

    by abe ferlman ( 205607 ) <bgtrio&yahoo,com> on Sunday January 25, 2004 @02:57PM (#8082575) Homepage Journal
    Nothing happens when I issue the following command

    mount /dev/fd.o /mnt/floppy

    Am I using this wrong?

  • Share and enjoy!

    Are you Sirius?

  • How does this relate to XFree86 (Is it a fork?) (Score:3, Interesting)

    by rmsousa ( 614388 ) on Sunday January 25, 2004 @03:12PM (#8082637) Homepage
    Are the people at XFree86 maintaining xlibs also? Will this be imported back at XFree86? The release email says xlibs is actively maintained by fd.o (does this mean it is not actively maintained by xf86.org?), but does this mean fd.o will become the official version (i.e., the version bundled in the mainstream distros)? Or will they be two competing implementations?

    IIRC, Debian already uses libXft from fd.o (which is a bit obvious, as Keith Packard is in fd.o).

  • Things That Happen When You Say X-Windows (Score:3, Offtopic)

    by SimHacker ( 180785 ) on Sunday January 25, 2004 @04:59PM (#8083108) Homepage Journal
    I was digging through some old papers, and ran across a 15 year old "XNextEvent" newsletter, "The Official Newsletter of XUG, the X User's Group", Volume 1 Number 2, from June 1988. Here's an article that illustrates how far the usage of the term "X Windows" [slashdot.org] has evolved over the past 15 years. (Too bad The Window System Improperly Known as X Windows itself hasn't evolved [catalog.com].)

    Someone on slashdot asks, "
    Why is it still called X-Windows?".

    Predictably, the first reply says: "It isn't. It's called 'The X Window System.' Or simply 'X'. 'X Windows' is a misnomer."

    He didn't ask why it is "X-Windows". He asked why it's called "X-Windows". You're wrong that it isn't called "X-Windows". It is! It's just that it isn't "X-Windows". Being something is independent of being called something.

    The answer to the question 'Why is it still called X-Windows?' is: It's still called X-Windows in order to annoy the X-Windows Fanatics, who take it upon themselves to correct you every time you call it X-Windows. That's why it's called X-Windows.

    The following definitive guide to the consequences of saying "X Windows" is from the June 1988 "XNextEvent" newsletter, "The Official Newsletter of XUG, the X User's Group", Volume 1 Number 2:

    Things That Happen When You Say 'X Windows'

    THE OFFICAL NAMES

    The official names of the software described herein are:

    X
    X Window System
    X Version 11
    X Window System, Version 11
    X11

    Note that the phrases X.11, X-11, X Windows or any permutation thereof, are explicitly excluded from this list and should not be used to describe the X Window System (window system should be thought of as one word).

    The above should be enough to scare anyone into using the proper terminology, but sadly enough, it's not. Recently, certain people, lacking sufficient motivation to change their speech patterns, have fallen victim to various 'accidents', or 'misfortune'. I've compiled a short list of happenings, some of which I have witnessed, others which remain heresay. I'm not claiming any direct connection between their speech habits and the reported incidents, but you be the judge... And woe betide any who set the cursed phrase into print!

    You are forced to explain toolkit programming to X neophytes.

    Bob Schiefler says, "You should know better than that!"

    The Power Supply (and unknown boards) on your workstation mysteriously give up the ghost.

    Ditto for the controller board for the disk on your new Sun.

    Your hair falls out.

    xmh refuses to come up in a useful size, no matter what you fiddle.

    You inexplicitly lose both of your complete Ultrix Doc sets.

    R2 won't build.

    Bob Schiefler says "Type 'man X'".

    Your nifty [livejournal.com] new X screen saver [jwz.org] just won't go away [jwz.org].

    The window you're working in loses input focus. Permanently

    -Don [donhopkins.com]

Slashdot Top Deals

If mathematically you end up with the wrong answer, try multiplying by the page number.

Close