[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: One for our asian language experts...

From: Eric Christopherson
Subject: Re: One for our asian language experts...
Date: Tue, 29 Jul 2003 15:01:54 -0500
User-agent: Mutt/1.5.4i

On Tue, Jul 29, 2003 at 11:58:23AM +0100, Richard Frith-Macdonald wrote:
> On Tuesday, July 29, 2003, at 11:23 AM, Pete French wrote:
> >>The problem lies not in the recent unicode support, but in the
> >>implementation of gpbs.
> >
> >Ah, O.K. Now that is a shame. Understandable in some ways I guess. I
> >have to admit that I used to write code to support european users
> >first and then retro-fit internationalisation afterwards. A habit which
> >bit me badly the day someone pointed out that Greece is part of the 
> >union
> >and thus I need to give it equal status to the other languages. Which
> >lead to a large amount of re-engineering of code!
> I have to put my hand up as the guilty party ... when I wrote that, I 
> couldn't
> find how X supported internationalised text cut/paste (I still don't 
> know) and
> as the gui at that time didn't support non-western charactersets, I 
> couldn't
> have tested it anyway.
> However, IIRC the pasteboard system basically just sets some atoms to
> say what type of data you have, and converts between our internal
> unicode representation and the (basically ascii) text format that was 
> the
> only example of X cut and paste I could find.  I don't expect it would 
> need
> a major rewrite to extend that to whatever mechanism X has for 
> internationalised
> text cut and paste

While we are talking about reforming gpbs, I would like to ask something
that's been bothering me for some time: Does GNUstep handle selection and cut
buffers in a "proper" way?

Background: From the very little that I understand about X internals, X has
a selection mechanism and a cut buffer mechanism (I'm not sure if the latter
is the precisely correct term). When you highlight some text with your mouse
in an X app (say xterm), it goes into the selection; the selection is pasted
back to an app by pressing the middle mouse button in that app. However,
apps which have cut/copy/paste actions in them, such as KDE and GNOME apps,
implement "cut" and "copy" by copying the data in the selection into a cut
buffer. Unlike the selection, the cut buffer is not disturbed every time you
highlight something. Also unlike the selection, the cut buffer data is not
emitted when you hit the middle button; you have to explicitly choose

(Please feel free to correct me on the preceding.)

Anyway, I have noticed very strange behaviors when going back and forth
between GNUstep and GNOME or KDE apps. It seems that when going from GNUstep
to a KDE or GNOME app, the selection and cut buffer get switched around.
Middle mouse pastes whatever was last copied, when it should paste whatever
was last selected; the "paste" operation pastes whatever was last selected,
instead of whatever was last copied.

So, I am hoping that someone knowledgeable about both GNUstep and X
selection/cut buffer behavior could take a look at the code and see if it is
in fact broken, as it seems to be, and hopefully fix it :)

Furrfu!         r a k k o  at  c h a r t e r  dot  n e t

reply via email to

[Prev in Thread] Current Thread [Next in Thread]