Yuri D'Elia wrote:
> I know Greg reads this newsgroup so I post this question here;
>
> Is it feasible to split Fl_Native_File_Chooser implementation in two
> parts, so that system headers such as "Carbon.h/win32.h" do not get
> included in the public header? (just like x.H/platform stuff is handled
> in FLTK 1.1).
>
> I have at least one project that suffers from namespace pollution under
> OSX when switching from FLTK's chooser to Fl_Native_File_Chooser.
I'm not sure the FLTK coding standards directly addresses the
issue of incidental OS namespace pollution.
I'm going to bounce this question to Mike; should users of FLTK
headers expect to be isolated from OS namespace requirements of headers
such as Carbon.H/win32.h?
I can see where a single effort put into isolating/wrapperizing
FLTK headers from the OS specific data in the public FLTK headers
would save app programmers from having to duplicate that effort
should they need it in their own apps.
I can probably make an 'underbar class' (Fl_Native_File_Chooser_.H)
that contains all the OS specific stuff, so that casual users
of the public class don't have to get a hit from the OS headers,
while users wanting access to OS specific 'advanced' features
of the class can #include the underbar class to gain access to it.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
