On 13/07/2012 16:26, Matthias Melcher wrote: >> as it used to in fltk-1.1 if _() was set as a gettext function. Is that a >> regression/bug or did something change in fltk-1.3? >> Also in fltk-1.3 there is newly an additional widget constructor generated >> which uses w() and h() and label from fluid entries, this constructor would >> be very >> useful, unfortunately it disregards internalization settings too... >> Shall I fill an STR? > > Well, in C++ there is no predefined order in which static variables are > initialized. Both, MenuItems and i18n use static initialization. So it used > to be a hit-or-miss situation if menu items were internationalized or not. > This is why i18n for menu items must be done manually to be reliable (IIRC, > we have added a function for just that somewhere - but I don't know where > anymore). >
I do not think so. You static menu calls _() as a regular function before program enters main(), and initialization fiasco of _() can easily be avoided if (either if it only calls another init-correct functions or uses variables defined before in the same compilation unit). The situation with menus is no different than for instance initialization of constant strings const char * my_string = _("Some internationalised text"); which is used in C++ programs all the time. The only problem which could arise is that this static menu is used before main() uninitialized. However this menu is private and could be used only by other fluid-generated function. Do not forget that the name of the menu is is normally "not known" as it is generated automatically (to avoiding name collisions) BEFORE its use in the widget responsible for its generation. If you name a menu item, fluid generates something like Fl_Menu_Item* My_Class::menu_item_name = My_Class::private_menu_name + 0; AFTER My_Class::menu definition, so again the item is already initialised (C++ assures that) All that means that I do not see any possibility to use the menu uninitialized - at least not without an effort and ugly hacks like looking at generated private name of the menu. Overall, I do not see any reason why fluid can not use gettext function to initialize that static menus. If the fluid does not translate menu items, the i18n feature in fluid is quite useless. Roman _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk