On 13.12.2009, at 12:24, manolo gouy wrote: >> FL/x.H is the correct header for this since this is a system specific = >> function. You can document that by adding a \note field in the doxygen = >> paragraph. > > There is some ambiguity here between where to put the prototype (mac.H > is my guess) and what include to ask the user (x.H which includes > mac.H). Am I correct ?
Yes. There are even marnings given out if the user includes mac.h instead of x.h . x.h should probably be named differently to reflect that it includes the system specific interface, but it was left this way for Forms compatibility. >> >> I will add your recent patches to the SVN now. > > Thanks. There is also the small src/Makefile patch Yep, got that too. >> >> *** Thanks for the continued great work *** > > As you can guess, I'm very keen to see this Cocoa port work. > I hope we won't hit a wall with the Fl_Native_File_Chooser bug in > Ian's app. It seems to be a tough bug, whereas all others were > simple to repair when looked closely. I use the native chooser > in my own app without error, so am very puzzled. Let's see what > Ian obtains after my suggested change (just of test for now). I would like to integrate the native file chooser into FLTK and make it an end user preference, unless explicitly required by the programmer. That way, maybe we can also port that to the corresponding Cocoa code? > By the way, I have also Cocoa-ized Fl_Native_File_Chooser, necessary > because the framework it uses is absent from 64-bit snow leopard > (though it is still in leopard), and I have sent that to Greg. > I remember that inclusion of Fl_Native_File_Chooser is in the > FLTK-1.3 roadmap. Did you decide when to include it in 1.3 ? Grin. I wrote the previous text block before reading this paragraph ;-). Yes, let's include the native file chooser code. We need two preference files: 1: a global preference should be introduced that decides if the user prefers the FLTK or the native file chooser. This could be the same file that decides if the preview is visible or not in the FLTK file chooser. 2: we should have a second preference that uses the executable filename to override the global setting for individual apps. This can be connected to the Fl_Window::show(argc, argv) call, which in turn triggers another long requested feature 3. 3: in the mailing list, there was a solution (or on Greg's cheat page) that provided a function call for finding the application name and the directory where the application resides (which is often not the same as the current directory). I have to stop. I a drifting off ;-) Matthias _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
