Slashdot Mirror

Why not consolidate quality standards between major open desktop before continue working separately on each of them?

Freedesktop.org does exactly that. More and more great desktop standards are coming out all the time -- thumbnailing, window manager hints, MIME types.... It's a great project. oGALAXYo is basically saying that freedesktop.org shouldn't exist, that user-level programs should not drive kernel enhancements, and that GNOME 1.4 was "right" while GNOME 2 is "wrong".

Can you say, "troll"? oGALAXYo: Just don't use GNOME 2 if you don't like it! If you're going to disagree with every decision every GNOME developer makes, maybe you're focusing on the wrong project....

The Xorg Release Plan has a good overview.

The first release of Xorg was indeed pretty much XFree86 4.4rc + some patches. But technical praise is still merited IMO, take a look at one of the Xorg mailing lists. They've managed to rally all the relevant X developers to their banner, and there's lots of neat stuff going on. Particularly check out the "Next X.Org Foundation release plan" thread. Probably in August we will see the first Xorg release with the much awaited desktop composition manager. In comparison, the XFree86 developer mailing list is an empty wasteland and the "forum" list is all spam these days.

Forking XFree86 was the best thing to happen to desktop Linux in a long time.

It's fairly hard for a "normal" User on the slim line between an fairly actual system and a productive system. Anyway, new stuff always attracts me a lot (another load of hours lost :-)...

But the problem on Linux and especially with distributions a la Fedora is interoperability. Every version demands it's own RPM archive, there isn't just this thing like "xine-0.99xx.rpm" and GO. It's just like DLL Hell on Windows with the difference that it's more complicated to have different versions coexisting (M$ did some tweaks in that area); i know, it's cleaner but under M$ "IT JUST WORKS".

What really needs to get done is a wider adoption of sort of freedesktop.org "standards" like DBUS and a defined versioning System for all those *.so libraries on the system. Apple does some fairly cool tricks in that area with so called "frameworks" which exist as isolated directories and can contain multiple versions of a framework. Combined with late binding, it's just possible to trust a certain frozen API version.

I know it was already a huge step forward that most libraries now feature those xxx-config scripts so that the "user" doesn't have to supply all those directories and stuff for easier building. But let's get serious on that: A "real" user doesn't compile his stuff. And without tackling that matter we won't get serious (and working) package dependencies. And till that doesn't work every distribution is in fact a big bloated testing team trying to figure out the dependencies and building propietary packages that only work with this specific version of the distrib...

BTW I think that's part of the reason why gentoo is so successful...

It's fairly hard for a "normal" User on the slim line between an fairly actual system and a productive system. Anyway, new stuff always attracts me a lot (another load of hours lost :-)...

But the problem on Linux and especially with distributions a la Fedora is interoperability. Every version demands it's own RPM archive, there isn't just this thing like "xine-0.99xx.rpm" and GO. It's just like DLL Hell on Windows with the difference that it's more complicated to have different versions coexisting (M$ did some tweaks in that area); i know, it's cleaner but under M$ "IT JUST WORKS".

What really needs to get done is a wider adoption of sort of freedesktop.org "standards" like DBUS and a defined versioning System for all those *.so libraries on the system. Apple does some fairly cool tricks in that area with so called "frameworks" which exist as isolated directories and can contain multiple versions of a framework. Combined with late binding, it's just possible to trust a certain frozen API version.

I know it was already a huge step forward that most libraries now feature those xxx-config scripts so that the "user" doesn't have to supply all those directories and stuff for easier building. But let's get serious on that: A "real" user doesn't compile his stuff. And without tackling that matter we won't get serious (and working) package dependencies. And till that doesn't work every distribution is in fact a big bloated testing team trying to figure out the dependencies and building propietary packages that only work with this specific version of the distrib...

BTW I think that's part of the reason why gentoo is so successful...

Things that interest me:

- I see the Freedesktop.org HAL code is being included in test1. That will be interesting to see if and how integrated it will be in the final release. We'll probably also see some sort of real udev support this time.

- The timetable for the next official X.org release is planned to sync with Fedora Core 3. I'm a bit skeptical they can make it in time, but it would be really cool if they did. This will be the first X.org to include the new desktop composition extension from Keith Packards kdrive test.

