> 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). >> 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. >> If they actually want @-commands to work with their strings, it seems >> they must be modifying them to add these commands. They should be able >> to double the @ signs in the original string at the same time. On 09.12.2011 21:52, Greg Ercolano wrote: > I've run into this need myself quite often, and it is > troublesome to manage. > > 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 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. > Creating wrappers for all widgets that add/remove @'s for set/get > label methods is a major undertaking. (What I've done in other apps) > > Also, doubling up @'s makes it really hard for apps to read back > label()s and get expected results; such as doing searches by label() > name involves adding the extra @'s to the search string so that it > properly matches the label()'s return value. And reading back > label() values and use them in other parts of the app (to save > to files) involves /stripping/ the extra @'s. > > For the many apps that don't want @'s to be parsed at all, > it would really be helpful to be able to disable globally. > > I think a static should be OK for this, shouldn't it? > And an Fl::xxx() function to set/get. Wouldn't involve > any conditionals to the code I think. Just have to make sure > setting it to NULL doesn't bungle up string parsing. Yep, good points... > The only alternative I can think of is new methods to set/get > labels that add/remove the @'s automatically, eg: > label_nosym(const char*) would automatically pre-insert @., > and const char* label_nosym(void) would return a pointer > that skips over the leading @. This would at least allow > per-widget control I suppose. 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). > Perhaps there are other techniques I'm not thinking of, > but would like some better way to manage this. Agreed, too. Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
