Re: Multi-lingual cut & paste support (was Re: One for our asian language experts...)

[Kazunobu Kuriyama]

Fred Kiefer wrote:

> Adam Fedor wrote:
>
> > > -----Original Message----- From: Fred Kiefer
> > > [mailto:fredkiefer@gmx.de]
> > >
> > > I was not suggesting to revert back to the old code, but as you
> > > also agreeed to, support different ways at once in our xpbs code. 
> > > Hopefully code that wont be used in the long run, but would still
> > > be there as a fallback.
> >
> > I'm not sure I understand what you mean. However, just to be clear,
> > for people using an old X server, the gpbs code is exactly the same
> > as it was before, only people using new X servers will see a change.
> No, I was not refering to an old X server, but to an X application that
> would be able to exchange STRING data but not UTF8 data via the 
> pasteboard. What needs to be added to our code for this is the 
> ablility to read and write different data depending on what the other 
> application can process. This is what the specification I was refering 
> to suggest for all applications. To put it into other words, I was 
> suggesting the switch from a compile time setting of the pasteboard 
> type to a run time setting. Does this make my position a bit clearer?

I understand.  Let's think of its feasibility.

My naive idea tells me to use a sort of timeout mechanism: First, ask 
utf8 datum.
If failed, ask STRING one.

Clearly, this idea is bad.  I'm afraid it won't work reliably because 
copy-and-paste
is forced to rely on the duration of timeout, which is irrelevent to the 
capability
of a given client.  When an X server is busy or an X terminal is 
connected with it
through network, copy-and-paste is occasionally carried out with STRING 
datum even if utf8
one is available.

So the feasibility depends on this: Is there a reliable way for gpbs to 
see whether or
not a given X client is capable of utf8?  I'm afraid almost all clients 
won't tell us
their capability unless a certain atom is defined on their side (Even if 
it is actually
defined, it is almost impossible for gpbs to know what the atom is, 
becuase the inter-client
communication conventions don't specify such a predefined atom.)

Or should we do away with the inter-client communication conventions?

- Kazu