Albrecht Schlosser wrote: > Fl_Double_Window, since the current file chooser window is > Fl_Double_Window.
obviously... > > Generally, I think that's not a bad idea, but I'm afraid that this > wouldn't work without changing the API. There's at least one conflicting > method together with its overloaded forms: > > int Fl_File_Chooser::type() and > void Fl_File_Chooser::type(int). Yeh, in the mean time I have realised this too and there are other two functions which have completely different meaning: color(); iconize(); so I have also changed my mind an I am building my own chooser instead. Unfortunately Fl_File_Chooser in its recent form is useless for inheritance but maybe there could be a few things which would make people happy enough: 1) Make the window and the main widgets (filter, favorites, list, preview, prew_check, filename, newdir and OK/Cancel buttons) protected instead of private (some with better names) 2)Making additional "protected" (maybe even public?) constructor with widget-like parameters (int x, int y, int w, int h, const char * label = 0). This constructor would not call window->end() so the behaviour would be similar to the group and play nicely with fluid and you could either embed this browser in some parent or add additional widgets to it. R. _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
