> Stan, in an attempt to bring closure to this thread, > if you think my response below will help, let me know > and I'll submit an STR. > ... > > > > Maybe each widget should have special sections for Colors, > > Fonts, Events.. anything where the behavior goes off from > > what one might otherwise expect. > >
Yes, certainly it would help. Apparently (judging by matt's comments in this thread) the situation is complicated by the fact that some Widgets in the library are, shall we charitably say, "idiosyncratic?" Perhaps laying out the documentation in the way you suggest would encourage developers to think about fact that every class in the library is implementing a fairly fat (50 plus public method in Fl_Widget alone, as I recall) interface. This is especially problematic for widgets composed from two or more other widgets, for obvious reasons. One area of special importance is what events each class consumes. For instance, one that eats KEYUP events will have a significant impact on keyboard navigation (sidebar: it would have been nice to know that from the docs, rather than from spending a morning digesting the code for Fl:Group::handle()). In any case, as a developer, I wish I could find out by reading the docs rather than through experimentation or inspection of the source code. Another hazy area is what the various WHEN conditions mean for any particular widget. Again, this is particularly problematic for "compound" widgets. Finally, for each settable attribute for each class, it would be helpful to know what (if any) is the default value. The thing is, the documentation acts as a specification. Absent thorough documentation the implementation is the specification.. the library "does what it does." Hope it helps, Stan _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
