X.org and XFree86 Reform

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

Comments

Good for everybody

[Mork29]

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.

Hopefully...

[rongage]

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.

Re:Hopefully...

[arvindn]

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.

Re:Hopefully...

[ichimunki]

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

Oh, no, not again

[dabadab]

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.

Cut-and-Paste in X beats the competition...

[FreeUser]

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

Article about it on CNN!

[Anonymous Coward]

Linux needs to fix cut and paste

Okkkay...

[starseeker]

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?

windows desktop killer

[pleasetryanotherchoi]

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.

Unix Philosophy

[RAMMS EIN]

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

Clippy the deamon

[StrawberryFrog]

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

Re:You are factually wrong

[Luyseyal]

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