Static menus and gettext issue

[Gonzalo Garramuño]

Currently, static menus are created with Fl_Menu_Item, like:

Fl_Menu_Item ViewerUI::menu_uiWindows[] = {
 {_("Reels"), 0,  (Fl_Callback*)ViewerUI::cb_Reels, 0, 0,
(uchar)FL_NORMAL_LABEL, 0, 14, 0},
 {_("Media Info"), 0,  (Fl_Callback*)ViewerUI::cb_Media, 0, 0,
(uchar)FL_NORMAL_LABEL, 0, 14, 0},
 };

Then, gettext is run on the menus, like this:

          { Fl_Menu_Item* o = &menu_uiWindows[0];
            o->label(gettext(o->label()));
          }

The problem is that this modifies the original menu entry, as it is
modified thru a pointer.  Ideally we would like a o->copy_label() call
but Fl_Menu_Item does not provide one. Another approach would be if the
menus would get add()ed like: uiWindows->add( menu_uiWindows[0][0] );
(and the other flags).

The issue I ran into is when the menus need to be recreated, like when
the UI changes language on the fly while the application is running. 
The menus don't get recreated properly, as they contain the other
language, no longer the original language (English).

I can open a github issue for this, if you so desire (Matthias).

[Gonzalo Garramuño]

El 20/3/22 a las 18:28, Gonzalo Garramuño escribió:

> I can open a github issue for this, if you so desire (Matthias).

I opened a new issue on github.  Issue #417.

[melcher....@googlemail.com]

Well, we have two different ways to create menus. One is through static arrays, which Fluid uses, and which is indeed modifying the original menu array. This is not ideal, but it was a design decision made 30 or so years ago. You can of course build your menus with the add() command and assign labels dynamically, but FLTK will again store everything menu related in arrays. We have discussed at length on how and when the menu code deallocates labels, and when the user needs to do it. 

To make things worse, users can create custom label type that hold and icon *and* a label, or whatever they come up with. Deallocating those would crash the app. The compromise is, that generally the user has to deallocate labels, unless the system can be absolutely sure that it also allocated the label. Better to have a memory leak than a crash.

We can't change the menu API without loosing compatibility. We could add a second menu system, based on widgets, but that would double code that wants to be maintained and confuses users.

Sorry for the long reply, but I don't really know how to solve this for you. Generally, changing language while an app is running, is not something that is needed very often. Most existing apps (including non-FLTK) simply ask the user to restart the app to use the new language. Arduino IDE does it, for example, many apps don't even offer that. Heck, even Tesla cars reboot the entertainment system when the user changes languages.

 -Matthias