[STFL] Getting a widget's width without drawing it?

[Clifford Wolf]

Hi,

On Wed, Sep 19, 2007 at 10:45:32PM +0200, Andreas Krennmair wrote:
> BTW, before you push out another release, could you before have a look
> at the proof-of-concept patch regarding "rich text" support for the
> textview that I sent to the list in August, and tell me whether the rich
> text support looks OK to you from the syntactical point of view? If yes,
> then I'd like to improve the patch to make it work properly with escaped
> characters and multi-column Unicode characters.

ah, yes. I knew I forgot something..  ;-)

You wrote:
> Anyway, my idea is that the textview widget by default behaves like it does
> right now, unless an attribute "richtext:1" is provided. With this attribute,
> every line of text is interpreted as rich text.  Text attributes within such
> lines is provided in the format:
> 
> 	$<colors and attributes>$<text to format>$
> 
> e.g. $fg=blue,bg=white$this is blue and white$.
> 
> Such a special string can be contained 0 or more times in a line. When the
> character $ shall be displayed, it must be escaped with \ (as mentioned above,
> the escaping is the part that I haven't implemented yet). A patch that
> implements the PoC is attached to this mail. Comments are welcome.

Id prefer something like this (stfl example code):

  vbox
    @style_foo:fg=white,bg=blue
    @style_bar:fg=red,bg=black
    @richtext:1
    label
      text:"This is a $foo$colorfull $bar$richtext $normal$test."
    label
      text:"This is a dollar sign: $$"
    label
      text:"Another dollar sign: $fg=blue$$$ $normal$(and it is blue)"

So, richtext tags are embedded in dollar signs. An empty tag expands to
a simple dollar sign, a tag conatining a '=' is a style string and a tag
not containing a '=' is resolved using a 'style_<tagvalue>' variables.

The handler for this should imo be part of style.c so it can easily be used
by all widgets displaying text in one way or another. Id think of an api
with three functions: one for returning the actual length (in terminal
characters) of the string, one for writing it to the curses window and one
for converting a string with richtext tags to a string without richtext
tags. The drawing function should also have offset and length parameters
for widgets with horizontal scrolling (like the input widget). An
additional function for inserting text in a richtext string on a character
position would be fine (e.g. for the input widget).

why the input widget? this would e.g. allow it to write applications with
embedded spell checking in input fields, displaying words wich do not pass
spell checking in another color..

What do you think of that api?

yours,
 - clifford

-- 
Caffeine for mind, pizza for body, sushi for soul.