Slashdot Mirror

← Back to Stories (view on slashdot.org)

X.org and XFree86 Reform

Posted by michael on from the shifting-sands dept.

albepetr writes "NewsForge is reporting about a press conference held today at LinuxWorld 2004 in New York, where some members of the X Consortium, XFree86, and freedesktop.org announced that X.org and XFree86 have merged. They claim that the reformed group will be working together to bring "not just more eye candy but new functionality" to the X Window Manager for Linux and Unix." Newsforge and Slashdot are both part of OSDN. Update: 01/23 18:06 GMT by M : XFree86.org denies the story. I think a more accurate description of the event might be something like, "XFree86 core developers leave XFree86, join X.org, remaining people of XFree86 are peeved".

34 of 597 comments (clear)

  1. What does this mean for KDE/Gnome? by Anonymous Coward · · Score: 1, Interesting

    Will we see a unified Windows environment for Linux now?

  2. Good for everybody by Mork29 · · Score: 4, Interesting

    give credit to -- individual contributors rather than continue to view X development primarily as a corporate activity.

    I like this alot. Functionality to the desktop is something that Unix and Linux both need to see loads of improvement on to help spread it to a larger market. I also like to see the OpenSource community coming together and joining into larger projects that can do more, rather than see hundreds of smaller projects all going in the same direction seperately. Bringing lots of brain power together gets stuff done.

    1. Re:Good for everybody by DickBreath · · Score: 1, Interesting

      Functionality to the desktop is something that Unix and Linux both need to see loads of improvement on to help spread it to a larger market.

      Like the ability to reconfigure X on the fly. Right-click on desktop -> properties -> change desktop resolution. Why can't it be that simple? Well, a prerequisite to making it that simple is for X to be reconfigurable on the fly without having to quit out of X, run some "configurator" program, and then restart X and hope it works. If the hooks in X to dynamically reconfigure are there, it is likely that such hooks would be supported by at least KDE / GNOME and possibly others.

      --

      I'll see your senator, and I'll raise you two judges.
    2. Re:Good for everybody by Mikkeles · · Score: 2, Interesting

      "Functionality to the desktop is something that Unix and Linux both need to see loads of improvement on to help spread it to a larger market."

      I would like to have the ability to open different windows with differing resolutions. I could use this in scientific visualization and I think it could be handy in photographic work: ultra resolution for the image and ordinary for the control panel.

      (I believe the Amiga had this, but I never needed to use it back then, so I'm not sure. I also don't know how much of this ability was due to Agnes, Paula, and Denise (i.e.: the hardware) rather than the software.)

      --
      Great minds think alike; fools seldom differ.
  3. Hopefully... by rongage · · Score: 3, Interesting

    Hopefully, they will work out a SINGLE standard for getting copy/cut and paste working correctly.

    I can't tell you how infuriating it is when you go to copy a page of text from, say, openoffice.org, and paste it into a webform in Mozilla - only to find that perhaps the first half a paragraph out of 6 made it over.

    --
    Ron Gage - Westland, MI
    1. Re:Hopefully... by arvindn · · Score: 4, Interesting
      Yeah.

      There are lots of "X sucks" flamethrowing morons around who have been told a million times that (for example) network transparency doesn't have overhead when both client and server are on the local machine.

      But the parent's complaint, IMHO, shows one of the genuine weak points of the "mechanism, not policy" philosophy of X.

      The gist is this: the X designers were faced with the choice of whether selecting text would copy it to a buffer or would merely mark it as selected. All window systems which were designed with a human user in mind would have found it a no-brainer -- copy the text to an internal buffer, since that's what the user intuitively expects.

      Not X.

      X merely marks the text as selected. That's because it avoids unnecessary network transfer in case the application is running remotely. The second reason is that it enables "content-type negotiation", between the copying and pasting programs. One of the consequences is that if you select text and close that program then that data is gone! This is unexpected data loss, as bad (to Joe Enduser) as your os randomly deleting files on disk.

      Note: I'm not saying X made the wrong choice, just that the choices it made aren't very suitable for normal desktop use.

      The second consequence of this is that programs (in practice, widget toolkits) that implement copy-paste must all need to agree on a common protocol/format etc. to make things work. And of course, we all know how good open source developers are at doing that. (Its not their fault, just a consequence of the fact that its made of various indepedent projects and not one company).

      So that's why nothing can happen right in the desktop linux world without freedesktop.org. Its the standards effort that sits on top of all these disparate pieces and tries to bring some sanity to the whole situation. And I would say it has been going extremely well. Keep it up guys!

      Everyone say a little thanks to Keith Packard, please.

    2. Re:Hopefully... by twistedcubic · · Score: 2, Interesting

      One of the consequences is that if you select text and close that program then that data is gone!
      This is not true. Your assumptions are wrong, but I won't get into it. Nevertheless, you have fooled a lot of people here.
    3. Re:Hopefully... by ichimunki · · Score: 4, Interesting

      It's a hard problem to solve because it requires content negotation. If I select and copy a graphic in a web browser and try to paste it into a pure text editor, what should it do? Nothing? Should it paste the ALT text? How about the longer description text if there is any? Should it paste the URL of the image? Should it attempt to use OCR on the image to convert it to textual data?

      I can think of lots of content negotation problems with text, too, especially styled text. What if part of the style is unsupported? What if the style is the result of a named style using a name that both applications support but the visual rendering of that style is very different-- should it attempt to mimic the rendering or should it use the style as named? (Quick example would be copying some text from one HTML document to another where both used CSS for styling-- which style sheet's H1 definition would be used for headers?)

      And FWIW, while I like left-drag-select and middle-click-paste sometimes. I find it annoying too. Because it fails miserably at replacing on the fly. Once you drag to select text to paste over you have wiped the clipboard clean.

      For a fantastic demonstration of the real problem. Go into GNOME-terminal. Select some text. Press ctrl-c to copy (since that's the standard shortcut). Whoops. You just killed your running process if you had one. :)

      --
      I do not have a signature
    4. Re:Hopefully... by ratboy666 · · Score: 2, Interesting

      X is a graphics server. It is *not* a "desktop" in the sense of Microsoft Windows.

      To make X into a desktop, we have to add a window manager, an operating system (with all that entails), etc.

      An example -- I run X on a system. I use it as a terminal. The window manager runs on another computer, as do all of my applications. Indeed, they run on three computers (or more).

      Each of the "windows" is displayed on my terminal, and I have a single keyboard and mouse. Using X, it looks like I have a single big computer, and not three (or more) different ones.

      This IS a coherent environment. And, it has had time to be tested and proven.

      So -- we have "coherent". A broader definition than the one you probably meant...

      Performance. The X clients do not need the resources of a local X server. Thus, the boxes running in my "coherent" environment generally do NOT have monitors, keyboards, mice of their own. Indeed, the only box I have that HAS another monitor has a variety of TVs (I do set-top box work). Performance is higher because these boxes do NOT have to waste resources on a GUI. *That* task is moved to other machines.

      Given that the "remoteness" is important, the "lack of change" is also important. An X server is an X server.

      My X server is cygwin, running on Windows 2K (company mandated -- I must also run Outlook). Clients are on a custom processor (Xilleon), Linux (Intel), or SUN. I shouldn't care WHICH machine originates the X to the server -- I just want the graphics.

      Given that this works, and that X has proven itself, why throw it out? *YOU* may not need the support, but *I* do. If you don't want X, go with Microsoft or Apple. If you need to run X, you can always throw on an X server. Be happy that the X code is portable enough to allow this to work reliably (and its free/Free).

      Ratboy

      --
      Just another "Cubible(sic) Joe" 2 17 3061
    5. Re:Hopefully... by Kent+Recal · · Score: 2, Interesting

      Well, it seems to be hard to write such a daemon, or does anyone else know why nobody has come up with one, yet?

      I mean there is a demand. And if I could only find any usable documentation that gives me hints only on how to approach the problem (I'm not familar with X internals) I'd probably try to write one myself.

      The fact that there isn't already one out in the wild tells me it's either not possible or really hard to do?

      I imagine something simple like screwing the whole middle-click idea (its way too flaky for my taste and I don't like loosing my clipboard when I select something else) and just implementing CTRL-C/CTRL-V properly.

  4. Oh, no, not again by dabadab · · Score: 3, Interesting

    Please, let's get off this dead horse.
    Cut'n'paste works on X's level.
    The problem is (or probably: was) not with X, but with Gnome and/or KDE.

    --
    Real life is overrated.
  5. Re:X again by dabadab · · Score: 2, Interesting

    "It's just too big, slow, and full of features desktop users don't need. Directfb is more like what desktop users need, but not quite."

    If you really would have taken the time to read the previous X stories on /., you would have known by this time, that X is neither big or slow, and the framebuffer approach is not what users really want (and that Windows' model is slowly transforming from the framebuffer to a more X-like approach)

    --
    Real life is overrated.
  6. Cut-and-Paste in X beats the competition... by FreeUser · · Score: 4, Interesting

    ...hands down.

    The problem is (or probably: was) not with X, but with Gnome and/or KDE

    Indeed.

    X has the most elegant cut-and-paste scheme I've ever seen, certainly vastly superior to Mac OS X and Windows.

    Select with the left button pressed, and click with the middle button in the target window to paste. No Apple-C or control-V crap, no need to press any key of any kind. Click-select, click, and you're done.

    Once you get used to it, you won't be able to stand the way Mac OS X and Windows handle cut-and-paste.

    Gnome and KDE made the extremely boneheaded decision to mimic Windows even when it really doesn't make sense; when the X way of doing things is vastly better. Click to focus as a default? Ugh! Windows-style cut-and-paste? An affront to humankind.

    --
    The Future of Human Evolution: Autonomy
    1. Re:Cut-and-Paste in X beats the competition... by adrianbaugh · · Score: 2, Interesting

      It overwrites it as the active clipboard selection, sure. That doesn't mean it empties the entire clipboard, for example in KDE if you click on the klipper icon in your system panel you can choose from recent text selections.

      Where copy'n'paste really sucks is the almost total lack of support for handling anything beyond text selections. I can easily select an image in exactly the same way and X has no problem with shoving this selection into a copy buffer somewhere, but very few applications are capable of using this. In my view the single most useful step forward for X usability would be if the app designers went and implemented media copy'n'paste handling properly. If I select an image in firebird I ought to be able to drop it into konqueror, gimp, openoffice etc. X can cope but as of now the applications put their fingers in their ears and sing "la la la I can't hear you".

      --
      "'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
      - JRR Tolkien.
    2. Re:Cut-and-Paste in X beats the competition... by sloptaco · · Score: 2, Interesting

      Ummm... I don't think that was the argument. Nothing is inherently "wrong" with ctrl-C Ctrl-v. Think of the two processes and compare hand movements:

      X:

      1. [Mouse] Left-Click and select Text.
      2. [Mouse] Left-Click destination.
      3. [Mouse] Middle-Button paste.

      Doze:

      1. [Mouse] Left-click and select text.
      2. [Keyboard] CTRL-C
      3. [Mouse] Left-click destination.
      4. [Keyboard] CTRL-V

      Now, from an objective standpoint (or as ergonomist analyzing the 2 processes) - pretending you are not used to one method over the other - which is better?

      --sloppy
  7. Article about it on CNN! by Anonymous Coward · · Score: 3, Interesting

    Linux needs to fix cut and paste

  8. About time they do this!! by fizz · · Score: 2, Interesting

    Its been a while since xfree has done anything innovative at all, and with freedesktop making its rounds very quickly, this could lead to really great things for the linux desktop.

  9. Okkkay... by starseeker · · Score: 4, Interesting

    So, how do the new developments at freedesktop.org like XCB/XCL fit into this new picture? I'm hoping the exciting new code can be eventually rolled in more easily now?

    --
    "I object to doing things that computers can do." -- Olin Shivers, lispers.org
  10. Thank god by base_chakra · · Score: 2, Interesting

    Because lord knows XFree86 has one of the dookiest logos ever!

    Yes, there are many more important reasons why the merge is a positive thing, but when I first started using Linux as a teenager in 1994, I loved the X11 logo, and it definitely contributed to my perception of Linux and UNIX. Let's face it: the X Consortium's logo feels clean and elegant, but it looks hard and deadly.

  11. windows desktop killer by pleasetryanotherchoi · · Score: 3, Interesting

    CNN has a story today in which various people purport that Linux isn't ready for desktop prime time but has a window (rimshot) of opportunity to establish itself therein before the release of Longhorn in 2006.

    Might this be a step in the right direction? Your fabled bluehaired grandmother doesn't want to choose between different window managers, etc. Hell, she doesn't know what a window manager is and doesn't want to know. Try to explain various incarnations of X to her and watch granny sizzle.

    1. Re:windows desktop killer by fuzzybunny · · Score: 2, Interesting

      Yes, true. However, take a walk around your average company sometime, and try to peek at peoples' desktops.

      Notice background images, scrollbar positions, whatever. They like to change things around.

      Now, if you're smart, you'll use window managers as nothing more than a logical extension of this--any good display manager lets you choose which window manager (assuming you configured it) to start with. Bundle several decent WMs with, say, kdm, present it as "desktop environment style" or something silly PEBKAC-friendly, and you have a winner.

      And the beauty of it is, those of us who want to can still customize shit to our heart's content.

      --
      Cole's Law: Thinly sliced cabbage
  12. Unix Philosophy by RAMMS+EIN · · Score: 3, Interesting

    "If you want copy and paste, write a deamon to manage it"

    I agree with that stance, though. The problem is not that there is no support, it's that there is too much support. KDE and GNOME do it differently. Some applications do it differently yet. If I select text in Mozilla and press Ctl+C, it goes to a different buffer than just selecting it. Etc...

    My solution would be a module (lkm, library, daemon, I don't care) that handles it for all apps (be they console, GTK, ...), preferably doing it the select and paste way as well as the keyboard way (which could add support for named buffers). U am not writing this, though, because it would merely add yet another standard, and besides, I don't care enough. It works for me as it is now.

    --
    Please correct me if I got my facts wrong.
    1. Re:Unix Philosophy by somethinghollow · · Score: 2, Interesting

      A daemon would only be better than having X or some other program if I could switch over to TTY* and paste. And if we are going that far, maybe copy from the TTY and paste to the TTY or X.

  13. Garbage Collection by RAMMS+EIN · · Score: 2, Interesting

    ``One of the consequences is that if you select text and close that program then that data is gone!''
    Sometimes I think the proponents of LISP-OS are right. Everything in one address space, no unnecessary copying of data or checking permissions.

    If you select data, the clipboard obtains a reference to it. Close your app, the reference is still there and you can still paste the data. Replace the reference in the clipboard and your data gets garbage collected.

    --
    Please correct me if I got my facts wrong.
  14. Clippy the deamon by StrawberryFrog · · Score: 4, Interesting

    "If you want copy and paste, write a deamon to manage it"

    I've been wondering for a long time why this hasn't happened already. How on earth can it be hard to come up with a daemon that can recieve, store and reguritate small blobs of text or binary data?!?

    Best of all, it wouldn't depend on which gui you were using. It could work with all of them. It wouldn't depend on any gui being present all.

    With a standard clipboard service/daemon, you could do stuff like cut in mozilla or a KDE app, and paste in commandline vi/emacs or reboot and paste into a gnome app.

    --

    My Karma: ran over your Dogma
    StrawberryFrog

  15. Re:UnitedX by RAMMS+EIN · · Score: 2, Interesting

    I was hoping somebody would come up with a thoughtful post rather than just slamming me (like the other poster did). I know that X is considered efficient, the point is that it doesn't show.

    If I drag a window across the screen, my CPU load goes up to 100%. Resizing a window takes ages. uncovering prviously covered portions of a window on XFree86 sends expose events, causing redraws, which is somehow slow. Playing a movie (or any other pixel-based thing) doesn't give me a decent framerate. All this is better under other systems (BeOS, Windows) on the same hardware, using unaccelerated VESA drivers.

    Thus, X is not efficient for local display. I am not saying that it is because it can display remotely. I don't know why, it's just slow.

    As for remote display...it strikes me that I get a more responsive UI when using VNC than when using X. That doesn't speak in favor of X, either. I count myself lucky that there are so many good command-line apps and tools.

    --
    Please correct me if I got my facts wrong.
  16. Re:You are factually wrong by Luyseyal · · Score: 4, Interesting

    Cut-n-paste works under X, but I hate that Move-n-replace is ugly.

    Windows:
    1) Highlight new text
    2) Ctl-x
    3) Highlight text-to-be-replaced
    4) Ctl-v

    X:
    1) Highlight text-to-be-replaced
    2) Delete text-to-be-replaced
    3) Highlight new text
    4) Delete new text
    5) Paste new text

    I'd like to see X do something like this:
    1) Highlight new text with left button
    2) Keep holding left button and press right button to cut to clipboard
    3) Highlight text-to-be-replaced with left button
    4) Keep holding left button and press middle button to copy from clipboard

    This wouldn't work for Left+Right=Middle, but Ctl-x|c|v would work for those people.

    What do you think? I find move-n-replace to be very handy for text editing.

    -l

    --
    Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
  17. Great name changes, please... by WWWWolf · · Score: 2, Interesting

    This is good news, I hope things will change to better over time.

    I hope this will also be the end of the "XFree86" name/brand. Let's face it, it's not really that great name - Not couting "GNU Anything", I've always disliked names that push the "free software" or "openness" aspect, so names with "Free" in them always sound silly. The ideology should be in the heart, not the name.

    Also, the whole name is a joke on something that hasn't been around for a while. I hear it's supposed to be a pun on "x-three-eight-six" - X386, which was what the project was called until 1992. I'm sure whoever came up with "XFree86" name had a good laugh with fellow developers, but now, over a decade later, this obscure fact has been completely buried in sands of time. No new users find it funny because they have no idea where it comes from - it has turned from silly and odd-looking to just plain odd-looking. Kind of like "DivX ;-)". Yawn.

    "X11 Public Implementation" sounds nice and technical, however =)

  18. Forking / Merging by sirReal.83. · · Score: 2, Interesting

    If forking is one of the "bad things" that can happen to OSS, merging is one of the "good things." Multiple similar projects, each with their own advantages, merge together to make... damnit, what was that huge robot in the Power Rangers called...

  19. I like it by FreeUser · · Score: 2, Interesting

    I'd like to see X do something like this:
    1) Highlight new text with left button
    2) Keep holding left button and press right button to cut to clipboard
    3) Highlight text-to-be-replaced with left button
    4) Keep holding left button and press middle button to copy from clipboard

    What do you think? I find move-n-replace to be very handy for text editing.

    That would be a handy enhancement.

    I'd actually like to see something a little more general.

    Cut-and-paste works as it is now, but make the buffer a stack (a little app could even display the buffer stack graphically)

    Middle-click+number pulls that item from the stack.

    Middle click pastes stack[0]
    Your #4 (left and middle button) pastes stack[1] (your second cut has pushed it up and replaced stack[0]), as does middle-click+1.

    middle-click+11 pastes stack[11],
    middle-click+756 pastes stack[756] (if your stack is so large and you remember what you cut 756 steps ago ... but again, here a handy graphical app showing the stack could be handy for such ... expansive uses of the buffer).

    This returns keystrokes to more complex cut-and-paste operations, but 1) keeps basic cut-and-paste, copy-and-paste simple the way they are now, and allows for much more expandability in pasting older cuts and doing other complex c by only adding a couple of keystrokes.

    --
    The Future of Human Evolution: Autonomy
  20. Widget based ineffecient. by Inoshiro · · Score: 2, Interesting

    If we were stuck with a widget-based implementation, I'd have to upgrade my X server every time Xlib, GTK+, WxWindows, QT, Motif, Lesstif, etc, changed. That's stupid.

    What's not stupid is using the existing protocol, which is fast (it ran well on 10 mhz SPARC machines 15 years ago!), efficient, and easy to compress for slower links.

    --
    --
    Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
  21. I have a feeling... by bonch · · Score: 2, Interesting

    I have a feeling your post will be ignored, and the XFree86-heads will continue to call X's system of copy-paste "the most elegant they've ever seen," etc.

    Yours is the most level-headed, rational criticism of X's copy-paste system I've ever seen, but as I've said before, X users have this bizarre fear of change and want things to stay the same for another 20 years.

  22. From XFree86.org by Icy · · Score: 2, Interesting

    XFree86 has not Merged with X.Org
    [23 January 2004]
    There are several news items claiming that X.Org and The XFree86 Project have merged. This is a blatant lie. The XFree86 Project remains an independent organisation, and will continue as operate as an independent organisation according to its mission statement. There has been no discussion with X.Org about any such merge, let alone any agreement to a merge.

    X.Org is a vendor-sponsored organisation, formed by vendors to best suit the interests of those vendors; XFree86 is an independent volunteer organisation, with a focus on the individual. Therein lies the rub.

  23. Re:UnitedX by RAMMS+EIN · · Score: 2, Interesting

    ``No amount of speed is going to fix the resize problems. They are caused by two different processes drawing the window border and the window contents.''

    It doesn't have to be that way. If the server keeps a copy of the contents and either knows how to draw the decorations or keeps a copy of them too, then it would be one process that does the drawing.

    Also, I wonder if what you said relates to x86 in any way. I have heard someone say that context switches are comparitively slow on x86. Might the sluggishness come from that?

    ``And yes, I know this means the window borders can look different between programs, and that dreaded boogyman of "inconsistency" will be raised yet again.''

    Not even necessarily. If applications call some library function to draw the borders, the library could ensure consistency.

    ``IMHO "sending widgets" is a mistake and will cause more communication: check out how many methods you need to create and control a Qt widget, and compare that to how many graphics calls you have to do to draw it.''

    I can't imagine it costs more to send one message when a widget is created, one to attach a callback, and receive one message when the callback is triggered than it costs to send all the messages to draw the wizard, draw it differently when the mouse moves over it, yet different when it is clicked, etc. etc.

    What I have in mind is something like HTML: you send the user interface once, and you only hear back from the user when they take certain actions. Now, web interfaces are a bit limited, because the server can't send events to the user, but I guess you get the idea.

    --
    Please correct me if I got my facts wrong.