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

[Dominic Lachowicz <domlachowicz gmail com>]

Hi Matthias,

> > *) The TextView can serialize and deserialize (a selection of) itself
> > into UTF-8 text, for the common copy + paste semantic.
>
> Sure, it does that already.

Yup, I'm fully aware.

> > *) 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.
>
> This is what mitch's gtk_rich_text_register() api does, more or less:
> it gives apps a way to register functions for serializing and deserializing
> text buffer content into different formats.

If that's all it did, I wouldn't have a problem with it.

> > *) 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.
>
> mitch's current patch just provides an "internal format", but I think
> we would be happy to include XHTML and RTF format support
> if patches appear...
>
> So, it seems your recommendations are fairly close to what mitch's
> patch already provides. Or did I miss your critcism of the tagset
> mechanism somehow ?

I think that you missed my point completely. So let me restate it,
hopefully more clearly:

*) I think that Mitch's data model incompatibility problem is a very
real one that needs to be addressed.

*) I think that the tagset metaphor is too primitive to do anything
genuinely useful with and we will be butting our heads up against that
wall *very* quickly.

*) Richtext copy + paste should be handled *only and entirely* by the
app that owns the GtkTextView, and not the GtkTextView itself, because
only the application necessarily knows what its data model can
represent. Combine this with the limitations evidenced by my previous
point to get the full effect.

The fact that some applications might use GtkTextView as both their
Model and View is confusing the situation. The app and only the app
needs to have fine control over what goes into the Model. It - not the
GtkTextView - is the Controller. This should be solely the
application's responsibility, and not part of the GtkTextView API.

*) I think that if we want to provide convenience functions for
serializing/deserializing common formats, then that's great. But I
don't think it is necessary, nor do I think that a
subsetting/translation mechanism such as the one that Mitch proposes
has any business being anywhere near the serialization API or
GtkTextView.

*) I think that tagsets are the wrong approach for solving this
problem. As such, I think that richtext copy+paste facilities should
be something layered on top of the GtkTextView by the parent
application and not be a builtin feature of the TextView itself. The
application knows in detail what its data model and controller
supports. The TextView does not, and should remain dumb in this
regard.

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