Re: Future gtk-text widget

[Kenneth Albanowski <kjahds kjahds com>]

On Sat, 24 Apr 1999, Dov Grobgeld wrote:

> Notes about an ideal text widget
> ================================

Sorry, no answers here, just suggestions for more questions...

[...]
> * A tag may inherit from a different tag and overload a subset of 
>   properties.
> 
> * A special tag always spans the whole text widget and by changing the
>   attributes of this tag, the default attributes of the text widget is
>   changed.
> 
> * Another special tag defines the attributes of selected text. 

Now we need to figure out what tags mean when more they overlap. Is there
a precedence, an inheritance, can tags be programmed to do special things
in special cases, etc.

> * It should be possible to import and export a XML representation of the
>   entire contents of the text widget.

Too specific: it should be possible to efficiently and effectively walk
the text widget's storage mechanism, with mechanisms available in the
package to convert to XML, plain text, word-wrapped and/or tabbish text,
RTF, etc. Mechanisms for the reverse direction are also necessary.

> * The concept of tag may be used for l10n as well by making it possible
>   to define a fontmap in the gtkrc file so that the gettext resource files
>   can be interpreted in Unicode and displayed in the desired font for 
>   all widgets with default widgets that display text.

Please consider application-wide concerns vs. single widget concerns. Is
it useful to define what Japanese means separately for each widget? Is it
wise?

>   (How are the l10n concerns that are addressed in the latest version of the
>   perl journal addressed btw? There it is basically claimed that the static
>   gettext method don't work for a lot of languages of the world! The
>   article defines a way of writing subroutines that given a set of
>   paremeters returns a resolved string.)

I'd advise folks to read the article, it's quite good, although the
suggested approach to a solution is Perl specific. I do think the
technique (allow programmer-, system-, and user-supplied interpreted code
to muck with the substituted text) is the most sensible in the long run,
although we don't yet have the infrastructure to support it in a flexible
manner at the moment. 


-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)