In article <[EMAIL PROTECTED]>, matthiasm <[EMAIL PROTECTED]> wrote:
> The idea was to allow FLUID to write efficient resource files that are > then included into the executable and interpreted at run time, > creating the default GUI. It would then be possible to extract the > resource file, localize it using FLUID (including text changes and > widget sizes), and write it back, or provide it as a seperate > localized resource file. > > It was (probably rightfully so back then) dismissed as violating the > Fast and Light approach of FLTK. I don't see it violating, though it may be a little slower when used. If you introduce a new function that simply parses a .fl file, constructing and registering handlers for you, it's not a runtime overhead; just a maybe sightly slower at construction. Still, there's no need to use the function, so it doesn't contribute to the file size either. I have just two questions: compatibility with current fluid files: you can't certainly introduce C code in the handlers, just declare references to executable functions in order to keep things clean and elegant. handling of GUI forks: assuming you have two variants of a GUI (for locale purposes) and positioning of the widgets is not an issue, I would like a way to ensure that fluid requires certain handlers to be registered and/or certain IDs to be present and be of a certain kind. A possible solution would be generaring another kind of file, say "rc resource files", directly from fluid. In the main file, which is identical to the current one, a property needs to be set which allows a widget to be "enforced". The generated rc file is exactly the same file, with C code replaced with the generated function names as found currently in the generated files. If fluid could open that simpler rc file, constraining the required widgets/code, then anyone could localize/fix the gui without breaking (unintentionally) the program. > Maybe something to consider now? Still, there's to consideer a consistent way to place those rc files, without necessarily enforcing localization semantics. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
