[ Show All Polls | Show Comments | Submit Comment ]
This poll is closed.
|What kind of filenames should fl_file_chooser() return?|
|Relative filenames only|| 29 / 3%|
|Absolute filenames only|| 67 / 8%|
|Relative by default, optionally Absolute|| 268 / 35%|
|Absolute by default, optionally Relative|| 350 / 46%|
|I don't care at all|| 45 / 5%|
|759 total votes.|
[ Submit Comment ]
From Anonymous, 10:41 Jan 03, 2003 (score=1)
I think an abstraction layer should be added here to encpsulate the platform's idea of how paths are represented. I don't like having to test for the current path separator aso into my application. More generally, i think a sub-library to provide a minimal amountof portable access to the underlying platfom's services would be a great thing (should at least provide the above, and maybe threading?).
[ Reply ]
From Anonymous, 20:45 Jan 08, 2003 (score=4)
Considering the poll on the STL response I think platform services should be implemented in a way that allows the standard (STL) replacements (if any) be used instead/when needed. For example: if boost::thread was added to C++0x you would have to deprecate your implementation to fully use the (new)STL. My personal preference is to leave fltk as a windowing library, that is what it is best at. Some platform services would be nice :) e.g. optional db controls (SPTK)
[ Reply ]
From Anonymous, 13:34 Jan 17, 2003 (score=1)
Then the file chooser design is wrong, as it *already* provides a platform service ! I still think (i posted the first comment) that as long as you provide some sort of platform-dependent service you must provide an abstraction for it (think, this is what exactly fltk is ! why not do things in a consistent way?) The file chooser is an aggregate of two things, the UI itself, and the OS path. The seoncd of theem is not implemented in a really portable way. Anyone agreeing with me ?
[ Reply ]