> I just updated to the head of 1.3, and my app failed to compile,
> complaining that Fl_X was undefined. Looking at FL/mac.H, it looks
> like it's intentionally hidden when compiling against an application.
> Hiding system specific stuff seems like a good idea, but it looks like
> this is inconsistent with X11 and win32. And if Fl_X is meant to be
> hidden, documentation should be removed for it, and there should be
> some alternate way to write:
>
> int has_windows() { return Fl_X::first != NULL; }
>
> Otherwise, hiding Fl_X for the mac is probably an oversight and should be
> fixed.
>
This has been intentionally done following the request by a user
who wanted to compile application programs with a non-Apple compiler
that was unable to compile Apple headers.
Also, the system headers used by FLTK source files have been changed
from <Carbon/Carbon.h>
to <ApplicationServices/ApplicationServices.h>
to remove dependency from the Carbon library.
The new setup is:
- if FL_LIBRARY is defined, Apple system headers are included
by include <FL/x.H> and the Fl_X class is declared;
- if FL_LIBRARY is not defined, Apple system headers aren't included
and the Fl_X class is unknown.
Thus, FL_LIBRARY must be defined to compile the library
(this is done in the Xcode project and in make and CMake support
files). Application programs should normally by compiled without
defining FL_LIBRARY, unless they want to access the Fl_X class.
I don't see the Fl_X class documented in Doxygen. Am I wrong ?
You can write:
int has_windows() { return Fl::first_window() != NULL; }
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
