On 17.01.2009, at 11:24, Fabien Costantini wrote: > IMHO, a safer approach would be to let Fl_Browser untouched > concerning API backward compatibility. > It may cost us a major rewrite of new tree browser API ; but we > will benefit of much less regression bugs, much more flexibility and > freedom for new tree api specification that would be more > independent from the Fl_Browser code. > I like the flu approach and functionalities but frankly, I would not > like to embark such code in fltk (just review the flu internals!). > We should write it from scratch but based on a solid _minimum_ yet > complete specification.
Yes, I agree. I would like to try to avoid code doubeling: a widget hierarchy is already, well, a hierarchy. So a hierarchical (tree) browser should simply be a widget tree, and not a special Browser implementation which doubles yet another hierarchy (the same is wrong with the Fl_Menu_Item array aproach, but that is a different story). Oh, and that does of course not keep us from creating an API that is simple and somewhat like the Fl_Browser one. Matthias ---- http://robowerk.com/ _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
