rlseal <[EMAIL PROTECTED]> writes: > > Ugh, I wonder if the above reasoning results in too much copied code/multi > > inheritance type conditions. > > > > > This is the whole problem. You are not refreshing a label every 7 > milliseconds - you're not running a label in a tight loop several > thousand iterations long, etc.. . The whole point of using C++ is to > make use of object-oriented concepts and the standard library. I > understand the concept of fast and light, but there is always a > trade-off when making something standard, readable, and maintainable. > There should be unit testing for each of the classes developed along > with some timing and size information included if it's that big of a > deal. Then we could fight over 1.42 usec vs. 1.44 usec and 16 bytes vs. > 18 bytes, etc...
I'm not exactly sure whatthis has to do with c++ itself. The biggest issue I have with fltk is how difficult it can be to lay things out. I use GUI builders for prototyping only since GUI builders fall totally flat on their faces when it comes time to refactor/reshuffle the whole deal (same complaint I have about these object diagram tools). One negative of the embedded labels as they are now is that they have potentially somewhat independent geometry compared with the widgets they are attached to. This is most evident when the fltk::ALIGN_INSIDE flag is not set. However right now there's nothing stop users from creating fltk::Widget objects specifically as labels only and using them as standalone labels. At first quick glance this is potentially non orthogonal behavior for fltk::Widget. I find the most elegant designs end up falling out with the best performance. First and foremost should be to establish orthogonal policies that make sense. The more truly modular and pluggable classes are the easier they are to test & debug. _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
