[Annoyances] X-Windows Copy & Paste

George jirka at 5z.com
Wed Aug 20 00:57:57 EEST 2003


On Tue, Aug 19, 2003 at 01:24:36PM -0700, John Meacham wrote:
> standard keybindings would be a perfectly acceptable solution. better in
> fact. my proposal only applied when apps, for some reason or other,
> cannot use standard keybindings or menus. Pretending such apps don't
> exist is counterproductive, my only concern is interoperability, i.e.

Which app absolutely, positively cannot use menus or standard keybindings?
For a momemnt consider that we assume that for terminals that can't use
Ctrl-C we'll use Shift-Ctrl-C.

> it shall be possible to transfer text from any app to any app via
> selections.

Yes, by as havoc said, fixing the apps to follow the spec.  If an app has a
UI that will not work with the spec then perhaps there is something wrong
with the UI of that application.

> > And how does using CLIPBOARD with explicit copy cut and paste not address
> > that issue?
> 
> this does address the issue and is a very good solution. my proposal
> included this as a solution in fact. There was an exclusive or, if you
> have an explicit copy/paste then nothing changes. (except to make sure
> you are setting PRIMARY as well as CLIPBOARD on copy, but everything
> does this anyway) If you have an app without explicit copy then you must
> add it. or LESS PREFERENTIALLY do something else, but only if you have
> very very good reason. I can understand that you feel that there is a
> never a good reason not to add an explicit copy, but the universe of X
> applications is large, and my primary concern is making sure that it is
> interoperable with each other meaning that we must tell people that if
> they wish their app to be able to cut-paste with other apps AT ALL, they
> must provide a mechanism for copying to CLIPBOARD.

give me a "very good reason" to not have some normal, standard UI for
explicit copy?  You cannot write a spec that is ultimately flexible and the
whole point of a spec is to say "this is the way things should be done".
An app which breaks the spec should then face the consequences, that is,
it will not work with others that do implement the spec.

100% interoperability with apps that are not interested in following a basic
set of guidelines is impossible.  You will just get an incredible tangled
mess of spagetti functionality that nobody quite understand, works
differently in every app, and users are not able to use it anyway.

When an app doesn't follow the spec, the solution is not to change the spec,
it is to fix the app.

> just saying PRIMARY is an easter egg doesn't work if there are apps
> where it is the ONLY mechanism for selection/pasting. this is what I am
> trying to fix. so that we MAY tell people it is an alternate method
> which is never necisary.

Such apps are broken with respect to the spec and should be fixed.  What you
are proposing is instead of fixing a few broken apps is to add workarounds
everywhere else to make it semi-interoperate with those few broken apps.

Either way as you we MUST ADD CODE somewhere, why not add it in the apps that
are breaking the spec and which are inconsistent with the rest of the
desktop?

George

-- 
George <jirka at 5z.com>
   Miau miau, zikala kocicka dyz hapala do studne.
                       -- Hyta a Batul



More information about the xdg mailing list