fltk

IDE's under Linux: The Fast, Light, Toolkit (FLTK)

Written by Mike Andrew

The FLUID window

If you're looking for an NON KDE development environment, you hit gold here.

FLTK is the C++ version of XFORMS (alias Forms Designer).

This is all you need to know, if you are looking for, the new, improved version of Fdesign. It generates C++, not C, code. ( see elsewhere on the SxS for Forms Designer)

Some explanation is in order.

Xforms (alias forms, alias Forms Designer, alias FL, alias fl_) is or has been used *extensively* in Sun Microsystems gui interfaces. If somewhat clunky, it is excellent, intuitive, and quick to use. It's best feature by far, is it's ease of integration into the controlling C code (the underlying author-inspired, program). The single generated struct, the uniform callback functions, make it exceptionally simple to apply. To C code. It does not generate C++, and, the motif appearance of the resulting widgets are out of step with the thinner, leaner meaner looking frame designs of current voque.

The Author(s) of FLTK come from a different direction. FLTK is NOT Xforms, in shape or form, nor is it derived from Xform source code. It is however inspired by it, and is the direct, intended, replacement as C++. Don't look for an Xforms C++, it doesn't exist. (Xforms has been released as GPL source circa mid 2001, this statement *might* change). If you need C++, use FLTK.

FLTK even has a <forms.h> for translation of existing, Xforms, designs.

Rather than simply taking Xforms and modifying it slightly to generate C++ source (a simple "extern C {...}" statement can suffice), the author(s) applied the principles of C++ to form design makeup. Thus, in short and slightly innacurately, the widgets which FLTKcreates, are classes in their own right. This, long term, is a good thing. The use-by date of Fdesign is long past. There isn't much mileage left in adding feature-widgets to Forms Designer, that can't be done better (tm), using a C++ approach.

The difference in approach is important, because the Author(s) focussed goal makes FLTK an un-intuitive pig to initally work with. The authors primary, and important, concerns were:

to remove the reliance on X as the underlying windowing system.
to make FLTK very tight in code.
In the former case, FLTK is available under OS/2 , Windoze and Mac.

In the latter, great reliance is made of using static class(es) and inline functions, and, removing phantom stubs so that only those functions required in the library are built into the end product. The Authors achieved this, at the expense of generating, or having cause to generate, somewhat esoteric C++. A learning curve is required.

In contrast, Xforms is both overly huge in unused bloat (nearly the entire lib is included in any program), and, it uses raw X functions to do it's thing. Relying on X naturally, stunts portability.

The drawback with FLTK is that the gui design wizard for FLTK, FLUID, has a poor, unintutive, control panel. That said, FLUID has an association between the list of items you click, the consequent display, and the consequent properties window that is very good, very effortless. Unfortunately, there is a large content of assumed knowledge about C++. Great use is made of inline, statics, and virtual functions. The twists and tweaks of the generated source is cumbersome and by no means easy to follow. Secondly, the production of new elements, eg, the simple need to generate a button, in a window (form) is not intuitive and not easy to accomplish. Some serious work needs to be done to make FLUID user friendly. There are some unexpected, and sometimes nasty, actions using shortcut key strokes. Lastly, the added code you are required to insert as a callback, is very arbitrary, and difficult to follow.

The negatives said, FLTK is a great product and benefets from NOT being KDE sensitive. You can quickly get to work generating gui dialog applications which do NOT require to be run under the sometimes loathsome, KDE. KDE is a great product, so too it's IDE, Kdevelop, but it is often the most serious of overkills for the intended target.

In short, there is a day or two's learning curve involved in understanding the results of playing with FLUID, but once learned, are beneficial, if for the only reason, you'll be a more imaginative C++ programmer.

Installation:

As of writing, fltk is not packaged in an rpm format, nor, is it normally provided on a distro's CD. Both *will* change. As of writing, most distros known to me, make a toilet of installing png, jpeg and Mesa (OpenGL) libraries. Redhat 7.x for instance have wrong dependency checks in their rpm files which cause some of the above to not install. For this reason, in general, you should compile source for the immediate future, or until one distro at least , sorts the mess out.

Step 1:

Download and extract the latest tarball from www.fltk.org

Step 2: Compile.

the essential steps are

(dot)(slash)configure
make

as su

make install

Step 3: OpenGL and Jpegs.

Fluid (fltk) has really, really good widgets for image manipulation. Truly excellent stuff. The configure process is *quite likely* to miss both libpng / libjpeg and MesaGL. The answer is, in all cases, to ensure you installed the xxx-devel rpm's for these products. Redhat distros 7.x eg do not _normally_ install devel.rpms unless told to. This is fair enough, not everyone wants to compile programs for Xsane-devel.rpm or Sendmail-devel. They want to use the product, not program it.

Make sure that IF you get annoying configure problems as above, that when you fix them you ALSO

rm config.cache

Fail to do this, and fltk will never "see" the changes you made.

Enjoy!