| [ Show All Polls | Show Comments | Submit Comment ]
Poll #7
| 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. |
This poll is closed.
[ 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 ]
|
| |