Hello All, We've been putting some thought into exactly what we would like to work on. The feedback from the forum has been very helpful. I have a few thoughts I would like to run by y'all.
I hope this doesn't stir up a hornets nest, but I guess we'll see. FLTK2 After spending some time looking at the source for both FLTK-1.3.x and FLTK2, I'm kind of left wondering about the goal. I understand that api cleanup was a line item, but it seems like there should be more. The thinking here is that maybe the FLTK2 api should provide a higher level set of widgets. For example, I've been working on porting an existing application to FLTK1.3.x. There is a part of this app that needs to display pdf files. In FLTK this translated to a combination of Fl_Scroll, Fl_Group, Fl_Box, etc.. I found myself wishing for a higher level scrolling widget that would simply let me add widgets to it and handle all of the scrolling and resizing behavior for me. It occurred to me that anyone that needed to do something similar would end up writing the same code that I did. Now, I realize that this probably tugs at the "Fast Light" part of FLTK for some folks, but it seems like a lot of cases would require the same code to be written over and over again. It doesn' t seem like a higher level layer would take anything away from the "Fast Light" feature, if the lower layer was preserved. If you want the existing "Fast Light" feature, then you would go for the existing (lower level) api library. However, if your writing a business oriented app, perhaps you would want a higher level more functional set of widgets. Then, of course, you would link in the higher level library. Fire away... Low Level Abstraction Layer (HAL/PAL) This is something that we are very interested in. This interest has been echoed by a few devs on the forum as well. The project would benefit from this in many ways. We have already started working on this one. UTF8 The consensus among us is that we don't have enough knowledge between us to actually make any significant contribution to the UTF8 code. However, we do have a lot of experience with cross-platform development. This being the case, we plan to look at the UTF8 code from that perspective and as it relates to the abstraction layer above. Themes / Skins Firstly, for the sake of clarity, I don't think these are the same thing. When I think of "themes", I think of things like colors, fonts, sizes, properties, etc.. When I think of skins, I think of images that are used to draw interface elements. I am curious to know what y'all are thinking about with regard to this. No matter what terminology is used, we believe all of this is important. We would like to see a good feature rich implementation of this including a utility to aid in creating themes/skins. Since a part of this would need to fit under the abstraction layer, we plan to address this as well. We would start by looking at the existing implementation in FLTK2. Again, fire away CMake We plan to bring the CMake build current. Please let me know what you think. Thanks, Gerry _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
