Hi, Manolo and others,
I've tried to localize the printer dialog strings in a cross-platform
way, but the relevant global string pointers are defined in
print_panel.cxx and thus only available on the U*X (Xlib) platforms,
because this file is not included in the Win32 and Mac builds.
It's for the (Xl1) printer dialog only. They are marked "These
attributes apply to the Xlib platform only" in the current docs.
This implies that developers who want to do localization of these
strings would need something like
#if !defined(WIN32) && !defined(__APPLE__)
... localization of strings ...
#endif
in their code. I don't like that. :-(
Thus, I moved these strings to Fl_Abstract_Printer, so that they
are available on all platforms.
Advantage: no platform dependency in user code.
Drawbacks:
(1) There are about 20 pointers and their associated strings on all
platforms that will only be used on Linux or other X11 platforms
(about additional 150 bytes / 230 bytes on 32/64 bit platforms).
(2) The global static string pointers will belong to the class
Fl_Abstract_Printer.
To (1): I wouldn't mind on 64 bit platforms at all, but maybe someone
who uses a 32 bit embedded device with small memory.. [but we thought
about isolating the printing functions in a separate librarie anyway,
if someone would complain about size for embedded platforms]
To (2): They can be *used* with the Fl_Printer:: class prefix though,
as if they belonged to Fl_Printer because of inheritance, but that's
maybe not very nice.
If done so, we'd have (in Fl_Printer.cxx):
const char *Fl_Abstract_Printer::dialog_title = "Print";
const char *Fl_Abstract_Printer::dialog_printer = "Printer:";
const char *Fl_Abstract_Printer::dialog_range = "Print Range";
[...]
and for German localization, we can use (e.g. in test/device.cxx):
Fl_Printer::dialog_title = "Drucken ...";
Fl_Printer::dialog_printer = "Drucker:";
Fl_Printer::dialog_range = "Druckbereich";
[...]
We could also recommend to use Fl_Abstract_Printer::, but this class
is not officially used by end users/developers (although documented).
Questions:
(1) is there a better way to achieve platform transparency for these
string localizations ?
(2) Would this be an acceptable way to go ?
Please give your opinions and thoughts. I volunteer to do the changes
if the feedback is positive [in fact, it's almost ready to commit].
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
