If such changes are being considered, I would MUCH prefer changing to 
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.

The version I am thinking of would never produce errors. Any "<..." that 
does not match a known command will print literally. The "<" must be 
immediately followed by a letter or '/' or it is printed literally. 
There is no requirement for matching close delimiters. Unexpected '>' 
print literally. '&' followed by anything other than the few recognized 
chars is also printed literally. And newlines act exactly like <br>.

On 12/10/2011 12:34 PM, Greg Ercolano wrote:
>> A global option to disable '@' processing
>
>      On a slightly related tangent, one of the few things I've had
>      to actually /modify/ fltk for to support my commercial app is
>      adding ANSI escape sequences (eg. \033[xxx) to control per-character
>      foreground and background color attributes in Fl_Browser.
>
>      I think I posted an STR for this, or at very least a patch
>      on one of the newsgroups.
>
>      IMHO the vt100 escape sequences are both flexible and well
>      documented. And with a few extensions, one can access full
>      24 bit RGB color information (as well as color map colors)
>      using this technique. (ie. \033[1X for color map color 1
>      vs. \033[#ff885500X to get R/G/B color ff/88/55 in fltk's
>      RGB color format), where 'X' is some unused ANSI control code.
>
>      Similarly, font selection and font size could be selected
>      within a line. (I think I included that too in my patch,
>      not sure.)
>
>      ANSI might be an interesting alternative for in-line
>      color/font/etc selection of general labels (and not
>      just Fl_Browser), itself being something that could
>      be enabled/disabled with a flag.
>
>      Anyway, just tossing that out there, in case it aides
>      in forward planning.
>
>      With such a feature, I could see then just being able
>      to disable @ and enable ANSI as a way around getting
>      what I need without worrying about the '@' character.
>

_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to