Well, GStreamer is steadily getting there (this project deserves more awareness also among end users, so that's why I keep posting about it).

The last thing we should want to see is an Install Wizard on Linux. The software should be smart enough to install itself, without any help on my part (unless I want something special, like a different install directory, or some such). We're almost there with apt-rpm-autopackage. Dependecy resolution is the tough nut to crack for all distros.

Why do people think that Install Wizards are so easy? For someone who has never installed software (or, used a computer beyond checking email, etc), they are not. To an experienced user, most of the questions are un-important (they just accept the defaults). But, to a true new user, all of the questions are important, because they don't know what's not important! All they see is this baradge of questions: Install path, menu location, modules, etc, etc, etc. Those kinds of questions could be overwhelming.

The install wizards where the product of lazy programers who wanted to off load the resposibility decision making during the installation process to the user. Simple as that.

Linux is on the right track with simple commands like urpmi gimp. No questions. Just install the damn thing.

People that want install wizards are probably more likley to throw the baby out with the bath-water, too. The pkg systems on Linux are close. We need dependcy resolution, and cross-platform menu entries (so users know where to look for the new software). Get those, and we've got software that is easy as pie to install.

But some people would prefer to take the easy way out, and require the user to make all the decisions.

The last thing we should want to see is an Install Wizard on Linux. The software should be smart enough to install itself, without any help on my part (unless I want something special, like a different install directory, or some such). We're almost there with apt-rpm-autopackage. Dependecy resolution is the tough nut to crack for all distros.

Why do people think that Install Wizards are so easy? For someone who has never installed software (or, used a computer beyond checking email, etc), they are not. To an experienced user, most of the questions are un-important (they just accept the defaults). But, to a true new user, all of the questions are important, because they don't know what's not important! All they see is this baradge of questions: Install path, menu location, modules, etc, etc, etc. Those kinds of questions could be overwhelming.

The install wizards where the product of lazy programers who wanted to off load the resposibility decision making during the installation process to the user. Simple as that.

Linux is on the right track with simple commands like urpmi gimp. No questions. Just install the damn thing.

People that want install wizards are probably more likley to throw the baby out with the bath-water, too. The pkg systems on Linux are close. We need dependcy resolution, and cross-platform menu entries (so users know where to look for the new software). Get those, and we've got software that is easy as pie to install.

But some people would prefer to take the easy way out, and require the user to make all the decisions.

Let's go back to Joe User Joe User isnt SSHing into his desktop Does it display my apps? Does it look nice?

That doesn't mean that there won't be a program developed, using the network tranperancy of X11, that allows joe user to easily and securely bring up his work desktop at home (ala GoToMyPC).

Right now, the open source X world is going through a Big flux. xorg has a developer base that is working on, and will feed back pretty little UI improvements as they become stable and mature (X Server). That will come. Several projects have tried to come up with an alternative for X, and very few have gained popularity for one reason or another. The activation energy required for a whole new UI system for *nix has shown to be a damn hard hill to climb.

Well, GStreamer is probably going to be it.

linux has usability standards? problem is there are probably 5 of them and 90% of linux apps don't follow any of them

Why don't you check out the GNOME Human Interface Guidelines. KDE has their own, but both share a common base-set of standards outlined here.

Stick to gnome applications under a gnome desktop, everything should be fine. The most disturbing thing for me is Balsa, written with GTK+ 2, has an address book manager written in GTK+ 1.2, which sticks out like a sore thumb.

Linux apps have some way to go, but the situation is a thousand times better than the mess we had a few years ago. It's getting there.

Well, some parts of this are nice. I have reservations about the actual 3D parts, but window scaling would come in handy.

Having another X server to mediate this stuff isn't very clean though; I understand that they went that way for early development, since there isn't really anything finished that would be better, and they apparently wanted to get to the effects stuff. On the long run, however, it seems that this stuff should be done by a Compositing Manager. Of course, this also requires that the X Composite Extension be implemented in mainstream X servers (read: X.org).

From what I've gathered, the looking glass project will probably be not able to function under the "normal" xserver which was until recently xfree86 and now is x.org. I think that the engineers at Sun are utilising the damage and the composite extensions which are available in the new xserver which by the way is based on kdrive which was primarily developed by Keith Packard. It is possible though that eventualy these extensions will be reimplemented for the x.org server.

From what I've gathered, the looking glass project will probably be not able to function under the "normal" xserver which was until recently xfree86 and now is x.org. I think that the engineers at Sun are utilising the damage and the composite extensions which are available in the new xserver which by the way is based on kdrive which was primarily developed by Keith Packard. It is possible though that eventualy these extensions will be reimplemented for the x.org server.

From what I've gathered, the looking glass project will probably be not able to function under the "normal" xserver which was until recently xfree86 and now is x.org. I think that the engineers at Sun are utilising the damage and the composite extensions which are available in the new xserver which by the way is based on kdrive which was primarily developed by Keith Packard. It is possible though that eventualy these extensions will be reimplemented for the x.org server.

Does this mean that the GStreamer media framework that Gnome has been adopting will now take the back seat in RedHat's Gnome distribution? Helix Player seems not to use the GStreamer infrastructure.

The tree has been kept in sync with XFree86, through the release of their version 4.4 with the exception of changes to their files that contain their new version 1.1 license.

Have you looked at waimea? I've not tried it yet, but it certainly looks cool. Perhaps a bit over the top for you though, but would do the "4 terminal windows" very nicely indeed :-)

That should have been xsettings manager. Forgot to set the post to HTML mode ;)

