On 20.06.2008, at 16:32, Roman Kantor wrote: > In theory it sounds good, but I am not convinced it will lead to any > real-life usable product in foreseeable future. When you start merging > these two, you will introduce lot of bugs.
I would like to find out if that is true. It may very well be, but it is worth a try, right? > And there are also differences like relative/absolute drawing code and > event delivery. We can set a flag that will decide if a widget uses relative or absolute coordinates and set the offset just before calling Widget::draw(). No other changes needed. > I am afraid that this will lead to long-time broken code We must not have broken code. If we do, we end up in yet another FLTK2 hell. We must use correct branching in the SVN and only merge back when a functional elemnt is complete and tested in both compat layers. > And think about fluid, which depends a lot on many api tricks and will > break instantly (and I fear will be dead for good) in a case of a > merge. Which brings us to regression test application number one ;-) > So my vote would be to keep evolution of 1.3 (...) > And another reason is that it is a lot of work (...) > But that is just my selfish opinion, I have some code (cca 100k lines) > depending on fltk1 and need to keep it working and having it > production-ready more less all the time. And I care more about > practical > features like utf-8, printing etc than having the best api in the > word. Fair enough. I just might give this a try with a few essential files and see how it works. If we can do this in reasonable time, we will have double the developer power after the break. ---- http://robowerk.com/ _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
