[GUI] Another RFC on setting and getting.

[Glynn Clements]

Vincenzo Ciancia wrote:

> > Ok, some inspiration: Gtk allows labels to contain
> >  either a simple string or markup like
> >  "<red>warning</red>: about to erase file". If the
> >  markup is passed as an algebraic data type we would
> >  need to parse the label's text in order to get the
> >  algebraic data type back. So it's easier to consider
> >  the text of a Gtk lable as write only. But the label
> >  can be changed after the creation.
> 
> You can also record the label's value, in algebraic form, in a mutable
> variable wich stays in the haskell land. Of course, if the toolkit
> itself can change the label, this makes few sense, and OTOH, it might be
> not so bad if you parse back the text: if the widget is not a label but
> a textbox, it's perfectly legitimate that the user cuts and pastes
> formatted text, and you have to read that back.
> 
> Perhaps in this particular case it's easier to say: that is not markup,
> it's a string. A successive layer will take care of markup and similar
> issues.

What if you need to programmatically set a button's label to the
literal string "<red>" in a portable manner?

I suspect that similar issues will arise regarding I18N (do we discuss
those on the GUI list or the I18N list?). One toolkit may dictate that
everything is UTF-8 encoded. Motif uses compound text (basically
ISO-2022 encoding, with some restrictions). Athena just treats the
data as an octet stream, and it's up to the programmer (or user) to
ensure that the font uses the same encoding as the data.

It gets even more messy when you start dealing with cut/paste between
applications using different toolkits and/or different encodings.

-- 
Glynn Clements <glynn.clements@virgin.net>