> I've been thinking this over a bit more. I have a couple of > folks that are c++ programming students. Perhaps I could make > use of them to get something going.
Well, it's all open source, so as long as you comply with the fltk license it's yours to play with. They do say a volunteer is worth 10 pressed men... > I guess there are a > couple of different ways to approach this. One would be to > take a similar approach to FLTK2 (fork and start from a FLTK1 > base). The second would be to develop a c++ api as an > optional library leaving the lower level intact and in c. The > latter would probably require a bit more effort to implement. But as has been pointed out elsewhere, abstracting the low-level and high-level layers opens up the prospect of having differing high-level API's on the same low-level codebase. That does sound like a better solution, rather than having yet another fltk-variant...! > Would there be any interest in such a beast? Probably. > I don't think I > would take the same approach as FLTK2 though. A couple of > examples would be to drop the namespace use in favor of a > class naming convention that is similar to FLTK1 Dropping namespaces is fine with me, although c++ zealots will not agree. I had a real bad experience with this, working with an "engineer" who was zealously c++ (but actually not a very good engineer) and a raged and flamed about using namespaces and templates and all that high-level good stuff, but his actual code was rubbish... Anyway, he was very inclined to just do the "using namespace xyz" thing in all his code, which to me completely negates any benefit of namespaces anyway, and we got into a nasty and embarrassing bug (with method names colliding) because of it, exactly the sort of thing namespaces are supposed to prevent. So... Since then, well, lets just say I'm not inclined to believe that namespaces are a solution to any real world problems at all. > and most > certainly an object oriented event handling mechanism. Hmm, not so sure. The fltk callback-based event handling and tree-walking event propagation technique is actually a very efficient and clever way to do this job. It's quite deeply in the foundations of the fltk core, so might be difficult to avoid. That said, providing it with a more OO wrapper is straightforward, as several of the add-on libs in the links pages show, and that could be worth doing. And would probably be easier for folk coming from other toolkits to get their heads around. > The > begin/end hocus pocus would probably be a casualty too. Again, I'd be inclined to keep that (albeit in the fltk-2 style where you need the explicit begin, rather than the fltk-1 implicit begin) as it is a fairly efficient way to group widgets into their parent containers. > A > minimalist c++ interface if you will. It would not be a > demonstration of c++ mastery. No templates or fancy c++ > tricks. This sounds ideal to me. > The goal would be to create (as much as > possible) an easy transition between the two APIs. The FLTK2 > classes could probably be used as a good starting point > though. I haven't looked at the lower layers from this > perspective enough yet to know how feasible it would be or > whether it could be done without any changes to the lower > level code. I think compatility and coexistence would be > primary requirements. > > Any thoughts? Sounds brilliant. If you have the will and the resource to pull it off, that'll be fantastic! -- Ian SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
