On 12/10/11 05:51, Albrecht Schlosser wrote:
>> On 12/09/11 12:05, Bill Spitzak wrote:
>>> I would not do this, as it will make it impossible to link unrelated
>>> fltk-using code together as this would have to be a static value. Or we
>>> have to waste space to put the value on every widget.
>
> Fully agreed (this refers to changing the "@" symbol with a configure
> option). This would make it impossible to link one's FLTK app with a
> dynamic library (as is often provided on Unix/Linux systems and others).
Right, I wouldn't suggest it as a ./configure option either;
in my mind it would be an API thing (where the app can set it)
>>> The user should be able to turn on the "don't interpret @" flag on the
>>> widgets they need it for.
>
> Yes, that looks like a sensible option, agreed as well.
I'd be for it, but would lobby for a matching global option
as well.
>> Would be nice if the @ char could be set to NULL to "disable" it
>> globally, as it's more often then not an @ can sneak into the app
>> via user supplied input, config files, etc.
>
> Absolutely true. But if you can disable '@' processing on a per-widget
> base, wouldn't this help?
A flag to disable @ would be nice, but perhaps a step better
is to change the char (with NULL being 'off'), as there are
situations where an app wants the features of @, but using
a character that is known to be 'safe' for the data the app
is managing, such as \x7f (DEL), \x1b (ESC), or even \x01 (SOH)
(which should all be 'safe' even in the presence of UTF8)
> A global option to disable '@' processing (hence application-wide) would
> be useful as well, IMHO. If we went one step further, we could also add
> a new Fl::option() to enable/disable '@' symbol substitution.
Yes, Fl::option() would be a good way to go for a boolean 'flag',
but being able to change the char would be better for my needs.
> Per-widget control could be achieved much easier with a new Fl::Widget
> option/setting method, and I believe that we have some usable bits in
> the widget flags. However, it *might* be a problem to propagate the
> per-widget option to the basic draw and measure methods that do symbol
> substitution eventually, since there might be no argument in some cases
> (I didn't look at the code, that's just a guess, and I might well be
> wrong here).
An interesting sugg to use widget flags to enable/disable
label()'s use of '@'.
One wouldn't be able to change the char that way, but if
that ability is voted down, a flag would be the next best thing.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
