New: X11UnicodeClipboard

On 9/21/2012 12:12 AM, Holger Kleinsorgen wrote:
> And what about support for current platforms with current VMs and images?
> Is compatibility with older platforms actually *more* important?

Like I said before, there are two aspects to this problem.  One is that
existing functionality shouldn't be broken because it breaks backwards
compatibility.  The other aspect is that there are various ways to
preserve backwards compatibility while adding new features.

There is an existing example that I think answers both questions.
Consider the Windows Unicode VM.  That VM, among many other things,
enables a UTF-16 clipboard.  The same VM is also backwards compatible
with older images.  As you can see, this VM provides support for more
current platform features with current VMs and images.  Backwards
compatibility and newer features are not mutually exclusive goals.

I should also note that when I mention backwards compatibility, I'm
referring specifically to backwards compatibility with older *images*.
What we need to avoid, during the same major release, is to have the
situation where you fire up an older image with a newer VM and the code
that used to work now breaks.

> We're not talking of "Xfoobar or CoreBellsAndWhistles", as you mentioned
> above.

I'm sorry, I was referring to things like Xft, which also appeared in
this thread.  I just didn't want to talk about Xft in particular because
I didn't mean to make an example of it.

> We're talking about a broken core functionality of the GUI, e.g. an
> unhandled exception when pasting certain ISO-8859-1 characters. And it's
> broken for years now.
>
> UTF-8 locales, UTF8_STRING and friends are not new kids in the town, they've
> been around for years. Given that there is no single vendor for X11-based
> platforms, it will be difficult to implement a "perfect" solution, because
> things *might* change. But I doubt that UTF-8 locales and UTF8_STRING will
> be replaced in the near future.

As I've stated before, I'm all for considering what to do about this as
long as we do the due diligence.  Action without due diligence will
simply give us even more grief in the future when the needed cleanup
gets in the way of further change.

> A suggestion concerning backward compatibility:
>
>     ObjectMemory
>         registerObject: 'UTF8_STRING'
>         withEngineFor: 'X11SelectionAtom'
>     Screen externalSelectionEncoding: #'utf-8'.

Noted.

Andres.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I understand your frustration.  I do not have much to say about prior
decisions outside of my control.  What I'm trying to promote are steps
that make it easier for these types of changes to happen.  In other
words, let's do the homework first and determine what solutions will
work.  I'd like to see an honest attempt at delivering something once
we're done with the research.

BTW, we looked at this for a while on Solaris 9, and what's going on is
that some convenience macros called e.g. XA_UTF8_STRING are not there.
However, that doesn't mean you do not have access to the X11 atom for
XA_UTF8_STRING.  A plausible approach that is emerging out of this is
that one could produce a new couple primitives that implement clipboard
functionality with UTF8, and have the older primitives implemented in
terms of the new UTF8 code.  On the image side, we would have the older
primitive call sites redirected to the new primitives.  It might work.
We'd still have to support XA_STRING for apps that do not know how to
request the clipboard selection with XA_UTF8_STRING and stuff like that.
  The testing procedure for this so far looks like a huge time sink:
every platform x various encodings for the clipboard x various displays
both local and remote.  It's never as simple as one would wish when it
comes to these things, sigh.

And of course all of this is just some sort of draft half-baked thought
that is not even close to being finalized, your mileage may vary, all of
this is mod priorities from management, etc.

Andres.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc