STR #2678

GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Post Text | Post File | Prev | Next ]

STR #2678

Application:FLTK Library
Status:5 - New
Priority:4 - High, e.g. key functionality not working
Scope:3 - Applies to all machines and operating systems
Subsystem:FLUID
Summary:internationalization (fluid)
Version:1.4-feature
Created By:parisse
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]

No files


Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
 
#1 parisse
00:05 Jul 14, 2011
Menu_Item labels are now printed without gettext() by the fluid compiler which prevents including them automatically inside the po files.
I have made a workaround on my own version of fltk by adding in fluid/Fl_Menu_Type.cxx ligne 245
    fprintf(stderr,"gettext(\"%s\");\n",((Fl_Menu_Item_Type*)q)->label());
then running fluid -c >& menus
and adding menus to POTFILE.in in the po directory of my software does the work.
 
 
#2 ianmacarthur
01:47 Jul 20, 2011
Do you have any botes of which versions do work / which version do not work, to help us pin down the regression?

Also, perhaps you could post a small example fluid file that can be used to elict the fault, to ease investigation?
 
 
#3 ianmacarthur
01:25 Aug 03, 2011
Is there any update on this error report?  
 
#4 matt
03:54 Sep 30, 2011
FLTK 1.3.x correctly allocates Fl_Menu_Item arrays without get text (if it *would* use get text here, your application would crash, because the get text system is not initialized yet!).

However, when the menu is loaded into the owner widget, Fluid generates code that runs gettext() then.

Please verify this. If it still does not work for you, please send me example code.

We need to update FLTK to 1.3.1. Please send your code within a week, or this bug will not be fixed in the next release. Thank you!
 
 
#5 parisse
04:45 Sep 30, 2011
Ok, I can see for example
      { Xcas_Page_format = new Fl_Menu_Button(10, 145, 165, 30, gettext("Print format"));
        Xcas_Page_format->tooltip(gettext("Printer page format"));
        Xcas_Page_format->textsize(10);
        Xcas_Page_format->align(Fl_Align(FL_ALIGN_CLIP));
        Xcas_Page_format->when(3);
        if (!menu_Xcas_Page_format_i18n_done) {
          int i=0;
          for ( ; i<5; i++)
            if (menu_Xcas_Page_format[i].label())
              menu_Xcas_Page_format[i].label(gettext(menu_Xcas_Page_format[i].label()));
          menu_Xcas_Page_format_i18n_done = 1;
        }
        Xcas_Page_format->menu(menu_Xcas_Page_format);
      } // Fl_Menu_Button* Xcas_Page_format
But it did not work before I added the initial gettext, otherwise I would not have commited a bug report. And I don't see why gettext would be more initialized in the loop than in the new, perhaps it depends on the system? I'm initializing gettext and setting the language before this object file is loaded, and it works OK for my application (a free computer algebra system named Xcas, the source code is http://www-fourier.ujf-grenoble.fr/~parisse/giac/giac_frozen.tgz, the relevant fluid file is giac-0.9.3/src/hist.fl).
Anyway, I had to do other modifications for EPS print format support, and a few other things, and unfortunately this forum is not reactive enough for my needs. Therefore I'll stay with my own modification of FLTK and won't try to make my changes upstream in the new FLTK versions.
 
 
#6 matt
05:41 Sep 30, 2011
I am sorry that we can't react faster at times. We are a tiny team.

Most developers have no influence on the order in which the global variables are instatiated. Having gettext called even before Main was called has lead to many crashes and frustrated developers. It would be nice to find out why the current implementation doesn't work for you.
 
 
#7 matt
05:43 Sep 30, 2011
What were the modifications needed for EPS? Maybe Manolo has time to add these to the core if they benefit all?  
 
#8 parisse
11:53 Sep 30, 2011
I don't remember, it's too old. The best is probably to get ftp://ftp-fourier.ujf-grenoble.fr/linux/xcas/freebsd/fltk-1.3.0/src/Fl_PostScript.cxx and compare. I also made the following comments for all the changes I had to make to get everything compile on Mac, cygwin and linux x86 and ARM *and* compile with my codebase.
FL/Fl_Input.H: line 266, changed from protected to public for draw()
FL/Fl_Device.H:#define FL_REGION_STACK_SIZE 100 instead of 10
src/gl_start.cxx: removed static line 58 for gl_choice
FL/Fl_Window.H: added public method   void * window_ref() const;
FL/Fl_Window.cxx: implemented as
void * Fl_Window::window_ref() const {
#ifdef __APPLE__
  return Fl_X::i(this)->window_ref();
#else
  return 0;
#endif
}
src/gl_draw.cxx: #define GL_DRAW_USES_TEXTURES  0 // (defined(__APPLE__) && !__p
pc__) // 1 only for non-PPC OSX
makeinclude: disable x64 using ARCHFLAGS        = -arch i386 # -arch x86_64

Various changes in Fl_Postscript.cxx to support encapsulated postscript,
changed driver() from protected to public in Fl_Postscript.H
 
 
#9 ianmacarthur
15:53 Mar 11, 2014
Is there any update or action on this STR?

It is several years old now with no reports or changes - should we close this or is it still needed?
 
 
#10 AlbrechtS
02:55 Sep 01, 2016
Bumped to 1.4-feature.

A fix in 1.3.4 would certainly break existing user code.
We hope we can find a better solution in FLTK 1.4.0.
 
 
#11 AlbrechtS
03:58 Sep 01, 2016
Set priority to 4 (high).

Please see STR #3289 for a summary of related STR's and further actions:
http://www.fltk.org/str.php?L3289
 
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2021 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.