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
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk