On 12/14/11 02:19, MacArthur, Ian (SELEX GALILEO, UK) wrote:
>> [html suggestion]
>> the limited pseudo-html syntax that is used by Qt and Pango 
>> and possibly a large number of other pieces of software.
>>
>> This would let users write "foo <b>bold<i>bold 
>> italic</i></b>" and so on.

> Greg's idea (ANSI "inspired" sequences) does have some appeal too,
> though, and the extended version of Greg's proposal was that we could
> have support for different mark-up styles, flagged in the widget.

    There are probably practical reasons to use both.
    *though I agree with Bill, HTML is the saner choice for general cases.*

    The reason I gravitated towards ANSI was:

       o I was displaying a command line tool's color output in the GUI
       o ANSI is generally shorter sequences (html can end up being more chars)
       o Parsing speed (ANSI can be implemented with a switch statement, 
parsing is fast)

    I suppose if I hadn't been working with a command line tool that
    printed out color progress bars to a terminal, I would have gone
    the HTML route.

    Seems like both ideas would perhaps be useful,.
    Certainly html is more readable when inlined in code:

        const char *msg = "<b>Alert!</b><br>Your printer is on fire";
    vs.
        #define BOLD_ON  "\e[1m"
        #define BOLD_OFF "\e[0m"
        const char *msg = BOLD_ON "Alert!" BOLD_OFF "\nYour printer is on fire";

    There are several concepts that neither have or share, so we'd
    have to come up with extensions to support them. For instance,
    eg. html doesn't have a way to control bgcolor (other than css or tables) 
or 'dim',
    and ansi doesn't have a way to set font face or size.

    BTW,  as a related aside, here's a fun little one liner perl that shows
    a 32 value grayscale that works on all X based linux terminals:

perl -e 'for($y=0;$y<5;$y++){for($t=232;$t<256;$t++){printf("\e[48;5;${t}m    
");}printf("\e[0m\n");}'

    eg: http://seriss.com/people/erco/fltk/tmp/ansi-256color.png

    Like FLTK, the ANSI xterm-256 color extension uses a color cube
    and gray scale to get as much color as possible from a 256 value limit.

    There also seems to be a way to access 24bit rgb, though I haven't messed
    with it.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to