Poll #7

  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Show All Polls | Show Comments | Submit Comment ]

Poll #7

What kind of filenames should fl_file_chooser() return?
Relative filenames only 28 / 3%
Absolute filenames only 67 / 8%
Relative by default, optionally Absolute 267 / 35%
Absolute by default, optionally Relative 349 / 46%
I don't care at all 45 / 5%
756 total votes.

User Comments

Submit Comment ]

From Anonymous, 13: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, 23: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, 16: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 ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2015 by Bill Spitzak and others. This project is hosted by Seriss Corporation. Please report site problems to 'erco@seriss.com'.