In article <[EMAIL PROTECTED]>, matthiasm <[EMAIL PROTECTED]> wrote:
> Dynamic loading is very much needed for FLUID to allow easy > extensions. It is also useful for theme plugins, and maybe even for > drop-in-replacements of such controversial dialogs like the file > browser. Maybe dynamic linking should be part of the API? Maybe we can Yes, I would rather not implement "themes" in fltk directly - but that doesn't mean I don't support the idea. If you extend a bit the box types (so that you can query the box for spacings and minimal sizes) and allow dynamic loading of external box types, you get theme engines for *free* without actually slowing down anything. The are more than one reason to avoid bundling a package with more than a reasonable default and a _simple_ api: - unneeded complexity: theme engines tend to be complex and have bugs. - UI issues: as far as modern theme designers go, one application may not always be correct with another due to the extensive appearance changes. One may wish to develop his own theme engine specific to a single application only. This is pretty common for commercial apps. - there will be ALWAYS the need to some small changes in the theme engine, resulting eventually in a monster - GTK2 is a good example. Leave these issues for those who actually want a blinky application. - you can create a second community dedicated to theme development without interfering with FLTK (those grow very fast if you don't press too much for code quality). With dynamic loading, we could be done with a very simple api, a base theme (say gtk+ alike) and forget about it. Let's have a second package for theme engines instead with more frequent releases and less stringent standards. Or a public repository, even! (something like Haskell's Hackage which works very well). Having a portable dl() api is probably a byproduct :), like thread support in FLTK2. Many applications would benefit from this instead of relying on conditional-based code. It's not that difficult to implement either, as long as you don't throw C++'s OO into the mix. > add a broader Application support, just like we have optional image > library support. Image support is not something that will go off without control like themes, so I don't think its very important. I would prefer standard, good quality baseline format support here. Serious imaging applications need much more control over data, memory and format that you will never fulfill the requirements with FLTK. But yes, dynamic loading here would also help for those who want just basic viewing capabilities (I'm thinking of CoreImage support on OSX, for example). Widgets is the last area were dynamic loading would definitively help FLUID. I don't see other cases. > > I dream of an FLTK2 style api which works like wxWindows. > > Can you bundle your experiences with wxWidgets for us, so we > understand the differences and potential improvements to FLTK? Awful, like most other toolkits ;). wxWindows started with the very good premise of having native UI, the theory being that applications would be more friendly. The first mistake was using MFC-like event declarations, which makes wxWindows a mayor pain to use. I assume this was somewhat inherited by some developer with experience with MFC. The code is generally riddled with macros and is very hard to understand. The macros are so long to type and have so little flexibility that, unless you have a form editor, you waste most of your time writing those. The API itself is ugly, poorly though-of. FLTK1 looks like *much* more consistent in that respect. The second mistake was thinking that using the native widgets would work the same way in all the platforms. This is, of course, wrong. Some examples: tab navigation, event delivery order, refresh order, widget spacing and sizing, etc. Since having different behavior would lead to ugly portability issues, they patched most of them to behave in the same way. The result is that the application *looks* native, but it's not responding like a native application. Since patching a native widget has some limits, wxWindows application often have small issues, being graphical or behavioral. You always need to test your application on all the systems and perform some tests to be sure. This is why QT tries to imitate the look, but does _not_ use the native widgets. For these reasons you can always tell on win32 and OSX that wxWindows is being used. Third mistake: huge portability layer. This was done by almost every toolkit in existence. This results in bloated applications, mostly, because wxWindows's layer is tailored for wxWindows itself, so you eventually need another portable library to perform the same tasks in a more flexible manner. Take posix threading for example: I like FLTK's approach: minimal, _bare_ threading support (ie: mutexes). When I need portability, I just grab pthreads for win32 and instantly have full support, without duplication. Another consequence is abuse of FLTK code where it's not actually needed, for example just to be able to interface with FLTK itself. QT is a great example here: have you ever seen how application develop? First, they use QT for the guy, then they need to use qstring everywhere because of performance issues, type proliferation and whatever, then they need the entire QT-core library to compile everything. And they, finally, cannot use anything else, because mixing pthreadwin32 with QT's threads becomes almost impossible. Fourth mistake: performance. wxWindows is of course, even slower than QT. Having to layer the real widget is a reason, by I was also under the impression that their signaling mechanism was the culprit. I used a lot of widget sets, and abandoned them for many of these reasons. I want an usable GUI, fast, consistent, and light. Currently, FLTK is the only survivor. I was really fond of GTK1, for instance. But when they abandoned development (including patches) for GTK2, I could never stand a chance to fix the issues myself. So I will moan a lot before allowing you to force me to change again ;). _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
