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.
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list