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
+1. > - built in tree widget (using groups and children) FLTK2 already has this as Browser. Was the second reason I chose to go with fltk2. > - UTF-8 (already in FLTK2) FLTK1.1's utf8 patches (at least the one I saw) are broken in subtle ways. FLTK2's utf8 is more solid. > - printing support +1 for doing this in 2.0 first as it has really good utf8 support, 1.1 should come later. -1 for doing this in 1.1 first as it means 2.0 will not get it, as Michael is the only FLTK developer in the group with expert printing knowledge. > - callbacks for member functions +1 for this in principle, but with Fluid this is not much of an issue. > - signals You mean a signal/slot mechanism? +3 for using the sigslot library (thread safe and nice api). +2 for doing it like Fox but without crazy enums and macros. +1 for doing it like Fox. -1 for doing it like Qt (ugly preprocessor). -2 for doing it like boost (not thread safe). > - abstraction of underlying OS libraries Huh? FLTK DirectX??? Nightmare to maintain. > - support for embedded systems, WindowsCE Isn't this already supported? ARM at least is, isn't it? > - plugin support from within FLTK Just rewrite it as scripting language. It should take me about 3-4 weeks to do. > - documentation via Doxygen Isn't that already being done? That should be part of the makefile and svn checkin, btw. > - built in scripting via Python -1 for Python. +1 for Ruby. And +1 for integrating this as part of the fltk distro as standard (any or even several scripting languages thru swig). This helps catch development bugs (and bad API design decisions) and makes it MUCH easier to develop new code/find bugs. BTW... the reason I prefer Ruby is that I can discuss at length the headaches a certain well known VFX company runs into for using Python (they are one of the oldest Python users and have one of the largest python codebases) and why those problems don't show up on Ruby. > - layout files generated via Fluid, interpreted at run time Scripting, please. Not another custom format. You guys are shooting yourselves in the foot by doing it otherwise. Advanced users, specially in vfx, require to have custom (and fast) control on their GUI experience. A scripting language nowadays is a must (blame Alias Maya MEL for that :). > - shaped windows (already in FLTK2) Only 1/2 done. Shape cannot be changed or animated after set. This limits its use quite a bit. > - plugin themes and styles +1. This is supposed to be there in 2.0 but it is severely broken on 2.0 and there's no test suite for it. > - typed drag and drop Not needed. You just need to do good marshaling, like YAML or worse, like XML. > additional widget stuff: > > - higher lever application support Like? > - direct support for communication like TCP/IP and serial ports -1. Tons of libs for this already exist. > - built in multimedia support (sound, video) +1 for sound as it is easy. 0 for video. While a nice idea... there are too many codecs, too many formats, several incompatible libs (libquicktime, ffmpeg, etc). Syncing of audio and video is a pretty nightmare once you want to start adding more stuff. A basic flipbook widget is not too hard to do, but it's probably not worth adding to the library. > - simple OS support (threading, pipes, locks, messaging) > -1 for all this. You WON'T be able to beat boost at this. Its design is perfect. > additional device support: > - plugin system for additional devices like tablets, 3D mice, > extended keyboards +1 > - built-in support for tablet PCs 1/2 done in FLTK2 already. > - screen drivers to support output to any kind of frame buffer -1 for this. Each driver needs to be manually written and adjusted. Any sort of framework is doomed to fail. > > OpenGL: > - built-in widget with full navigation > - maybe even a simple scene graph > -1 for this. Fox has all those already. While they are nice for EXTREMELY simple stuff, for most things they are a burden. There's better scene graph navigation libraries out there than Fox or FLTK will ever be able to provide and most games have special requirements on their scene graphs. ========= I'll add my own now: The basics: - docking+floating windows and toolbar widget. There's a simple one out there available for fltk2 (and several bad and buggy ones for fltk1). But this needs standarization asap, as it is a standard feature on all widget toolkits. - Icon support. FLTK's icon support is pitiful or non-existant. Changing a window's icon requires writing platform specific code, which is silly. Today's applications are used to being able to update icons on the fly, too, not just on startup. Fox handling of this is SO much elegant. - Better file requester. The one in FLTK right now is butt ugly, even by Windows standards. The basic FLTK file requester should mimic the window's standard file requester (functionality wise at least), allowing users to create folders, rename files, delete them, multiselect them, drag them, draw selection boxes, sort by dates, show icons, etc. See Fox for an example of this almost fully done. GTK/KDE do it even better. ===== - variables callbacks like Fox. This is a special form of signal/slot link that links an actual C++ variable to several widgets. The idea and api of this in Fox is great. The implementation of it is not very speedy thou. - Integrated HTML/.chm/.man viewer. Bring the somewhat deceased Dillo as an optional HTML viewer widget? - Optional YAML marshalling widget. Scripting languages give you this for free, but it could also be good to have it in C++ natively. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
