STR #3295: fluid -c is running GUI code (again), bad for headless operation

STR #3295

Application:	FLTK Library
Status:	2 - Closed w/o Resolution
Priority:	2 - Low, e.g. a documentation error or undocumented side-effect
Scope:	3 - Applies to all machines and operating systems
Subsystem:	FLUID
Summary:	fluid -c is running GUI code (again), bad for headless operation
Version:	1.3-current
Created By:	greg.ercolano
Assigned To:	greg.ercolano
Fix Version:	1.4-current
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

#1	greg.ercolano 11:17 Mar 21, 2016

fluid.patch
4k

#2	AlbrechtS 15:27 Mar 21, 2016

fix_redraw.diff
3k

Trouble Report Comments:

#1	greg.ercolano 10:32 Mar 21, 2016

'fluid -c' is intended to run in batch mode (console app) used by Makefiles to convert .fl -> .cxx/.h It should have no reason to be doing any GUI code, yet in main() we have these functions being called, even during -c, which is bad: fl_register_images(); make_main_window(); I believe this has been fixed then regressed several times over the years. Unless it's no longer avoidable (why?), main() should be rewritten in a way that clearly handles -c as a special case right at the top of main, with a clear warning not to put any GUI code above it, e.g. int main(..arg,argv..) { // NO CODE ABOVE THIS LINE // Leave this at the top of main()! // handle_c_flag(argc,argv); // handle batch mode 'fluid -c' w/out GUI init ..the rest of fluid's main goes here.. }

#2	greg.ercolano 11:17 Mar 21, 2016

Bleh -- I guess this sort of thing is why: (gdb) where #0 0x000000000040e38a in Fl_Widget::type (this=0x0) at ../FL/Fl_Widget.H:274 #1 0x0000000000451054 in Fl_Widget::damage (this=0x0, fl=128 '\200') at Fl.cxx:1828 #2 0x0000000000450979 in Fl_Widget::redraw (this=0x0) at Fl.cxx:1767 #3 0x0000000000416d83 in Fl_Type::add (this=0x77ba00, p=0x0) at Fl_Type.cxx:609 #4 0x0000000000408c40 in Fl_Function_Type::make (this=0x764d20) at Fl_Function_Type.cxx:126 #5 0x000000000043bdd4 in Fl_Type_make (tn=0x77b950 "Function") at factory.cxx:1095 #6 0x000000000043df7a in read_children (p=0x0, paste=0) at file.cxx:453 #7 0x000000000043e1ed in read_file (filename=0x7fffffffe697 "fast_slow.fl", merge=0) at file.cxx:498 #8 0x0000000000442935 in handle_csu_flags (argc=3, argv=0x7fffffffe3c8) at fluid.cxx:1747 #9 0x0000000000442a01 in main (argc=3, argv=0x7fffffffe3c8) at fluid.cxx:1771 Here just loading an .fl file apparently tries to create widgets, which implies a GUI is needed. Is this true? Afraid I don't grok fluid, but I thought it was designed with batch mode generation in mind. Can this sort of thing be prevented? Assuming it /can/ be prevented, providing a preliminary patch showing at least how to isolate fluid's batch mode code from the rest, so never the two shall mix.

#3	AlbrechtS 15:27 Mar 21, 2016

Greg, the only thing I know that was always a goal was that fluid would not open the display. Recently it did in the porting branch, and somehow Manolo fixed it. In the regular branch-1.3 fluid does not open the display (under Linux). You might want to set a breakpoint on fl_open_display() or add a printf() statement to see if this is also true for other platforms. My test under Linux is simply to `unset DISPLAY', then run a fresh build. You would see an error message like this one: $ xeyes Error: Can't open display: if fluid opened the display. In my test it doesn't. BTW, building FLTK in the current porting branch *does* open the display (again): ... Generating fast_slow.cxx and header from fast_slow.fl... Can't open display: make[1]: *** [fast_slow.cxx] Error 1 make: *** [all] Error 1 Back to branch-1.3 and your patch: I didn't really test or review it, but I agree that it would be useful to separate batch mode better from GUI mode. However, there are "GUI statements" intermixed in code that is also used in batch mode, particularly calling redraw() as can be seen in your stack trace. I did a quick check by running `fluid -c fast_slow.fl` in the debugger and I attach fix_redraw.diff that prevents calling redraw() in this particular case. Maybe I missed something else, and maybe there's a better way, but at least it "fixes" calling redraw() in 'fluid -c' for this case. Whether this is useful I don't know though, but it can't be wrong. Anyway, since this is not a bug that needs to be fixed right now (IMHO) I suggest that we move it to FLTK 1.4 (and take a deeper look at it in the new porting branch so we don't need to do the patch twice).

#4	AlbrechtS 15:41 Mar 21, 2016

Note: it's probably a better idea to fix redraw_browser() in fluid/Fl_Type.cxx, at about line no. 452: void redraw_browser() { if (!batch_mode) // add this line widget_browser->redraw(); } and replace all(?) other occurrences of: widget_browser->redraw(); with: redraw_browser(); if that is what we need (avoid calling redraw()). But that's maybe not all we need to change if we really don't want to call any GUI code.

#5	greg.ercolano 18:13 Mar 21, 2016

Thanks for the patch. I applied it, but 'fluid -c' is still invoking e.g. damage() calls. But it's true it's not actually round tripping to the window manager; when DISPLAY is unset it runs OK, and on OSX no flickers in the window mgr. I'm not quite sure of the design philosophy behind fluid when it comes to its use of FLTK widgets when converting .fl files -> .cxx/.h in batch mode. It seems to actively use them, as redraw()/damage()/etc are being called, but I guess without the windows mapped, the widgets don't actually do any GUI interaction. Fluid's main() calls these two methods even during batch mode, which gave me additional concern: fl_register_images(); make_main_window(); So I take it fluid knows /for sure/ nothing is mapped when widgets are created, it's only when Fl::check() or Fl::run() gets cpu. On other words, make_main_window() is safe to call in batch mode up until someone calls Fl::check() or Fl::run(). So perhaps this STR is a non-issue; just because redraw() and damage() are being called doesn't mean the window manager is being used? If so, I'll close this..

#6	AlbrechtS 04:20 May 01, 2018

Greg wrote: > perhaps this STR is a non-issue; just because redraw() and damage() > are being called doesn't mean the window manager is being used? > If so, I'll close this.." Yes, please. We should close this STR. I just double-checked that the display is not opened when fluid -c and/or fluid -u are executed with a fresh build of FLTK 1.3-svn and 1.4-svn. This is all we need.

#7	greg.ercolano 16:03 May 01, 2018

OK - closing. Gotta admit I'd feel safer with /something/ like the patch to give a clear dividing line in fluid's code, as this seems to pop up from time to time for various reasons. For instance: a future change to fl_register_images() might cause a round-trip to the window manager. I recall many professional applications (Maya and Nuke) ran into this unwittingly on Macs, as they ran QuickTime library initialization routines on startup (similar in function to fl_register_images) that interrogated details about the graphics card, causing nasty crashes when the tools were run in headless contexts (ssh/rsh).