My conservative view: On 12/07/2011 12:29, Piotr Beling [qwak] wrote:
> > We will also have new C++ (0x) standard which gives in my opinion new > possibilities in constructing API. -1 Please don't. It will take years when all/most compilers will support that new features properly. > > That is why, I think that next FLTK should have new, much modern API, > attractive to developers for long time in future (still having reasonable > fast, light > engine which not duplicate nothing from standard library) which: > - using namespaces (like FLTK2) +0 non essential for me > - using relative coords and canvas abstraction for drawing/printing/etc. -1 for 1.x compatibility reasons. Most real application use a lot of custom widgets with custom draw() and handle(). This would break them badly. And fl_translate(x(), y()); before drawing code will do the job most of the time - as long as all drawing primitives obey the transformation. > - using std::string or even std::u32string -0.5 Strings are nice for resizable buffers but its misuse where (const)char* is perfectly adequate annoys me a bit. I would not mind to use them internally for dynamic buffers but I would keep "char *" in the api. > - allows to use C++0x lambdas as call-backs -1 for the same reason as above > - using STL or some its concepts (for example iterators and begin/end to > allow use new C++0x for loop and STL algorithms) -1 - my personal distaste of some parts of poluted STL api. Dont get me wrong, I like templates and I am using them quite a lot in my code. But for the graphics library I like the the approach that fltk might not even require linking to libstdc++. Also once you start to use templates, you will have a lot of problems with bindings to other languages. I thing that the ultimate goal could be a "C" wrapper for fltk. Paradoxically the easiest approach for c api is a use of a general template which you apply to subclass each class with function hooks to create(), and destroy() and additional function pointers to virtual function wrappers. Once you have a wrapper for c, most scripting lanugages have hooks to C and further bindings are more-less automatic. Having modern API does not mean to use all available features of c++. What I have always liked about fltk (at least in 1.x) is that it uses common types "int", char* (as opposed to QString, FooLibraryInt ...) which everybody is familiar with so you do not need to investigate what kind of animals they are and how do they behave. This and minimalistic approach makes fltk so easy to learn. R. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
