| [ Return to Bugs & Features | Post Text | Post File | Prev | Next ]
STR #2766
Application: | FLTK Library |
Status: | 5 - New |
Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Core Library |
Summary: | New configurable option to change symbol prefix character |
Version: | 1.4-feature |
Created By: | dfatfl |
Assigned To: | Unassigned |
Fix Version: | Unassigned |
Update Notification: | |
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post Text ]
|
#1 | dfatfl 14:06 Nov 09, 2011 |
| This change allows someone to configure FLTK to use 0x0F as the symbol prefix character instead of @. This allows the use of @ without special handling which can be troublesome since internal widgets use @ for things like arrows and special characters. To enable support for the new prefix you'd run ./configure with the --enable-newprefix option (you may have to remake the configure first, "make clean" seems to do that for you). | |
|
#2 | dfatfl 01:32 Nov 10, 2011 |
| this needs to be fixed - not all .cxx modules include <config.h>. | |
|
#3 | AlbrechtS 02:31 Nov 10, 2011 |
| David, thanks for the patch. This is a good starting point when it comes to implementing such an enhancement. This is really something that is needed, together with a way to switch "@" symbol substitution on and off, when needed (which is often a problem - maybe a FAQ - and it looks like there isn't a proper way to deal with it).
However, I do fully agree with Greg that this is not appropriate as a configure option, for the reasons Greg mentioned in his post in fltk.development [1]. Besides that, I'd rather have the symbol substitution character changeable (at runtime), so that it is not another constant - and in your proposal a non-printing/control character that would be difficult (but not impossible) to handle in strings. I would even go so far that this should be settable per widget (on, off, which character) and not only globally.
Another point not to add a new configure option is to avoid having to remove it again later. This would seriously break backwards compatibility.
I'd vote -1 for the patch in this form, but think that it is good to add such a feature in the future.
---------------------------------------------------------------- [1] http://www.fltk.org/newsgroups.php?gfltk.development+v:12951 | |
|
#4 | dfatfl 08:53 Nov 10, 2011 |
| I think this would be good for those starting to use fltk or those who don't use 3rd party fltk libraries. For those just starting, they can use the macros easily and those wanting to covert can do so easily as well. For example things that used to be "some text @-> more txt" can be converted by "some text " FL_SYMBOL_CHAR "-> more text" (easy) where as you couldn't do "some text " Fl::symbol_str("->") " more text" (gonna be work). Also, the macros could always be converted to fit any future solution that could work out how to return symbol strings in static buffers (or whatever other solution that could be used). I'd hate to see it not used and 1, 2 or more years from now there was no solution added. For those creating 3rd party libraries where they only want to provide one version, a single variable could be setup to contain the symbol char that they could use to build up their custom strings internally. While I agree keeping it all in variables and assignable would be great (which was my fist thought as well and what I've done for all the other optional items), there may be too many issues for it to be practical. However, I do think a variable should be added for those 3rd party library providers. | |
|
#5 | dfatfl 08:57 Nov 10, 2011 |
| Sorry the sample should have been: "some text " FL_SYMBOL_TX "-> more text"
Not: "some text " FL_SYMBOL_CHAR "-> more text" | |
|
#6 | dfatfl 12:01 Nov 10, 2011 |
| I changed this to not use config.h but to just put as a build option via fltk-config and via make. This also adds the static variable to Fl class to hold the prefix character.
side note: I do the changes to my main working copy then use winmerge to move in to a download of the current branch, I think I got everything. | |
|
#7 | AlbrechtS 03:36 Feb 07, 2019 |
| Moved from 1.3-feature to 1.4-feature.
This STR has been superseded, see also cumulative patch in STR 3485: https://www.fltk.org/str.php?L3485 | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |