> This might be a bit more problematic. FLTK has traditionally shied > away from the mandatory inclusion of external libraries (including > the standard C++ library) because there are users who require the > Fast and Light aspects of FLTK for their embedded systems. However > you really need to have some feedback from some of those developers > whether this is still the same killer requirement that it used to be. >
We certainly wouldn't want to make this a hard requirement. It would be handled as a build option. The SDL code would probably not be part of the base build tree by default. It would require the download of a separate package to populate the build. > FLUID can be a bit quirky, but it is a very powerful tool. It will > never be a full environment like Visual Studio, Kdevelop or Eclipse > but it is very good at what it does. If you use FLUID to develop > GUI elements that are effectively abstract classes, you can then > flesh these out in a main-stream coding environment tool. It does > take a little discipline, and I think this is an area of personal preference. We believe that if you have a good layout management scheme, that there is really no need for such a tool. The use of hard coded widget coordinates is kind of a bad idea and that seems to be the major benefit. For example, I have worked with Qt quite a bit. The casual or new (to Qt) developer will tend to make use of the "Designer", but a more experienced (with Qt) developer will inevitably drop it in favor of hand coding. I've seen this happen many times. The hand coding (API) support is one thing that Qt does pretty well. That said, I certainly don't mean to imply that anyone who uses this kind of tool is a casual developer. It is the API and layout design that makes the difference. > unfortunately isn't really described anywhere in the documentation. > It comes up frequently in the forums. It sounds like you have some valuable experience with FLUID. Perhaps a nice introduction video would allow others to benefit from the less obvious features. I find that for something like this, a video is easier and less time consuming to make than docs. I think there are a couple of decent free apps for creating this type of video. Does FLUID provide some other functions that I'm not aware of? 1.3.x development, or are part of the future development. > > Therefore would it not make more sense to contribute to the FLTK-1.3.x > development directly to improve the code base in line with your goals? > > The FLTK community has already seen that the FLTK2 fork ran out of > steam, as did the unofficial 1.2 fork to add UTF-8 to FLTK1. Does > efltk also count as a fork? At least two FLTK1 users had their own > forks ring-fenced for their commercial products, where they had to > backport the 1.2 changes. It is only now that FLTK1 has been able to > merge these UTF-8 versions for the FLTK-1.3.x development. > There are probably as many reasons that people fork projects as there are forks. Unfortunately, in many cases the momentum is lost when a project is pulled away from it's origins. That being said, the primary reason that we decided to do this was to avoid distracting FTLK development, which seems to be getting back on track. We don't intend to take a slash and burn attitude or make wholesale changes to the api. The thinking here is to maintain compatilibty as much as possible. If the FLTK team sees something they like, then we would be more than happy to help. It seems like a win/win approach. We can freely implement our wishlist and FLTK can benefit through new features/functions and a team that is more than happy to help support them. We don't really view this as a fork. I think it would be better characterized as R&D. We absolutely don't intend to create an alternative version of FLTK for mass consumption. Unless someone is following the FLTK forum, they will probably neve r know anything about it. I forgot to mention that we have decided to replace the Doxygen task with the port of an existing application. This will allow us to validate some ideas and keep detailed notes about what we bump into along the way. We want a reasonably sized app that we feel will push the limits of FLTK a little bit. It looks like we may have a banking app that would fill the bill. I should probably mention that half of us are seasoned developers. We killed off our programming egos a long time ago. We invite everyone to be as critical as they like. There is no need to worry about being politically correct. If there is one thing that I have learned, it is that in this line of work there is no such thing as an "expert". The area is just to vast for it to be possible. Thanks, Gerry _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
