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.
My 2 cents, Fabien. > Greg wrote: > > matthiasm wrote: > > On 15.01.2009, at 15:00, Eric Sokolowsky wrote: > >> Will FLTK 1.3 have a built-in hierarchical browser such as that in 2.0? > >> I am using FLTK 1.1.x with a browser from the FLU widget set for my > >> application, and I would prefer not to use that browser in the future. > > > > Yes, the hierarchical browser is one of the key features for the 1.3 > > release. We had some discussions on the API a while ago and are likely > > to implement the browser as a widget hierarchy. Details will follow as > > soon as we have reduced to bug ist a bit more. > > Is this to be a 'tree' widget? (kinda like fluid's code browser) > > I just want to make sure Fl_Browser isn't changing in any large way, > as I like it just the way it is ;) _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