Xorg's release notes state that it will look for the old XF86Config if the new xorg.conf doesn't exist.

More info about the similarities/differences of X11R6.7 and XF86 4.4 at fdo.

As noted in another post, X.org and XFree86 are basically identical code-wise. The only difference is that X.org has a more palatable license, which is why all the major distros switched over so quickly.

The other reason requires looking into the mysterious future... basically, politics at XFree86 were getting in the way of development, which was part of the reason for the fork; in 1 year's time, you can expect X.org to have a vibrant community of developers, with all funky new features in the X server, while XFree86 just sits and stagnates.

Read up about the X.org server

Ew, that's bad.
echo "x11-base/xorg-x11" >>/etc/portage/package.keywords
(you'll have to do the same thing for things like utempter and xterm as well, since those are ~x86)
emerge -C xfree (xfree blocks xorg, so you have to uninstall first)
emerge xorg-x11

And as should be implied, if you already have an installation of xfree, the config file works with it out of the box. In fact, the config file generated from xorgconfig (which, incidentally, looks exactly like the XF86Config util) is pretty much the same as the one generated from the XF86Config util, save for a different header most likely ("This config file was generated" by blah).

But there's really no difference between the current X.org release and Xfree4.3.0 save for some patches that they have may have backported from 4.4. But I've been running X.org's implementation for quite a few months now and while I haven't noticed any significant difference between xfree and X.org at the moment.. that's not to say that will be the same as time goes on.

I think this "release" was mostly just to get the thing out of the door and get its name out there. The REAL cool stuff will be coming during the next releases. They're already trying to get the damage and composite extensions ported to the X.org tree. Those who've played around with KeithP's kdrive/Xserver have seen both of those extensions in action. Just imagining the composite extention in cooperation with something like cairo and glitz just makes me drool.

Ew, that's bad.
echo "x11-base/xorg-x11" >>/etc/portage/package.keywords
(you'll have to do the same thing for things like utempter and xterm as well, since those are ~x86)
emerge -C xfree (xfree blocks xorg, so you have to uninstall first)
emerge xorg-x11

And as should be implied, if you already have an installation of xfree, the config file works with it out of the box. In fact, the config file generated from xorgconfig (which, incidentally, looks exactly like the XF86Config util) is pretty much the same as the one generated from the XF86Config util, save for a different header most likely ("This config file was generated" by blah).

But there's really no difference between the current X.org release and Xfree4.3.0 save for some patches that they have may have backported from 4.4. But I've been running X.org's implementation for quite a few months now and while I haven't noticed any significant difference between xfree and X.org at the moment.. that's not to say that will be the same as time goes on.

I think this "release" was mostly just to get the thing out of the door and get its name out there. The REAL cool stuff will be coming during the next releases. They're already trying to get the damage and composite extensions ported to the X.org tree. Those who've played around with KeithP's kdrive/Xserver have seen both of those extensions in action. Just imagining the composite extention in cooperation with something like cairo and glitz just makes me drool.

Ew, that's bad.
echo "x11-base/xorg-x11" >>/etc/portage/package.keywords
(you'll have to do the same thing for things like utempter and xterm as well, since those are ~x86)
emerge -C xfree (xfree blocks xorg, so you have to uninstall first)
emerge xorg-x11

And as should be implied, if you already have an installation of xfree, the config file works with it out of the box. In fact, the config file generated from xorgconfig (which, incidentally, looks exactly like the XF86Config util) is pretty much the same as the one generated from the XF86Config util, save for a different header most likely ("This config file was generated" by blah).

But there's really no difference between the current X.org release and Xfree4.3.0 save for some patches that they have may have backported from 4.4. But I've been running X.org's implementation for quite a few months now and while I haven't noticed any significant difference between xfree and X.org at the moment.. that's not to say that will be the same as time goes on.

I think this "release" was mostly just to get the thing out of the door and get its name out there. The REAL cool stuff will be coming during the next releases. They're already trying to get the damage and composite extensions ported to the X.org tree. Those who've played around with KeithP's kdrive/Xserver have seen both of those extensions in action. Just imagining the composite extention in cooperation with something like cairo and glitz just makes me drool.

Ew, that's bad.
echo "x11-base/xorg-x11" >>/etc/portage/package.keywords
(you'll have to do the same thing for things like utempter and xterm as well, since those are ~x86)
emerge -C xfree (xfree blocks xorg, so you have to uninstall first)
emerge xorg-x11

And as should be implied, if you already have an installation of xfree, the config file works with it out of the box. In fact, the config file generated from xorgconfig (which, incidentally, looks exactly like the XF86Config util) is pretty much the same as the one generated from the XF86Config util, save for a different header most likely ("This config file was generated" by blah).

But there's really no difference between the current X.org release and Xfree4.3.0 save for some patches that they have may have backported from 4.4. But I've been running X.org's implementation for quite a few months now and while I haven't noticed any significant difference between xfree and X.org at the moment.. that's not to say that will be the same as time goes on.

I think this "release" was mostly just to get the thing out of the door and get its name out there. The REAL cool stuff will be coming during the next releases. They're already trying to get the damage and composite extensions ported to the X.org tree. Those who've played around with KeithP's kdrive/Xserver have seen both of those extensions in action. Just imagining the composite extention in cooperation with something like cairo and glitz just makes me drool.

Ew, that's bad.
echo "x11-base/xorg-x11" >>/etc/portage/package.keywords
(you'll have to do the same thing for things like utempter and xterm as well, since those are ~x86)
emerge -C xfree (xfree blocks xorg, so you have to uninstall first)
emerge xorg-x11

And as should be implied, if you already have an installation of xfree, the config file works with it out of the box. In fact, the config file generated from xorgconfig (which, incidentally, looks exactly like the XF86Config util) is pretty much the same as the one generated from the XF86Config util, save for a different header most likely ("This config file was generated" by blah).

But there's really no difference between the current X.org release and Xfree4.3.0 save for some patches that they have may have backported from 4.4. But I've been running X.org's implementation for quite a few months now and while I haven't noticed any significant difference between xfree and X.org at the moment.. that's not to say that will be the same as time goes on.

I think this "release" was mostly just to get the thing out of the door and get its name out there. The REAL cool stuff will be coming during the next releases. They're already trying to get the damage and composite extensions ported to the X.org tree. Those who've played around with KeithP's kdrive/Xserver have seen both of those extensions in action. Just imagining the composite extention in cooperation with something like cairo and glitz just makes me drool.

The X implementations in commercial Unix-like systems are almost all based on the X11R6.x code base that is the descendant of the MIT code. X.org is the maintainer of that code base, enhanced by a merge of code from XF86 4.4.0RC2, i.e. XF86 just before the license change. The initialization of the current X.org code repository is described here and the result of that merge was the release of X11R6.7 in April.

X.org did undergo a rather significant organizational revolution leading up to the import of the XFree86 code. They had seemed to be mostly dead for a couple of years, but in January the 'X.org foundation' was announced and they took off again. As with any corporate-born organization, they did up some slides and did a presentation.

In short: you had it a bit backwards. The 'official' X11 was a joint project (more or less...) that was pretty slow and closed for quite a while, slow and closed enough to make XF86 look dynamic and open. The various issues with XF86 (license, acceptance of patches, etc) triggered a rebirth of the X11R6 project, infused with XF86 code. Vendors of other non-Linux and non-x86 systems have nothing really to be concerned about, since they are effectively in control of X.org now as they were before.

Debian WAS the official maintainer of the non-x86 branches of the XF86 tree, however, I don't believe that will continue because Daniel Stone has stated for the record that they will NOT ship any version of XFree86 under the 1.1 license.

As I said, You don't know what you are talking about. the core stuff won't EVER change, all new stuff goes into these really practical things called "X extensions" which are some sort of plugins that can be used when available, or simulated if not present.
now, stop trolling and go do your homework before whining, you have a lot to read on xorg.freedesktop.org

This page probably can.

The X11 licence didn't change, xfree86's licence changed.

There are some applications which just don't use the protocol the same way; but this is becoming quite uncommon since emacs was fixed. There is also a content negotation system for negotiating what types of content can be pasted where, which KDE and Gnome both support.

One remaining difficulty, with Gnome at least, is that when an X client exits, its selections disappear (so you can't copy, close the app and then paste).

For more info see here.

Well, you asked for it.

1. The Menus should be much more customizable; treated like folders that you can click and drag into (I hate to say this, but "Like Windows").

2. Better Video control properties; take advantage of XFree's extended features and have options like TV switching and such.

3. Better preferences; the control panels are quite lacking.

4. Other aesthetic enhancements that will make gnome pretty enough to compete with other window environments (like win XP's or OSX's). Smooth scrolling, the zoom-on-hover icons in OSX are sweet, and _drop shadows on windows_ would be real nice.

5. Some kind of Linux-version-of-Active-Desktop would be real nice, so I could have an IRC session running as part of my wallpaper,anchor the weather channel radar map to the background, etcetera.

I don't really know what the issue is. There really are few programs out there that on Linux _don't_ use GTK or QT and use their cut/paste semantics, which I am quite familiar with. It works just like Windows...

I suspect the issue is, at least in part, one or more of

1. some people don't understand that selecting text doesn't automatically copy it to the clipboard, in most cases, and the middle mouse button doesn't paste the clipboard, in most cases, and therefore get confused by mixing the primary-selection-based select/middle-mouse-button mechanism and the clipboard-based ^C/^X/^V mechanism;
2. some people don't know that the clipboard-based ^C/^X/^V mechanism even exists in many X11 toolkits and applications (where "many" includes the toolkits for GNOME and KDE, so "many" here is a lot);
3. some applications/toolkits don't implement the behaviors described in the X clipboard explanation, leading people to believe the problem is "the clipboard is completely broken in X" because they generalize from problems with some applications and to then act as if ^C/^X/^V is completely unavailable.

Is there a way to get xterm to use the Clipboard selector, instead of the Primary selector?

Use it for what? If you want to have selections become the clipboard selection rather than the primary selection and have the middle mouse button paste the clipboard (and thus make xterm behave differently from most other applications on your desktop, and run the risk of confusion with applications that use PRIMARY and CLIPBOARD in the fashion recommended by the X clipboard explanation:

• selecting but with no explicit copy should only set PRIMARY, never CLIPBOARD
• middle mouse button should paste PRIMARY, never CLIPBOARD
• explicit cut/copy commands (i.e. menu items, toolbar buttons) should always set CLIPBOARD to the currently-selected data (i.e. conceptually copy PRIMARY to CLIPBOARD)
• explicit paste commands should paste CLIPBOARD, not PRIMARY)

you can probably set mouse bindings in your .Xdefaults file.

All I know for certain, is that I'm using Gnome 2.6, and I don't have any problems with any of my Gnome or GTK+ applications in regards to the clipboard buffers. Yet, when I used applications not based on a particular toolkit or set of libraries this wasn't the case.

Well, Konqueror is definitely based on a particular toolkit (Qt) and set of libraries (the KDE libraries), so it'd be in a different category from the applications you describe as having problems with GTK+ applications, and other KDE applications fall into the same category as Konqueror, so the next question is "did you see clipboard problems with KDE applications?" It might be that the "applications not based on a particular toolkit or set of libraries" are those based on lesser-known toolkits or those whose developers have written their own toolkits (or equivalents - if, for example, you have more than one scrollbar in your application, you might have routines to draw scrollbars and respond to input in scrollbars, even if you don't call them part of a toolkit), and those toolkits might not implement the X PRIMARY and CLIPBOARD selections the same way Qt 3.0 and later, for example, do.

However, I have noticed that some applications don't seem to use the 2 X clipboard buffers in the same way.

They might, as noted, be based on toolkits that don't (or don't yet) implement PRIMARY and CLIPBOARD as per the X clipboard explanation.

So it seems that using applications based on the same libraries and toolkit work better together.

Applications based on the same libraries and toolkit are more likely to implement PRIMARY and CLIPBOARD compatibly with each other than are applications based on arbitrary different libraries and toolkits; however, there may be specific pairs of toolkits that implement them in the same way, and a pair of applications, one using toolkit A from that pair and one using toolkit B from that pair, are probably nearly as likely, and perhaps as likely, to work together as well as applications using the same toolkit, so from "it seems that using applications based on the same libraries and toolkit work better together" one cannot necessarily conclude that applications not based on the same libraries and toolkits won't work well together - there might be cases where that's true, but it's probably unwise to generalize from those cases, especially if one of the toolkits isn't one of the major ones.

Repeat the following to yourself. "Xterm is broken." "Xterm is broken."

When you drag the mouse in xterm, it defines the PRIMARY selection. This has the same meaning as it does on the Mac and Windows, in GTK and in Mozilla: this text is significant for later. The text gets highlighted. Now what?

For everything else listed above, you run some sort of command and load that selection into the clipboard. As the ClipboardsWiki page mentioned above (http://freedesktop.org/Standards/ClipboardsWiki), PRIMARY is used as the argument to the "copy to clipboard" command.

Xterm doesn't provide any way of setting the clipboard. It doesn't provide any way of getting the clipboard contents. Instead the middle mouse button is a completely different command: "insert text at cursor". The argument to this command is, once again, PRIMARY. The clipboard is completely bypassed. No wonder it doesn't work correctly.

Various programs like rxvt and Emacs have inherited this broken behavior to be compatible with xterm. Luckily, modern terminal emulators like "gnome-terminal" have fixed it. You select the region with the mouse, then do an explicit copy to the clipboard. This can be with a right-click content menu, an entry on the menu-bar, or the chord "Ctrl-Shift-C". (Note that adding the "shift" modifier prevents it from conflicting with ordinary "Ctrl-C"). To paste at the cursor, there's an explicit command to read from the clipboard.

Gnome, KDE, and WindowMaker all have clipboard managers that integrate & abstract the various toolkit clipboards.

GTK+ and Qt all have clipboard managers that, at least in current versions, use the same clipboard - the X11 CLIPBOARD selection, as has been present in X11 for, I think, close to 20 years, dating back to reasonably early versions of the ICCCM - and that's why you can copy from Qt apps and paste into GTK+ apps. See the X clipboard explanation.

If you need some "clipboard manager" application to make that work, that's either a screwup in GTK+ or Qt or, more likely, a screwup in a GTK+-based or Qt-based application.

And any mention of a possible solution brings down the wrath of nerds who want to keep unix as unintuitive and awkward as possible.

Besides the nuisance of what mouse click or keystroke you use to move text, it's not a clipboard like Windows uses, merely a text buffer. Ie; it's only good for text. You cant copy/paste (and by extension drag and drop) files, bitmaps, etc uniformly between apps.

This is a common mistake. In reality:

Highlighting text puts it into the X selection buffer.
Middle clicking pastes the X selection buffer.
CTRL+C (or whatever copy is set to) puts text onto the X clipboard.
CTRL+V (or whatever) pastes the X clipboard.

Notice: THERE ARE TWO BUFFERS. The X selection buffer and the X clipboard buffer. If your app overwrites the clipboard on highlight then it s misbehaving (see fd.o for what is "right").

Adjust your thinking just a smidge: When you select, it does not copy. It acts just like in Windows... only you can also access the last selection on a way Windows prevents.

Repeat: If your apps do not behave this way, /they are broken/. Don't blame *nix, or X, blame the author of the app. Some apps are deliberately broken (because it makes More Sense[tm]) but not terribly many.

In a nutshell, there are TWO completely different clipboards implemented in X:

1. The "select->middle click" clipboard
2. And the "copy->paste" clipboard

These two clipboards do not affect or interact with each other.

Other OS's (like Windows) only have the second kind. Modern Unix applications (like anything based on GTK, QT, or Mozilla) support both clipboards simultaneously and independently.

Old X Windows applications like XTerm only support the first kind. This is why you can't copy from or paste into an XTerm using C-c and C-v.

So if you are using modern applications, you should always be able to use C-c and C-v. If you have to copy or paste something into an XTerm, you will have to select it and middle-click. The solution is to use a moderm terminal, like gnome-terminal, instead of XTerm.

If you read the article, you'll learn that there are actually three different clipboards in X (one of which is never used), and that Emacs and XEmacs then implement yet another fourth clipboard!

Also see the freedesktop.org reference.

Use applications that support copy/paste correctly, and file wishlist bugs against applications that don't.

X (or actually: the standards lying on top of it, such as the ICCCM and Freedesktop.org's specs), supports two concurrent copy/paste clipboards; One for select-middle-click-paste, and one for classical copy/paste using explicit actions.

This way, you can select text A, ctrl-C it, select text B, and ctrl-V-paste text A over text B, just like you're used to. Additionally, you can do a quick copy/paste by just selecting text and middle-click-pasting it (this is more of a shortcut, and can for example be ignored by non-computer-literate users).

Unfortunately, although X supports this fine, the UI widgetsets, as usual, have been lacking proper support for this. Recently, this has much improved, and at least GTK 2 and QT 3 support this correctly. What we need to do now is fixing all widgetsets and/or applications that don't do this properly.

See this paper from Freedesktop.org for a more detailed explanation.

1. The primary selection is to be used for middle-click pasting.
   
2. The secondary selection is unused now
   
3. the clipboard selection is to be used for Windows-style copy/paste.
   

There is a de-facto standard for this - basically, Ctrl-X/C/V should use one selection "CLIPBOARD" and the highlight selection should be a completely independent "bonus", "PRIMARY". Then, if anything cut/copy/paste works _better_ than windows - the "normal" clipboard behaviour that windows/mac/amiga/everyone-else is used to, _plus_ the "bonus" of fast middle-button-paste for the simple stuff.

Problem solved - except for applications that wilfully break the conventions or were written before the conventions were established and not updated. Oh well. APPLICATION AUTHORS - PLEASE READ AND UNDERSTAND THE CLIPBOARD SPEC ON FREEDESKTOP.ORG.

A helpful discussion of the X clipboard behavior on freedesktop:

Clipboard Standards.

Read this and see why.

The only times you will encounter problems is when you are running legacy (pre gtk2/qt3 applications), which in modern distrutions are going quite quickly.

Copying and pasting text just works for me in Linux for years now, I am bewildered why this subject actually came up again!

Why would divergence be a problem if the majority of distroes/flavours* (*the proper term for BSD variants as I learned on osnews) standardizes on one? Now almost the complete X.org implementation is in ports, and I think x.org will be the default (or 4.3 at worst) in 5.3 release. Also, note that one of the freedesktop.org developers (DRI work) is Eric Anholt. So don't worry, only good can come out of this fork :)

See also what KeithP & Co. does in -CURRENT. This is their to do list. Release notes.