Subchapters:
.fl
files. These files are text, and you can (with care) edit them in a text editor, perhaps to get some special effects.
FLUID can "compile" the .fl
file into a .cxx
and a .h
file. The .cxx
file defines all the objects from the .fl
file and the .h
file declares all the global ones. FLUID also supports localization (Internationalization) of label strings using message files and the GNU gettext or POSIX catgets interfaces.
A simple program can be made by putting all your code (including a main()
function) into the .fl
file and thus making the .cxx
file a single source file to compile. Most programs are more complex than this, so you write other .cxx
files that call the FLUID functions. These .cxx
files must #include
the .h
file or they can #include
the .cxx
file so it still appears to be a single source file.
Figure 9-1: FLUID organization
Normally the FLUID file defines one or more functions or classes which output C++ code. Each function defines a one or more FLTK windows, and all the widgets that go inside those windows.
Widgets created by FLUID are either "named", "complex named" or "unnamed". A named widget has a legal C++ variable identifier as its name (i.e. only alphanumeric and underscore). In this case FLUID defines a global variable or class member that will point at the widget after the function defining it is called. A complex named object has punctuation such as '.'
or '->'
or any other symbols in its name. In this case FLUID assigns a pointer to the widget to the name, but does not attempt to declare it. This can be used to get the widgets into structures. An unnamed widget has a blank name and no pointer is stored.
Widgets may either call a named callback function that you write in another source file, or you can supply a small piece of C++ source and FLUID will write a private callback function into the .cxx
file.
fluid filename.fl &
to edit the .fl
file filename.fl
. If the file does not exist you will get an error pop-up, but if you dismiss it you will be editing a blank file of that name. You can run FLUID without any name, in which case you will be editing an unnamed blank setup (but you can use save-as to write it to a file).
You can provide any of the standard FLTK switches before the filename:
-display host:n.n -geometry WxH+X+Y -title windowtitle -name classname -iconic -fg color -bg color -bg2 color -scheme schemename
Changing the colors may be useful to see what your interface will look at if the user calls it with the same switches. Similarly, using "-scheme plastic" will show how the interface will look using the "plastic" scheme.
In the current version, if you don't put FLUID into the background with '&'
then you will be able to abort FLUID by typing CTRL-C
on the terminal. It will exit immediately, losing any changes.
.cxx
and .h
file from a .fl
file. To do this type:
fluid -c filename.fl
This will read the filename.fl
file and write filename.cxx
and filename.h
. Any leading directory on filename.fl
will be stripped, so they are always written to the current directory. If there are any errors reading or writing the files, FLUID will print the error and exit with a non-zero code. You can use the following lines in a makefile to automate the creation of the source and header files:
my_panels.h my_panels.cxx: my_panels.fl fluid -c my_panels.fl
Most versions of make support rules that cause .fl
files to be compiled:
.SUFFIXES: .fl .cxx .h .fl.h .fl.cxx: fluid -c $<
Figure 9-2: CubeView demo
The window is of class CubeViewUI, and is completely generated by FLUID, including class member functions. The central display of the cube is a separate subclass of Fl_Gl_Window called CubeView. CubeViewUI manages CubeView using callbacks from the various sliders and rollers to manipulate the viewing angle and zoom of CubeView.
At the completion of this tutorial you will (hopefully) understand how to:
You can safely skip this section as long as you realize the CubeView is a sublass of Fl_Gl_Window and will respond to calls from CubeViewUI, generated by FLUID.
class CubeView : public Fl_Gl_Window { public: CubeView(int x,int y,int w,int h,const char *l=0); // this value determines the scaling factor used to draw the cube. double size; /* Set the rotation about the vertical (y ) axis. This function is called by the horizontal roller in CubeViewUI and the initialize button in CubeViewUI. */ void v_angle(float angle){vAng=angle;}; // Return the rotation about the vertical (y ) axis. float v_angle(){return vAng;}; /* Set the rotation about the horizontal (x ) axis. This function is called by the vertical roller in CubeViewUI and the initialize button in CubeViewUI. */ void h_angle(float angle){hAng=angle;}; // the rotation about the horizontal (x ) axis. float h_angle(){return hAng;}; /* Sets the x shift of the cube view camera. This function is called by the slider in CubeViewUI and the initialize button in CubeViewUI. */ void panx(float x){xshift=x;}; /* Sets the y shift of the cube view camera. This function is called by the slider in CubeViewUI and the initialize button in CubeViewUI. */ void pany(float y){yshift=y;}; /* The widget class draw() override. The draw() function initialize Gl for another round of drawing then calls specialized functions for drawing each of the entities displayed in the cube view. */ void draw(); private: /* Draw the cube boundaries Draw the faces of the cube using the boxv[] vertices, using GL_LINE_LOOP for the faces. The color is #defined by CUBECOLOR. */ void drawCube(); float vAng,hAng; float xshift,yshift; float boxv0[3];float boxv1[3]; float boxv2[3];float boxv3[3]; float boxv4[3];float boxv5[3]; float boxv6[3];float boxv7[3]; };
#include "CubeView.h" #include <math.h> CubeView::CubeView(int x,int y,int w,int h,const char *l) : Fl_Gl_Window(x,y,w,h,l) { vAng = 0.0; hAng=0.0; size=10.0; /* The cube definition. These are the vertices of a unit cube centered on the origin.*/ boxv0[0] = -0.5; boxv0[1] = -0.5; boxv0[2] = -0.5; boxv1[0] = 0.5; boxv1[1] = -0.5; boxv1[2] = -0.5; boxv2[0] = 0.5; boxv2[1] = 0.5; boxv2[2] = -0.5; boxv3[0] = -0.5; boxv3[1] = 0.5; boxv3[2] = -0.5; boxv4[0] = -0.5; boxv4[1] = -0.5; boxv4[2] = 0.5; boxv5[0] = 0.5; boxv5[1] = -0.5; boxv5[2] = 0.5; boxv6[0] = 0.5; boxv6[1] = 0.5; boxv6[2] = 0.5; boxv7[0] = -0.5; boxv7[1] = 0.5; boxv7[2] = 0.5; }; // The color used for the edges of the bounding cube. #define CUBECOLOR 255,255,255,255 void CubeView::drawCube() { /* Draw a colored cube */ #define ALPHA 0.5 glShadeModel(GL_FLAT); glBegin(GL_QUADS); glColor4f(0.0, 0.0, 1.0, ALPHA); glVertex3fv(boxv0); glVertex3fv(boxv1); glVertex3fv(boxv2); glVertex3fv(boxv3); glColor4f(1.0, 1.0, 0.0, ALPHA); glVertex3fv(boxv0); glVertex3fv(boxv4); glVertex3fv(boxv5); glVertex3fv(boxv1); glColor4f(0.0, 1.0, 1.0, ALPHA); glVertex3fv(boxv2); glVertex3fv(boxv6); glVertex3fv(boxv7); glVertex3fv(boxv3); glColor4f(1.0, 0.0, 0.0, ALPHA); glVertex3fv(boxv4); glVertex3fv(boxv5); glVertex3fv(boxv6); glVertex3fv(boxv7); glColor4f(1.0, 0.0, 1.0, ALPHA); glVertex3fv(boxv0); glVertex3fv(boxv3); glVertex3fv(boxv7); glVertex3fv(boxv4); glColor4f(0.0, 1.0, 0.0, ALPHA); glVertex3fv(boxv1); glVertex3fv(boxv5); glVertex3fv(boxv6); glVertex3fv(boxv2); glEnd(); glColor3f(1.0, 1.0, 1.0); glBegin(GL_LINES); glVertex3fv(boxv0); glVertex3fv(boxv1); glVertex3fv(boxv1); glVertex3fv(boxv2); glVertex3fv(boxv2); glVertex3fv(boxv3); glVertex3fv(boxv3); glVertex3fv(boxv0); glVertex3fv(boxv4); glVertex3fv(boxv5); glVertex3fv(boxv5); glVertex3fv(boxv6); glVertex3fv(boxv6); glVertex3fv(boxv7); glVertex3fv(boxv7); glVertex3fv(boxv4); glVertex3fv(boxv0); glVertex3fv(boxv4); glVertex3fv(boxv1); glVertex3fv(boxv5); glVertex3fv(boxv2); glVertex3fv(boxv6); glVertex3fv(boxv3); glVertex3fv(boxv7); glEnd(); };//drawCube void CubeView::draw() { if (!valid()) { glLoadIdentity(); glViewport(0,0,w(),h()); glOrtho(-10,10,-10,10,-20000,10000); glEnable(GL_BLEND); glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); } glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); glPushMatrix(); glTranslatef(xshift, yshift, 0); glRotatef(hAng,0,1,0); glRotatef(vAng,1,0,0); glScalef(float(size),float(size),float(size)); drawCube(); glPopMatrix(); };
Figure 9-3: FLUID file for CubeView
Then add a window to the CubeViewUI class. Highlight the name of the constructor in the FLUID browser window and click on New->Group->Window. In a similar manner add the following to the CubeViewUI constructor:
hrot
vrot
xpan
ypan
zoom
When you are finished you should have something like this:
Figure 9-4: FLUID window containing CubeView demo
We will talk about the show()
method that is highlighted shortly.
The CubeView class inherits the Fl_Gl_Window class, which is created in the same way as a Fl_Box widget. Use New->Other->Box to add a square box to the main window. This will be no ordinary box, however.
The Box properties window will appear. The key to letting CubeViewUI display CubeView is to enter CubeView in the Class: text entry box. This tells FLUID that it is not an Fl_Box, but a similar widget with the same constructor.
In the Extra Code: field enter #include "CubeView.h"
This #include
is important, as we have just included CubeView as a member of CubeViewUI, so any public CubeView methods are now available to CubeViewUI.
Figure 9-5: CubeView methods
ypan
slider is:
cube->pany(((Fl_Slider *)o)->value()); cube->redraw();
We call cube->redraw()
after changing the value to update the CubeView window. CubeView could easily be modified to do this, but it is nice to keep this exposed in the case where you may want to do more than one view change only redrawing once saves a lot of time.
There is no reason no wait until after you have added CubeView to enter these callbacks. FLUID assumes you are smart enough not to refer to members or functions that don't exist.
Make sure the top level CubeViewUI is selected and select New->Code->Function/Method. Just use the name show()
. We don't need a return value here, and since we will not be adding any widgets to this method FLUID will assign it a return type of void
.
Figure 9-6: CubeView constructor
Once the new method has been added, highlight its name and select New->Code->Code. Enter the method's code in the code window.
At the bottom of the preferences dialog box is the key: "Include Header from Code". Select that option and set your desired file extensions and you are in business. You can include the CubeViewUI.h (or whatever extension you prefer) as you would any other C++ class.
.fl
file being edited is shown in the window title.The widgets are stored in a hierarchy. You can open and close a level by clicking the "triangle" at the left of a widget. The leftmost widgets are the parents, and all the widgets listed below them are their children. Parents don't have to have any children.
The top level of the hierarchy is composed of functions and classes. Each of these will produce a single C++ public function or class in the output .cxx
file. Calling the function or instantiating the class will create all of the child widgets.
The second level of the hierarchy contains the windows. Each of these produces an instance of class Fl_Window.
Below that are either widgets (subclasses of Fl_Widget) or groups of widgets (including other groups). Plain groups are for layout, navigation, and resize purposes. Tab groups provide the well-known file-card tab interface.
Widgets are shown in the browser by either their name (such as "main_panel" in the example), or by their type and label (such as "Button "the green"").
You select widgets by clicking on their names, which highlights them (you can also select widgets from any displayed window). You can select many widgets by dragging the mouse across them, or by using Shift+Click to toggle them on and off. To select no widgets, click in the blank area under the last widget. Note that hidden children may be selected even when there is no visual indication of this.
You open widgets by double-clicking on them, or (to open several widgets you have picked) by typing the F1 key. A control panel will appear so you can change the widget(s).
.fl
file. You are asked for confirmation if you have changed the current file..fd
files produced by the Forms and XForms "fdesign" programs. It is best to File/Merge them instead of opening them. FLUID does not understand everything in a .fd
file, and will print a warning message on the controlling terminal for all data it does not understand. You will probably need to edit the resulting setup to fix these errors. Be careful not to save the file without changing the name, as FLUID will write over the .fd
file with its own format, which fdesign cannot read!.fl
file, without changing the name of the current .fl
file. All the functions (even if they have the same names as the current ones) are added, and you will have to use cut/paste to put the widgets where you want..fl
file. If the file is unnamed then FLUID will ask for a filename..cxx
and .h
file. These are exactly the same as the files you get when you run FLUID with the -c
switch..fl
file, with the leading directory and trailing ".fl" stripped, and ".h" or ".cxx" appended..fl
file, with the leading directory and trailing ".fl" stripped, and ".txt", ".po", or ".msg" appended depending on the Internationalization Mode.Figure 9-7: FLUID Preferences Window
void
)..cxx
output be a self-contained program that can be compiled and executed. This is done by deleting the function name so main(argc,argv)
is used. The function will call show()
on all the windows it creates and then call Fl::run()
. This can also be used to test resize behavior or other parts of the user interface.When you change attributes using this panel, the changes are reflected immediately in the window. It is useful to hit the "no overlay" button (or type Ctrl+Shift+O) to hide the red overlay so you can see the widgets more accurately, especially when setting the box type.
If you have several widgets selected, they may have different values for the fields. In this case the value for one of the widgets is shown. But if you change this value, all of the selected widgets are changed to the new value.
Hitting "OK" makes the changes permanent. Selecting a different widget also makes the changes permanent. FLUID checks for simple syntax errors such as mismatched parenthesis in any code before saving any text.
"Revert" or "Cancel" put everything back to when you last brought up the panel or hit OK. However in the current version of FLUID, changes to "visible" attributes (such as the color, label, box) are not undone by revert or cancel. Changes to code like the callbacks are undone, however.
Figure 9-8: The FLUID widget GUI attributes
show()
.Figure 9-9: The FLUID widget Style attributes
Figure 9-10: The FLUID widget C++ attributes
#include
header file is put in the .h
file. You must provide a #include
line as the first line of the "Extra Code" which declares your subclass. #include <FL/Fl_Double_Window.h>
public
or private
in the class. Otherwise is controls whether the widget is declared static
or global (extern
)..h
or .cxx
files.#
or the word extern
then FLUID thinks this is an "include" line, and it is written to the .h
file. If the same include line occurs several times then only one copy is written.o
. The window being constructed is pointed to by the local variable w
. You can also access any arguments passed to the function here, and any named widgets that are before this one..cxx
code.void name(<class>*,void*)
..cxx
output file. The function prototype is void name(class *o, void *v)
so that you can refer to the widget as o
and the user_data()
as v
. FLUID will check for matching parenthesis, braces, and quotes, but does not do much other error checking. Be careful here, as it may be hard to figure out what widget is producing an error in the compiler.user_data()
of the widget. If blank the default value of zero is used. This can be any piece of C code that can be cast to a void
pointer.void*
in the callback function prototypes is replaced with this. You may want to use long
for old XForms code. Be warned that anything other than void*
is not guaranteed to work! However on most architectures other pointer types are ok, and long
is usually ok, too.when()
field that are not in the menu. You should use the extra code fields to put these values in.ESC
.To select a widget, click it. To select several widgets drag a rectangle around them. Holding down shift will toggle the selection of the widgets instead.
You cannot pick hidden widgets. You also cannot choose some widgets if they are completely overlapped by later widgets. Use the browser to select these widgets.
The selected widgets are shown with a red "overlay" line around them. You can move the widgets by dragging this box. Or you can resize them by dragging the outer edges and corners. Hold down the Alt key while dragging the mouse to defeat the snap-to-grid effect for fine positioning.
If there is a tab box displayed you can change which child is visible by clicking on the file tabs. The child you pick is selected.
The arrow, tab, and shift+tab keys "navigate" the selection. Left, right, tab, or shift+tab move to the next or previous widgets in the hierarchy. Hit the right arrow enough and you will select every widget in the window. Up/down widgets move to the previous/next widgets that overlap horizontally. If the navigation does not seem to work you probably need to "Sort" the widgets. This is important if you have input fields, as FLTK uses the same rules when using arrow keys to move between input fields.
To "open" a widget, double click it. To open several widgets select them and then type F1 or pick "Edit/Open" off the pop-up menu.
Type Ctrl+o to temporarily toggle the overlay off without changing the selection, so you can see the widget borders.
You can resize the window by using the window manager border controls. FLTK will attempt to round the window size to the nearest multiple of the grid size and makes it big enough to contain all the widgets (it does this using illegal X methods, so it is possible it will barf with some window managers!). Notice that the actual window in your program may not be resizable, and if it is, the effect on child widgets may be different.
The panel for the window (which you get by double-clicking it) is almost identical to the panel for any other Fl_Widget. There are three extra items:
.cxx
file. If many widgets share the same image then only one copy is written. Since the image data is embedded in the generated source code, you need only distribute the C++ code and not the image files themselves.
However, the filenames are stored in the .fl
file so you will need the image files as well to read the .fl
file. Filenames are relative to the location of the .fl
file and not necessarily the current directory. We recommend you either put the images in the same directory as the .fl
file, or use absolute path names.
.fl
file.libxpm
library. These files use C source code to define a pixmap. The filenames usually have the ".xpm" extension..bmp
file..gif
file. Only the first image of an animated GIF file is used.Ctrl+p
) provides access to the I18N options.The "GNU gettext" method uses GNU gettext (or a similar text-based I18N library) to retrieve a localized string before calling the widget constructor.
The "POSIX catgets" method uses the POSIX catgets function to retrieve a numbered message from a message catalog before calling the widget constructor.
setlocale()
and textdomain()
or bindtextdomain()
to select the appropriate language and message file.To use GNU gettext for I18N, open the preferences window and choose "GNU gettext" from the Use: chooser. Two new input fields will then appear to control the include file and function/macro name to use when retrieving the localized label strings.
Figure 9-11: Internationalization using GNU gettext
The #include field controls the header file to include for I18N; by default this is <libintl.h>, the standard I18N file for GNU gettext.
The Function: field controls the function (or macro) that will retrieve the localized message; by default the gettext
function will be called.
.fl
file; you still need to call setlocale()
to select the appropriate language.To use POSIX catgets for I18N, open the preferences window and choose "POSIX catgets" from the Use: chooser. Three new input fields will then appear to control the include file, catalog file, and set number for retrieving the localized label strings.
Figure 9-12: Internationalization using POSIX catgets
The #include field controls the header file to include for I18N; by default this is <nl_types.h>, the standard I18N file for POSIX catgets.
The File: field controls the name of the catalog file variable to use when retrieving localized messages; by default the file field is empty which forces a local (static) catalog file to be used for all of the windows defined in your .fl
file.
The Set: field controls the set number in the catalog file. The default set is 1 and rarely needs to be changed.
#if 0
and #endif
type construction. This will effectively avoid compilation of blocks of code. However, static code and data generated by this segment (menu items, images, include statements, etc.) will still be generated and likely cause compile-time warnings.
[Prev] Using OpenGL | [Index] | Advanced FLTK [Next] |