> > 1. When you create a window, the properties window will > appear on the top left corner of the desktop without the title bar, > > making the window unmovable. > > Yes, I saw that when I finally tested on MS Windows. I was > very surprised and I wonder if 1.3 does that, too. Or if it > is specific to FLTK compiled with one IDE?
Hmm, interesting. Testing on WinXP with mingw (old gcc 3.4.x version) shows this effect. I initially thought this was peculiar to fltk3, but in testing I see it also happens with fltk-1.3 too. Fltk-1.1 seems to be fine. What is *really* odd is that with fltk-1.3 the behaviour is not consistent; sometimes it works OK, and I'm not sure why that should be. Also, fltk3 and fltk-1.3 do show slightly different "wrong" behaviours. Try this: - for_each fluid in (1.1, 1.3, 3) - open print_panel.fl - show the print_panel window -- on fltk1.3 and fltk3 this shows the print_panel window borderless, whereas 1.1 shows it with a border. - in the print_panel window, double-click on the "Print" button to bring up its properties -- on fltk1.1 and 1.3 the properties window has a border. On fltk3 it is borderless... This sequence appears to be reproducible consistently in my tests here. Note that, in this case, fltk-1.3 has shown the properties window with a border - yet in the more general case it shows the properties window without a border. This is very strange, I think. Indeed, I find that with fltk-1.3, depending on what order I click on widgets in fluids browser I can sometimes observe either behaviour for a given input .fl file, whereas fltk-1.1 seems to be always OK and fltk3 seems to be always broken... Though once fltk-1.3 is broken, it "stays" broken until I quit and restart it, whereas once I shows a "good" properties window it tends to stay "fixed". I hazard that there's an initialization issue - something is not setting a root or parent correctly or something, and once it is "set" it either stays broken or stays fixed... Wild guess... > > 2. If compiled with gcc version 4.5.0 with the default > configure, any executable would not run, complaining about > missing gcc or g++ > > runtime dlls. This is easily fixed with > > > > LDFLAGS='-static-libgcc -static-libstdc++' ./configure > > > > but is annoying nevertheless. > > Again, is this also the case in 1.3? I have not really > changed any Makefiles (I think), and definitely not configure.in. This is a gcc/mingw thing - see Albrecht's post. If we stick with older gcc versions, this problem does not appear, but it will affect "everyone", not just fltk, when moving up to gcc 4.5.x at some point. If I understand the issue (I really don't) then if we don't want to propagate exceptions to DLL's, maybe we just don't care and can link static, and I think that's pretty much what the gcc 3.x mingw does... But... -- Ian SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
