I agree that a new class is probably the way to do this. It can be made compatible somewhat, so that you *may* be able to use it in your existing program by changing the class name, but if you use the old name back-compatibility is preserved.
Some things like the first item having index 1 instead of zero are impossible to fix and remain compatible. This probably should be done for the menus as well. Internally ideally the "old" one can be implemented by the "new" one doing all the work by translating any api. There was significant work done in 2.0 for this that should be looked at but being able to ignore 1.0 compatibility matthiasm wrote: > > 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
