Perhaps we could also allow defining FL_UNSTABLE or
FL_UNPORTABLE to get the OS-specific definitions then?
Oh yes, I can see that working, +1,
Some sort of FL_low_level_feature_here_be_dragons... option sounds
like a good idea, and we separate the Fl_X stuff from the FL_LIBRARY
option,
Michael Sweet wrote:
Perhaps we could also allow defining FL_UNSTABLE or FL_UNPORTABLE to get the
OS-specific definitions then?
Or FL_OS_SPECIFIC or FL_INTERNALS ?
Yes, something like that maybe.
Albrecht
___
fltk-dev mailing list
MacArthur, Ian (SELEX GALILEO, UK) wrote:
Some sort of FL_low_level_feature_here_be_dragons... option sounds
like a good idea, and we separate the Fl_X stuff from the FL_LIBRARY
option, resolving Albrecht's point.
Though if we are doing that, I guess we'd need to do it before 1.3.0
goes
I voted for hiding as well, and Manolo did it recently for X11, but
now I found out that we *have* some documentation for Fl_X in the
chapter Operating System Issues, section Using a Subclass of
Fl_Window for Special X Stuff. This is X11 only, and I guess only
hardcore X11 developers can
On Jan 13, 2011, at 2:11 AM, Albrecht Schlosser wrote:
On 11.01.2011 17:32, Michael Sweet wrote:
Otherwise, hiding Fl_X for the mac is probably an oversight
and should be fixed.
One for Manolo I guess. Though... There is the bigger question of
whether Fl_X should be exposed or not.
On 13.01.2011 21:40, Michael Sweet wrote:
Document the workaround (define FL_LIBRARY) and note that such code will
likely not be portable to future versions of FLTK.
That's a good idea, and I believe such a warning is in the docs anyway,
so we can surely go that route. OTOH, FL_LIBRARY is
I voted for hiding as well, and Manolo did it recently for X11, but
now I found out that we *have* some documentation for Fl_X in the
chapter Operating System Issues, section Using a Subclass of
Fl_Window for Special X Stuff. This is X11 only, and I guess only
hardcore X11 developers can
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
I don't see the Fl_X class documented in Doxygen. Am I wrong ?
I think you're right, I don't see it either. I'm not sure where I got
the idea to use it. It seems less likely to make portability if it's
consistently not exported for all OSes, but if it's not documented
then I suppose you can
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
On 11.01.2011 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.
What do folk think?
I'd say don't expose, because it's internal and can be changed.
If we really need to expose some of the
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.
What do folk think?
I don't know - I'd guess not, for safety reasons, but there are some
advantages, too...
This
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,
On 11.01.2011, at 14:58, Manolo Gouy wrote:
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 ?
first_window, btw., is a static member of Fl_Window in FLTK2 (or
rather fltk::Window). I find
What do folk think?
I'd say don't expose, because it's internal and can be changed.
If we really need to expose some of the internals that are not
available now, then we should write accessor methods that do it
in a defined way.
Except that we used to expose it on all hosts, and now
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 ?
I tend to agree, and that's what I've used in my code (where I have
needed this functionality) but it may still be a change that has side
On Jan 11, 2011, at 1:21 AM, MacArthur, Ian (SELEX GALILEO, UK) wrote:
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
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
18 matches
Mail list logo
