RE: Rich Text copy and paste (bug #324177)

[Dominic Lachowicz <domlachowicz gmail com>]

On the Windows platform (as an example), there are standards for
richtext interchange between applications. Those standards are RTF and
to a lesser (but growing) extent, (X)HTML. You'll find that a lot of
the more richtext copy+paste centric apps on Linux and MacOS also
commonly use these interchange formats. Applications like MSIE,
Outlook, Office, Mozilla, Evolution, AbiWord, etc. will offer their
selections in these formats and copy+paste between them can be said to
work fairly well.

These are applications that know how to serialize and deserialize
their data Model. If these applications encounter some semantic that
their data Model can't handle, they have already assumed responsiblity
of the data and will fall-back or transform that data as is necessary.
The Model will never be in a state that is inconsistent with what its
View or Controller can respresent.

In his simple MUA example, Mitch proposes that perhaps there is a
class of applications where the Model and View are considerably
smarter than the Controller. GtkTextView is pretty smart, I'll grant
you, but all of its data must have come from somewhere. The
application feeding the TextView data must have a mapping from that
data's model into the TextView's model. And the inverse must be true
for deserialization.

Consider the primary ways that a user will get data into a MUA:

1) Typing it herself, interacting with the MUA's controls
2) Displaying a previously sent email (either by itself, or in a
"reply-to" form). This email may have come from a smarter MUA, and
thus need to be dumbed-down for viewing or editing.
3) A distant third is pasting between MUA message windows. Since the
data came from another window in your application, it is probably safe
to assume that this data is already in a format that your MUA
understands.

I contend that this shows that Mitch's example MUA would necessarily
be smart enough to filter out the bits of HTML it doesn't understand
for viewing. It must also be smart enough to serialize the TextView
into a HTML syntax that it does understand when sending. It's not hard
to make the leap from serializing all of a message when you click
"Send" to serializing a subset of the message when you hit "copy".
Similarly for "recieve" vs. "paste". In these cases, the MUA doesn't
need (or even want) the TextView to do anything on behalf of it.

Applications should not blindly use GtkTextView blindly as both their
Model and their View. Any app that does this probably deserves
whatever wonky results they get.

Mitch's tagset attempts to strike a middle-ground, but I don't think
that a middle ground is what we should seek. The tagset attempts to
brute-force filter some semantics that aren't handled by an
application. Think "I don't support bold text". But it can't handle
more complex scenarios, such as "I don't handle tables inside of
tables" or "I handle bold text and italic text, but not bold, italic
text". But filtering may not be what you want. One might want to
tranform a HTML table into an ASCII-art one, or a bullet/numbered list
into asterisks/numbers plus some tabs.

The tagset as proposed can't capture even these simple semantics. In
doing so, it proposes to use yet another interchange format that is
specific to GtkTextView. Unless more common formats are offered AND
accepted or a clipboard manager does conversion, copying and pasting
richtext between applications is in the same sorry state that it is
today. This is especially true for inter-toolkit cases.

I can't see a tagset-based approach working for anything but the most
contrived examples. And I don't see that as preferable (or even
easier) than having the application filtering the data itself as it
must already be doing elsewhere.

With that said, I think that the best course of action is to keep this
sort of application-style logic out of the TextView, and push the onus
onto the apps that would use it. My ideal setup would probably be:

*) The TextView can serialize and deserialize (a selection of) itself
into UTF-8 text, for the common copy + paste semantic.
*) Applications are responsible for serializing and deserializing the
text view into more complex formats, such as RTF and XHTML. Push any
"smarts" up to the application level rather than the widget level,
since the application should have control over its Model, and not the
other way around.
*) If it is felt to be necessary (and I'm not convinced that it is),
there can be an opt-in serialization/deserialization API for several
of these more-common interchange formats, such as XHTML and RTF. These
must be optional, since they mustn't compete with their parent
applications for control of the interchange atoms on the clipboard.

Best,
Dom
--
Counting bodies like sheep to the rhythm of the war drums.