On 27.05.2011, at 21:08, anon wrote: > > I will later. I have an actual gui class providing my app a specific API so > that the class can be reimplemented to use any toolkit. > > I have done basic tests with FileChooser and unless it provides API to strip > it from unnecessary widgets (everything beside the actual file/dir > structure/tree) and also embed it inside a Window than it won't fir my needs. > > I've now sat down to look in the APIs to see if it does provide said APIs, > but it would be nice to hear what's your recommendation on this: does it > provide functionality for my aforementioned needs (two-paned audio player) or > should I keep examining FileBrowser + other parts of FLTK ?
I have not used FLTK 2 in a long while, so I may be wrong. But my memory tells me this: FileBrowser is pretty mighty. You have so many options that the easy access is somewhat blocked. You can use two FIleBorwser widgets an limit the left one to show only directories while the right one can probably be limited to files, using the type() and.or using filename filters. Other than that, the browsers are hierarchies of widgets and are accesses that way. When one item is clicked, IIRC you get a callback and can use something like "last_clicked()" or similar to find the trigger widget. That widget has a label that corresponds to that part of the path. Add the Browser's director in front, and you have your file path. The same should be true for the sound file browser. Whenever the user clicks a path on the left, recalculate the file path and tell the right browser to refresh. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
