> > On 11.01.2011, at 10:21, MacArthur, Ian (SELEX GALILEO, UK) wrote: > > One for Manolo I guess. Though... There is the bigger question of > > whether Fl_X should be exposed or not. > >=20 > > What do folk think?=20 > >=20 > > I don't know - I'd guess not, for "safety" reasons, but there are some > > advantages, too... > > This is bad. The xid should be available to the user.
Isn't the fl_xid(const Fl_Window*) function (documented in the OS issues section) enough ? > In the original code, including any header except "FL/x.H" would not > load (or "try not to load") anything specific to the underlying OS. > However including "FL/x.H" (and *NOT* "FL/mac.H" or "FL/win32.H", > these are included automatically when using x.H!) would open up > access to the system resources. The new setup requires, under Mac OS for now, to define FL_LIBRARY for FL/x.H to give full access to what's OS-specific. Without FL_LIBRARY, there's access only to what's documented (e.g., fl_gc, fl_xid()). The benefit of that is to allow for a completely OS-independant compilation of application programs, many of which include FL/x.H. The drawback is the requirement to define FL_LIBRARY to get full access to the OS-specific part of FLTK. This has been done in reply to a user's request to compile application programs with non Apple compilers on Mac OS. The use of non Apple compilers on Mac OS is probably a very marginal situation. But, the concept of OS-independent compilation of FLTK applications seems interesting to me. It's very possible to return to the previous setup, though, if that's preferred. > first_window, btw., is a static member of Fl_Window in FLTK2 (or > rather fltk::Window). I find that a good idea. Isn't Fl::first_window(void) just as good ? _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
