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. Separation of low-level "core" from the api is nice, but there is lot of interconnections which will break the things in one (or both) api's. And there are also differences like relative/absolute drawing code and event delivery. I am afraid that this will lead to long-time broken code with people frustrated to work with and they will be returning back to the good-old stable 1.1.x. Maybe it will sound arrogant, but if there is easy possibility to make two compatible different api interfaces, it is usually just a syntactic sugar and it is worth to keep them both ONLY for compatibility reasons (not to break old code). The real differences which are worth something are usually very difficult to keep compatible. 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.
So my vote would be to keep evolution of 1.3 with improvements to the api also borrowing (read:stealing) from 2.0 and gradually cleaning the code: graphics abstraction, cleaning image classes etc. And another reason is that it is a lot of work and... people are busy, and there are not so many fltk developers. So if the development is stalled but the code is not broken, thats fine: release new version with only a few additions and/or fixes and people will still be happy. 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. R. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
