Yes I think it is a top design priority that namespace pollution be avoided if at all possible.
I would think any fltk call to bring up the native file chooser would not require any namespace pollution. Surely the entire implementation can be hidden in the C++ file with nothing in the header file, right? Greg Ercolano wrote: > 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
