> Fabien Costantini wrote: > > I'd suggest to always favorize the content than the form though I also > > understand that a proper form will make more easy the documentation reading. > > Yes, I know what you mean. > > Though to a new user, a lot of things are important, such as getting > an initial 'feel' for each widget's way of working. Code examples can > help that, and I think consistent form will give the reader the added > "warm and fuzzies" that there's some consistency to the docs; Totally true, and since the beginning of your participation, I clearly encourage such pratices. There's not such thing as a good example to clarify things. grealy >documentation > features they see in one widget they'll probably expect from others. > > I'm going to try focusing on the widgets that I know have been > historically > thin or too terse. Probably going to be a long process that will reach > beyond 1.3.x's release date.. which should be fine. > > I know for 1.3.x to go out, we mainly want to get the code stable, > so I figure that's what you guys are all on top of. Any kind of help is fully appreciated Greg ;-) That said, yes we should IMHO stop fancy modifications/improvements and focus exclusively on bug fixes asap.
We all like adding/improving features, and this is important that each and every one in the team can find an opportunity to do so ; afterall this is the least that a coredev deserves as a counterpart for so many everyday unfair maintanance tasks, but still what should be probably done now is focusing on a release. FLTK2 development history teached us a lesson of humility, IMHO: We should be happy of all that was already done in 1.3 ! Fabien _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
