matthiasm wrote:
>
> Adding to my previous mail, here are a few features I would like to see
> in the next FLTK:
>
> - built in table widget
> - built in tree widget (using groups and children)
> - fully featured multi-column browser
These can be add-on widgets, added to the FLTK when matured.
> - printing support
+ For me this is a MUST. I have played with cairo implementation and
that is an easiest route not only for printing but also for porting to
other platforms (where cairo is implemented). I have already working
patches for fltk-1.1.8 tree with exception of images (which should be
properly cached using surfaces to speed up drawing if transformation is
applied) Need also to implement better font caching (which for now uses
"toy" api and internal caching for 256 font/transformation combinations)
Stay tuned...
> - callbacks for member functions
> - signals
again, these can be easily done as add-ons. You will end up with
templated wrappers anyway - for that I am using Fl_Signal library. There
is no need to add templates to the fltk core.
> - menu structures based on groups and children (already in FLTK2)
+ .. that would be nice, as long as we can assure source compatibility
> - abstraction of underlying OS libraries
not sure what in particular you have in mind, you would be reinventing
the wheel - there are lot of projects which already do that. It would
require lot of work (otherwise wrapping existing libraries with fl_
prefix or fltk:: namespace would be silly...)
> - support for embedded systems, WindowsCE
> - modularization of additional feature groups
> - plugin support from within FLTK
what do you mean - some wrappers to dlopen() & friends or use in fluid?
> - documentation via Doxygen
++++
> - built in scripting via Python
Although I like Python, we do not want to make fltk dependent on it.
Python bindings and optional scripting should be (and are) separate
projects.
> - shaped windows (already in FLTK2)
why not, can be added at any time...
> - labels containing images (already in FLTK2)
This can be also done at any time. We can have some generic simple
hashing mechanism used for registration not only symbols, images (and
other drawing functions) to be included in labels using "@". In other
places hashing could be used for registration of other things, functions
boxtypes etc.
> - plugin themes and styles
I am more in favor of overloading widget functions so that they can
accept not only values but also pointers, like:
Fl_Widget::labelsize(int s);
Fl_Widget::Labelsize(const int *);
and an union{int labelsize_; const int * labelsize_p_;} inside widget
structure for these (with a bit within some flags indicating what it is)
This is simple to implement, allows global control, by default it would
point to some members of global style structure. Even widget labels
could accept double dereferencing (like additional method
Fl_Widget::label(const char * *) which would allow easy global
internationalization of the application.
Highlighting also would be nice which is now a standard feature of other
toolkits.
>
> additional widget stuff:
>
> - higher lever application support
??
> - direct support for communication like TCP/IP and serial ports
no, this should be third party libs again...
> - built in multimedia support (sound, video)
> - simple OS support (threading, pipes, locks, messaging)
> - maybe even a simple scene graph
the same as above... After implementing scene graph people would start
to bother you wanting additional features, import/export etc. Thats what
OpenSceneGraph & others are for. Anyway for simple things it is usually
easier to write some direct code and call gl+glu(+glut) api than
implementing it in some high-level scenegraph.
Roman
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
