clipboard again (was Re: Gnumeric and RHEL3)
- From: Nick Lamb <njl98r ecs soton ac uk>
- To: gnumeric-list gnome org
- Subject: clipboard again (was Re: Gnumeric and RHEL3)
- Date: Wed, 14 Jul 2004 18:35:30 +0100
On Wed, Jul 14, 2004 at 10:13:41AM -0400, Morten Welinder wrote:
Anything that does not interoperate with the default terminal window (that
would be xterm) is broken. No "ifs" and no "buts" about it.
The version number on xterm does not support the implicit assumption that
xterm is a pristine example of bug-free and feature complete X apps.
xterm does not use the CLIPBOARD because it does not have any explicit
mechanism to CUT or COPY anything, text included. If such a mechanism was
added, it would of course use the CLIPBOARD. I like xterm, and if I ever
found the time, I'd add such a mechanism, but as the Gnumeric and GIMP
maintainers must have noticed, I seem to be rather busy.
Terminals with amazing 20th century inventions like menu bars do tend to
have explicit CUT, COPY and even PASTE and lo and behold they work with
Gnumeric as expected.
Thus, Gnome (and not Emacs) is broken in this regard. And it should be
considered broken until such time the authors of the new wannabe-standard
implement _and_ _widely_ _deploy_ changes to xterm to make it use the new
proposed standard. That should perhaps have been initiated years ago, but
it was not -- a grand failure of those who support the new behaviour.
Is it a wannabe-standard? Looks like merely a clarification of (1) the ICCCM
recommendations and (2) real world practice of applications that actually
have explicit cut, copy and paste. When the "standard" was written it
mentions that there are just two notable exceptions to the usual practice
and indeed today that's reduced to just one, GNU Emacs because Qt 2 is now
obsolete.
It's also not "new behaviour" unless you mean that it obviously had to wait
for X to introduce the selections mechanism and deprecate cut buffers in
order to be introduced. The CLIPBOARD selection and its intended meaning
appear early in the history of X11.
Did I mention cut buffers? That would be xterm again, using and indeed
encouraging a mechanism that's i18n-unfriendly, bandwidth-hungry and has
been officially deprecated for so long most X11 coders haven't heard of it.
Not really the benchmark against which to measure others...
Gnumeric supports both broken (Gnome) and correct (xterm) behaviour. There
is a gconf key for it. I know because I put it there.
typo, should read correct (GNOME and GTK+, KDE AND Qt >= 3.0, FLTK, Tk, and
suchlike toolkits) and broken (older Qt, some GNU Emacs installs) since
xterm doesn't have any relevant behaviour (only explicit cut, copy & paste
is at issue, which xterm doesn't do).
Actually I'm somewhat surprised that you went to such efforts, I haven't
looked at the Gnumeric source tree since 1.3 opened, but it used to use
ordinary GTK+ widgets, which of course don't have the behaviour you're
talking about. How much of GTK+ did you have to duplicate in order to
create widgets with your preferred behaviour...?
Because you see, if you didn't fix that, then what you have is an application
that isn't even consistent _internally_ let alone when you copy and paste
between applications. That would be pretty stupid, I'm sure you agree.
Nick.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]