diff options
| author | Michael R Sweet <michael.r.sweet@gmail.com> | 1999-01-07 16:36:11 +0000 |
|---|---|---|
| committer | Michael R Sweet <michael.r.sweet@gmail.com> | 1999-01-07 16:36:11 +0000 |
| commit | 367f908d8ed5a3464b9676223a26ddf4e11bdb5b (patch) | |
| tree | 2b0ec583852973ccf7b9804957e78d474e0e7e5d /documentation | |
| parent | 85e6f449590eeb6e09f7547733adf4c7137470d0 (diff) | |
"Final" changes for first draft of 1.0 documentation.
git-svn-id: file:///fltk/svn/fltk/trunk@187 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Diffstat (limited to 'documentation')
| -rw-r--r-- | documentation/Fl_Widget.html | 42 | ||||
| -rw-r--r-- | documentation/Makefile | 10 | ||||
| -rw-r--r-- | documentation/basics.html | 13 | ||||
| -rw-r--r-- | documentation/common.html | 10 | ||||
| -rw-r--r-- | documentation/drawing.html | 1464 | ||||
| -rw-r--r-- | documentation/editor.html | 6 | ||||
| -rw-r--r-- | documentation/enumerations.html | 693 | ||||
| -rw-r--r-- | documentation/events.html | 572 | ||||
| -rw-r--r-- | documentation/fluid.html | 578 | ||||
| -rw-r--r-- | documentation/forms.html | 327 | ||||
| -rw-r--r-- | documentation/functions.html | 1442 | ||||
| -rw-r--r-- | documentation/glut.html | 231 | ||||
| -rw-r--r-- | documentation/intro.html | 14 | ||||
| -rw-r--r-- | documentation/license.html | 8 | ||||
| -rw-r--r-- | documentation/opengl.html | 666 | ||||
| -rw-r--r-- | documentation/osissues.html | 550 | ||||
| -rw-r--r-- | documentation/preface.html | 15 | ||||
| -rw-r--r-- | documentation/subclassing.html | 668 | ||||
| -rw-r--r-- | documentation/widgets.html | 5 |
19 files changed, 3321 insertions, 3993 deletions
diff --git a/documentation/Fl_Widget.html b/documentation/Fl_Widget.html index 5509a8f85..933e1ef7e 100644 --- a/documentation/Fl_Widget.html +++ b/documentation/Fl_Widget.html @@ -53,11 +53,11 @@ after these. <li><a href="#Fl_Widget.argument">argument</a> <li><a href="#Fl_Widget.box">box</a> <li><a href="#Fl_Widget.callback">callback</a> - <li><a href="#Fl_Widget.changed">changed</a> </ul> </td> <td align=left valign=top> <ul> + <li><a href="#Fl_Widget.changed">changed</a> <li><a href="#Fl_Widget.clear_changed">clear_changed</a> <li><a href="#Fl_Widget.color">color</a> <li><a href="#Fl_Widget.contains">contains</a> @@ -66,27 +66,22 @@ after these. <li><a href="#Fl_Widget.default_callback">default_callback</a> <li><a href="#Fl_Widget.do_callback">do_callback</a> <li><a href="#Fl_Widget.h">h</a> - <li><a href="#Fl_Widget.hide">hide</a> - <li><a href="#Fl_Widget.ih">ih</a> </ul> </td> <td align=left valign=top> <ul> - <li><a href="#Fl_Widget.init_size">init_size</a> + <li><a href="#Fl_Widget.hide">hide</a> <li><a href="#Fl_Widget.inside">inside</a> - <li><a href="#Fl_Widget.iw">iw</a> - <li><a href="#Fl_Widget.ix">ix</a> - <li><a href="#Fl_Widget.iy">iy</a> <li><a href="#Fl_Widget.label">label</a> <li><a href="#Fl_Widget.labelcolor">labelcolor</a> <li><a href="#Fl_Widget.labelfont">labelfont</a> <li><a href="#Fl_Widget.labelsize">labelsize</a> <li><a href="#Fl_Widget.labeltype">labeltype</a> + <li><a href="#Fl_Widget.parent">parent</a> </ul> </td> <td align=left valign=top> <ul> - <li><a href="#Fl_Widget.parent">parent</a> <li><a href="#Fl_Widget.position">position</a> <li><a href="#Fl_Widget.redraw">redraw</a> <li><a href="#Fl_Widget.resize">resize</a> @@ -94,12 +89,13 @@ after these. <li><a href="#Fl_Widget.set_changed">set_changed</a> <li><a href="#Fl_Widget.show">show</a> <li><a href="#Fl_Widget.size">size</a> - <li><a href="#Fl_Widget.type">type</a> - <li><a href="#Fl_Widget.user_data">user_data</a> + <li><a href="#Fl_Widget.take_focus">take_focus</a> </ul> </td> <td align=left valign=top> <ul> + <li><a href="#Fl_Widget.type">type</a> + <li><a href="#Fl_Widget.user_data">user_data</a> <li><a href="#Fl_Widget.visible">visible</a> <li><a href="#Fl_Widget.w">w</a> <li><a href="#Fl_Widget.when">when</a> @@ -150,27 +146,11 @@ way to update the display, such as scrolling from the old position). <p><tt>position(x,y)</tt> is a shortcut for <tt>resize(x,y,w(),h())</tt>, and <tt>size(w,h)</tt> is a shortcut for <tt>resize(x(),y(),w,h)</tt>. -<h4><a name="Fl_Widget.ix">short Fl_Widget::ix() const</a><br> -<a name="Fl_Widget.iy">short Fl_Widget::iy() const</a><br> -<a name="Fl_Widget.iw">short Fl_Widget::iw() const</a><br> -<a name="Fl_Widget.ih">short Fl_Widget::ih() const</a><br> -<a name="Fl_Widget.init_size">void Fl_Widget::init_size(int,int,int,int)</a></h4> - -The initial size and position of the widget. This is a copy of the -arguments that the constructor was called with. This information is -used by <a href="#Fl_Group"><tt>Fl_Group</tt></a> to calculate new sizes of -the children when they are resized. - -<p><tt>init_size()</tt> calls <tt>resize()</tt> with the passed sizes, -and then replaces the initial size with the new values. If this widget -is a group you will have to init_size all the children as well or -unpredictable results will occur. - <h4><a name="Fl_Widget.window">Fl_Window* Fl_Widget::window() const;</a></h4> Return a pointer to the <a href="#Fl_Window"><tt>Fl_Window</tt></a> that this widget is in (it will skip any and all parent widgets between -this and the window). Returns NULL if none. Note: for an +this and the window). Returns <tt>NULL</tt> if none. Note: for an <tt>Fl_Window</tt>, this returns it's <i>parent</i> window (if any), not <i>this</i> window. @@ -376,5 +356,13 @@ this widget. Returns false if <tt>b</tt> is <tt>NULL</tt>. Returns true if this is a child of <tt>a</tt>, or is equal to <tt>a</tt>. Returns false if <tt>a</tt> is <tt>NULL</tt>. +<h4><a name="Fl_Widget.take_focus">int Fl_Widget::take_focus()</a></h4> + +Tries to make this widget be the <tt>Fl::focus()</tt> widget, by first +sending it an <tt>FL_FOCUS</tt> event, and if it returns non-zero, +setting <tt>Fl::focus()</tt> to this widget. You should use this +method to assign the focus to an widget. Returns true if the widget +accepted the focus. + </body> </html> diff --git a/documentation/Makefile b/documentation/Makefile index 89ae65ac1..d3bd0e1f1 100644 --- a/documentation/Makefile +++ b/documentation/Makefile @@ -1,5 +1,5 @@ # -# "$Id: Makefile,v 1.2 1998/12/29 14:58:59 mike Exp $" +# "$Id: Makefile,v 1.3 1999/01/07 16:36:05 mike Exp $" # # Documentation makefile for the Fast Light Tool Kit (FLTK). # @@ -29,6 +29,8 @@ HTMLFILES = \ src/basics.html \ src/common.html \ src/editor.html \ + src/drawing.html \ + src/events.html \ src/subclassing.html \ src/fluid.html \ src/opengl.html \ @@ -113,14 +115,14 @@ index.html: $(HTMLFILES) fltk.ps.gz: $(HTMLFILES) @echo "Generating PostScript documentation..." @rm -f fltk.ps fltk.ps.gz - @htmldoc -f fltk.ps --no-compression --jpeg=90 --duplex --verbose --toclevels 2 --title src/FL.gif $(HTMLFILES) + @htmldoc -f fltk.ps --jpeg=90 --duplex --verbose --toclevels 2 --title src/FL.gif $(HTMLFILES) @gzip -9 fltk.ps fltk.pdf: $(HTMLFILES) @echo "Generating PDF documentation..." @rm -f fltk.pdf - @htmldoc -f fltk.pdf --no-compression --jpeg=90 --duplex --verbose --toclevels 2 --title src/FL.gif $(HTMLFILES) + @htmldoc -f fltk.pdf --compression=9 --jpeg=90 --duplex --verbose --toclevels 2 --title src/FL.gif $(HTMLFILES) # -# End of "$Id: Makefile,v 1.2 1998/12/29 14:58:59 mike Exp $". +# End of "$Id: Makefile,v 1.3 1999/01/07 16:36:05 mike Exp $". # diff --git a/documentation/basics.html b/documentation/basics.html index 62e74d7e0..d3b01a5b8 100644 --- a/documentation/basics.html +++ b/documentation/basics.html @@ -31,7 +31,7 @@ The proper way to include FLTK header files is: #include <FL/Fl_xyz.H> </pre></ul> -Microsoft Windows developers please note: case *is* significant +<b>Microsoft Windows developers please note:</b> case *is* significant under other operating systems, and the C standard uses the forward slash (/) to separate directories. The following <tt>#include</tt> directives are *not* recommended for portability reasons: @@ -71,9 +71,8 @@ header files. This can be done by selecting "Settings" from the <p>You can build your Microsoft Windows applications as Console or WIN32 applications. If you want to use the standard C <tt>main()</tt> -function as the entry point, enter the name <tt>mainCRTStartup</tt> in -the "Entry-point symbol" field in the "Output" settings under the -"Link" tab. +function as the entry point, FLTK includes a <tt>WinMain()</tt> function +that will call your <tt>main()</tt> function for you. <p><i>Note: The Visual C++ optimizer is known to cause problems with many programs. We only recommend using the "Favor Small Code" @@ -155,7 +154,7 @@ The <tt>boxtype</tt> value is the style of the box that is drawn around the widget. Usually this is <tt>FL_NO_BOX</tt>, which means that no box is drawn. In our "Hello, World!" example we use <tt>FL_UP_BOX</tt>, which means that a raised button border will be drawn around the -widget. You can learn more about boxtypes in <a href="#common">Chapter +widget. You can learn more about boxtypes in <a href="#boytypes">Chapter 3</a>. <p>The <tt>x</tt> and <tt>y</tt> parameters determine where the widget @@ -170,7 +169,7 @@ governed by the underlying window system or hardware. <H3>Labels</H3> All widgets support labels. In the case of window widgets, the label -is used for the label in the title bar. Our example program calls the +is used for the label in the title bar. Our example program calls the <a href="#Fl_Widget.labelfont"><tt>labelfont</tt></a>, <a href="#Fl_Widget.labelsize"><tt>labelsize</tt></a>, and <a href="#Fl_Widget.labeltype"><tt>labeltype</tt></a> methods. @@ -185,7 +184,7 @@ directly. <p>The <tt>labeltype</tt> method sets the type of label. FLTK supports normal, embossed, shadowed, symbol, and image labels. -<p>A complete list of all label options can be found in <a href="#common"> +<p>A complete list of all label options can be found in <a href="#labels"> Chapter 3</a>. <H3>Showing the Window</H3> diff --git a/documentation/common.html b/documentation/common.html index 2f75ea98b..18911c86b 100644 --- a/documentation/common.html +++ b/documentation/common.html @@ -1,7 +1,7 @@ <HTML> <BODY> -<H1 ALIGN=RIGHT>3 - Common Widgets and Attributes</H1> +<H1 ALIGN=RIGHT><A NAME="common">3 - Common Widgets and Attributes</A></H1> This chapter describes many of the widgets that are provided with FLTK and covers how to query and set the standard attributes. @@ -119,7 +119,7 @@ window->size(width, height); Changing the size or position of a widget will cause a redraw of that widget and its children. -<H2>Colors</H2> +<H2><A NAME="colors">Colors</A></H2> FLTK manages a virtual color palette of "standard" colors. The standard colors are: @@ -148,7 +148,7 @@ Similarly, the label color can be set using the <tt>labelcolor()</tt> method: button->labelcolor(FL_WHITE); </pre></ul> -<H2>Box Types</H2> +<H2><A NAME="boxtypes">Box Types</A></H2> <p>The type <tt>Fl_Boxtype</tt> stored and returned in <a href="#Fl_Widget.box"> <tt>Fl_Widget::box()</tt></a> is an enumeration defined in @@ -204,9 +204,9 @@ The last 4 arguments to <tt>Fl::set_boxtype()</tt> are the offsets for the bounding box that should be subtracted when drawing the label inside the box. -<H2>Labels and Label Types</H2> +<H2><A NAME="labels">Labels and Label Types</A></H2> -The <tt>label()</tt>, <tt>align</tt>, <tt>labelfont()</tt>, <tt>labelsize()<tt>, +The <tt>label()</tt>, <tt>align</tt>, <tt>labelfont()</tt>, <tt>labelsize()</tt>, and <tt>labeltype()</tt> methods control the labeling of widgets. <H3>label()</H3> diff --git a/documentation/drawing.html b/documentation/drawing.html index 2e78a7086..2d195d3de 100644 --- a/documentation/drawing.html +++ b/documentation/drawing.html @@ -1,9 +1,11 @@ <HTML> <BODY> -<H1>Chapter XXX - Drawing Things in FLTK</H1> +<H1>5 - Drawing Things in FLTK</H1> -<h2>When can you draw things in FLTK?</h2> +This chapter covers the drawing functions that are provided with FLTK. + +<h2>When Can You Draw Things in FLTK?</h2> There are only certain places you can execute drawing code in FLTK. Calling these functions at other places will result in undefined @@ -11,1285 +13,669 @@ behavior! <ul> -<li>The most common is inside the virtual method <a -href=subclass.html#draw>Fl_Widget::draw()</a>. To write code here, -you must subclass one of the existing Fl_Widget classes and implement -your own version of draw(). - -<p> - -<li>You can also write <a href=Boxtypes.html>boxtypes</a> and <a href -= Labeltypes.html>labeltypes</a>. These are small procedures that can be -called by existing Fl_Widget draw() methods. These "types" are -identified by an 8-bit index that is stored in the widget's box(), -labeltype(), and possibly other properties. - -<p> - -<li>You can call <a -href=Fl_Window.html#make_current>Fl_Window::make_current()</a> to do -incremental update of a widget (use <a -href=Fl_Widget.html#window>Fl_Widget::window()</a> to find the -window). <i>Under X this only works for the base Fl_Window class, not -for double buffered, overlay, or OpenGL windows!</i> + <li>The most common is inside the virtual method <a + href="#draw"><tt>Fl_Widget::draw()</tt></a>. To write code + here, you must subclass one of the existing <tt>Fl_Widget</tt> + classes and implement your own version of <tt>draw()</tt>. + + <li>You can also write <a href="#boxtypes">boxtypes</a> and <a + href="#labeltypes">labeltypes</a>. These are small procedures + that can be called by existing <tt>Fl_Widget</tt> + <tt>draw()</tt> methods. These "types" are identified by an + 8-bit index that is stored in the widget's <tt>box()</tt>, + <tt>labeltype()</tt>, and possibly other properties. + + <li>You can call <a + href="#Fl_Window.make_current"><tt>Fl_Window::make_current()</tt></a> + to do incremental update of a widget. Use <a + href="#Fl_Widget.window"><tt>Fl_Widget::window()</tt></a> to + find the window. <i>Under X this only works for the base + <tt>Fl_Window</tt> class, not for double buffered, overlay, or + OpenGL windows!</i> </ul> -</ul><h2>FLTK Drawing functions<br>#include <FL/fl_draw.H></h2> +<h2>FLTK Drawing Functions</h2> + +To use the drawing functions you must first include the +<tt><FL/fl_draw.H></tt> header file. FLTK provides the following types +of drawing functions: <ul> -<li><a href=#clipping>Clipping</a> -<li><a href=#color>Colors</a> -<li><a href=#fast>Fast Shapes</a> -<li><a href=#vertex>Complex Shapes</a> -<li><a href=#text>Text</a> -<li><a href=images.html>Images</a> -<li><a href=#cursor>Cursor</a> -<li><a href=#overlay>Overlay</a> -<li><a href=Fl_Gl_Window.html#gl_start>Using OpenGL</a> + <li><a href="#clipping">Clipping</a> + <li><a href="#color">Colors</a> + <li><a href="#fast">Fast Shapes</a> + <li><a href="#vertex">Complex Shapes</a> + <li><a href="#text">Text</a> + <li><a href="#images">Images</a> + <li><a href="#cursor">Cursor</a> + <li><a href="#overlay">Overlay</a> </ul> -</ul><hr><h3>Clipping</h3> +<h3><a name="clipping">Clipping</a></h3> -<p>You can limit all your drawing to a rectangular region by calling -fl_clip, and put the drawings back by using fl_pop_clip. This -rectangle is measured in pixels (it is unaffected by the current -transformation matrix). +You can limit all your drawing to a rectangular region by calling +<tt>fl_clip</tt>, and put the drawings back by using +<tt>fl_pop_clip</tt>. This rectangle is measured in pixels (it is +unaffected by the current transformation matrix). <p>In addition, the system may provide clipping when updating windows, this clip region may be more complex than a simple rectangle. -</ul><h4><code>void fl_clip(int x, int y, int w, int h);</code></h4><ul> +<h4>void fl_clip(int x, int y, int w, int h)</h4> -Intesect the current clip region with a rectangle and push this new +Intersect the current clip region with a rectangle and push this new region onto the stack. -</ul><h4><code>void fl_pop_clip();</code></h4><ul> +<h4>void fl_pop_clip()</h4> -Restore the previous clip region. <i>You must call fl_pop_clip() once -for every time you call fl_clip(). If you return to FLTK with the -clip stack not empty unpredictable results occur.</i> +Restore the previous clip region. <i>You must call +<tt>fl_pop_clip()</tt> once for every time you call +<tt>fl_clip()</tt>. If you return to FLTK with the clip stack not +empty unpredictable results occur.</i> -</ul><h4><code>int fl_not_clipped(int x, int y, int w, int h);</code></h4><ul> +<h4>int fl_not_clipped(int x, int y, int w, int h)</h4> Returns true if any of the rectangle intersects the current clip region. If this returns false you don't have to draw the object. -<i>On X this returns 2 if the rectangle is partially clipped, and 1 if -it is entirely inside the clip region</i>. +<i>Under X this returns 2 if the rectangle is partially clipped, and 1 +if it is entirely inside the clip region</i>. -</ul><h4><code>int fl_clip_box(int x, int y, int w, int h,<br> -    int& X, int& Y, int& W, int& H);</code></h4><ul> +<h4>int fl_clip_box(int x, int y, int w, int h, int &X, int &Y, int &W, int &H)</h4> -Intersect the rectangle x,y,w,h with the current clip region and -returns the bounding box of the result in X,Y,W,H. Returns non-zero -if the resulting rectangle is different than the original. This can -be used to limit the necessary drawing to a rectangle. W and H are set to -zero if the rectangle is completely outside the region. +Intersect the rectangle <tt>x,y,w,h</tt> with the current clip region +and returns the bounding box of the result in <tt>X,Y,W,H</tt>. +Returns non-zero if the resulting rectangle is different than the +original. This can be used to limit the necessary drawing to a +rectangle. <tt>W</tt> and <tt>H</tt> are set to zero if the rectangle +is completely outside the region. -</ul><hr><h3>Colors</h3> +<h3><a name="colors">Colors</a></h3> -</ul><h4><code>void fl_color(Fl_Color);</code></h4><ul> +<h4>void fl_color(Fl_Color)</h4> -<p>Set the color for all subsequent drawing operations. Fl_Color is -an enumeration type, all values are in the range 0-255. This is -<i>not</i> the X pixel, it is an internal table! The table provides -several general colors, a 24-entry gray ramp, and a 5x8x5 color cube. -All of these are named with poorly-documented symbols in <a -href=Enumerations.html><FL/Enumerations.H></a>. +Set the color for all subsequent drawing operations. <tt>Fl_Color</tt> +is an enumeration type, and all values are in the range 0-255. This is +<i>not</i> the X or WIN32 pixel, it is an index into an internal +table! The table provides several general colors, a 24-entry gray +ramp, and a 5x8x5 color cube. All of these are named with +poorly-documented symbols in <a +href=#enumerations><tt><FL/Enumerations.H></tt></a>. -<p><i>Under X, a color cell will be allocated out of fl_colormap each -time you request an fl_color the first time. If the colormap fills up -then a least-squares algorithim is used to find the closest color.</i> +<p>For colormapped displays, a color cell will be allocated out of +<tt>fl_colormap</tt> the first time you use a color. If the colormap +fills up then a least-squares algorithm is used to find the closest +color.</i> -</ul><h4><code>Fl_Color fl_color();</code></h4><ul> +<h4>Fl_Color fl_color()</h4> -Returns the last fl_color() that was set. This can be used for state +Returns the last <tt>fl_color()</tt> that was set. This can be used for state save/restore. -</ul><h4><code>void Fl::set_color(Fl_Color, uchar r, uchar g, uchar b); -<br>void Fl::get_color(Fl_Color, uchar &, uchar &, uchar &);</code></h4><ul> - -Set or get an entry in the fl_color index table. You can set it to -any 8-bit rgb color. <i>On X, if the index has been requested before, -the pixel is free'd. No pixel is allocated until fl_color(i) is used -again, and there is no guarantee that the same pixel will be used next -time.</i> - -</ul><h4><code>void fl_color(uchar r, uchar g, uchar -b);</code></h4><ul> +<h4>void fl_color(uchar r, uchar g, uchar b)</h4> -<p>Set the color for all subsequent drawing operations. The closest -possible match to the rgb color is used. <i>Under X this works -perfectly for TrueColor visuals. For colormap visuals the nearest index -in the gray ramp or color cube is figured out, and fl_color(i) is done -with that, this can result in two approximations of the color and is -very inaccurate!</i> +Set the color for all subsequent drawing operations. The closest +possible match to the RGB color is used. The RGB color is used +directly on TrueColor displays. For colormap visuals the nearest index +in the gray ramp or color cube is used. -</ul><hr><h3>Fast Shapes</h3> +<h3><a name="fast_shapes">Fast Shapes</a></h3> -These are used to draw almost all the FLTK widgets. They draw on -exact pixel boundaries and are as fast as possible, and their behavior -will be duplicated exactly on any platform FLTK is ported to. It is +These are used to draw almost all the FLTK widgets. They draw on exact +pixel boundaries and are as fast as possible, and their behavior will +be duplicated exactly on any platform FLTK is ported to. It is undefined whether these are affected by the <a -href=#vertex>transformation matrix</a>, so you should only call these +href="#complex_shapes">transformation matrix</a>, so you should only call these while it is the identity. -<p><i>All arguments are integers.</i> - -</ul><h4><code>void fl_rectf(x, y, w, h);</code></h4><ul> +<h4>void fl_rectf(int x, int y, int w, int h)</h4> Color a rectangle that exactly fills the given bounding box. -</ul><h4><code>void fl_rectf(x, y, w, h, uchar r, uchar g, uchar b);</code></h4><ul> +<h4>void fl_rectf(int x, int y, int w, int h, uchar r, uchar g, uchar b)</h4> -Color a rectangle with "exactly" the passed r,g,b color. On screens -with less than 24 bits of color this is done by drawing a +Color a rectangle with "exactly" the passed <tt>r,g,b</tt> color. On +screens with less than 24 bits of color this is done by drawing a solid-colored block using <a -href=images.html#fl_draw_image>fl_draw_image()</a> so that dithering -is produced. If you have 24 bit color, this fills the rectangle with a -single pixel value and is about 1 zillion times faster. +href="#fl_draw_image"><tt>fl_draw_image()</tt></a> so that dithering is +produced. -</ul><h4><code>void fl_rect(x, y, w, h);</code></h4><ul> +<h4>void fl_rect(int x, int y, int w, int h)</h4> Draw a 1-pixel border <i>inside</i> this bounding box. -</ul><h4><code>void fl_line(x, y, x1, y1); -<br>void fl_line(x, y, x1, y1, x2, y2);</code></h4><ul> +<h4>void fl_line(int x, int y, int x1, int y1)<br> +void fl_line(int x, int y, int x1, int y1, int x2, int y2)</h4> Draw one or two 1-pixel thick lines between the given points. -</ul><h4><code>void fl_loop(x, y, x1, y1, x2, y2); -<br>void fl_loop(x, y, x1, y1, x2, y2, x3, y3); -</code></h4><ul> +<h4>void fl_loop(int x, int y, int x1, int y1, int x2, int y2)<br> +void fl_loop(int x, int y, int x1, int y1, int x2, int y2, int x3, int y3)</h4> Outline a 3 or 4-sided polygon with 1-pixel thick lines. -</ul><h4><code>void fl_polygon(x, y, x1, y1, x2, y2); -<br>void fl_polygon(x, y, x1, y1, x2, y2, x3, y3); -</code></h4><ul> +<h4>void fl_polygon(int x, int y, int x1, int y1, int x2, int y2)<br> +void fl_polygon(int x, int y, int x1, int y1, int x2, int y2, int x3, int y3)</h4> Fill a 3 or 4-sided polygon. The polygon must be convex. -</ul><h4><code>void fl_xyline(x, y, x1, y1); -<br>void fl_xyline(x, y, x1, y1, x2); -<br>void fl_xyline(x, y, x1, y1, x2, y3); -</code></h4><ul> +<h4>void fl_xyline(int x, int y, int x1, int y1)<br> +void fl_xyline(int x, int y, int x1, int y1, int x2)<br> +void fl_xyline(int x, int y, int x1, int y1, int x2, int y3)</h4> Draw 1-pixel wide horizontal and vertical lines. A horizontal line is drawn first, then a vertical, then a horizontal. -</ul><h4><code>void fl_yxline(x, y, y1); -<br>void fl_yxline(x, y, y1, x2); -<br>void fl_yxline(x, y, y1, x2, y3); -</code></h4><ul> +<h4>void fl_yxline(int x, int y, int y1)<br> +void fl_yxline(int x, int y, int y1, int x2)<br> +void fl_yxline(int x, int y, int y1, int x2, int y3)</h4> Draw 1-pixel wide vertical and horizontal lines. A vertical line is drawn first, then a horizontal, then a vertical. -</ul><h4><code> -void fl_arc(x, y, w, h, double a1, double a2);<br> -void fl_pie(x, y, w, h, double a1, double a2);<br> -void fl_chord(x, y, w, h, double a1, double a2);</code></h4><ul> +<h4>void fl_arc(int x, int y, int w, int h, double a1, double a2)<br> +void fl_pie(int x, int y, int w, int h, double a1, double a2)<br> +void fl_chord(int x, int y, int w, int h, double a1, double a2)</h4> High-speed ellipse sections. These functions match the rather limited -circle drawing code provided by X and MSWindows. The advantage over using <a -href=#fl_arc>fl_arc</a> is that they are faster because they often use -the hardware, and they draw much nicer small circles, since the small -sizes are often hard-coded bitmaps. +circle drawing code provided by X and MSWindows. The advantage over +using <a href="#fl_arc"><tt>fl_arc</tt></a> is that they are faster +because they often use the hardware, and they draw much nicer small +circles, since the small sizes are often hard-coded bitmaps. <p>If a complete circle is drawn it will fit inside the passed bounding box. The two angles are measured in degrees counterclockwise -from 3'oclock and are the starting and ending angle of the arc, a2 -must be greater or equal to a1. +from 3'oclock and are the starting and ending angle of the arc, <tt>a2</tt> +must be greater or equal to <tt>a1</tt>. -<p>fl_arc draws a 1-pixel thick line (notice this has a different -number of arguments than the <a href=#fl_arc>fl_arc</a> described +<p><tt>fl_arc()</tt> draws a 1-pixel thick line (notice this has a different +number of arguments than the <a href="#fl_arc"><tt>fl_arc()</tt></a> described below. -<p>fl_pie draws a filled-in pie slice. This slice may extend outside -the line drawn by fl_arc, to avoid this use w-1 and h-1. +<p><tt>fl_pie()</tt> draws a filled-in pie slice. This slice may extend outside +the line drawn by <tt>fl_arc</tt>, to avoid this use <tt>w - 1</tt> and +<tt>h - 1</tt>. -<p>fl_chord is not yet implemented. +<p><tt>fl_chord()</tt> is not yet implemented. -</ul><hr><h3>Complex Shapes</h3> +<h3><a name="complex_shapes">Complex Shapes</a></h3> These functions let you draw arbitrary shapes with 2-D linear -transformations. The functionality matches PostScript. The exact -pixels filled in is less defined than for the above calls, so that FLTK -can take advantage of drawing hardware. (Both Xlib and MSWindows round -all the transformed verticies to integers before drawing the line -segments. This severely limits the accuracy of these functions for -complex graphics. Try using OpenGL instead) - -<p><i>All arguments are float.</i> +transformations. The functionality matches that found in Adobe® +PostScript<sup>TM</sup>. The exact pixels filled in is less defined +than for the above calls, so that FLTK can take advantage of drawing +hardware. The transformed vertices are rounded to integers before +drawing the line segments. This severely limits the accuracy of these +functions for complex graphics. Use OpenGL when greater accuracy +and/or performance is required. -</ul><h4><code>void fl_push_matrix(); -<br>void fl_pop_matrix();</code></h4><ul> +<h4>void fl_push_matrix()<br> +void fl_pop_matrix()</h4> Save and restore the current transformation. The maximum depth of the stack is 4. -</ul><h4><code>void fl_scale(x, y); -<br>void fl_scale(x); -<br>void fl_translate(x, y); -<br>void fl_rotate(d); -<br>void fl_mult_matrix(a, b, c, d, x, y);</code></h4><ul> +<h4>void fl_scale(float x, float y)<br> +void fl_scale(float x)<br> +void fl_translate(float x, float y)<br> +void fl_rotate(float d)<br> +void fl_mult_matrix(float a, float b, float c, float d, float x, float y)</h4> -Concat another transformation to the current one. The rotation angle -is in degrees (not radians) counter-clockwise. +Concatenate another transformation onto the current one. The rotation angle +is in degrees (not radians) and is counter-clockwise. -</ul><h4><code>void fl_begin_line(); -<br>void fl_end_line();</code></h4><ul> +<h4>void fl_begin_line()<br> +void fl_end_line()</h4> Start and end drawing 1-pixel thick lines. -</ul><h4><code>void fl_begin_loop(); -<br>void fl_end_loop();</code></h4><ul> +<h4>void fl_begin_loop()<br> +void fl_end_loop()</h4> Start and end drawing a closed sequence of 1-pixel thick lines. -</ul><h4><code>void fl_begin_polygon(); -<br>void fl_end_polygon();</code></h4><ul> +<h4>void fl_begin_polygon()<br> +void fl_end_polygon()</h4> Start and end drawing a convex filled polygon. -</ul><h4><code>void fl_begin_complex_polygon(); -<br>void fl_gap(); -<br>void fl_end_complex_polygon();</code></h4><ul> +<h4>void fl_begin_complex_polygon()<br> +void fl_gap()<br> +void fl_end_complex_polygon()</h4> Start and end drawing a complex filled polygon. This polygon may be concave, may have holes in it, or may be several disconnected pieces. -Call fl_gap() to seperate loops of the path (it is unnecessary but -harmless to call fl_gap() before the first vertex, after the last one, -or several times in a row). For portability, you should only draw -polygons that appear the same whether "even/odd" or "non-zero" -"winding rules" are used to fill them. This mostly means that holes -should be drawn in the opposite direction of the outside. +Call <tt>fl_gap()</tt> to seperate loops of the path (it is unnecessary +but harmless to call <tt>fl_gap()</tt> before the first vertex, after +the last one, or several times in a row). For portability, you should +only draw polygons that appear the same whether "even/odd" or +"non-zero" winding rules are used to fill them. This mostly means that +holes should be drawn in the opposite direction of the outside. -<p><i>fl_gap() should only be called between -fl_begin/end_complex_polygon(). To outline the polygon, use -fl_begin_loop() and replace each fl_gap() with -fl_end_loop();fl_begin_loop().</i> +<p><tt>fl_gap()</tt> should only be called between +<tt>fl_begin_complex_polygon()</tt> and +<tt>fl_end_complex_polygon()</tt>. To outline the polygon, use +<tt>fl_begin_loop()</tt> and replace each <tt>fl_gap()</tt> with +<tt>fl_end_loop();fl_begin_loop()<tt>. -</ul><h4><code>void fl_vertex(x, y);</code></h4><ul> +<h4>void fl_vertex(float x, float y)</h4> Add a single vertex to the current path. -</ul><h4><code>void fl_curve(int x,int y,int x1,int y1,int x2,int -y2,int x3,int y3);</code></h4><ul> +<h4>void fl_curve(float x, float y, float x1, float y1, float x2, float y2, float x3, float y3)</h4> Add a series of points on a Bezier curve to the path. The curve ends -(and two of the points) are at x,y and x3,y3. +(and two of the points) are at <tt>x,y</tt> and <tt>x3,y3</tt>. -</ul><h4><code>void fl_arc(x, y, r, start, end);</code></h4><ul> +<h4>void fl_arc(float x, float y, float r, float start, float end)</h4> Add a series of points to the current path on the arc of a circle (you can get elliptical paths by using scale and rotate before calling -this). <i>x,y</i> are the center of the circle, and <i>r</i> is it's -radius. fl_arc() takes <i>start</i> and <i>end</i> angles that are -measured in degrees counter-clockwise from 3 o'clock. If <i>end</i> -is less than <i>start</i> then it draws clockwise. +this). <tt>x,y</tt> are the center of the circle, and <tt>r</tt> is +its radius. <tt>fl_arc()</tt> takes <tt>start</tt> and <tt>end</tt> +angles that are measured in degrees counter-clockwise from 3 o'clock. +If <tt>end</tt> is less than <tt>start</tt> then it draws the arc in a +clockwise direction. -</ul><h4><code>void fl_circle(x, y, r);</code></h4><ul> +<h4>void fl_circle(float x, float y, float r)</h4> -fl_circle() is equivalent to fl_arc(...,0,360) but may be faster. It -must be the <i>only</i> thing in the path: if you want a circle as -part of a complex polygon you must use fl_arc(). <i>Under Xlib and -MSWindows this draws incorrectly if the transformation is both rotated -and non-square scaled.</i> +<tt>fl_circle()</tt> is equivalent to <tt>fl_arc(...,0,360)</tt> but +may be faster. It must be the <i>only</i> thing in the path: if you +want a circle as part of a complex polygon you must use +<tt>fl_arc()</tt>. <i>This draws incorrectly if the transformation is +both rotated and non-square scaled.</i> -</ul><hr><h3>Text</h3> +<h3><a name="text">Text</a></h3> -All text is drawn in the <a href=#fl_font>current font</a>. It is +All text is drawn in the <a href="#fl_font">current font</a>. It is undefined whether this location or the characters are modified by the current transformation. -</ul><h4><code>void fl_draw(const char*, float x, float y); -<br>void fl_draw(const char*, int n, float x, float y);</code></h4><ul> +<h4>void fl_draw(const char *, float x, float y)<br> +void fl_draw(const char *, int n, float x, float y)</h4> -Draw a null terminated string or an array of <i>n</i> characters +Draw a nul-terminated string or an array of <tt>n</tt> characters starting at the given location. -</ul><h4><code>void fl_draw(const char*, int x,int y,int w,int h, Fl_Align);</code></h4><ul> +<h4>void fl_draw(const char *, int x, int y, int w, int h, Fl_Align)</h4> Fancy string drawing function which is used to draw all the labels. The string is formatted and aligned inside the passed box. Handles '\t' and '\n', expands all other control characters to ^X, and aligns inside or against the edges of the box. See <a -href=Fl_Widget.html#align>Fl_Widget::align()</a> for values for -<i>align</i>. The value FL_ALIGN_INSIDE is ignored, this always -prints inside the box. +href="#Fl_Widget.align"><tt>Fl_Widget::align()</tt></a> for values for +<tt>align</tt>. The value <tt>FL_ALIGN_INSIDE</tt> is ignored, as this +function always prints inside the box. -</ul><h4><code>void fl_measure(const char*, int& w, int& h);</code></h4><ul> +<h4>void fl_measure(const char *, int &w, int &h)</h4> Measure how wide and tall the string will be when printed by the -fl_draw(...align) function. If the incoming w is non-zero it will -wrap to that width. +<tt>fl_draw(...align)</tt> function. If the incoming <tt>w</tt> is +non-zero it will wrap to that width. -</ul><h4><code>int fl_height();</code></h4><ul> +<h4>int fl_height()</h4> Recommended minimum line spacing for the current font. You can also -just use the value of <i>size</i> passed to <a -href=#fl_font>fl_font()</a>. +just use the value of <tt>size</tt> passed to <a href="#fl_font"> +<tt>fl_font()</tt></a>. -</ul><h4><code>int fl_descent();</code></h4><ul> +<h4>int fl_descent()</h4> -Recommended distance above the bottom of a fl_height() tall box to -draw the text at so it looks centered vertically in that box. +Recommended distance above the bottom of a <tt>fl_height()</tt> tall +box to draw the text at so it looks centered vertically in that box. -</ul><h4><code>float fl_width(const char*); -<br>float fl_width(const char*, int n); -<br>float fl_width(uchar);</code></h4><ul> +<h4>float fl_width(const char*)<br> +float fl_width(const char*, int n)<br> +float fl_width(uchar)</h4> -Return the width of a null-terminated string, a sequence of n -characters, and a single character. +Return the width of a nul-terminated string, a sequence of <tt>n</tt> +characters, or a single character. -</ul><h4><code>const char* fl_shortcut_label(ulong);</code></h4><ul> +<h4>const char *fl_shortcut_label(ulong)</h4> Unparse a shortcut value as used by <a -href=Fl_Button.html#shortcut>Fl_Button</a> or <a -href=Fl_Menu.html>Fl_Menu_Item</a> into a human-readable string like -"Alt+N". This only works if the shortcut is a character key or a -numbered Function key. If the shortcut is zero an empty string is -returned. The return value points at a static buffer that is +href="#Fl_Button.shortcut"><tt>Fl_Button</tt></a> or <a +href="#Fl_Menu_Item"><tt>Fl_Menu_Item</tt></a> into a human-readable +string like "Alt+N". This only works if the shortcut is a character +key or a numbered function key. If the shortcut is zero an empty +string is returned. The return value points at a static buffer that is overwritten with each call. -</ul><hr><h3>Fonts</h3> +<h3><a name="fonts">Fonts</a></h3> -</ul><h4><code>void fl_font(int face, int size);</code></h4><ul> +<h4><a name="fl_font">void fl_font(int face, int size)</a></h4> Set the current font, which is then used by the routines described above. You may call this outside a draw context if necessary to call -fl_width(), but on X this will open the display. +<tt>fl_width()</tt>, but on X this will open the display. -<p>The font is identified by a <i>face</i> and a <i>size</i>. The -size of the font is measured in <i>pixels</i> (ie. it is not -"resolution [in]dependent"). Lines should be spaced <i>size</i> +<p>The font is identified by a <tt>face</tt> and a <tt>size</tt>. The +size of the font is measured in <tt>pixels</tt> (i.e. it is not +"resolution [in]dependent"). Lines should be spaced <tt>size</tt> pixels apart (or more). -<p>The <i>face</i> is an index into an internal table. Initially only -the first 16 faces are filled in. There are symbolic names for them: -FL_HELVETICA, FL_TIMES, FL_COURIER, and modifier values FL_BOLD and -FL_ITALIC which can be added to these, and FL_SYMBOL and -FL_ZAPF_DINGBATS. Faces greater than 255 cannot be used in Fl_Widget -labels, since it stores the index as a byte. - -</ul><h4><code>int fl_font();<br> -int fl_size();</code></h4><ul> - -Returns the face and size set by the most recent fl_font(a,b). This -can be used to save/restore the font. - -</ul><h4><code>const char* Fl::get_font(int face);</code></h4><ul> - -Get the string for this face. This string is different for each face. -Under X this value is passed to XListFonts to get all the sizes of -this face. - -</ul><h4><code>const char* Fl::get_font_name(int face, int* attributes=0);</code></h4><ul> +<p>The <tt>face</tt> is an index into an internal table. Initially +only the first 16 faces are filled in. There are symbolic names for +them: <tt>FL_HELVETICA</tt>, <tt>FL_TIMES</tt>, <tt>FL_COURIER</tt>, +and modifier values <tt>FL_BOLD</tt> and <tt>FL_ITALIC</tt> which can +be added to these, and <tt>FL_SYMBOL</tt> and +<tt>FL_ZAPF_DINGBATS</tt>. Faces greater than 255 cannot be used in +<tt>Fl_Widget</tt> labels, since it stores the index as a byte. -Get a human-readable string describing the family of this face. This -is useful if you are presenting a choice to the user. There is no -guarantee that each face has a different name. The return value -points to a static buffer that is overwritten each call. +<h4>int fl_font()<br> +int fl_size()</h4> -<p>The integer pointed to by <i>attributes</i> (if the pointer is not -zero) is set to zero, <code>FL_BOLD</code>(1) or -<code>FL_ITALIC</code>(2) or <code>FL_BOLD|FL_ITALIC</code> (maybe -more attributes will be defined in the future). To locate a "family" -of fonts, search forward and back for a set with non-zero attributes, -these faces along with the face with a zero attribute before them -constitute a family. +Returns the face and size set by the most recent call to +<tt>fl_font(a,b)</tt>. This can be used to save/restore the font. -</ul><h4><code>int get_font_sizes(int face, int*& sizep);</code></h4><ul> +<h3><a name="cursor">Cursor</a></h3> -Return an array of sizes in <i>sizep</i>. The return value is the -length of this array. The sizes are sorted from smallest to largest -and indicate what sizes can be given to fl_font() that will be matched -exactly (fl_font() will pick the closest size for other sizes). A -zero in the first location of the array indicates a scalable font, -where any size works, although the array may list sizes that work -"better" than others. Warning: the returned array points at a static -buffer that is overwritten each call. Under X this will open the -display. - -</ul><h4><code>int Fl::set_font(int face, const char*);</code></h4><ul> - -Change a face. The string pointer is simply stored, the string is not -copied, so the string must be in static memory. - -</ul><h4><code>int Fl::set_font(int face, int from);</code></h4><ul> - -Copy one face to another. - -</ul><h4><code>int Fl::set_fonts(const char* = 0);</code></h4><ul> - -FLTK will open the display, and add every font on the server to the -face table. It will attempt to put "families" of faces together, so -that the normal one is first, followed by bold, italic, and bold -italic. - -<p>The optional argument is a string to describe the set of fonts to -add. Passing NULL will select only fonts that have the ISO8859-1 -character set (and are thus usable by normal text). Passing "-*" will -select all fonts with any encoding as long as they have normal X font -names with dashes in them. Passing "*" will list every font that -exists (on X this may produce some strange output). Other values may -be useful but are system dependent. On MSWindows NULL selects fonts -with ISO8859-1 encoding and non-NULL selects all fonts. - -<p>Return value is how many faces are in the table after this is done. - -</ul><hr><h2>Bitmaps, Pixmaps and Images</h2> - -<a href=images.html#direct>Click here for information on drawing images</a> - -</ul><hr><h3>Cursor</h3> - -</ul><h4><code>void fl_cursor(Fl_Cursor, Fl_Color=FL_WHITE, Fl_Color=FL_BLACK);</code></h4><ul> +<h4>void fl_cursor(Fl_Cursor, Fl_Color = FL_WHITE, Fl_Color = FL_BLACK)</h4> Change the cursor. Depending on the system this may affect the cursor everywhere, or only when it is pointing at the window that is current when you call this. For portability you should change the cursor back -to the default in response to FL_LEAVE events. +to the default in response to <tt>FL_LEAVE</tt> events. -<p>The type Fl_Cursor is an enumeration defined in <a -href=Enumerations.html><Enumerations.H></a>. The +<p>The type <tt>Fl_Cursor</tt> is an enumeration defined in <a +href="#enumerations"><tt><Enumerations.H></tt></a>. The double-headed arrows are bitmaps provided by FLTK on X, the others are provided by system-defined cursors. Under X you can get any XC_cursor -value by passing <code>Fl_Cursor((XC_foo/2)+1)</code>. - -<p><ul> -<li><code>FL_CURSOR_DEFAULT</code> (0) usually an arrow -<li><code>FL_CURSOR_ARROW</code> -<li><code>FL_CURSOR_CROSS</code> - crosshair -<li><code>FL_CURSOR_WAIT</code> - watch or hourglass -<li><code>FL_CURSOR_INSERT</code> - I-beam -<li><code>FL_CURSOR_HAND</code> - hand (uparrow on MSWindows) -<li><code>FL_CURSOR_HELP</code> - question mark -<li><code>FL_CURSOR_MOVE</code> - 4-pointed arrow -<li><code>FL_CURSOR_NS</code> - up/down arrow -<li><code>FL_CURSOR_WE</code> - left/right arrow -<li><code>FL_CURSOR_NWSE</code> - diagonal arrow -<li><code>FL_CURSOR_NESW</code> - diagonal arrow -<li><code>FL_CURSOR_NONE</code> - invisible -</ul> - -</ul><hr><h3>Overlay rectangle</h3> +value by passing <tt>Fl_Cursor((XC_foo/2)+1)</tt>. -</ul><h4><code>void fl_overlay_rect(int x, int y, int w, int h);<br> -void fl_overlay_clear();</code></h4><ul> +<p>The following standard cursors are available: -<p>Big kludge to draw interactive selection rectangles without using -the overlay. FLTK will xor a single rectangle outline over a window. -Calling this will erase any previous rectangle (by xor'ing it), and -then draw the new one. Calling fl_overlay_clear() will erase the -rectangle without drawing a new one. Using this is tricky. You -should make a widget with both a handle() and draw() method. draw() -should call fl_overlay_clear() before doing anything else. Your -handle() method should call window()->make_current() and then -fl_overlay_rect() after FL_DRAG events, and should call -fl_overlay_clear() after a FL_RELEASE event. +<ul> + <li><tt>FL_CURSOR_DEFAULT</tt> - the default cursor, usually an arrow + <li><tt>FL_CURSOR_ARROW</tt> - an arrow pointer + <li><tt>FL_CURSOR_CROSS</tt> - crosshair + <li><tt>FL_CURSOR_WAIT</tt> - watch or hourglass + <li><tt>FL_CURSOR_INSERT</tt> - I-beam + <li><tt>FL_CURSOR_HAND</tt> - hand (uparrow on MSWindows) + <li><tt>FL_CURSOR_HELP</tt> - question mark + <li><tt>FL_CURSOR_MOVE</tt> - 4-pointed arrow + <li><tt>FL_CURSOR_NS</tt> - up/down arrow + <li><tt>FL_CURSOR_WE</tt> - left/right arrow + <li><tt>FL_CURSOR_NWSE</tt> - diagonal arrow + <li><tt>FL_CURSOR_NESW</tt> - diagonal arrow + <li><tt>FL_CURSOR_NONE</tt> - invisible +</ul> -</ul><p><a href = index.html>(back to contents)</a> -</BODY> -</HTML> -<title>Drawing Images in FLTK</title> -<h2>Drawing Images in FLTK</h2> - -To draw images, you can either do it directly from data in your -memory, or you can create <a href=#Fl_Bitmap>Fl_Bitmap</a> or <a -href=#Fl_Image>Fl_Image</a> or <a href=#Fl_Pixmap>Fl_Pixmap</a> -objects. The advantage of drawing directly is that it is more -intuitive, and it is faster if the image data changes more often than -it is redrawn. The advantage of using the object is that FLTK will -cache translated forms of the image (on X it uses a server pixmap) and -thus redrawing it is <i>much</i> faster. - -<a name=direct> -<h2><hr>Direct Image Drawing<br> -#include <FL/fl_draw.H></h2> - -<p>It is undefined whether the location or drawing of the image is +<h3><a name="overlay">Overlays</a></h3> + +<h4>void fl_overlay_rect(int x, int y, int w, int h)<br> +void fl_overlay_clear()</h4> + +These functions allow you to draw interactive selection rectangles +without using the overlay hardware. FLTK will XOR a single rectangle +outline over a window. Calling this will erase any previous rectangle +(by XOR'ing it), and then draw the new one. Calling +<tt>fl_overlay_clear()</tt> will erase the rectangle without drawing a +new one. + +<p>Using this is tricky. You should make a widget with both a +<tt>handle()</tt> and <tt>draw()</tt> method. <tt>draw()</tt> should +call <tt>fl_overlay_clear()</tt> before doing anything else. Your +<tt>handle()</tt> method should call <tt>window()->make_current()</tt> +and then <tt>fl_overlay_rect()</tt> after <tt>FL_DRAG</tt> events, and +should call <tt>fl_overlay_clear()</tt> after a <tt>FL_RELEASE</tt> +event. + +<h2><a name="images">Images</a></h2> + +To draw images, you can either do it directly from data in your memory, +or you can create <a href="#Fl_Bitmap"><tt>Fl_Bitmap</tt></a>, <a +href="#Fl_Image"><tt>Fl_Image</tt></a>, or <a +href="#Fl_Pixmap"><tt>Fl_Pixmap</tt></a> objects. The advantage of +drawing directly is that it is more intuitive, and it is faster if the +image data changes more often than it is redrawn. The advantage of +using the object is that FLTK will cache translated forms of the image +(on X it uses a server pixmap) and thus redrawing is <i>much</i> +faster. + +<h3>Direct Image Drawing</h3> + +It is undefined whether the location or drawing of the image is affected by the current transformation, so you should only call these when it is the identity. -<p><i>All untyped arguments are integers.</i> - -</ul><h4><code> -void fl_draw_bitmap(const uchar*, X, Y, W, H, LD = 0);</code></h4><ul> +<h4>void fl_draw_bitmap(const uchar *, int X, int Y, int W, int H, int LD = 0)</h4> This function is planned but not yet implemented (it may be impossible under X without allocating a pixmap). -<a name=fl_draw_image> -</ul><h4><code> -void fl_draw_image(const uchar*, X, Y, W, H, D = 3, LD = 0);<br> -void fl_draw_image_mono(const uchar*, X, Y, W, H, D = 1, LD = 0); -</code></h4><ul> - -Draw an 8-bit per color rgb image. The pointer points at the "r" data -of the top-left pixel. Data must be in r,g,b order. X, Y are where -to put the top-left corner. W and H define the size of the image. D -is the delta to add to the pointer between pixels, it may be any value -greater or equal to 3, or it can be negative to flip the image -horizontally. LD is the delta to add to the pointer between lines (if -0 is passed it uses W*D), and may be larger than W*D to crop data, or -negative to flip the image vertically. +<h4>void fl_draw_image(const uchar *, int X, int Y, int W, int H, int D = 3, int LD = 0)<br> +void fl_draw_image_mono(const uchar *, int X, int Y, int W, int H, int D = 1, int LD = 0)</h4> + +Draw an 8-bit per color RGB or luminance image. The pointer points at +the "r" data of the top-left pixel. Data must be in <tt>r,g,b</tt> +order. <tt>X,Y</tt> are where to put the top-left corner. <tt>W</tt> +and <tt>H</tt> define the size of the image. <tt>D</tt> is the delta +to add to the pointer between pixels, it may be any value greater or +equal to <tt>3</tt>, or it can be negative to flip the image +horizontally. <tt>LD</tt> is the delta to add to the pointer between +lines (if 0 is passed it uses <tt>W * D</tt>), and may be larger than +<tt>W * D</tt> to crop data, or negative to flip the image vertically. <p>It is highly recommended that you put the following code before the -first show() of <i>any</i> window in your program to get rid of the -dithering if possible: +first <tt>show()</tt> of <i>any</i> window in your program to get rid +of the dithering if possible: -<ul><p><code>Fl::visual(FL_RGB)</code></ul> +<ul><pre> +Fl::visual(FL_RGB); +</pre></ul> -<p>Gray scale (1-channel) images may be drawn. This is done if abs(D) -is less than 3, or by calling <code>fl_draw_image_mono</code>. Only -one 8-bit sample is used for each pixel, and (on screens with -different numbers of bits for red, green, and blue) only gray colors -are used. Setting D greater than 1 will let you display one channel -of a color image. +Gray scale (1-channel) images may be drawn. This is done if +<tt>abs(D)</tt> is less than 3, or by calling +<tt>fl_draw_image_mono()</tt>. Only one 8-bit sample is used for each +pixel, and on screens with different numbers of bits for red, green, +and blue only gray colors are used. Setting <tt>D</tt> greater than 1 +will let you display one channel of a color image. <p><i>The X version does not support all possible visuals.</i> If FLTK cannot draw the image in the current visual it will abort. FLTK supports any visual of 8 bits or less, and all common TrueColor visuals up to 32 bits. -</ul><h4><code> -typedef void (*fl_draw_image_cb)(void*, x, y, w, uchar*);<br> -void fl_draw_image(fl_draw_image_cb, void*, X, Y, W, H, D = 3);<br> -void fl_draw_image_mono(fl_draw_image_cb, void*, X, Y, W, H, D = 1); -</code></h4><ul> +<h4>typedef void (*fl_draw_image_cb)(void *, int x, int y, int w, uchar *)<br> +void fl_draw_image(fl_draw_image_cb, void *, int X, int Y, int W, int H, int D = 3)<br> +void fl_draw_image_mono(fl_draw_image_cb, void *, int X, int Y, int W, int H, int D = 1)</h4> Call the passed function to provide each scan line of the image. This lets you generate the image as it is being drawn, or do arbitrary decompression of stored data (provided it can be decompressed to individual scan lines easily). -<p>The callback is called with the void* user data pointer (this can -be used to point at a structure of information about the image), and -the x, y, and w of the scan line desired from the image. 0,0 is the -upper-left corner (<i>not X,Y</i>). A pointer to a buffer to put the -data into is passed. You must copy w pixels from scanline y, starting -at pixel x, to this buffer. - -<p>Due to cropping, less than the whole image may be requested. So x -may be greater than zero, the first y may be greater than zero, and w -may be less than W. The buffer is long enough to store the entire W*D -pixels, this is for convienence with some decompression schemes where -you must decompress the entire line at once: decompress it into the -buffer, and then if x is not zero, memcpy the data over so the x'th +<p>The callback is called with the <tt>void *</tt> user data pointer +(this can be used to point at a structure of information about the +image), and the <tt>x</tt>, <tt>y</tt>, and <tt>w</tt> of the scan line +desired from the image. 0,0 is the upper-left corner (<i>not +<tt>X,Y</tt></i>). A pointer to a buffer to put the data into is +passed. You must copy <tt>w</tt> pixels from scanline <tt>y</tt>, +starting at pixel <tt>x</tt>, to this buffer. + +<p>Due to cropping, less than the whole image may be requested. So +<tt>x</tt> may be greater than zero, the first <tt>y</tt> may be +greater than zero, and <tt>w</tt> may be less than <tt>W</tt>. The +buffer is long enough to store the entire <tt>W * D</tt> pixels, this +is for convienence with some decompression schemes where you must +decompress the entire line at once: decompress it into the buffer, and +then if <tt>x</tt> is not zero, copy the data over so the <tt>x</tt>'th pixel is at the start of the buffer. -<p>You can assumme the y's will be consecutive, except the first one +<p>You can assumme the <tt>y</tt>'s will be consecutive, except the first one may be greater than zero. -<p>If D is 4 or more, you must fill in the unused bytes with zero. +<p>If <tt>D</tt> is 4 or more, you must fill in the unused bytes with zero. -</ul><h4><code> -int fl_draw_pixmap(char** data, X, Y, Fl_Color=FL_GRAY);</code></h4><ul> +<h4>int fl_draw_pixmap(char **data, int X, int Y, Fl_Color = FL_GRAY)</h4> Draw XPM image data, with the top-left corner at the given position. The images is dithered on 8-bit displays so you won't lose color space for programs displaying both images and pixmaps. This function -returns zero if there was any error decoding the xpm data. +returns zero if there was any error decoding the XPM data. -<p>To use an XPM, do "<code>#include "foo.xpm"</code>" and then -"<code>fl_draw_pixmap(foo, X, Y)</code>". +<p>To use an XPM, do: -<p>In the current version the XPM data is converted to 8-bit full -color and passed through fl_draw_image(). This is obviously not the -most efficient way to do it, and has the same visual limitations as -listed above for fl_draw_image(). Transparent colors are replaced by -the optional Fl_Color argument (this may change in the future). +<ul><pre> +#include "foo.xpm" +... +fl_draw_pixmap(foo, X, Y); +</pre></ul> -<p><a href=xpm.html>FLTK supports some (questionable) enhancements to -the XPM format.</a> +In the current version the XPM data is converted to 8-bit full color +and passed through <tt>fl_draw_image()</tt>. This is obviously not the +most efficient way to do it, and has the same visual limitations as +listed above for <tt>fl_draw_image()</tt>. Transparent colors are +replaced by the optional <tt>Fl_Color</tt> argument (this may change in +the future). -</ul><h4><code> -int fl_measure_pixmap(char** data, int &w, int -&h);</code></h4><ul> +<h4>int fl_measure_pixmap(char **data, int &w, int &h)</h4> -An XPM image contains the dimensions in it's data. This function +An XPM image contains the dimensions in its data. This function finds and returns the width and height. The return value is non-zero if it parsed the dimensions ok, and zero if there is any problem. -</ul> - -<a name=Fl_Bitmap> -<h2><hr>class Fl_Bitmap -<br>#include <FL/Fl_Bitmap.H></h2> +<h3><a name="Fl_Bitmap">class Fl_Bitmap</a></h3> -This object encapsulates the width, height, and bits of an Xbitmap -(XBM), and allows you to make an Fl_Widget use a bitmap as a label, or -to just draw the bitmap directly. <i>Under X it will create an +This object encapsulates the width, height, and bits of an X bitmap +(XBM), and allows you to make an <tt>Fl_Widget</tt> use a bitmap as a +label, or to just draw the bitmap directly. Under X it will create an offscreen pixmap the first time it is drawn, and copy this each -subsequent time it is drawn</i>. +subsequent time it is drawn. -<h4><code>Fl_Bitmap(const char *bits, int W, int H); -<br>Fl_Bitmap(const uchar *bits, int W, int H);</code></h4> +<h4>Fl_Bitmap(const char *bits, int W, int H)<br> +Fl_Bitmap(const uchar *bits, int W, int H)</h4> -Construct from an Xbitmap. The bits pointer is simply copied to the -object, so it must point at persistent storage. I provide two -constructors because various X implementations disagree about the type -of bitmap data. To use an XBM file, -<code>#include "foo.xbm"</code>, and then do "<code>new -Fl_Bitmap(foo_bits,foo_width,foo_height)</code>" +Construct using an X bitmap. The bits pointer is simply copied to the +object, so it must point at persistent storage. The two constructors +are provided because various X implementations disagree about the type +of bitmap data. To use an XBM file use: + +<ul><pre> +#include "foo.xbm" +... +Fl_Bitmap bitmap = new Fl_Bitmap(foo_bits, foo_width, foo_height); +</pre></ul> -<h4><code>~Fl_Bitmap()</code></h4> +<h4>~Fl_Bitmap()</h4> The destructor will destroy any X pixmap created. It does not do anything to the bits data. -<h4><code>void draw(int x, int y, int w, int h, int ox=0, int oy=0);</code></h4> +<h4>void draw(int x, int y, int w, int h, int ox = 0, int oy = 0)</h4> -<i>x,y,w,h</i> indicates a destination rectangle. <i>ox,oy,w,h</i> is -a source rectangle. This source rectangle from the bitmap is drawn in -the destination. 1 bits are drawn with the current color, 0 bits are -unchanged. The source rectangle may extend outside the bitmap (i.e. ox -and oy may be negative and w and h may be bigger than the bitmap) and -this area is left unchanged. +<tt>x,y,w,h</tt> indicates a destination rectangle. <tt>ox,oy,w,h</tt> +is a source rectangle. This source rectangle from the bitmap is drawn +in the destination. 1 bits are drawn with the current color, 0 bits +are unchanged. The source rectangle may extend outside the bitmap +(i.e. <tt>ox</tt> and <tt>oy</tt> may be negative and <tt>w</tt> and +<tt>h</tt> may be bigger than the bitmap) and this area is left +unchanged. -<h4><code>void draw(int x, int y);</code></h4> +<h4>void draw(int x, int y)</h4> -Draws the bitmap with the upper-left corner at <i>x,y</i>. This is -the same as doing <code>draw(x,y,this->w,this->h,0,0)</code>. +Draws the bitmap with the upper-left corner at <tt>x,y</tt>. This is +the same as doing <tt>draw(x,y,this->w,this->h,0,0)</tt>. -<h4><code>void label(Fl_Widget *);</code></h4> +<h4>void label(Fl_Widget *)</h4> -Change the label() and the labeltype() of the widget to draw the -bitmap. 1 bits will be drawn with the labelcolor(), zero bits will be -unchanged. You can use the same bitmap for many widgets. +Change the <tt>label()</tt> and the <tt>labeltype()</tt> of the widget +to draw the bitmap. 1 bits will be drawn with the +<tt>labelcolor()</tt>, zero bits will be unchanged. You can use the +same bitmap for many widgets. -<a name=Fl_Pixmap> -<h2><hr>class Fl_Pixmap -<br>#include <FL/Fl_Pixmap.H></h2> + +<h2><a name="Fl_Pixmap">class Fl_Pixmap</h2> This object encapsulates the data from an XPM image, and allows you to -make an Fl_Widget use a pixmap as a label, or to just draw the pixmap -directly. <i>Under X it will create an offscreen pixmap the first -time it is drawn, and copy this each subsequent time it is drawn</i>. +make an <tt>Fl_Widget</tt> use a pixmap as a label, or to just draw the +pixmap directly. <i>Under X it will create an offscreen pixmap the +first time it is drawn, and copy this each subsequent time it is +drawn</i>. <p>The current implementation converts the pixmap to 8 bit color data -and uses <a href=#fl_draw_image>fl_draw_image()</a> to draw +and uses <a href="#fl_draw_image"><tt>fl_draw_image()</tt></a> to draw it. Thus you will get dithered colors on an 8 bit screen. -<h4><code>Fl_Pixmap(char * const * data);</code></h4> +<h4>Fl_Pixmap(char *const* data)</h4> + +Construct using XPM data. The data pointer is simply copied to the +object, so it must point at persistent storage. To use an XPM file do: -Construct from XPM data. The data pointer is simply copied to the -object, so it must point at persistent storage. To use an XPM file, -<code>#include "foo.xpm"</code>, and then do "<code>new -Fl_Pixmap(foo)</code>" +<ul><pre> +#include <FL/Fl_Pixmap.H> +#include "foo.xpm" +... +Fl_Pixmap pixmap = new Fl_Pixmap(foo); +</ul></pre> -<h4><code>~Fl_Pixmap()</code></h4> +<h4>~Fl_Pixmap()</h4> The destructor will destroy any X pixmap created. It does not do anything to the data. -<h4><code>void draw(int x, int y, int w, int h, int ox=0, int oy=0);</code></h4> +<h4>void draw(int x, int y, int w, int h, int ox = 0, int oy = 0)</h4> -<i>x,y,w,h</i> indicates a destination rectangle. <i>ox,oy,w,h</i> is -a source rectangle. This source rectangle is copied to the -destination. The source rectangle may extend outside the pixmap -(i.e. ox and oy may be negative and w and h may be bigger than the -pixmap) and this area is left unchanged. +<tt>x,y,w,h</tt> indicates a destination rectangle. <tt>ox,oy,w,h</tt> +is a source rectangle. This source rectangle is copied to the +destination. The source rectangle may extend outside the pixmap (i.e. +<tt>ox</tt> and <tt>oy</tt> may be negative and <tt>w</tt> and +<tt>h</tt> may be bigger than the pixmap) and this area is left +unchanged. -<h4><code>void draw(int x, int y);</code></h4> +<h4>void draw(int x, int y)</h4> -Draws the image with the upper-left corner at <i>x,y</i>. This is -the same as doing <code>draw(x,y,this->w,this->h,0,0)</code>. +Draws the image with the upper-left corner at <tt>x,y</tt>. This is +the same as doing <tt>draw(x,y,this->w,this->h,0,0)</tt>. -<h4><code>void label(Fl_Widget *);</code></h4> +<h4>void label(Fl_Widget *)</h4> -Change the label() and the labeltype() of the widget to draw the -pixmap. You can use the same pixmap for many widgets. +Change the <tt>label()</tt> and the <tt>labeltype()</tt> of the widget +to draw the pixmap. You can use the same pixmap for many widgets. -<a name=Fl_Image> -<h2><hr>class Fl_Image -<br>#include <FL/Fl_Image.H></h2> -This object encapsulates a full-color RGB image, and allows you to -make an Fl_Widget use a Image as a label, or to just draw the Image -directly. <i>Under X it will create an offscreen pixmap the first -time it is drawn, and copy this each subsequent time it is drawn</i>. +<H3><a name="Fl_Image">class Fl_Image</a></H3> -<p>See <a href=#fl_draw_image>fl_draw_image()</a> for what -happens. On 8 bit screens dithering is used. +This object encapsulates a full-color RGB image, and allows you to make +an <tt>Fl_Widget</tt> use an image as a label, or to just draw the +image directly. <i>Under X it will create an offscreen pixmap the +first time it is drawn, and copy this each subsequent time it is +drawn</i>. -<h4><code>Fl_Image(char uchar *data, int W, int H, int D=3, int LD=0);</code></h4> +<h4>Fl_Image(char uchar *data, int W, int H, int D = 3, int LD = 0)</h4> -Construct from a pointer to RGB data. W and H are the size of the -image in pixels. D is the delta between pixels (it may be more than 3 -to skip alpha or other data, or negative to flip the image -left/right). LD is the delta between lines (it may be more than D*W -to crop images, or negative to flip the image vertically). The data -pointer is simply copied to the object, so it must point at persistent -storage. +Construct using a pointer to RGB data. <tt>W</tt> and <tt>H</tt> are +the size of the image in pixels. <tt>D</tt> is the delta between +pixels (it may be more than 3 to skip alpha or other data, or negative +to flip the image left/right). <tt>LD</tt> is the delta between lines +(it may be more than <tt>D * W</tt> to crop images, or negative to flip +the image vertically). The data pointer is simply copied to the +object, so it must point at persistent storage. -<h4><code>~Fl_Image()</code></h4> +<h4>~Fl_Image()</h4> The destructor will destroy any X pixmap created. It does not do anything to the data. -<h4><code>void draw(int x, int y, int w, int h, int ox=0, int oy=0);</code></h4> - -<i>x,y,w,h</i> indicates a destination rectangle. <i>ox,oy,w,h</i> is -a source rectangle. This source rectangle is copied to the -destination. The source rectangle may extend outside the image -(i.e. ox and oy may be negative and w and h may be bigger than the -image) and this area is left unchanged. - -<h4><code>void draw(int x, int y);</code></h4> - -Draws the image with the upper-left corner at <i>x,y</i>. This is -the same as doing <code>draw(x,y,this->w,this->h,0,0)</code>. - -<h4><code>void label(Fl_Widget *);</code></h4> - -Change the label() and the labeltype() of the widget to draw the -Image. You can use the same Image for many widgets. - -<p><a href = index.html>(back to contents)</a> -<title>FLTK enhancements to the XPM format</title> -<h2>FLTK enhancements to the XPM format</h2> - -<p>I made some additions to XPM that may be good, or intensely -disliked by X purists. I do not know if the changes are compatable -with current XPM. - -<p>The change was to make a "compressed colormap" that avoids -XParseColor(), and gives the actual color values (which is really what -everybody wants!). Only colormaps of this form, and ones where the -colors are named as "#rrggbb", will be portable to non-X platforms. - -<p>A compressed colormap is indicated by the number of colors being -negative. The colormap is then given as an array of 4*numcolors -characters. Each color is described by 4 characters: the index -character, and the red, green, and blue value (for 2-character indexes -each color needs 5 characters). - -<p>XPM files support a single transparent index. I require this index -to be ' ' (space). To indicate that ' ' is transparent, it should be -first in the color table. To make ' ' not be transparent, put it -somewhere other than first in the table. - -<p>To make the XPM files easily parseable, but still portable to most -C compilers, I suggest the following format: - -<pre> -/* XPM */ -static char * name[] = { -/* width height ncolors chars_per_pixel */ -"64 64 -4 1 ", -/* colormap */ -"\ - \x50\x50\x80\ -.\xff\xff\x00\ -r\xff\x00\x00\ -b\x00\x00\x00", -/* pixels */ -" bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb ", -" bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb ", -" bb............................................bb ", -... -</pre> - -<p>All lines starting with "/*" are optional. Parsers should handle -'\' at the end of the line and \xNN and \NNN characters. This -requires the C compiler to parse \xNN characters. -<HTML> -<BODY> - -<H1>Chapter XXX - Drawing Things in FLTK</H1> - -<h2>When can you draw things in FLTK?</h2> - -There are only certain places you can execute drawing code in FLTK. -Calling these functions at other places will result in undefined -behavior! - -<ul> - -<li>The most common is inside the virtual method <a -href=subclass.html#draw>Fl_Widget::draw()</a>. To write code here, -you must subclass one of the existing Fl_Widget classes and implement -your own version of draw(). - -<p> +<h4>void draw(int x, int y, int w, int h, int ox = 0, int oy = 0)</h4> -<li>You can also write <a href=Boxtypes.html>boxtypes</a> and <a href -= Labeltypes.html>labeltypes</a>. These are small procedures that can be -called by existing Fl_Widget draw() methods. These "types" are -identified by an 8-bit index that is stored in the widget's box(), -labeltype(), and possibly other properties. - -<p> - -<li>You can call <a -href=Fl_Window.html#make_current>Fl_Window::make_current()</a> to do -incremental update of a widget (use <a -href=Fl_Widget.html#window>Fl_Widget::window()</a> to find the -window). <i>Under X this only works for the base Fl_Window class, not -for double buffered, overlay, or OpenGL windows!</i> - -</ul> - -</ul><h2>FLTK Drawing functions<br>#include <FL/fl_draw.H></h2> - -<ul> -<li><a href=#clipping>Clipping</a> -<li><a href=#color>Colors</a> -<li><a href=#fast>Fast Shapes</a> -<li><a href=#vertex>Complex Shapes</a> -<li><a href=#text>Text</a> -<li><a href=images.html>Images</a> -<li><a href=#cursor>Cursor</a> -<li><a href=#overlay>Overlay</a> -<li><a href=Fl_Gl_Window.html#gl_start>Using OpenGL</a> -</ul> - -</ul><hr><h3>Clipping</h3> - -<p>You can limit all your drawing to a rectangular region by calling -fl_clip, and put the drawings back by using fl_pop_clip. This -rectangle is measured in pixels (it is unaffected by the current -transformation matrix). - -<p>In addition, the system may provide clipping when updating windows, -this clip region may be more complex than a simple rectangle. - -</ul><h4><code>void fl_clip(int x, int y, int w, int h);</code></h4><ul> - -Intesect the current clip region with a rectangle and push this new -region onto the stack. - -</ul><h4><code>void fl_pop_clip();</code></h4><ul> - -Restore the previous clip region. <i>You must call fl_pop_clip() once -for every time you call fl_clip(). If you return to FLTK with the -clip stack not empty unpredictable results occur.</i> - -</ul><h4><code>int fl_not_clipped(int x, int y, int w, int h);</code></h4><ul> - -Returns true if any of the rectangle intersects the current clip -region. If this returns false you don't have to draw the object. -<i>On X this returns 2 if the rectangle is partially clipped, and 1 if -it is entirely inside the clip region</i>. - -</ul><h4><code>int fl_clip_box(int x, int y, int w, int h,<br> -    int& X, int& Y, int& W, int& H);</code></h4><ul> - -Intersect the rectangle x,y,w,h with the current clip region and -returns the bounding box of the result in X,Y,W,H. Returns non-zero -if the resulting rectangle is different than the original. This can -be used to limit the necessary drawing to a rectangle. W and H are set to -zero if the rectangle is completely outside the region. - -</ul><hr><h3>Colors</h3> - -</ul><h4><code>void fl_color(Fl_Color);</code></h4><ul> - -<p>Set the color for all subsequent drawing operations. Fl_Color is -an enumeration type, all values are in the range 0-255. This is -<i>not</i> the X pixel, it is an internal table! The table provides -several general colors, a 24-entry gray ramp, and a 5x8x5 color cube. -All of these are named with poorly-documented symbols in <a -href=Enumerations.html><FL/Enumerations.H></a>. - -<p><i>Under X, a color cell will be allocated out of fl_colormap each -time you request an fl_color the first time. If the colormap fills up -then a least-squares algorithim is used to find the closest color.</i> - -</ul><h4><code>Fl_Color fl_color();</code></h4><ul> - -Returns the last fl_color() that was set. This can be used for state -save/restore. - -</ul><h4><code>void Fl::set_color(Fl_Color, uchar r, uchar g, uchar b); -<br>void Fl::get_color(Fl_Color, uchar &, uchar &, uchar &);</code></h4><ul> - -Set or get an entry in the fl_color index table. You can set it to -any 8-bit rgb color. <i>On X, if the index has been requested before, -the pixel is free'd. No pixel is allocated until fl_color(i) is used -again, and there is no guarantee that the same pixel will be used next -time.</i> - -</ul><h4><code>void fl_color(uchar r, uchar g, uchar -b);</code></h4><ul> - -<p>Set the color for all subsequent drawing operations. The closest -possible match to the rgb color is used. <i>Under X this works -perfectly for TrueColor visuals. For colormap visuals the nearest index -in the gray ramp or color cube is figured out, and fl_color(i) is done -with that, this can result in two approximations of the color and is -very inaccurate!</i> - -</ul><hr><h3>Fast Shapes</h3> - -These are used to draw almost all the FLTK widgets. They draw on -exact pixel boundaries and are as fast as possible, and their behavior -will be duplicated exactly on any platform FLTK is ported to. It is -undefined whether these are affected by the <a -href=#vertex>transformation matrix</a>, so you should only call these -while it is the identity. - -<p><i>All arguments are integers.</i> - -</ul><h4><code>void fl_rectf(x, y, w, h);</code></h4><ul> - -Color a rectangle that exactly fills the given bounding box. - -</ul><h4><code>void fl_rectf(x, y, w, h, uchar r, uchar g, uchar b);</code></h4><ul> - -Color a rectangle with "exactly" the passed r,g,b color. On screens -with less than 24 bits of color this is done by drawing a -solid-colored block using <a -href=images.html#fl_draw_image>fl_draw_image()</a> so that dithering -is produced. If you have 24 bit color, this fills the rectangle with a -single pixel value and is about 1 zillion times faster. - -</ul><h4><code>void fl_rect(x, y, w, h);</code></h4><ul> - -Draw a 1-pixel border <i>inside</i> this bounding box. - -</ul><h4><code>void fl_line(x, y, x1, y1); -<br>void fl_line(x, y, x1, y1, x2, y2);</code></h4><ul> - -Draw one or two 1-pixel thick lines between the given points. - -</ul><h4><code>void fl_loop(x, y, x1, y1, x2, y2); -<br>void fl_loop(x, y, x1, y1, x2, y2, x3, y3); -</code></h4><ul> - -Outline a 3 or 4-sided polygon with 1-pixel thick lines. - -</ul><h4><code>void fl_polygon(x, y, x1, y1, x2, y2); -<br>void fl_polygon(x, y, x1, y1, x2, y2, x3, y3); -</code></h4><ul> - -Fill a 3 or 4-sided polygon. The polygon must be convex. +<tt>x,y,w,h</tt> indicates a destination rectangle. <tt>ox,oy,w,h</tt> +is a source rectangle. This source rectangle is copied to the +destination. The source rectangle may extend outside the image (i.e. +<tt>ox</tt> and <tt>oy</tt> may be negative and <tt>w</tt> and +<tt>h</tt> may be bigger than the image) and this area is left +unchanged. -</ul><h4><code>void fl_xyline(x, y, x1, y1); -<br>void fl_xyline(x, y, x1, y1, x2); -<br>void fl_xyline(x, y, x1, y1, x2, y3); -</code></h4><ul> - -Draw 1-pixel wide horizontal and vertical lines. A horizontal line is -drawn first, then a vertical, then a horizontal. - -</ul><h4><code>void fl_yxline(x, y, y1); -<br>void fl_yxline(x, y, y1, x2); -<br>void fl_yxline(x, y, y1, x2, y3); -</code></h4><ul> - -Draw 1-pixel wide vertical and horizontal lines. A vertical line is -drawn first, then a horizontal, then a vertical. - -</ul><h4><code> -void fl_arc(x, y, w, h, double a1, double a2);<br> -void fl_pie(x, y, w, h, double a1, double a2);<br> -void fl_chord(x, y, w, h, double a1, double a2);</code></h4><ul> - -High-speed ellipse sections. These functions match the rather limited -circle drawing code provided by X and MSWindows. The advantage over using <a -href=#fl_arc>fl_arc</a> is that they are faster because they often use -the hardware, and they draw much nicer small circles, since the small -sizes are often hard-coded bitmaps. - -<p>If a complete circle is drawn it will fit inside the passed -bounding box. The two angles are measured in degrees counterclockwise -from 3'oclock and are the starting and ending angle of the arc, a2 -must be greater or equal to a1. - -<p>fl_arc draws a 1-pixel thick line (notice this has a different -number of arguments than the <a href=#fl_arc>fl_arc</a> described -below. - -<p>fl_pie draws a filled-in pie slice. This slice may extend outside -the line drawn by fl_arc, to avoid this use w-1 and h-1. - -<p>fl_chord is not yet implemented. - -</ul><hr><h3>Complex Shapes</h3> - -These functions let you draw arbitrary shapes with 2-D linear -transformations. The functionality matches PostScript. The exact -pixels filled in is less defined than for the above calls, so that FLTK -can take advantage of drawing hardware. (Both Xlib and MSWindows round -all the transformed verticies to integers before drawing the line -segments. This severely limits the accuracy of these functions for -complex graphics. Try using OpenGL instead) - -<p><i>All arguments are float.</i> - -</ul><h4><code>void fl_push_matrix(); -<br>void fl_pop_matrix();</code></h4><ul> - -Save and restore the current transformation. The maximum depth of the -stack is 4. - -</ul><h4><code>void fl_scale(x, y); -<br>void fl_scale(x); -<br>void fl_translate(x, y); -<br>void fl_rotate(d); -<br>void fl_mult_matrix(a, b, c, d, x, y);</code></h4><ul> - -Concat another transformation to the current one. The rotation angle -is in degrees (not radians) counter-clockwise. - -</ul><h4><code>void fl_begin_line(); -<br>void fl_end_line();</code></h4><ul> - -Start and end drawing 1-pixel thick lines. - -</ul><h4><code>void fl_begin_loop(); -<br>void fl_end_loop();</code></h4><ul> - -Start and end drawing a closed sequence of 1-pixel thick lines. - -</ul><h4><code>void fl_begin_polygon(); -<br>void fl_end_polygon();</code></h4><ul> - -Start and end drawing a convex filled polygon. - -</ul><h4><code>void fl_begin_complex_polygon(); -<br>void fl_gap(); -<br>void fl_end_complex_polygon();</code></h4><ul> - -Start and end drawing a complex filled polygon. This polygon may be -concave, may have holes in it, or may be several disconnected pieces. -Call fl_gap() to seperate loops of the path (it is unnecessary but -harmless to call fl_gap() before the first vertex, after the last one, -or several times in a row). For portability, you should only draw -polygons that appear the same whether "even/odd" or "non-zero" -"winding rules" are used to fill them. This mostly means that holes -should be drawn in the opposite direction of the outside. - -<p><i>fl_gap() should only be called between -fl_begin/end_complex_polygon(). To outline the polygon, use -fl_begin_loop() and replace each fl_gap() with -fl_end_loop();fl_begin_loop().</i> - -</ul><h4><code>void fl_vertex(x, y);</code></h4><ul> - -Add a single vertex to the current path. - -</ul><h4><code>void fl_curve(int x,int y,int x1,int y1,int x2,int -y2,int x3,int y3);</code></h4><ul> - -Add a series of points on a Bezier curve to the path. The curve ends -(and two of the points) are at x,y and x3,y3. - -</ul><h4><code>void fl_arc(x, y, r, start, end);</code></h4><ul> - -Add a series of points to the current path on the arc of a circle (you -can get elliptical paths by using scale and rotate before calling -this). <i>x,y</i> are the center of the circle, and <i>r</i> is it's -radius. fl_arc() takes <i>start</i> and <i>end</i> angles that are -measured in degrees counter-clockwise from 3 o'clock. If <i>end</i> -is less than <i>start</i> then it draws clockwise. - -</ul><h4><code>void fl_circle(x, y, r);</code></h4><ul> - -fl_circle() is equivalent to fl_arc(...,0,360) but may be faster. It -must be the <i>only</i> thing in the path: if you want a circle as -part of a complex polygon you must use fl_arc(). <i>Under Xlib and -MSWindows this draws incorrectly if the transformation is both rotated -and non-square scaled.</i> - -</ul><hr><h3>Text</h3> - -All text is drawn in the <a href=#fl_font>current font</a>. It is -undefined whether this location or the characters are modified by the -current transformation. - -</ul><h4><code>void fl_draw(const char*, float x, float y); -<br>void fl_draw(const char*, int n, float x, float y);</code></h4><ul> - -Draw a null terminated string or an array of n characters in the -current font, starting at the given location. - -</ul><h4><code>void fl_draw(const char*, int x,int y,int w,int h, Fl_Align);</code></h4><ul> - -Fancy string drawing function which is used to draw all the labels. -The string is formatted and aligned inside the passed box. Handles -'\t' and '\n', expands all other control characters to ^X, and aligns -inside or against the edges of the box. See <a -href=Fl_Widget.html#align>Fl_Widget::align()</a> for values for -<i>align</i>. The value FL_ALIGN_INSIDE is ignored, this always -prints inside the box. - -</ul><h4><code>void fl_measure(const char*, int& w, int& h);</code></h4><ul> - -Measure how wide and tall the string will be when printed by the -fl_draw(...align) function. If the incoming w is non-zero it will -wrap to that width. - -</ul><h4><code>int fl_height();</code></h4><ul> - -Recommended minimum line spacing for the current font. You can also -just use the value of <i>size</i> passed to <a -href=#fl_font>fl_font()</a>. - -</ul><h4><code>int fl_descent();</code></h4><ul> - -Recommended distance above the bottom of a fl_height() tall box to -draw the text at so it looks centered vertically in that box. - -</ul><h4><code>float fl_width(const char*); -<br>float fl_width(const char*, int n); -<br>float fl_width(uchar);</code></h4><ul> - -Return the width of a null-terminated string, a sequence of n -characters, and a single character. - -</ul><h4><code>const char* fl_shortcut_label(ulong);</code></h4><ul> - -Unparse a shortcut value as used by <a -href=Fl_Button.html#shortcut>Fl_Button</a> or <a -href=Fl_Menu.html>Fl_Menu_Item</a> into a human-readable string like -"Alt+N". This only works if the shortcut is a character key or a -numbered Function key. If the shortcut is zero an empty string is -returned. The return value points at a static buffer that is -overwritten with each call. - -</ul><hr><h3>Fonts</h3> - -</ul><h4><code>void fl_font(int face, int size);</code></h4><ul> - -Set the current font, which is then used by the routines described -above. You may call this outside a draw context if necessary to call -fl_width(), but on X this will open the display. - -<p>The font is identified by a <i>face</i> and a <i>size</i>. The -size of the font is measured in <i>pixels</i> (ie. it is not -"resolution [in]dependent"). Lines should be spaced <i>size</i> -pixels apart (or more). - -<p>The <i>face</i> is an index into an internal table. Initially only -the first 16 faces are filled in. There are symbolic names for them: -FL_HELVETICA, FL_TIMES, FL_COURIER, and modifier values FL_BOLD and -FL_ITALIC which can be added to these, and FL_SYMBOL and -FL_ZAPF_DINGBATS. Faces greater than 255 cannot be used in Fl_Widget -labels, since it stores the index as a byte. - -</ul><h4><code>int fl_font();<br> -int fl_size();</code></h4><ul> - -Returns the face and size set by the most recent fl_font(a,b). This -can be used to save/restore the font. - -</ul><h4><code>const char* Fl::get_font(int face);</code></h4><ul> - -Get the string for this face. This string is different for each face. -Under X this value is passed to XListFonts to get all the sizes of -this face. - -</ul><h4><code>const char* Fl::get_font_name(int face, int* attributes=0);</code></h4><ul> - -Get a human-readable string describing the family of this face. This -is useful if you are presenting a choice to the user. There is no -guarantee that each face has a different name. The return value -points to a static buffer that is overwritten each call. - -<p>The integer pointed to by <i>attributes</i> (if the pointer is not -zero) is set to zero, <code>FL_BOLD</code>(1) or -<code>FL_ITALIC</code>(2) or <code>FL_BOLD|FL_ITALIC</code> (maybe -more attributes will be defined in the future). To locate a "family" -of fonts, search forward and back for a set with non-zero attributes, -these faces along with the face with a zero attribute before them -constitute a family. - -</ul><h4><code>int get_font_sizes(int face, int*& sizep);</code></h4><ul> - -Return an array of sizes in <i>sizep</i>. The return value is the -length of this array. The sizes are sorted from smallest to largest -and indicate what sizes can be given to fl_font() that will be matched -exactly (fl_font() will pick the closest size for other sizes). A -zero in the first location of the array indicates a scalable font, -where any size works, although the array may list sizes that work -"better" than others. Warning: the returned array points at a static -buffer that is overwritten each call. Under X this will open the -display. - -</ul><h4><code>int Fl::set_font(int face, const char*);</code></h4><ul> - -Change a face. The string pointer is simply stored, the string is not -copied, so the string must be in static memory. - -</ul><h4><code>int Fl::set_font(int face, int from);</code></h4><ul> - -Copy one face to another. - -</ul><h4><code>int Fl::set_fonts(const char* = 0);</code></h4><ul> - -FLTK will open the display, and add every font on the server to the -face table. It will attempt to put "families" of faces together, so -that the normal one is first, followed by bold, italic, and bold -italic. - -<p>The optional argument is a string to describe the set of fonts to -add. Passing NULL will select only fonts that have the ISO8859-1 -character set (and are thus usable by normal text). Passing "-*" will -select all fonts with any encoding as long as they have normal X font -names with dashes in them. Passing "*" will list every font that -exists (on X this may produce some strange output). Other values may -be useful but are system dependent. On MSWindows NULL selects fonts -with ISO8859-1 encoding and non-NULL selects all fonts. - -<p>Return value is how many faces are in the table after this is done. - -</ul><hr><h2>Bitmaps, Pixmaps and Images</h2> - -<a href=images.html#direct>Click here for information on drawing images</a> - -</ul><hr><h3>Cursor</h3> - -</ul><h4><code>void fl_cursor(Fl_Cursor, Fl_Color=FL_WHITE, Fl_Color=FL_BLACK);</code></h4><ul> - -Change the cursor. Depending on the system this may affect the cursor -everywhere, or only when it is pointing at the window that is current -when you call this. For portability you should change the cursor back -to the default in response to FL_LEAVE events. - -<p>The type Fl_Cursor is an enumeration defined in <a -href=Enumerations.html><Enumerations.H></a>. The -double-headed arrows are bitmaps provided by FLTK on X, the others are -provided by system-defined cursors. Under X you can get any XC_cursor -value by passing <code>Fl_Cursor((XC_foo/2)+1)</code>. - -<p><ul> -<li><code>FL_CURSOR_DEFAULT</code> (0) usually an arrow -<li><code>FL_CURSOR_ARROW</code> -<li><code>FL_CURSOR_CROSS</code> - crosshair -<li><code>FL_CURSOR_WAIT</code> - watch or hourglass -<li><code>FL_CURSOR_INSERT</code> - I-beam -<li><code>FL_CURSOR_HAND</code> - hand (uparrow on MSWindows) -<li><code>FL_CURSOR_HELP</code> - question mark -<li><code>FL_CURSOR_MOVE</code> - 4-pointed arrow -<li><code>FL_CURSOR_NS</code> - up/down arrow -<li><code>FL_CURSOR_WE</code> - left/right arrow -<li><code>FL_CURSOR_NWSE</code> - diagonal arrow -<li><code>FL_CURSOR_NESW</code> - diagonal arrow -<li><code>FL_CURSOR_NONE</code> - invisible -</ul> +<h4>void draw(int x, int y)</h4> -</ul><hr><h3>Overlay rectangle</h3> +Draws the image with the upper-left corner at <tt>x,y</tt>. This is +the same as doing <tt>draw(x,y,this->w,this->h,0,0)</tt>. -</ul><h4><code>void fl_overlay_rect(int x, int y, int w, int h);<br> -void fl_overlay_clear();</code></h4><ul> +<h4>void label(Fl_Widget *)</h4> -<p>Big kludge to draw interactive selection rectangles without using -the overlay. FLTK will xor a single rectangle outline over a window. -Calling this will erase any previous rectangle (by xor'ing it), and -then draw the new one. Calling fl_overlay_clear() will erase the -rectangle without drawing a new one. Using this is tricky. You -should make a widget with both a handle() and draw() method. draw() -should call fl_overlay_clear() before doing anything else. Your -handle() method should call window()->make_current() and then -fl_overlay_rect() after FL_DRAG events, and should call -fl_overlay_clear() after a FL_RELEASE event. +Change the <tt>label()</tt> and the <tt>labeltype()</tt> of the widget +to draw the image. You can use the same image for many widgets. -</ul><p><a href = index.html>(back to contents)</a> </BODY> </HTML> diff --git a/documentation/editor.html b/documentation/editor.html index 60dca040c..5c31a16e7 100644 --- a/documentation/editor.html +++ b/documentation/editor.html @@ -1,7 +1,7 @@ <HTML> <BODY> -<H1 ALIGN=RIGHT>4 - Designing a Simple Text Editor</H1> +<H1 ALIGN=RIGHT><A NAME="editor">4 - Designing a Simple Text Editor</A></H1> This chapter takes you through the design of a simple FLTK-based text editor. @@ -295,7 +295,7 @@ We call the <tt>load_file()</tt> function to actually load the file. <H3>paste_cb()</H3> This callback function will send a FL_PASTE message to the <tt>input</tt> -widget using the <a href="#paste"><tt>Fl::paste()</tt> method: +widget using the <a href="#paste"><tt>Fl::paste()</tt></a> method: <ul><pre> void paste_cb(void) { @@ -514,7 +514,7 @@ void load_file(char *newfile) { </pre></ul> When loading the file we use the <a href="#Fl_Input_.replace"> -<tt>input->replace()</tt> method to "replace" the text at the end of +<tt>input->replace()</tt></a> method to "replace" the text at the end of the buffer. The <tt>pos</tt> variable keeps track of the end of the buffer. diff --git a/documentation/enumerations.html b/documentation/enumerations.html index 355437a73..8d303bcc8 100644 --- a/documentation/enumerations.html +++ b/documentation/enumerations.html @@ -1,328 +1,373 @@ <HTML> <BODY> -<H1><A NAME="enumerations">C - FLTK Enumerations.H</A></H1> - -Here are the values of all the public-visible enumerations used by fltk: - -<pre> -#include <FL/Enumerations.H> - -// -// The FLTK version number; this is changed slightly from the beta versions -// because the old "const double" definition would not allow for conditional -// compilation... -// -// FL_VERSION is a double that describes the major and minor version numbers. -// Version 1.1 is actually stored as 1.01 to allow for more than 9 minor -// releases. -// -// The FL_MAJOR_VERSION, FL_MINOR_VERSION, and FL_PATCH_VERSION constants -// give the integral values for the major, minor, and patch releases -// respectively. -// - -#define FL_MAJOR_VERSION 1 -#define FL_MINOR_VERSION 0 -#define FL_PATCH_VERSION 0 -#define FL_VERSION ((double)FL_MAJOR_VERSION + \ - (double)FL_MINOR_VERSION * 0.01) - -typedef unsigned char uchar; -typedef unsigned long ulong; -typedef unsigned int u32; // you must fix if not 32 bits on your machine! - -enum Fl_Event { // events - FL_NO_EVENT = 0, - FL_PUSH = 1, - FL_RELEASE = 2, - FL_ENTER = 3, - FL_LEAVE = 4, - FL_DRAG = 5, - FL_FOCUS = 6, - FL_UNFOCUS = 7, - FL_KEYBOARD = 8, - FL_CLOSE = 9, - FL_MOVE = 10, - FL_SHORTCUT = 11, - FL_DEACTIVATE = 13, - FL_ACTIVATE = 14, - FL_HIDE = 15, - FL_SHOW = 16, - FL_PASTE = 17, - FL_SELECTIONCLEAR = 18 -}; - -enum Fl_When { // Fl_Widget::when(): - FL_WHEN_NEVER = 0, - FL_WHEN_CHANGED = 1, - FL_WHEN_RELEASE = 4, - FL_WHEN_RELEASE_ALWAYS= 6, - FL_WHEN_ENTER_KEY = 8, - FL_WHEN_ENTER_KEY_ALWAYS=10, - FL_WHEN_NOT_CHANGED = 2 // modifier bit to disable changed() test -}; - -// Fl::event_key() and Fl::get_key(n) (use ascii letters for all other keys): -#define FL_Button 0xfee8 // use Fl_Button+n for mouse button n -#define FL_BackSpace 0xff08 -#define FL_Tab 0xff09 -#define FL_Enter 0xff0d -#define FL_Pause 0xff13 -#define FL_Scroll_Lock 0xff14 -#define FL_Escape 0xff1b -#define FL_Home 0xff50 -#define FL_Left 0xff51 -#define FL_Up 0xff52 -#define FL_Right 0xff53 -#define FL_Down 0xff54 -#define FL_Page_Up 0xff55 -#define FL_Page_Down 0xff56 -#define FL_End 0xff57 -#define FL_Print 0xff61 -#define FL_Insert 0xff63 -#define FL_Menu 0xff67 // the "menu/apps" key on XFree86 -#define FL_Num_Lock 0xff7f -#define FL_KP 0xff80 // use FL_KP+'x' for 'x' on numeric keypad -#define FL_KP_Enter 0xff8d // same as Fl_KP+'\r' -#define FL_KP_Last 0xffbd // use to range-check keypad -#define FL_F 0xffbd // use FL_F+n for function key n -#define FL_F_Last 0xffe0 // use to range-check function keys -#define FL_Shift_L 0xffe1 -#define FL_Shift_R 0xffe2 -#define FL_Control_L 0xffe3 -#define FL_Control_R 0xffe4 -#define FL_Caps_Lock 0xffe5 -#define FL_Meta_L 0xffe7 // the left MSWindows key on XFree86 -#define FL_Meta_R 0xffe8 // the right MSWindows key on XFree86 -#define FL_Alt_L 0xffe9 -#define FL_Alt_R 0xffea -#define FL_Delete 0xffff - -// Fl::event_state(): -#define FL_SHIFT 0x00010000 -#define FL_CAPS_LOCK 0x00020000 -#define FL_CTRL 0x00040000 -#define FL_ALT 0x00080000 -#define FL_NUM_LOCK 0x00100000 // most X servers do this? -#define FL_META 0x00400000 // correct for XFree86 -#define FL_SCROLL_LOCK 0x00800000 // correct for XFree86 -#define FL_BUTTON1 0x01000000 -#define FL_BUTTON2 0x02000000 -#define FL_BUTTON3 0x04000000 - -enum Fl_Boxtype { // boxtypes (if you change these you must fix fl_boxtype.C): - FL_NO_BOX = 0, FL_FLAT_BOX, - - FL_UP_BOX, FL_DOWN_BOX, - FL_UP_FRAME, FL_DOWN_FRAME, - FL_THIN_UP_BOX, FL_THIN_DOWN_BOX, - FL_THIN_UP_FRAME, FL_THIN_DOWN_FRAME, - FL_ENGRAVED_BOX, FL_EMBOSSED_BOX, - FL_ENGRAVED_FRAME, FL_EMBOSSED_FRAME, - FL_BORDER_BOX, _FL_SHADOW_BOX, - FL_BORDER_FRAME, _FL_SHADOW_FRAME, - _FL_ROUNDED_BOX, _FL_RSHADOW_BOX, - _FL_ROUNDED_FRAME, _FL_RFLAT_BOX, - _FL_ROUND_UP_BOX, _FL_ROUND_DOWN_BOX, - _FL_DIAMOND_UP_BOX, _FL_DIAMOND_DOWN_BOX, - _FL_OVAL_BOX, _FL_OSHADOW_BOX, - _FL_OVAL_FRAME, _FL_OFLAT_BOX -}; -extern Fl_Boxtype define_FL_ROUND_UP_BOX(); -#define FL_ROUND_UP_BOX define_FL_ROUND_UP_BOX() -#define FL_ROUND_DOWN_BOX (Fl_Boxtype)(define_FL_ROUND_UP_BOX()+1) -extern Fl_Boxtype define_FL_SHADOW_BOX(); -#define FL_SHADOW_BOX define_FL_SHADOW_BOX() -#define FL_SHADOW_FRAME (Fl_Boxtype)(define_FL_SHADOW_BOX()+2) -extern Fl_Boxtype define_FL_ROUNDED_BOX(); -#define FL_ROUNDED_BOX define_FL_ROUNDED_BOX() -#define FL_ROUNDED_FRAME (Fl_Boxtype)(define_FL_ROUNDED_BOX()+2) -extern Fl_Boxtype define_FL_RFLAT_BOX(); -#define FL_RFLAT_BOX define_FL_RFLAT_BOX() -extern Fl_Boxtype define_FL_RSHADOW_BOX(); -#define FL_RSHADOW_BOX define_FL_RSHADOW_BOX() -extern Fl_Boxtype define_FL_DIAMOND_BOX(); -#define FL_DIAMOND_UP_BOX define_FL_DIAMOND_BOX() -#define FL_DIAMOND_DOWN_BOX (Fl_Boxtype)(define_FL_DIAMOND_BOX()+1) -extern Fl_Boxtype define_FL_OVAL_BOX(); -#define FL_OVAL_BOX define_FL_OVAL_BOX() -#define FL_OSHADOW_BOX (Fl_Boxtype)(define_FL_OVAL_BOX()+1) -#define FL_OVAL_FRAME (Fl_Boxtype)(define_FL_OVAL_BOX()+2) -#define FL_OFLAT_BOX (Fl_Boxtype)(define_FL_OVAL_BOX()+3) - -// conversions of box types to other boxtypes: -inline Fl_Boxtype down(Fl_Boxtype b) {return (Fl_Boxtype)(b|1);} -inline Fl_Boxtype frame(Fl_Boxtype b) {return (Fl_Boxtype)(b|2);} - -// back-compatability box types: -#define FL_FRAME FL_ENGRAVED_FRAME -#define FL_FRAME_BOX FL_ENGRAVED_BOX -#define FL_CIRCLE_BOX FL_ROUND_DOWN_BOX -#define FL_DIAMOND_BOX FL_DIAMOND_DOWN_BOX - -enum Fl_Labeltype { // labeltypes: - FL_NORMAL_LABEL = 0, - FL_NO_LABEL, - _FL_SYMBOL_LABEL, - _FL_SHADOW_LABEL, - _FL_ENGRAVED_LABEL, - _FL_EMBOSSED_LABEL, - _FL_BITMAP_LABEL, - _FL_PIXMAP_LABEL, - _FL_IMAGE_LABEL, - _FL_MULTI_LABEL, - FL_FREE_LABELTYPE -}; -extern Fl_Labeltype define_FL_SYMBOL_LABEL(); -#define FL_SYMBOL_LABEL define_FL_SYMBOL_LABEL() -extern Fl_Labeltype define_FL_SHADOW_LABEL(); -#define FL_SHADOW_LABEL define_FL_SHADOW_LABEL() -extern Fl_Labeltype define_FL_ENGRAVED_LABEL(); -#define FL_ENGRAVED_LABEL define_FL_ENGRAVED_LABEL() -extern Fl_Labeltype define_FL_EMBOSSED_LABEL(); -#define FL_EMBOSSED_LABEL define_FL_EMBOSSED_LABEL() - -enum Fl_Align { // align() values - FL_ALIGN_CENTER = 0, - FL_ALIGN_TOP = 1, - FL_ALIGN_BOTTOM = 2, - FL_ALIGN_LEFT = 4, - FL_ALIGN_RIGHT = 8, - FL_ALIGN_INSIDE = 16, - FL_ALIGN_CLIP = 64, - FL_ALIGN_WRAP = 128, - FL_ALIGN_TOP_LEFT = FL_ALIGN_TOP | FL_ALIGN_LEFT, - FL_ALIGN_TOP_RIGHT = FL_ALIGN_TOP | FL_ALIGN_RIGHT, - FL_ALIGN_BOTTOM_LEFT = FL_ALIGN_BOTTOM | FL_ALIGN_LEFT, - FL_ALIGN_BOTTOM_RIGHT = FL_ALIGN_BOTTOM | FL_ALIGN_RIGHT, - FL_ALIGN_LEFT_TOP = FL_ALIGN_TOP_LEFT, - FL_ALIGN_RIGHT_TOP = FL_ALIGN_TOP_RIGHT, - FL_ALIGN_LEFT_BOTTOM = FL_ALIGN_BOTTOM_LEFT, - FL_ALIGN_RIGHT_BOTTOM = FL_ALIGN_BOTTOM_RIGHT, - FL_ALIGN_NOWRAP = 0 // for back compatability -}; - -enum Fl_Font { // standard fonts - FL_HELVETICA = 0, - FL_HELVETICA_BOLD, - FL_HELVETICA_ITALIC, - FL_HELVETICA_BOLD_ITALIC, - FL_COURIER, - FL_COURIER_BOLD, - FL_COURIER_ITALIC, - FL_COURIER_BOLD_ITALIC, - FL_TIMES, - FL_TIMES_BOLD, - FL_TIMES_ITALIC, - FL_TIMES_BOLD_ITALIC, - FL_SYMBOL, - FL_SCREEN, - FL_SCREEN_BOLD, - FL_ZAPF_DINGBATS, - - FL_FREE_FONT = 16, // first one to allocate - FL_BOLD = 1, // add this to helvetica, courier, or times - FL_ITALIC = 2 // add this to helvetica, courier, or times -}; - -#define FL_NORMAL_SIZE 14 // default size of all labels & text - -enum Fl_Color { // standard colors - FL_BLACK = 0, - FL_RED = 1, - FL_GREEN = 2, - FL_YELLOW = 3, - FL_BLUE = 4, - FL_MAGENTA = 5, - FL_CYAN = 6, - FL_WHITE = 7, - FL_INACTIVE_COLOR = 8, - FL_SELECTION_COLOR = 15, - - FL_FREE_COLOR = 16, - FL_NUM_FREE_COLOR = 16, - - FL_GRAY_RAMP = 32, - - // boxtypes limit themselves to these colors so whole ramp is not allocated: - FL_GRAY0 = 32, // 'A' - FL_DARK3 = 39, // 'H' - FL_DARK2 = 45, // 'N' - FL_DARK1 = 47, // 'P' - FL_GRAY = 49, // 'R' default color - FL_LIGHT1 = 50, // 'S' - FL_LIGHT2 = 52, // 'U' - FL_LIGHT3 = 54, // 'W' - - FL_COLOR_CUBE = 56 -}; - -inline Fl_Color inactive(Fl_Color c) {return (Fl_Color)(c|8);} -Fl_Color contrast(Fl_Color fg, Fl_Color bg); -#define FL_NUM_GRAY 24 -inline Fl_Color fl_gray_ramp(int i) {return (Fl_Color)(i+FL_GRAY_RAMP);} -#define FL_NUM_RED 5 -#define FL_NUM_GREEN 8 -#define FL_NUM_BLUE 5 -inline Fl_Color fl_color_cube(int r, int g, int b) { - return (Fl_Color)((b*FL_NUM_RED + r) * FL_NUM_GREEN + g + FL_COLOR_CUBE);} - -enum Fl_Cursor { // standard cursors - FL_CURSOR_DEFAULT = 0, - FL_CURSOR_ARROW = 35, - FL_CURSOR_CROSS = 66, - FL_CURSOR_WAIT = 76, - FL_CURSOR_INSERT = 77, - FL_CURSOR_HAND = 31, - FL_CURSOR_HELP = 47, - FL_CURSOR_MOVE = 27, - // fltk provides bitmaps for these: - FL_CURSOR_NS = 78, - FL_CURSOR_WE = 79, - FL_CURSOR_NWSE = 80, - FL_CURSOR_NESW = 81, - FL_CURSOR_NONE = 255, - // for back compatability (non MSWindows ones): - FL_CURSOR_N = 70, - FL_CURSOR_NE = 69, - FL_CURSOR_E = 49, - FL_CURSOR_SE = 8, - FL_CURSOR_S = 9, - FL_CURSOR_SW = 7, - FL_CURSOR_W = 36, - FL_CURSOR_NW = 68 - //FL_CURSOR_NS = 22, - //FL_CURSOR_WE = 55, -}; - -enum { // values for "when" passed to Fl::add_fd() - FL_READ = 1, - FL_WRITE = 4, - FL_EXCEPT = 8 -}; - -enum Fl_Mode { // visual types and Fl_Gl_Window::mode() (values match Glut) - FL_RGB = 0, - FL_INDEX = 1, - FL_SINGLE = 0, - FL_DOUBLE = 2, - FL_ACCUM = 4, - FL_ALPHA = 8, - FL_DEPTH = 16, - FL_STENCIL = 32, - FL_RGB8 = 64, - FL_MULTISAMPLE= 128 -}; - -// damage masks - -enum Fl_Damage { - FL_DAMAGE_CHILD = 0x01, - FL_DAMAGE_EXPOSE = 0x02, - FL_DAMAGE_SCROLL = 0x04, - FL_DAMAGE_OVERLAY = 0x08, - FL_DAMAGE_ALL = 0x80 -}; -</pre> +<H1 ALIGN=RIGHT><A NAME="enumerations">C - FLTK Enumerations.H</A></H1> + +This appendix lists the enumerations provided in the +<tt><FL/Enumerations.H></tt> header file, organized by section. + +<H2>Version Numbers</H2> + +The FLTK version number is stored in a number of compile-time constants: + +<ul> + + <li><tt>FL_MAJOR_VERSION</tt> - The major release number, currently + 1. + + <li><tt>FL_MINOR_VERSION</tt> - The minor release number, currently + 0. + + <li><tt>FL_PATCH_VERSION</tt> - The patch release number, currently + 0. + + <li><tt>FL_VERSION</tt> - A combined floating-point version + number for the major and minor release numbers, currently 1.0. + +</ul> + +<H2>Events</H2> + +Events are identified by an <tt>Fl_Event</tt> enumeration value. The +following events are currently defined: + +<ul> + + <li><tt>FL_NO_EVENT</tt> - No event occurred. + + <li><tt>FL_PUSH</tt> - A mouse button was pushed. + + <li><tt>FL_RELEASE</tt> - A mouse button was released. + + <li><tt>FL_ENTER</tt> - The mouse pointer entered a widget. + + <li><tt>FL_LEAVE</tt> - The mouse pointer left a widget. + + <li><tt>FL_DRAG</tt> - The mouse pointer was moved with a button + pressed. + + <li><tt>FL_FOCUS</tt> - A widget should receive keyboard focus. + + <li><tt>FL_UNFOCUS</tt> - A widget loses keyboard focus. + + <li><tt>FL_KEYBOARD</tt> - A key was pressed. + + <li><tt>FL_CLOSE</tt> - A window was closed. + + <li><tt>FL_MOVE</tt> - The mouse pointer was moved with no buttons + pressed. + + <li><tt>FL_SHORTCUT</tt> - The user pressed a shortcut key. + + <li><tt>FL_DEACTIVATE</tt> - The widget has been deactivated. + + <li><tt>FL_ACTIVATE</tt> - The widget has been activated. + + <li><tt>FL_HIDE</tt> - The widget has been hidden. + + <li><tt>FL_SHOW</tt> - The widget has been shown. + + <li><tt>FL_PASTE</tt> - The widget should paste the contents of the + clipboard. + + <li><tt>FL_SELECTIONCLEAR</tt> - The widget should clear any selections + made for the clipboard. + +</ul> + +<H2>Callback "When" Conditions</H2> + +The following constants determine when a callback is performed: + +<ul> + + <li><tt>FL_WHEN_NEVER</tt> - Never call the callback. + + <li><tt>FL_WHEN_CHANGED</tt> - Do the callback only when the + widget value changes. + + <li><tt>FL_WHEN_NOT_CHANGED</tt> - Do the callback whenever the + user interacts with the widget. + + <li><tt>FL_WHEN_RELEASE</tt> - Do the callback when the button or + key is released and the value changes. + + <li><tt>FL_WHEN_ENTER_KEY</tt> - Do the callback when the user presses + the ENTER key and the value changes. + + <li><tt>FL_WHEN_RELEASE_ALWAYS</tt> - Do the callback when the button + or key is released, even if the value doesn't change. + + <li><tt>FL_WHEN_ENTER_KEY_ALWAYS</tt> - Do the callback when the user + presses the ENTER key, even if the value doesn't change. + +</ul> + +<H2>Fl::event_key() Values</H2> + +The following constants define the non-ASCII keys on the keyboard for +<tt>FL_KEYBOARD</tt> and <tt>FL_SHORTCUT</tt> events: + +<ul> + + <li><tt>FL_Button</tt> - A mouse button; use <tt>Fl_Button + + n</tt> for mouse button <tt>n</tt>. + + <li><tt>FL_BackSpace</tt> - The backspace key. + + <li><tt>FL_Tab</tt> - The tab key. + + <li><tt>FL_Enter</tt> - The enter key. + + <li><tt>FL_Pause</tt> - The pause key. + + <li><tt>FL_Scroll_Lock</tt> - The scroll lock key. + + <li><tt>FL_Escape</tt> - The escape key. + + <li><tt>FL_Home</tt> - The home key. + + <li><tt>FL_Left</tt> - The left arrow key. + + <li><tt>FL_Up</tt> - The up arrow key. + + <li><tt>FL_Right</tt> - The right arrow key. + + <li><tt>FL_Down</tt> - The down arrow key. + + <li><tt>FL_Page_Up</tt> - The page-up key. + + <li><tt>FL_Page_Down</tt> - The page-down key. + + <li><tt>FL_End</tt> - The end key. + + <li><tt>FL_Print</tt> - The print (or print-screen) key. + + <li><tt>FL_Insert</tt> - The insert key. + + <li><tt>FL_Menu</tt> - The menu key. + + <li><tt>FL_Num_Lock</tt> - The num lock key. + + <li><tt>FL_KP</tt> - One of the keypad numbers; use <tt>FL_KP + + n</tt> for number <tt>n</tt>. + + <li><tt>FL_KP_Enter</tt> - The enter key on the keypad. + + <li><tt>FL_F</tt> - One of the function keys; use <tt>FL_F + + n</tt> for function key <tt>n</tt>. + + <li><tt>FL_Shift_L</tt> - The lefthand shift key. + + <li><tt>FL_Shift_R</tt> - The righthand shift key. + + <li><tt>FL_Control_L</tt> - The lefthand control key. + + <li><tt>FL_Control_R</tt> - The righthand control key. + + <li><tt>FL_Caps_Lock</tt> - The caps lock key. + + <li><tt>FL_Meta_L</tt> - The left meta/Windows key. + + <li><tt>FL_Meta_R</tt> - The right meta/Windows key. + + <li><tt>FL_Alt_L</tt> - The left alt key. + + <li><tt>FL_Alt_R</tt> - The right alt key. + + <li><tt>FL_Delete</tt> - The delete key. + +</ul> + +<H2>Fl::event_state() Values</H2> + +The following constants define bits in the <tt>Fl::event_state()</tt> +value: + +<ul> + + <li><tt>FL_SHIFT</tt> - One of the shift keys is down. + + <li><tt>FL_CAPS_LOCK</tt> - The caps lock is on. + + <li><tt>FL_CTRL</tt> - One of the ctrl keys is down. + + <li><tt>FL_ALT</tt> - One of the alt keys is down. + + <li><tt>FL_NUM_LOCK</tt> - The num lock is on. + + <li><tt>FL_META</tt> - One of the meta/Windows keys is down. + + <li><tt>FL_SCROLL_LOCK</tt> - The scroll lock is on. + + <li><tt>FL_BUTTON1</tt> - Mouse button 1 is pushed. + + <li><tt>FL_BUTTON2</tt> - Mouse button 2 is pushed. + + <li><tt>FL_BUTTON3</tt> - Mouse button 3 is pushed. + +</ul> + +<H2>Alignment Values</H2> + +The following constants define bits that can be used with <a +href="#Fl_Widget.align"><tt>Fl_Widget::align()</tt></a> to control the +positioning of the label: + +<ul> + + <li><tt>FL_ALIGN_CENTER</tt> - The label is centered. + + <li><tt>FL_ALIGN_TOP</tt> - The label is top-aligned. + + <li><tt>FL_ALIGN_BOTTOM</tt> - The label is bottom-aligned. + + <li><tt>FL_ALIGN_LEFT</tt> - The label is left-aligned. + + <li><tt>FL_ALIGN_RIGHT</tt> - The label is right-aligned. + + <li><tt>FL_ALIGN_INSIDE</tt> - The label is put inside the widget. + + <li><tt>FL_ALIGN_CLIP</tt> - The label is clipped to the widget. + + <li><tt>FL_ALIGN_WRAP</tt> - The label text is wrapped as needed. + +</ul> + +<H2>Fonts</H2> + +The following constants define the standard FLTK fonts: + +</ul> + + <li><tt>FL_HELVETICA</tt> - Helvetica (or Arial) normal. + + <li><tt>FL_HELVETICA_BOLD</tt> - Helvetica (or Arial) bold. + + <li><tt>FL_HELVETICA_ITALIC</tt> - Helvetica (or Arial) oblique. + + <li><tt>FL_HELVETICA_BOLD_ITALIC</tt> - Helvetica (or Arial) bold-oblique. + + <li><tt>FL_COURIER</tt> - Courier normal. + + <li><tt>FL_COURIER_BOLD</tt> - Courier bold. + + <li><tt>FL_COURIER_ITALIC</tt> - Courier italic. + + <li><tt>FL_COURIER_BOLD_ITALIC</tt> - Courier bold-italic. + + <li><tt>FL_TIMES</tt> - Times roman. + + <li><tt>FL_TIMES_BOLD</tt> - Times bold. + + <li><tt>FL_TIMES_ITALIC</tt> - Times italic. + + <li><tt>FL_TIMES_BOLD_ITALIC</tt> - Times bold-italic. + + <li><tt>FL_SYMBOL</tt> - Standard symbol font. + + <li><tt>FL_SCREEN</tt> - Default monospaced screen font. + + <li><tt>FL_SCREEN_BOLD</tt> - Default monospaced bold screen font. + + <li><tt>FL_ZAPF_DINGBATS</tt> - Zapf-dingbats font. + +</ul> + +<H2>Colors</H2> + +The following color constants can be used to access the colors in the FLTK +standard color palette: + +<ul> + + <li><tt>FL_BLACK</tt> + + <li><tt>FL_RED</tt> + + <li><tt>FL_GREEN</tt> + + <li><tt>FL_YELLOW</tt> + + <li><tt>FL_BLUE</tt> + + <li><tt>FL_MAGENTA</tt> + + <li><tt>FL_CYAN</tt> + + <li><tt>FL_WHITE</tt> + + <li><tt>FL_GRAY0</tt> + + <li><tt>FL_DARK3</tt> + + <li><tt>FL_DARK2</tt> + + <li><tt>FL_DARK1</tt> + + <li><tt>FL_GRAY</tt> + + <li><tt>FL_LIGHT1</tt> + + <li><tt>FL_LIGHT2</tt> + + <li><tt>FL_LIGHT3</tt> + +</ul> + +<H2>Cursors</H2> + +The following constants define the mouse cursors that are available in +FLTK: + +<ul> + <li><tt>FL_CURSOR_DEFAULT</tt> - the default cursor, usually an arrow + <li><tt>FL_CURSOR_ARROW</tt> - an arrow pointer + <li><tt>FL_CURSOR_CROSS</tt> - crosshair + <li><tt>FL_CURSOR_WAIT</tt> - watch or hourglass + <li><tt>FL_CURSOR_INSERT</tt> - I-beam + <li><tt>FL_CURSOR_HAND</tt> - hand (uparrow on MSWindows) + <li><tt>FL_CURSOR_HELP</tt> - question mark + <li><tt>FL_CURSOR_MOVE</tt> - 4-pointed arrow + <li><tt>FL_CURSOR_NS</tt> - up/down arrow + <li><tt>FL_CURSOR_WE</tt> - left/right arrow + <li><tt>FL_CURSOR_NWSE</tt> - diagonal arrow + <li><tt>FL_CURSOR_NESW</tt> - diagonal arrow + <li><tt>FL_CURSOR_NONE</tt> - invisible +</ul> + +<H2>FD "When" Conditions</H2> + +<ul> + + <li><tt>FL_READ</tt> - Call the callback when there is data to be + read. + + <li><tt>FL_WRITE</tt> - Call the callback when data can be written + without blocking. + + <li><tt>FL_EXCEPT</tt> - Call the callback if an exception occurs on + the file. + +</ul> + +<H2>Damage Masks</H2> + +The following damage mask bits are used by the standard FLTK widgets: + +<ul> + + <li><tt>FL_DAMAGE_CHILD</tt> - A child needs to be redrawn. + + <li><tt>FL_DAMAGE_EXPOSE</tt> - The window was exposed. + + <li><tt>FL_DAMAGE_SCROLL</tt> - The <tt>Fl_Scroll</tt> widget was + scrolled. + + <li><tt>FL_DAMAGE_OVERLAY</tt> - The overlay planes need to be redrawn. + + <li><tt>FL_DAMAGE_ALL</tt> - Everything needs to be redrawn. + +</ul> + </BODY> </HTML> diff --git a/documentation/events.html b/documentation/events.html index b4b5f1513..c4bc8c052 100644 --- a/documentation/events.html +++ b/documentation/events.html @@ -1,499 +1,225 @@ <HTML> <BODY> -<H1 ALIGN=RIGHT>4 - Handling Events</H1> +<H1 ALIGN=RIGHT><A NAME="events">6 - Handling Events</A></H1> This chapter discusses the FLTK event model and how to handle events in your program or widget. <H2>The FLTK Event Model</H2> -<H2>Mouse Events</H2> - -<H3><TT>FL_PUSH</TT></H3> - -<H3><TT>FL_RELEASE</TT></H3> - -<H3><TT>FL_DRAG</TT></H3> - -<H3><TT>FL_MOVE</TT></H3> - -<H2>Keyboard Events</H2> - -<H3><TT>FL_KEYBOARD</TT></H3> - -<H3><TT>FL_SHORTCUT</TT></H3> - -<H2>Widget Events</H2> - -<H3><TT>FL_ACTIVATE</TT></H3> - -<H3><TT>FL_DEACTIVATE</TT></H3> - -<H3><TT>FL_HIDE</TT></H3> - -<H3><TT>FL_SHOW</TT></H3> - -<H3><TT>FL_FOCUS</TT></H3> - -<H3><TT>FL_UNFOCUS</TT></H3> +Events are identified the small integer argument passed to the <a +href="#handle"><tt>Fl_Widget::handle()</tt></a> virtual method. Other +information about the most recent event is stored in static locations +and acquired by calling the <a +href="#event_xxx"><tt>Fl::event_*()</tt></a> methods. This static +information remains valid until the next event is read from window +system (i.e. it is ok to look at it outside of the <tt>handle()</tt> method). -<H3><TT>FL_ENTER</TT></H3> - -<H3><TT>FL_LEAVE</TT></H3> - -<H3><TT>FL_PASTE</TT></H3> - -<H3><TT>FL_SELECTIONCLEAR</TT></H3> - -</BODY> -</HTML> -<title>Events in Fltk</title> -<a name=types> -<h2>Events in Fltk</h2> - -<p>Events are identified the small integer argument passed to the <a -href=subclass.html#handle>Fl_Widget::handle()</a> virtual method. -Other information about the most recent event is stored in static -locations and aquired by calling <a -href=#information><code>Fl::event_*()</code></a>. This static -information remains valid until the next event is read from the X -server (that is, it is ok to look at it outside the handle() method). +<H2>Mouse Events</H2> -</ul><h4><code>FL_PUSH (1)</code></h4><ul> +<h3>FL_PUSH</h3> A mouse button has gone down with the mouse pointing at this widget. You can find out what button by calling <a -href=#event_button>Fl::event_button()</a>. You find out the mouse -position by calling <a href=#event_x>Fl::event_x() and -Fl::event_y()</a>. +href="#event_button"><tt>Fl::event_button()</tt></a>. You find out the +mouse position by calling <a href="#event_x"><tt>Fl::event_x()</tt></a> +and <a href="#event_y"><tt>Fl::event_y()</tt></a>. <p>A widget indicates that it "wants" the mouse click by returning -non-zero from it's <a href=subclass.html#handle>handle()</a> method. -It will then become the <a href=#pushed>Fl::pushed()</a> widget and -will get FL_DRAG and the matching FL_RELEASE events. If handle() -returns zero then fltk will try sending the FL_PUSH to another widget. +non-zero from its <a href="#handle"><tt>handle()</tt></a> method. It +will then become the <a href="#pushed"><tt>Fl::pushed()</tt></a> widget +and will get <tt>FL_DRAG</tt> and the matching <tt>FL_RELEASE</tt> +events. If <tt>handle()</tt> returns zero then FLTK will try sending +the <tt>FL_PUSH</tt> to another widget. -</ul><h4><code>FL_DRAG (5)</code></h4><ul> +<h3>FL_DRAG</h3> -The mouse has moved with the button held down. +The mouse has moved with a button held down. -</ul><h4><code>FL_RELEASE (2)</code></h4><ul> +<h3>FL_RELEASE</h3> A mouse button has been released. You can find out what button by -calling <a href=#event_button>Fl::event_button()</a>. +calling <a href="#event_button"><tt>Fl::event_button()</tt></a>. -</ul><h4><code>FL_ENTER (3)</code></h4><ul> +<h3>FL_MOVE</h3> -The mouse has been moved to point at this widget. This can be used -for highlighting feedback. If a widget wants to highlight or -otherwise track the mouse, it indicates this by returning -non-zero from it's <a href=subclass.html#handle>handle()</a> method. -It then becomes the <a href=#belowmouse>Fl::belowmouse()</a> widget -and will receive FL_MOVE and FL_EXIT events. +The mouse has moved without any mouse buttons held down. This event +is sent to the <tt>belowmouse()</tt> widget. -</ul><h4><code>FL_MOVE (10)</code></h4><ul> +<H2>Focus Events</H2> -The mouse has moved without any mouse buttons held down. This event -is sent (sort of) to the belowmouse() widget. +<h3>FL_ENTER</h3> + +The mouse has been moved to point at this widget. This can be used for +highlighting feedback. If a widget wants to highlight or otherwise +track the mouse, it indicates this by returning non-zero from its <a +href="#handle"><tt>handle()</tt></a> method. It then becomes the <a +href="#belowmouse"><tt>Fl::belowmouse()</tt></a> widget and will +receive <tt>FL_MOVE</tt> and <tt>FL_LEAVE</tt> events. -</ul><h4><code>FL_LEAVE (4)</code></h4><ul> +<h3>FL_LEAVE</h3> The mouse has moved out of the widget. -</ul><h4><code>FL_FOCUS (6)</code></h4><ul> +<h3>FL_FOCUS</h3> This indicates an <i>attempt</i> to give a widget the keyboard focus. <p>If a widget wants the focus, it should change itself to display the -fact that it has the focus, and return non-zero from it's <a -href=subclass.html#handle>handle()</a> method. It then becomes the <a -href=#focus>Fl::focus()</a> widget and gets FL_KEYBOARD and FL_UNFOCUS -events. +fact that it has the focus, and return non-zero from its <a +href="#handle"><tt>handle()</tt></a> method. It then becomes the <a +href="#focus"><tt>Fl::focus()</tt></a> widget and gets <tt>FL_KEYBOARD</tt> +and <tt>FL_UNFOCUS</tt> events. <p>The focus will change either because the window manager changed which window gets the focus, or because the user tried to navigate using tab, arrows, or other keys. You can check <a -href=#event_key>Fl::event_key()</a> to figure out why it moved. For -navigation it will be the key pressed, for instructions from the +href="#event_key"><tt>Fl::event_key()</tt></a> to figure out why it moved. For +navigation it will be the key pressed and for instructions from the window manager it will be zero. -</ul><h4><code>FL_UNFOCUS (7)</code></h4><ul> +<h3>FL_UNFOCUS</h3> -Sent to the old <a href=#focus>Fl::focus()</a> when something else -gets the focus. +Sent to the previous <a href="#focus"><tt>Fl::focus()</tt></a> when +another widget gets the focus. + +<H2>Keyboard Events</H2> -</ul><h4><code>FL_KEYBOARD (8)</code></h4><ul> +<h3>FL_KEYBOARD</h3> A key press. The key pressed can be found in <a -href=#event_key>Fl::event_key()</a>, or, more usefully, the text that -the key should insert can be found with <a -href=#event_text>Fl::event_text()</a> and it's length is in <a -href=#event_length>Fl::event_length()</a>. If you use the key -handle() should return 1. If you return zero then fltk assummes you -ignored the key. It will then attempt to send it to a parent widget. -If none of them want it, it will change the event into a FL_SHORTCUT -event. - -</ul><h4><code>FL_SHORTCUT (11)</code></h4><ul> - -If the <a href=#focus>Fl::focus()</a> is zero or ignores an -FL_KEYBOARD event then fltk tries sending this event to every widget -it can, until one of them returns non-zero. FL_SHORTCUT is first sent -to the belowmouse widget, then it's parents and siblings, and -eventually to every widget in the window, trying to find an object -that returns non-zero. Fltk tries real hard to not let any keystrokes -be ignored! - -<p>If the <a href=#event_text>Fl::event_text()</a> is a lower or -upper-case letter, and nothing wants the shortcut +href="#event_key"><tt>Fl::event_key()</tt></a>. The text that the key +should insert can be found with <a +href="#event_text"><tt>Fl::event_text()</tt></a> and its length is in +<a href="#event_length"><tt>Fl::event_length()</tt></a>. If you use +the key <tt>handle()</tt> should return 1. If you return zero then +FLTK assummes you ignored the key. It will then attempt to send it to +a parent widget. If none of them want it, it will change the event into +a <tt>FL_SHORTCUT</tt> event. + +<h3>FL_SHORTCUT</h3> + +If the <a href="#focus"><tt>Fl::focus()</tt></a> is zero or ignores an +<tt>FL_KEYBOARD</tt> event then FLTK tries sending this event to every +widget it can, until one of them returns non-zero. +<tt>FL_SHORTCUT</tt> is first sent to the <tt>belowmouse()</tt> widget, +then its parents and siblings, and eventually to every widget in the +window, trying to find an object that returns non-zero. FLTK tries +really hard to not to ignore any keystrokes! <p>You can also make "global" shortcuts by using <a -href=#add_handler>Fl::add_handler()</a>. A global shortcut will work -no matter what windows are displayed or which one has the focus. +href="#add_handler"><tt>Fl::add_handler()</tt></a>. A global shortcut +will work no matter what windows are displayed or which one has the +focus. + +<H2>Widget Events</H2> -</ul><h4><code>FL_DEACTIVATE (13)</code></h4><ul> +<h3>FL_DEACTIVATE</h3> This widget is no longer active, due to <a -href=Fl_Widget.html#active>deactivate()</a> being called on it or one -of it's parents. active() may still be true after this, the widget is -only active if active() is true on it and all it's parents. +href="#Fl_Widget.deactivate"><tt>deactivate()</tt></a> being called on +it or one of its parents. <tt>active()</tt> may still be true after this, the +widget is only active if <tt>active()</tt> is true on it and all its parents +(use <tt>active_r()</tt> to check this). -</ul><h4><code>FL_ACTIVATE (14)</code></h4><ul> +<h3>FL_ACTIVATE</h3> This widget is now active, due to <a -href=Fl_Widget.html#activate>active()</a> being called on it or one -of it's parents. +href="#Fl_Widget.activate"><tt>activate()</tt></a> being called on it +or one of its parents. -</ul><h4><code>FL_HIDE (15)</code></h4><ul> +<h3>FL_HIDE</h3> This widget is no longer visible, due to <a -href=Fl_Widget.html#visible>hide()</a> being called, or a parent group -or window having hide() be called, or due to a parent window being -iconized. visible() may still be true after this, the widget is -visible only if visible() is true for it and all it's parents. +href="#Fl_Widget.hide><tt>hide()</a> being called on it or one of its +parents, or due to a parent window being minimized. <tt>visible()</tt> +may still be true after this, but the widget is visible only if +<tt>visible()</tt> is true for it and all its parents (use +<tt>visible_r()</tt> to check this). -</ul><h4><code>FL_SHOW (16)</code></h4><ul> +<h3>FL_SHOW</h3> This widget is visible again, due to <a -href=Fl_Widget.html#visible>show()</a> being called on it or one of -it's parents, or due to a parent window being deiconized. <i>Child -Fl_Windows respond to this by actually creating the X window if not -done already, so if you subclass a window, be sure to pass FL_SHOW to -the base class handle() method!</i> +href="#Fl_Widget.show"><tt>show()</tt></a> being called on it or one of +its parents, or due to a parent window being restored. <i>Child +<tt>Fl_Window</tt>s respond to this by actually creating the window if not +done already, so if you subclass a window, be sure to pass <tt>FL_SHOW</tt> to +the base class <tt>handle()</tt> method!</i> + +<H2>Clipboard Events</H2> -<a name=paste> -</ul><h4><code>FL_PASTE (17)</code></h4><ul> +<h3>FL_PASTE</h3> You should get this event some time after you call <a -href=cutpaste.html>Fl::paste()</a>. The contents of <a -href=#event_text>Fl::event_text()</a> is the text to insert and the -number of characters is in <a href=#event_length>Fl::event_length()</a>. +href="#paste"><tt>Fl::paste()</tt></a>. The contents of <a +href="#event_text"><tt>Fl::event_text()</tt></a> is the text to insert +and the number of characters is in <a +href="#event_length"><tt>Fl::event_length()</tt></a>. -</ul><h4><code>FL_SELECTIONCLEAR (18)</code></h4><ul> +<h3>FL_SELECTIONCLEAR</h3> -The <a href=cutpaste.html>Fl::selection_owner()</a> will get this +The <a href="#selection_owner">Fl::selection_owner()</a> will get this event before the selection is moved to another widget. This indicates that some other widget or program has claimed the selection. -</ul> - -<a name=information> -<h2>Fl::event_*() methods</h2> +<h2><a name="event_xxx">Fl::event_*() methods</a></h2> -Fltk keeps the information about the most recent event in static +FLTK keeps the information about the most recent event in static storage. This information is good until the next event is processed. -Thus it is valid inside handle() and callback() methods. +Thus it is valid inside <tt>handle()</tt> and <tt>callback()</tt> methods. <p>These are all trivial inline functions and thus very fast and -small. The data is stored in static locations and remains valid until -the next X event is handled. - -<a name=event_button> -</ul><h4><code>int Fl::event_button();</code></h4><ul> - -Returns which mouse button was pressed. This returns garbage if the -most recent event was not a FL_PUSH or FL_RELEASE. - -<a name=event_x> -</ul><h4><code>int Fl::event_x()</code> -<br><code>int Fl::event_y()</code></h4><ul> - -Returns the mouse position of the event (relative to the Fl_Window it -was passed to). - -</ul><h4><code>int Fl::event_x_root()</code> -<br><code>int Fl::event_y_root()</code></h4><ul> - -Returns the mouse position on the screen of the event. To find the -absolute position of an Fl_Window on the screen, use the difference -between event_x_root and event_x. - -<a name=get_mouse> -</ul><h4><code>void Fl::get_mouse(int &,int &)</code></h4><ul> - -<p>Return where the mouse is on the screen by doing a round-trip query -to the server. You should use <a -href=#event_x>Fl::event_x/y_root()</a> if possible, but this is -necessary if you are not sure if a mouse event has been processed -recently (such as to position your first window). If the display is -not open, this will open it. - -<a name=event_state> -</ul><h4><code>ulong Fl::event_state(); -<br>unsigned int Fl::event_state(int);</code></h4><ul> - -This is a bitfield of what shift states were on and what mouse buttons -were held down during the most recent event. The second version -returns non-zero if any of the passed bits are turned on. The legal -bits are <code>FL_SHIFT, FL_CAPS_LOCK, FL_CTRL, FL_ALT, FL_NUM_LOCK, -FL_META, FL_SCROLL_LOCK, FL_BUTTON1, FL_BUTTON2, FL_BUTTON3</code>. - -<i><p>X servers do not agree on shift states and FL_NUM_LOCK, FL_META, -and FL_SCROLL_LOCK may not work. The values were selected to match -the XFree86 server on Linux. In addition there is a bug in the way -Xlib works so that the shift state is not correctly reported until the -first event <b>after</b> the shift key is pressed or released.</i> - -<a name=event_key> -</ul><h4><code>int Fl::event_key(); -<br>int Fl::event_key(int); -<br>int Fl::get_key(int);</code></h4><ul> - -Fl::event_key() returns which key on the keyboard was last pushed. - -<p>Fl::event_key(int) returns true if the given key was held down (or -pressed) <i>during</i> the last event. This is constant until the -next event is read from the server. - -<p>Fl::get_key(int) returns true if the given key is held down -<i>now</i>. Under X this requires a round-trip to the server and is -<i>much</i> slower than Fl::event_key(int). - -<p>Keys are identified by the <i>unshifted</i> X keysym values. -However fltk defines a set of symbols that should work on most modern -machines for every key on the generic PC keyboard: - -<p><ul> - -<li>All keys on the main keyboard producing a printable ASCII -character use the value of that ASCII character (as though shift, -ctrl, and caps lock were not on). The space bar is 32. - -<li>All keys on the numeric keypad producing a printable ASCII -character use the value of that ASCII character plus -<code>FL_KP</code>. The highest possible value is -<code>FL_KP_Last</code> so you can range-check to see if something is -on the keypad. - -<li>All numbered function keys use the number on the function key plus -<code>FL_F</code>. The highest possible number is -<code>FL_F_Last</code>, so you can range-check a value. - -<li>Buttons on the mouse are considered keys, and use the button -number (where the left button is 1) plus <code>FL_Button</code>. - -<li>All other keys on the keypad have a symbol: <code>FL_Escape, -FL_BackSpace, FL_Tab, FL_Enter, FL_Print, FL_Scroll_Lock, FL_Pause, -FL_Insert, FL_Home, FL_Page_Up, FL_Delete, FL_End, FL_Page_Down, -FL_Left, FL_Up, FL_Right, FL_Down, FL_Shift_L, FL_Shift_R, -FL_Control_L, FL_Control_R, FL_Caps_Lock, FL_Alt_L, FL_Alt_R, -FL_Meta_L, FL_Meta_R, FL_Menu, FL_Num_Lock, FL_KP_Enter</code>. Be -careful not to confuse these with the very similar, but all-caps, -symbols used by <a href=#event_state>Fl::event_state()</a>. - -</ul> - -<p>Known bugs: on X <code>Fl::get_key(FL_Button+n)</code> does not -work. On MSWindows <code>Fl::get_key(FL_KP_Enter)</code> and -<code>Fl::event_key(FL_KP_Enter)</code> do not work. - -<a name=event_text> -</ul><h4><code>char * Fl::event_text()</code></h4><ul> - -<p>ASCII text (in the future this may be UTF-8) produced by the last -FL_KEYBOARD or FL_PASTE or possibly other event. A zero-length string -is returned for any keyboard function keys that do not produce text. -This pointer points at a static buffer and is only valid until the -next event is processed. - -<p>Under X this is the result of XLookupString. - -<a name=event_length> -</ul><h4><code>char * Fl::event_length()</code></h4><ul> - -<p>Length of the text in Fl::event_text(). There will always be a -null at this position in the text. However there may be a nul before -that if the keystroke translates to a nul character or you paste a nul -character. - -</ul><h4><code>int Fl::event_is_click()</code></h4><ul> - -Returns non-zero if the mouse has not moved far enough and not enough -time has passed since the last FL_PUSH or FL_KEYBOARD event for it -to be considered a "drag" rather than a "click". You can test this on -FL_DRAG, FL_RELEASE, and FL_MOVE events. - -</ul><h4><code>void Fl::event_is_click(0)</code></h4><ul> - -Clear the value returned by Fl::event_is_click(). Useful to prevent -the <i>next</i> click from being counted as a double-click or to make -a popup menu pick an item with a single click. Don't pass non-zero to -this. - -</ul><h4><code>int Fl::event_clicks()</code></h4><ul> - -Returns non-zero if the most recent FL_PUSH or FL_KEYBOARD was a -"double click". Returns N-1 for N clicks. A double click is counted -if the same button is pressed again while event_is_click() is true. - -</ul><h4><code>void Fl::event_clicks(int)</code></h4><ul> - -Directly set the number returned by Fl::event_clicks(). This can be -used to set it to zero so that later code does not think an item was -double-clicked. - -</ul><h4><code>int Fl::event_inside(const Fl_Widget *) const ; -<br>int Fl::event_inside(int,int,int,int);</code></h4><ul> - -Returns non-zero if the current event_x and event_y put it inside the -widget or inside an arbitrary bounding box. You should always call -this rather than doing your own comparison so you are consistent about -edge effects. - -</ul><h4><code>int Fl::test_shortcut(ulong) const ;</code></h4><ul> - -Test the current event, which must be an FL_KEYBOARD or FL_SHORTCUT, -against a shortcut value (described in <a -href=Fl_Button.html#shortcut>Fl_Button</a>). Returns non-zero if -there is a match. Not to be confused with <a -href=subclass.html#test_shortcut>Fl_Widget::test_shortcut()</a>. - +small: + +<ul> + <li><a name="event_button">Fl::event_button</a> + <li><a name="event_clicks">Fl::event_clicks</a> + <li><a name="event_inside">Fl::event_inside</a> + <li><a name="event_is_click">Fl::event_is_click</a> + <li><a name="event_key">Fl::event_key</a> + <li><a name="event_length">Fl::event_length</a> + <li><a name="event_state">Fl::event_state</a> + <li><a name="event_text">Fl::event_text</a> + <li><a name="event_x">Fl::event_x</a> + <li><a name="event_x_root">Fl::event_x_root</a> + <li><a name="event_y">Fl::event_y</a> + <li><a name="event_y_root">Fl::event_y_root</a> + <li><a name="get_key">Fl::get_key</a> + <li><a name="get_mouse">Fl::get_mouse</a> + <li><a name="test_shortcut">Fl::test_shortcut</a> </ul> -<a name=propagation> -<h2>Event Propagation</h2> +<h2><a name="propagation">Event Propagation</a></h2> -<p>Fltk follows very simple and unchangeable rules for sending events. -The major innovation is that widgets can indicate (by returning 0 from -the handle() method) that they are not interested in an event, and fltk -can then send that event elsewhere. This eliminates the need for +FLTK follows very simple and unchangeable rules for sending events. The +major innovation is that widgets can indicate (by returning 0 from the +<tt>handle()</tt> method) that they are not interested in an event, and +FLTK can then send that event elsewhere. This eliminates the need for "interests" (event masks or tables), and this is probably the main -reason fltk is much smaller than other X toolkits. - -<p>Most events are sent directly to the handle() method of the -Fl_Window that X says they belong to. The window (actually the -Fl_Group that Fl_Window is a subclass of) is responsible for sending -the events on to any child widgets. To make the Fl_Group code -somewhat easier, fltk sends some events (FL_DRAG, FL_RELEASE, -FL_KEYBOARD, FL_SHORTCUT, FL_UNFOCUS, FL_LEAVE) directly to leaf -widgets. These procedures control those leaf widgets: - -<a name=focus> -</ul><h4><code>Fl_Widget *Fl::focus() const; -<br>void Fl::focus(Fl_Widget *);</code></h4><ul> - -Get or set the widget that will receive FL_KEYBOARD events. - -<p>If you change Fl::focus(), the old one and all parents (that don't -contain the new widget) are sent FL_UNFOCUS events. Changing the -focus does <i>not</i> send FL_FOCUS to this or any widget, because -sending FL_FOCUS is supposed to <i>test</i> if the widget wants the -focus (by it returning non-zero from handle()). - -</ul><h4><code>int Fl_Widget::take_focus();</code></h4><ul> - -<p>Try to make this widget be the Fl::focus(), by first sending it an -FL_FOCUS event, and if it returns non-zero, setting Fl::focus() to -this widget. You should use this method to assign the focus to an -widget. Returns true if the widget accepted the focus. - -<a name=belowmouse> -</ul><h4><code>Fl_Widget *Fl::belowmouse() const; -<br>void Fl::belowmouse(Fl_Widget *);</code></h4><ul> - -Get or set the widget that is below the mouse. This is for -highlighting buttons. It is not used to send FL_PUSH or FL_MOVE -directly, for several obscure reasons, but those events typically go -to this widget. This is also the first widget tried for FL_SHORTCUT -events. - -<p>If you change the belowmouse widget, the old one and all parents (that -don't contain the new widget) are sent FL_LEAVE events. Changing this -does <i>not</i> send FL_ENTER to this or any widget, because -sending FL_ENTER is supposed to <i>test</i> if the widget wants the -mouse (by it returning non-zero from handle()). - -<a name=pushed> -</ul><h4><code>Fl_Widget *Fl::pushed() const; -<br>void Fl::pushed(Fl_Widget *);</code></h4><ul> - -<p>Get or set the widget that is being pushed. FL_DRAG or FL_RELEASE -(and any more FL_PUSH) events will be sent to this widget. - -<p>If you change the pushed widget, the old one and all parents (that -don't contain the new widget) are sent FL_RELEASE events. Changing -this does <i>not</i> send FL_PUSH to this or any widget, because -sending FL_PUSH is supposed to <i>test</i> if the widget wants the -mouse (by it returning non-zero from handle()). - -<a name=add_handler> -</ul><h4><code>void Fl::add_handler(int (*f)(int));</code></h4><ul> - -Install a function to parse unrecognized events. If fltk cannot figure -out what to do with an event, it calls each of these functions (most -recent first) until one of them returns non-zero. If none of them -returns non zero then the event is ignored. Events that cause this to -be called are: - -<p><ul> -<li>FL_SHORTCUT events that are not recognized by any widget. This -lets you provide global shortcut keys. - -<li>System events that fltk does not recognize. See <a -href=x.html#fl_xevent>fl_xevent</a>. - -<li><i>Some</i> other events when the widget fltk selected returns zero -from it's handle() method. Exactly which ones may change in future -versions, however. +reason FLTK is much smaller than other toolkits. + +<p>Most events are sent directly to the <tt>handle()</tt> method of the +<tt>Fl_Window</tt> that the window system says they belong to. The +window (actually the <tt>Fl_Group</tt> that <tt>Fl_Window</tt> is a +subclass of) is responsible for sending the events on to any child +widgets. To make the <tt>Fl_Group</tt> code somewhat easier, FLTK +sends some events (<tt>FL_DRAG</tt>, <tt>FL_RELEASE</tt>, +<tt>FL_KEYBOARD</tt>, <tt>FL_SHORTCUT</tt>, <tt>FL_UNFOCUS</tt>, and +<tt>FL_LEAVE</tt>) directly to leaf widgets. These procedures control +those leaf widgets: + +<ul> + <li><a href="#add_handler">Fl::add_handler</a> + <li><a href="#belowmouse">Fl::belowmouse</a> + <li><a href="#focus">Fl::focus</a> + <li><a href="#grab">Fl::grab</a> + <li><a href="#modal">Fl::modal</a> + <li><a href="#pushed">Fl::pushed</a> + <li><a href="#release">Fl::release</a> + <li><a href="#Fl_Widget.take_focus">Fl_Widget::take_focus</a> </ul> -<a name=modal> -</ul><h4><code>Fl_Window* Fl::modal();</code></h4><ul> - -The modal() window has it's handle() method called for all events, and -no other windows will have handle() called. If <a -href=#grab>grab()</a> has been done then this is equal to grab(). -Otherwise this is the most recently shown() window with <a -href=Fl_Window.html#modal>modal()</a> true, or null if there are no -modal() windows shown(). - -<a name=grab> -</ul><h4><code>void Fl::grab(Fl_Window&);<br> -Fl_Window* Fl::grab();</code></h4><ul> - -This is used when pop-up menu systems are active. Send all events to -the passed window no matter where the pointer or focus is (including -in other programs). The window <i>does not have to be shown()</i>, -this lets the handle() method of a "dummy" window override all event -handling and allows you to map and unmap a complex set of windows -(under both X and NT <i>some</i> window must be mapped because the -system interface needs a window id). - -<p>Fl::event_x() and y() are undefiend if the passed widget is not a -mapped Fl_Window. Use Fl::event_x_root() and Fl::event_y_root() -instead. - -<p><i>Be careful that your program does not enter an infinite loop -while grab() is on. On X this will lock up your screen!</i> - -<p>The second function returns the current grab window, or null if -none. - -<a name=release> -</ul><h4><code>void Fl::release()</code></h4><ul> - -Turn off the grab() behavior. - -</ul><p><a href = index.html>(back to contents)</a> +</BODY> +</HTML> diff --git a/documentation/fluid.html b/documentation/fluid.html index 47cb7d7fd..55a46d55f 100644 --- a/documentation/fluid.html +++ b/documentation/fluid.html @@ -1,269 +1,239 @@ <HTML> <BODY> -<H1 ALIGN=RIGHT><A NAME="fluid">6 - Programming with FLUID</A></H1> +<H1 ALIGN=RIGHT><A NAME="FLUID">8 - Programming with FLUID</A></H1> This chapter shows how to use the Fast Light User-Interface Designer ("FLUID") to create your GUIs. <H2>What is FLUID?</H2> -<H2>Creating A Simple Program</H2> +The Fast Light User Interface Designer, or "FLUID", is a graphical +editor that is used to produce FLTK source code. -<H2>Functions</H2> - -<H2>Windows</H2> - -<H2>Groups</H2> - -<H2>Tabs</H2> - -<H2>Menus</H2> - -<H2>Using Custom Widgets</H2> - -<H2>Classes</H2> - -</BODY> -</HTML> -<title>fluid Reference Manual</title> - -<center><img src=fluid.gif></center> - -<h2>What is Fluid?</h2> - -<p>Fluid (the Fast Light User Interface Designer) is a graphical -editor that is used to produce fltk source code. - -<p>Fluid edits and saves it's state in ".fl" files. These files are -text, and you could (with care) edit them in a text editor, perhaps to +<p>FLUID edits and saves its state in ".fl" files. These files are +text, and you can (with care) edit them in a text editor, perhaps to get some special effects. -<p>Fluid can "compile" the .fl file into a .C and a .H file. The .C -file defines all the objects from the .fl file and the .H file +<p>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. <p>A simple program can be made by putting all your code (including a -main() function) into the .fl file and thus making the .C file a -single source file to compile. Normally though you write other .C -files that call the fluid functions. These .C files must #include the -.H file output (or they can #include the .C file so it still appears -to make to be a single source file). - -<pre> - _________ - / / - __________ +->/.C file /--------+ - / / / /________/ | - /.fl file /<==>[fluid]< #include | - /_________/ \ ___v_____ | - \ / / | - +>/.H file / | - /________/ | - ^ | - #include | - ___|_____ | __________ - / / V / / - / main.C /--->[c++,link]-->/ program / - /________/ /_________/ -</pre> - -<p>Normally the fluid file defines one or more "functions", which -output C++ functions. Each function defines a one or more fltk +<tt>main()</tt> 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 <tt>#include</tt> the .h file or +they can <tt>#include</tt> the .cxx file so it still appears to be a single +source file. + +<hr break> +<ul><pre> + ___________ + / / + __________ +->/.cxx file /--------+ + / / / /__________/ | + /.fl file /<==>[FLUID]< #include | + /_________/ \ ___v_____ | + \ / / | + +>/.h file / | + /________/ | + ^ | + #include | + ___|_______ | __________ + / / V / / + / main.cxx /--->[c++,link]-->/ program / + /__________/ /_________/ +</pre></ul> + +<p>Normally the FLUID file defines one or more "functions", which +output C++ functions. Each function defines a one or more FLTK windows, and all the widgets that go inside those windows. -<p>Widgets created by fluid are either "named", "complex named" or -"unnamed". A named widget has a legal C++ variable identifier as it's -name (ie only alphanumeric and underscore). In this case fluid -defines a global variable 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 it's name. In -this case fluid assigns a pointer to the widget to the name, but does +<p>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 to them is stored. <p>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 .C file. +FLUID will write a private callback function into the .cxx file. -<a name=tutorial> -<h2>Worlds shortest tutorial</h2> +<h2>A Short Tutorial</h2> <ol> -<li>Type "fluid&" + <li>Type "FLUID&" -<li>Pick "New/code/function" off the menu. + <li>Pick "New/code/function" off the menu. -<li>Hit Tab, Delete to delete the function name and hit OK. This is -how you get fluid to output a "main()" function. The text "main()" -with a triangle next to it should appear highlighted in the main -window. + <li>Hit Tab, Delete to delete the function name and hit OK. This is + how you get FLUID to output a "main()" function. The text "main()" + with a triangle next to it should appear highlighted in the main + window. -<li>Pick "New/group/Window" off the menu. + <li>Pick "New/group/Window" off the menu. -<li>Move the new window and resize it to the size you want. + <li>Move the new window and resize it to the size you want. -<li>Pick "New/buttons/Button" off the menu. + <li>Pick "New/buttons/Button" off the menu. -<li>Hit the "OK" button to dismiss the panel that appears. + <li>Hit the "OK" button to dismiss the panel that appears. -<li>In the window you created, try moving the button by dragging it -around. Notice that it "snaps" to fixed locations. If you want to -drag it smoothly, hold down Alt. You can also change the size of the -steps with Edit/Preferences. + <li>In the window you created, try moving the button by dragging it + around. Notice that it "snaps" to fixed locations. If you want to + drag it smoothly, hold down Alt. You can also change the size of the + steps with Edit/Preferences. -<li>Try resizing the widget by dragging the edges and corners. + <li>Try resizing the widget by dragging the edges and corners. -<li>Type Alt+c to copy the widget. + <li>Type Alt+c to copy the widget. -<li>Type Alt+v to paste a copy into the window. + <li>Type Alt+v to paste a copy into the window. -<li>Type Alt+v several times. + <li>Type Alt+v several times. -<li>Drag the widgets and resize them so they don't overlap. Notice -that you have to click a widget to pick it first, then drag it. + <li>Drag the widgets and resize them so they don't overlap. Notice + that you have to click a widget to pick it first, then drag it. -<li>Try selecting several widgets by dragging a box around them. Check -what happens when you move them, or when you drag an edge to resize -them. + <li>Try selecting several widgets by dragging a box around them. Check + what happens when you move them, or when you drag an edge to resize + them. -<li>You can also use Shift+click to toggle widgets on and off. + <li>You can also use Shift+click to toggle widgets on and off. -<li>You can also select widgets by clicking on them in the list in the -main window, try that. + <li>You can also select widgets by clicking on them in the list in the + main window, try that. -<li>Double-click one of the widgets. You will get a control panel. + <li>Double-click one of the widgets. You will get a control panel. -<li>Try changing the "label". Try changing other items near the top of -the panel. To see any changes to the box type clearer, type "Alt+o" -to make the red overlay disappear. + <li>Try changing the "label". Try changing other items near the top of + the panel. To see any changes to the box type clearer, type "Alt+o" + to make the red overlay disappear. -<li>Type "#include <stdlib.h>" into the first line of "extra code:". + <li>Type "#include <stdlib.h>" into the first line of "extra code:". -<li>Type "exit(0);" into the "callback:". + <li>Type "exit(0);" into the "callback:". -<li>Hit OK. + <li>Hit OK. -<li>Pick "File/Save As" off the menu. + <li>Pick "File/Save As" off the menu. -<li>Type "test.fl" into the file chooser and hit return. + <li>Type "test.fl" into the file chooser and hit return. -<li>Pick "File/Write Code" off the menu, hit OK on the confirmation panel. + <li>Pick "File/Write Code" off the menu, hit OK on the confirmation panel. -<li>Go back to your terminal window. Type "more test.C" and "more -test.H" and you can see the code it made. Also try "more test.fl" to -see how fluid saves it's data. + <li>Go back to your terminal window. Type "more test.cxx" and "more + test.h" and you can see the code it made. Also try "more test.fl" to + see how FLUID saves its data. -<li>Type "make test" (you may have to add libaries to your Makefile). + <li>Type "make test" (you may have to add libaries to your Makefile). -<li>Type "./test" to run your program. + <li>Type "./test" to run your program. -<li>Try the buttons. The one you put the code into will exit the -program. + <li>Try the buttons. The one you put the code into will exit the + program. -<li>Type "Alt+Q" to exit fluid. + <li>Type "Alt+Q" to exit FLUID. -<li>Ok, now try to make a real program. + <li>Ok, now try to make a real program. </ol> -<a name=running> -<h2>Running fluid</h2> +<h2>Running FLUID Under UNIX</h2> -<p>Type +To run FLUID under UNIX, type: -<pre> - fluid <name>.fl & -</pre> +<ul><pre> +fluid <i>filename.fl</i> & +</pre></ul> -<p>to edit the .fl file <name>.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 setup of that name. You can run fluid without any name, in +to edit the .fl file <i>filename.fl</i>. 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). -<p>You can provide any of the standard fltk switches before the name: +<p>You can provide any of the standard FLTK switches before the name: -<pre> - -display host:n.n - -geometry WxH+X+Y - -title windowtitle - -name classname - -iconic - -fg color - -bg color - -bg2 color -</pre> +<ul><pre> +-display host:n.n +-geometry WxH+X+Y +-title windowtitle +-name classname +-iconic +-fg color +-bg color +-bg2 color +</pre></ul> -<p>Changing the colors may be useful to see what your interface will +Changing the colors may be useful to see what your interface will look at if the user calls it with the same switches. <p>In the current version, if you don't go into the background (with -'&') then you will be able to abort fluid by typing ^C on the terminal. +'&') then you will be able to abort FLUID by typing ^C on the terminal. It will exit immediately, losing any changes. -<a name=compiling> +<h2>Running FLUID Under Microsoft Windows</h2> + +To run FLUID under windows, double-click on the <i>fluid.exe</i> file. +You can also run FLUID from the </i>Command Prompt</i> window (FLUID +always runs in the background). + <h2>Compiling .fl files</h2> -<p>Fluid can also be called as a command-line "compiler" to create the -.C and .H file from a .fl file. To do this type +FLUID can also be called as a command-line "compiler" to create the +.cxx and .h file from a .fl file. To do this type: -<pre> - fluid -c <name>.fl -</pre> +<ul><pre> + FLUID -c <i>filename.fl</i> +</pre></ul> -<p>This will read the .fl file and write <name>.C and -<name>.H (the directory will be stripped, they are written to the -current directory always), and then exit. If there are any errors +This will read the .fl file and write <i>filename.cxx</i> and +<i>filename.h</i>. The directory will be stripped, so they are written to +the current directory always. If there are any errors reading or writing the files it will print the error and exit with a -non-zero code. This is useful in a makefile. A line like this will +non-zero code. In a makefile you can use a line like this: work: -<pre> -my_panels.H my_panels.C : my_panels.fl +<ul><pre> +my_panels.h my_panels.cxx: my_panels.fl fluid -c my_panels.fl -</pre> +</pre></ul> -<p>Some versions of Make will accept rules like this to allow all .fl +Some versions of make will accept rules like this to allow all .fl files found to be compiled: -<pre> -.SUFFIXES : .fl .C .H -.fl.H : +<ul><pre> +.SUFFIXES: .fl .cxx .h +.fl.h .fl.cxx: fluid -c $< -.fl.C : - fluid -c $< -</pre> - -<p>Some versions of Make (gnumake) may prefer this syntax: - -<pre> -%.H: %.fl - fluid -c $< - -%.C: %.fl - fluid -c $< -</pre> +</pre></ul> -<a name=browser> <h2>The Widget Browser</h2> -<p><img src=fluid_main.gif align = left> +<table cellpadding=0 cellspacing=0> +<tr> +<td> -<p>The main window shows a menu bar and a scrolling browser of all the +The main window shows a menu bar and a scrolling browser of all the defined widgets. The name of the .fl file being edited is shown in the window title. <p>The widgets are stored in a hierarchy. You can open and close a level by clicking the "triangle" at the left of a widget. This -widget is the <i>parent</i>, and all the widgets listed below it are it's +widget is the <i>parent</i>, and all the widgets listed below it are its <i>children</i>. There can be zero children. <p>The top level of the hierarchy is <i>functions</i>. Each of these -will produce a single C++ public function in the output .C file. -Calling the function will create all of it's child windows. +will produce a single C++ public function in the output .cxx file. +Calling the function will create all of its child windows. <p>The second level of the hierarchy is <i>windows</i>. Each of these produces an instance of class Fl_Window. @@ -277,7 +247,12 @@ provide the well-known file-card tab interface. as "main_panel" in the example), or if <i>unnamed</i> as their <i>type</i> and <i>label</i> (such as "Button "the green""). -<p>You <i>select</i> widgets by clicking on their names, which +</td> +<td><img src="fluid_main.gif" width=245></td> +</tr> +</table> + +You <i>select</i> 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 @@ -289,74 +264,73 @@ this. widgets you have picked) by typing the F1 key. This will bring up a control panel or window from which you can change the widget. -<a name=menu> <h2>Menu Items</h2> <p>The menu bar at the top is duplicated as a pop-up menu on any displayed window. The shortcuts for all the menu items work in any window. The menu items are: -</ul><h4>File/Open... (Alt+Shift+O)</h4><ul> +<h3>File/Open... (Alt+Shift+O)</h3> Discard the current editing session and read in a different .fl file. You are asked for confirmation if you have changed the current data. -<p>fluid can also read .fd files produced by the Forms and XForms -"fdesign" programs. It is best to read them with Merge. Fluid does not +<p>FLUID can also read .fd files produced by the Forms and XForms +"fdesign" programs. It is best to read them with Merge. 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 it's own format, which fdesign +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! -</ul><h4>File/Save (Alt+s)</h4><ul> +<H3>File/Save (Alt+s)</H3> Write the current data to the .fl file. If the file is unnamed -(because fluid was started with no name) then ask for a file name. +(because FLUID was started with no name) then ask for a file name. -</ul><h4>File/Save As...(Alt+Shift+S)</h4><ul> +<H3>File/Save As...(Alt+Shift+S)</H3> Ask for a new name to save the file as, and save it. -</ul><h4>File/Merge... (Alt+i)</h4><ul> +<H3>File/Merge... (Alt+i)</H3> Insert the contents of another .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, you will have to use cut/paste to put the widgets where you want. -</ul><h4>File/Write code (Alt+Shift+C)</h4><ul> +<H3>File/Write code (Alt+Shift+C)</H3> -"Compiles" the data into a .C and .H file. These are exactly the same -as the files you get when you run fluid with the -c switch. +"Compiles" the data into a .cxx and .h file. These are exactly the same +as the files you get when you run FLUID with the -c switch. <p>The output file names are the same as the .fl file, with the -leading directory and trailing ".fl" stripped, and ".H" or ".C" +leading directory and trailing ".fl" stripped, and ".h" or ".cxx" appended. Currently there is no way to override this. -</ul><h4>File/Quit (Alt+q)</h4><ul> +<H3>File/Quit (Alt+q)</H3> -Exit fluid. You are asked for confirmation if you have changed the +Exit FLUID. You are asked for confirmation if you have changed the current data. -</ul><h4>Edit/Undo (Alt+z)</h4><ul> +<H3>Edit/Undo (Alt+z)</H3> Don't you wish... This isn't implemented yet. You should do save often so that any mistakes you make don't irretrivably destroy your data. -</ul><h4>Edit/Cut (Alt+x)</h4><ul> +<H3>Edit/Cut (Alt+x)</H3> Delete the selected widgets and all their children. These are saved to a "clipboard" file (/usr/tmp/cut_buffer.fl) and can be pasted back -into this fluid or any other one. +into this FLUID or any other one. -</ul><h4>Edit/Copy (Alt+c)</h4><ul> +<H3>Edit/Copy (Alt+c)</H3> Copy the selected widgets and all their children to the "clipboard" file. -</ul><h4>Edit/Paste (Alt+c)</h4><ul> +<H3>Edit/Paste (Alt+c)</H3> Paste in the widgets in the clipboard file. @@ -372,7 +346,7 @@ doing a paste. <p>Cut/paste is the only way to change the parent of a widget. -</ul><h4>Edit/Select All (Alt+a)</h4><ul> +<H3>Edit/Select All (Alt+a)</H3> Select all widgets in the same group as the current selection. @@ -380,20 +354,20 @@ Select all widgets in the same group as the current selection. that group's parent. Repeatedly typing Alt+a will select larger and larger groups of widgets until everything is selected. -</ul><h4>Edit/Open... (F1 or double click)</h4><ul> +<H3>Edit/Open... (F1 or double click)</H3> If the current widget is a window and it is not displayed, display it. Otherwise open a control panel for the most recent (and possibly all) selected widgets. -</ul><h4>Edit/Sort</h4><ul> +<H3>Edit/Sort</H3> All the selected widgets are sorted into left to right, top to bottom -order. You need to do this to make navigation keys in fltk work +order. You need to do this to make navigation keys in FLTK work correctly. You may then fine-tune the sorting with "Earlier" and "Later". This does not affect the positions of windows or functions. -</ul><h4>Edit/Earlier (F2)</h4><ul> +<H3>Edit/Earlier (F2)</H3> All the selected widgets are moved one earlier in order amoung the children of their parent (if possible). This will affect navigation @@ -401,35 +375,35 @@ order, and if the widgets overlap it will affect how they draw, as the later widget is drawn on top of the earlier one. You can also use this to reorder functions and windows within functions. -</ul><h4>Edit/Later (F3)</h4><ul> +<H3>Edit/Later (F3)</H3> All the selected widgets are moved one later in order amoung the children of their parent (if possible). -</ul><h4>Edit/Group (F7)</h4><ul> +<H3>Edit/Group (F7)</H3> Create a new Fl_Group and make all the currently selected widgets be children of it. -</ul><h4>Edit/Ungroup (F8)</h4><ul> +<H3>Edit/Ungroup (F8)</H3> If all the children of a group are selected, delete that group and -make them all be children of it's parent. +make them all be children of its parent. -</ul><h4>Edit/Overlays on/off (Alt+o)</h4><ul> +<H3>Edit/Overlays on/off (Alt+o)</H3> Toggle the display of the red overlays off, without changing the selection. This makes it easier to see box borders and how the layout looks. The overlays will be forced back on if you change the selection. -</ul><h4>Edit/Preferences (Alt+p)</h4><ul> +<H3>Edit/Preferences (Alt+p)</H3> Currently the only preferences are for the "alignment grid" that all widgets snap to when you move them and resize them, and for the "snap" -which is how far a widget has to be dragged from it's original +which is how far a widget has to be dragged from its original position to actually change. -</ul><h4>New/code/Function</h4><ul> +<H3>New/code/Function</H3> Create a new C function. You will be asked for a name for the function. This name should be a legal C++ function template, without @@ -441,17 +415,17 @@ as returning an Fl_Window*. The unnamed window will be returned from it (more than one unnamed window is useless). If the function contains only named windows it will be declared as returning void. -<p>It is possible to make the .C output be a self-contained program +<p>It is possible to make the .cxx output be a self-contained program that can be compiled and executed. This is done by deleting the function name, in which case "main(argc,argv)" is used. The function will call show() on all the windows it creates and then call Fl::run(). This can be used to test resize behavior or other parts of the user interface. I'm not sure if it is possible to create really -useful programs using just Fluid. +useful programs using just FLUID. <p>You can change the function name by double clicking the function. -</ul><h4>New/Window</h4><ul> +<H3>New/Window</H3> Create a new Fl_Window. It is added to the currently selected function, or to the function containing the currently selected item. @@ -461,7 +435,7 @@ to whatever size you require. <p>You also get the window's control panel, which is almost exactly the same as any other Fl_Widget, and is described in the next chapter. -</ul><h4>New/...</h4><ul> +<H3>New/...</H3> All other items on the New menu are subclasses of Fl_Widget. Creating them will add them to the currently selected group or window, or the @@ -472,29 +446,28 @@ possible. <p>When you create the widget you will get the widget's control panel, described in the next chapter. -</ul><h4>Help/About fluid</h4><ul> - -Pops up a panel showing the version of fluid. +<H3>Help/About FLUID</H3> -</ul><h4>Help/Manual</h4><ul> +Pops up a panel showing the version of FLUID. -Not yet implemented. Use netscape to read these pages instead. +<H3>Help/Manual</H3> -</ul> +Not yet implemented. Use a HTML or PDF file viewer to read these pages +instead. -<a name=widget_panel> <h2>The Widget Panel</h2> -When you double-click a widget or a set of widgets you will get the -"widget attribute panel": +<table cellpadding=0 cellspacing=0> +<tr> +<td> -<p><img align = left src = fluid_widget.gif> +When you double-click a widget or a set of widgets you will get the +"widget attribute panel". -<p>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 Alt+o) to -hide the red overlay so you can see the widgets more accurately, -especially when setting the box type. +<p>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 Alt+o) to hide the red overlay so you can see +the widgets more accurately, especially when setting the box type. <p>If you have several widgets selected, they may have different values for the fields. In this case the value for <i>one</i> of the @@ -502,12 +475,17 @@ widgets is shown. But if you change this value, <i>all</i> the selected widgets are changed to the new value. <p>Hitting "OK" makes the changes permanent. Selecting a different -widget also makes the changes permanent. Fluid checks for simple +widget also makes the changes permanent. FLUID checks for simple syntax errors in any code (such as mismatched parenthesis) before saving any text. -<p>"Revert" or "Cancel" put everything back to when you last brought -up the panel or hit OK. However in the current version of Fluid, +</td> +<td><img src="fluid_widget.gif" width=225></td> +</tr> +</table> + +"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 is undone, however. @@ -515,55 +493,55 @@ is undone, however. <a name=widget_attributes> <h2>Widget Attributes</h2> -</ul><h4>Name (text field)</h4><ul> +<H3>Name (text field)</H3> Name of a global C variable to declare, and to store a pointer to this widget into. This variable will be of type "<class>*". If the name is blank then no variable is created. <p>You can name several widgets with "name[0]", "name[1]", "name[2]", -etc. This will cause Fluid to declare an array of pointers. The +etc. This will cause FLUID to declare an array of pointers. The array is big enough that the highest number found can be stored. All widgets that in the array must be the same type. -</ul><h4>Type (upper-right pulldown menu)</h4><ul> +<H3>Type (upper-right pulldown menu)</H3> Some classes have subtypes that modify their appearance or behavior. You pick the subtype off of this menu. -</ul><h4>Box (pulldown menu)</h4><ul> +<H3>Box (pulldown menu)</H3> The boxtype to draw as a background for the widget. <p>Many widgets will work, and draw faster, with a "frame" instead of a "box". A frame does not draw the colored interior, leaving whatever -was already there visible. Be careful, as fluid may draw this ok but +was already there visible. Be careful, as FLUID may draw this ok but the real program leave unwanted stuff inside the widget. <p>If a window is filled with child widgets, you can speed up -redrawing by changing the window's box type to "NO_BOX". Fluid will +redrawing by changing the window's box type to "NO_BOX". FLUID will display a checkerboard for any areas that are not colored in by boxes (notice that this checkerboard is not drawn by the resulting program, instead random garbage is left there). -</ul><h4>Color</h4><ul> +<H3>Color</H3> <p>The color to draw the box with. -</ul><h4>Color2</h4><ul> +<H3>Color2</H3> -<p>Some widgets will use this color for certain parts. Fluid does not +<p>Some widgets will use this color for certain parts. FLUID does not always show the result of this: this is the color buttons draw in when pushed down, and the color of input fields when they have the focus. -</ul><h4>Label</h4><ul> +<H3>Label</H3> String to print next to or inside the button. <p>You can put newlines into the string to make multiple lines, the easiest way is by typing ctrl+j. -</ul><h4>Label style (pull down menu)</h4><ul> +<H3>Label style (pull down menu)</H3> How to draw the label. Normal, shadowned, engraved, and embossed change the appearance of the text. "symbol" requires the label to @@ -575,46 +553,46 @@ href=#images>"Image..."</a>. This lets you use the contents of an image file (currently an xpm pixmap or xbm bitmap) to label the widget. -</ul><h4>Label alignement (buttons)</h4><ul> +<H3>Label alignement (buttons)</H3> Where to draw the label. The arrows put it on that side of the widget, you can combine the to put it in the corner. The "box" button puts the label inside the widget, rather than outside. -</ul><h4>Label font</h4><ul> +<H3>Label font</H3> Font to draw the label in. Ignored by symbols, bitmaps, and pixmaps. Your program can change the actual font used by these "slots", in case you want some font other than the 16 provided. -</ul><h4>Label size</h4><ul> +<H3>Label size</H3> Point size for the font to draw the label in. Ignored by symbols, bitmaps, and pixmaps. To see the result without dismissing the panel, type the new number and then Tab. -</ul><h4>Label color</h4><ul> +<H3>Label color</H3> Color to draw the label. Ignored by pixmaps (bitmaps, however, do use this color as the foreground color). -</ul><h4>Text font, size, color</h4><ul> +<H3>Text font, size, color</H3> Some widgets display text, such as input fields, pull-down menus, browsers. You can change this here. -</ul><h4>Visible</h4><ul> +<H3>Visible</H3> If you turn this off the widget is hidden initially. Don't change this for windows or for the immediate children of a Tabs group. -</ul><h4>Active</h4><ul> +<H3>Active</H3> If you turn this off the widget is deactivated initially. Currently -no fltk widgets display the fact that they are inactive (like by graying +no FLTK widgets display the fact that they are inactive (like by graying out), but this may change in the future. -</ul><h4>Resizable</h4><ul> +<H3>Resizable</H3> If a window is resizable or has an immediate child that is resizable, then the user will be able to resize it. In addition all the size @@ -627,41 +605,41 @@ other children. <p>You can get more complex behavior by making invisible boxes the resizable widget, or by using hierarchies of groups. Unfortunatley -the only way to test it is to compile the program. Resizing the fluid +the only way to test it is to compile the program. Resizing the FLUID window is <i>not</i> the same as what will happen in the user program. -</ul><h4>Hotspot</h4><ul> +<H3>Hotspot</H3> Each window may have exactly one hotspot (turning this on will turn off any others). This will cause it to be positioned with that widget -centered on the mouse. This position is determined <i>when the fluid +centered on the mouse. This position is determined <i>when the FLUID function is called, so you should call it immediately before showing the window</i>. If you want the window to hide and then reappear at a new position, you should have your program set the hotspot itself just before show(). -</ul><h4>subclass</h4><ul> +<H3>subclass</H3> This is how you put your own subclasses of Fl_Widget in. Whatever identifier you type in here will be the class that is instantiated. -<p>In addition, no #include header file is put in the .H file. You +<p>In addition, no #include header file is put in the .h file. You must provide a #include line as the first of the "extra code" which declares your subclass. <p>The class had better be similar to the class you are spoofing. It does not have to be a subclass. It is sometimes useful to change this -to another fltk class: currently the only way to get a double-buffered +to another FLTK class: currently the only way to get a double-buffered window is to change this field for the window to "Fl_Double_Window" -and to add "#include <FL/Fl_Double_Window.H>" to the extra code. +and to add "#include <FL/Fl_Double_Window.h>" to the extra code. -</ul><h4>Extra code</h4><ul> +<H3>Extra code</H3> These four fields let you type in literal lines of code to dump into -the .H or .C files. +the .h or .cxx files. -<p>If the text starts with a '#' or the word "extern" then fluid -thinks this is an "include" line, and it is written to the .H file. +<p>If the text starts with a '#' 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. @@ -671,37 +649,37 @@ 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. -<p>Fluid will check for matching parenthesis, braces, and quotes, but +<p>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. If you need more than 4 lines you probably should call a function in -your own .C code. +your own .cxx code. -</ul><h4>Callback</h4><ul> +<H3>Callback</H3> This can either be the name of a function, or a small snippet of -code. Fluid thinks that if there is any punctuation then it is code. +code. FLUID thinks that if there is any punctuation then it is code. <p>A name names a function in your own code. It must be declared as "void <name>(<class>*,void*)". -<p>A code snippet is inserted into a static function in the .C output +<p>A code snippet is inserted into a static function in the .cxx output file. The function prototype is "void f(<class>* o, void* v)", so you can refer to -the widget as 'o' and the user_data as 'v'. Fluid will check for +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. <p>If the callback is blank then no callback is set. -</ul><h4>user_data</h4><ul> +<H3>user_data</H3> <p>This is a value for the 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 put "(void*)(<here>)". -</ul><h4>User data type</h4><ul> +<H3>User data type</H3> The "void*" in the callback function prototypes is replaced with this. You may want to use "long" for old XForms code. Be warned that @@ -709,7 +687,7 @@ anything other than "void*" is not guaranteed to work by the C++ spec! However on most architectures other pointer types are ok, and long is usually ok. -</ul><h4>When</h4><ul> +<H3>When</H3> When to do the callback. Can be "never", "changed", "release". The value of "enter key" is only useful for text input fields. The "no @@ -720,8 +698,6 @@ if the data is not changed. are not in the menu. You should use the extra code fields to put these values in. -</ul> - <a name=windows> <h2>Selecting & Moving Widgets</h2> @@ -754,7 +730,7 @@ 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 +you have input fields, as FLTK uses the same rules when using arrow keys to move between input fields. <p>To "open" a widget, double click it. To open several widgets @@ -764,7 +740,7 @@ select them and then type F1 or pick "Edit/Open" off the pop-up menu. the selection, so you can see the widget borders. <p>You can resize the window by using the window manager border -controls. Fltk will attempt to round the window size to the nearest +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 @@ -775,21 +751,19 @@ child widgets may be different. almost identical to the panel for any other Fl_Widget. There are three extra items: -</ul><h4>Border</h4><ul> +<H3>Border</H3> This button turns the window manager border on or off. On most window managers you will have to close the window and reopen it to see the effect. -</ul><h4>xclass</h4><ul> +<H3>xclass</H3> The string typed into here is passed to the X window manager as the class. This can change the icon or window decorations. On most (all?) window managers you will have to close the window and reopen it to see the effect. -</ul> - <a name=images> <h2>Image Labels</h2> @@ -799,8 +773,8 @@ already been chosen, you can change the image used by picking "Image..." again. The name of the image will appear in the "label" field, but you can't edit it. -<p>The <i>contents</i> of the image file are written to the .C file, -so if you wish to distribute the C code, you only need to copy the .C +<p>The <i>contents</i> of the image file are written to the .cxx file, +so if you wish to distribute the C code, you only need to copy the .cxx file, not the images. If many widgets share the same image then only one copy is written. @@ -810,9 +784,9 @@ to the location the .fl file is (not necessarily the current directory). I recommend you either put the images in the same directory as the .fl file, or use absolute path names. -</ul><h4>Notes for all image types</h4><ul> +<H3>Notes for all image types</H3> -<p>Fluid runs using the default visual of your X server. This may be +<p>FLUID runs using the default visual of your X server. This may be 8 bits, which will give you dithered images. You may get better results in your actual program by adding the code "Fl::visual(FL_RGB)" to your code right before the first window is displayed. @@ -822,12 +796,12 @@ source X pixmap. Thus once you have put an image on a widget, it is nearly free to put the same image on many other widgets. <p>If you are using a painting program to edit an image: the only way -to convince Fluid to read the image file again is to remove the image +to convince FLUID to read the image file again is to remove the image from all widgets that are using it (including ones in closed windows), -which will cause it to free it's internal copy, and then set the image -again. You may find it easier to exit Fluid and run it again. +which will cause it to free its internal copy, and then set the image +again. You may find it easier to exit FLUID and run it again. -<p>Don't rely on how fltk crops images that are outside the widget, as +<p>Don't rely on how FLTK crops images that are outside the widget, as this may change in future versions! The cropping of inside labels will probably be unchanged. @@ -838,57 +812,55 @@ and you want the image inside it, you must change the button's boxtype to FL_UP_FRAME (or another frame), otherwise when it is pushed it will erase the image. -</ul><h4>XBM (X bitmap files)</h4><ul> +<H3>XBM (X bitmap files)</H3> -<p>Fluid will read X bitmap files. These files have C source code to +<p>FLUID will read X bitmap files. These files have C source code to define a bitmap. Sometimes they are stored with the ".h" or ".bm" extension rather than the standard ".xbm". -<p>Fluid will output code to construct an Fl_Bitmap widget and use it +<p>FLUID will output code to construct an Fl_Bitmap widget and use it to label the widget. The '1' bits in the bitmap are drawn using the -label color of the widget. You can change the color in Fluid. The +label color of the widget. You can change the color in FLUID. The '0' bits are transparent. <p>The program "bitmap" on the X distribution does an ok job of editing bitmaps. -</ul><h4>XPM (X pixmap files)</h4><ul> +<H3>XPM (X pixmap files)</H3> -<p>Fluid will read X pixmap files as used by the libxpm library. +<p>FLUID will read X pixmap files as used by the libxpm library. These files have C source code to define a pixmap. The filenames usually have a ".xpm" extension. -<p>Fluid will output code to construct an Fl_Pixmap widget and use it +<p>FLUID will output code to construct an Fl_Pixmap widget and use it to label the widget. The label color of the widget is ignored, even for 2-color images that could be a bitmap. <p>XPM files can mark a single color as being transparent. Currently -fltk and Fluid simulate this transparency rather badly. It will use the +FLTK and FLUID simulate this transparency rather badly. It will use the color() of the widget as the background, and all widgets using the same pixmap are assummed to have the same color. This may be fixed in the future or on non-X systems. <p>I have not found any good editors for small iconic pictures. For -pixmaps I have used <a -href=http://www.danbbs.dk/~torsten/xpaint/index.html>XPaint</a>. This +pixmaps I have used <a href=http://www.danbbs.dk/~torsten/xpaint/index.html>XPaint</a>. This (and most other) painting programs are designed for large full color images and are difficult to use to edit an image of small size and few colors. -</ul><h4>GIF files</h4><ul> +<H3>GIF files</H3> -<p>Fluid will also read GIF image files. These files are often used +<p>FLUID will also read GIF image files. These files are often used on html documents to make icons. This lets you use nice icons that you steal off the net in your user interface. -<p>Fluid converts these into <a href=xpm.html>(modified)</a> xpm -format and uses an Fl_Pixmap widget to label the widget. Transparency -is handled the same as for xpm files. Notice that the conversion -removes the compression, so the code may be much bigger than the .gif -file. Only the first image of an animated gif file is used. +<p>FLUID converts these into (modified) XPM format and uses an +Fl_Pixmap widget to label the widget. Transparency is handled the same +as for xpm files. Notice that the conversion removes the compression, +so the code may be much bigger than the .gif file. Only the first +image of an animated gif file is used. <p>Behavior and performance with large .gif files is not guaranteed! -</ul> - -<p><a href = index.html>(back to contents)</a> +</BODY> +</HTML> diff --git a/documentation/forms.html b/documentation/forms.html index 1d6614581..c1c69cf0e 100644 --- a/documentation/forms.html +++ b/documentation/forms.html @@ -3,182 +3,193 @@ <H1 ALIGN=RIGHT><A NAME="forms">E - Forms Compatibility</A></H1> -<a href="#fluid">Fluid</a> (the Fast Light User Interface Designer) -can read the .fd files put out by all versions of Forms and XForms -fdesign. However, it will mangle them a bit, but it prints a warning -message about anything it does not understand. Fluid cannot write -fdesign files, so you should save to a new name so you don't write -over the old one. +This appendix describes the Forms compatibility included with FLTK. + +<H2>Importing Forms Layout Files</H2> + +<a href="#FLUID">FLUID</a> can read the .fd files put out by all +versions of Forms and XForms fdesign. However, it will mangle them a +bit, but it prints a warning message about anything it does not +understand. FLUID cannot write fdesign files, so you should save to a +new name so you don't write over the old one. <p>You will need to edit your main code considerably to get it to link -with the output from fluid. If you are not interested in this you may -have more immediate luck with the forms compatability header, +with the output from FLUID. If you are not interested in this you may +have more immediate luck with the forms compatibility header, <tt><FL/forms.H></tt>. -<p>You should be able to compile existing Forms or XForms source code -by changing the -I switch to your compiler so that the forms.h file -supplied with FLTK is included. Take a look at forms.h to see how it -works, but the basic trick is lots of inline functions. -Most of the XForms demo programs work without changes. +<H2>Using the Compatibility Header File</H2> + +You should be able to compile existing Forms or XForms source code +by changing the include directory switch to your compiler so that the +<tt>forms.h</tt> file supplied with FLTK is included. Take a look at +<tt>forms.h</tt> to see how it works, but the basic trick is lots of +inline functions. Most of the XForms demo programs work without +changes. + +<p>You will also have to compile your Forms or XForms program using a +C++ compiler. The FLTK library does not provide C bindings or header +files. <p>Although FLTK was designed to be compatable with the GL Forms library (version 0.3 or so), XForms has bloated severely and it's interface is -X specific. Therefore, XForms compatability is no longer a goal of -FLTK. Compatability was limited to things that were free, or that -would add code that would not be linked in if the feature is unused. -I did not add anything that would make the FLTK widgets bigger, or that -used X types as arguments. +X-specific. Therefore, XForms compatibility is no longer a goal of +FLTK. Compatibility was limited to things that were free, or that +would add code that would not be linked in if the feature is unused, +or that was not X-specific. <p>To use any new features of FLTK, you should rewrite your code to not -use the inline functions and instead use "pure" FLTK. This -will make it a lot cleaner and make it easier to figure out how to -call the FLTK functions. Unfortunately this conversion is harder than I -expeceted and even our inhouse code still uses forms.H a lot. +use the inline functions and instead use "pure" FLTK. This will make +it a lot cleaner and make it easier to figure out how to call the FLTK +functions. Unfortunately this conversion is harder than expected and +even Digital Domain's inhouse code still uses <tt>forms.H</tt> a lot. <h2>Problems you will encounter</h2> -<ul> - -<p><li>Many parts of XForms use X-specific structures like XEvent in -their interface. I did not emulate these! Unfortunately these +<p>Many parts of XForms use X-specific structures like <tt>XEvent</tt> +in their interface. I did not emulate these! Unfortunately these features (such as the "canvas" widget) are needed by most large programs. You will need to rewrite these to use FLTK subclasses. -<p><li><a href=Fl_Free.html>Fl_Free</a> widgets emulate the <i>old</i> -Forms "free" widget. It may be useful for porting programs that -change the handle() function on widgets, but you will still need to -rewrite things. +<p><a href="#Fl_Free"><tt>Fl_Free</tt></a> widgets emulate the +<i>old</i> Forms "free" widget. It may be useful for porting programs +that change the <tt>handle()</tt> function on widgets, but you will +still need to rewrite things. -<P><li><a href=Fl_Timer.html>Fl_Timer</a> widgets are provided to -emulate the XForms timer. These work, but are quite inefficient -and inaccurate compared to using Fl::add_timeout(). +<p><a href="#Fl_Timer"><tt>Fl_Timer</tt></a> widgets are provided to +emulate the XForms timer. These work, but are quite inefficient and +inaccurate compared to using <a +href="#add_timeout"><tt>Fl::add_timeout()</tt></a>. -<p><li><i>All instance variables are hidden.</i> +<p><i>All instance variables are hidden.</i> If you directly refer to the x, y, w, h, label, or other fields of your Forms widgets you will have to add empty parenthesis after each reference. The easiest way to do this is to globally replace "->x" -with "->x()", etc. Replace "boxtype" with box(). +with "->x()", etc. Replace "boxtype" with "box()". -<p><li>const char* arguments to most FLTK methods are simply stored, while -Forms would strdup() the passed string. This is most noticable with the -label of widgets. Your program must always pass static data such as a -string constant or malloc'd buffer to label(). If you are using -labels to display program output you may want to try the <a -href=Fl_Output.html>Fl_Output</a> widget. +<p><tt>const char *</tt> arguments to most FLTK methods are simply +stored, while Forms would <tt>strdup()</tt> the passed string. This is +most noticable with the label of widgets. Your program must always +pass static data such as a string constant or malloc'd buffer to +<tt>label()</tt>. If you are using labels to display program output +you may want to try the <a href="#Fl_Output"><tt>Fl_Output</tt></a> widget. -<p><li>The default fonts and sizes are matched to the older GL version of +<p>The default fonts and sizes are matched to the older GL version of Forms, so all labels will draw somewhat larger than an XForms program does. -<p><li>fdesign outputs a setting of a "fdui" instance variable to the main -window. I did not emulate this because I wanted all instance -variables to be hidden. You can store the same information in the -user_data() field of a window. To do this, -search through the fdesign output for all occurances -of "->fdui" and edit to use "->user_data()" instead. This will -require casts and is not trivial. - -<p><li>The prototype for the functions passed to fl_add_timeout() and -fl_set_idle_callback() callback are different. - -<p><li><b>All the following XForms calls are missing:</b><p> - -<li><code>FL_VERSION, FL_REVISION</code>, fl_library_version() -<li><code>FL_RETURN_DBLCLICK</code> (use Fl::event_clicks()) -<li>fl_add_signal_callback() -<li>fl_set_form_atactivate() & fl_set_form_atdeactivate() -<li>fl_set_form_property() -<li>fl_set_app_mainform(), fl_get_app_mainform() -<li>fl_set_form_minsize(), fl_set_form_maxsize() -<li>fl_set_form_event_cmask(), fl_get_form_event_cmask() -<li>fl_set_form_dblbuffer(), fl_set_object_dblbuffer() (use an -Fl_Double_Window instead) -<li>fl_adjust_form_size() -<li>fl_register_raw_callback() -<li>fl_set_object_bw(), fl_set_border_width() -<li>fl_set_object_resize(), fl_set_object_gravity() -<li>fl_set_object_shortcutkey() -<li>fl_set_object_automatic() -<li>fl_get_object_bbox() (maybe FLTK should do this) -<li>fl_set_object_prehandler(), fl_set_object_posthandler() -<li>fl_enumerate_fonts() -<li>Most drawing functions -<li>fl_set_coordunit() (FLTK uses pixels all the time) -<li>fl_ringbell() -<li>fl_gettime() -<li>fl_win*() (all these functions) -<li>fl_initialize(argc,argv,x,y,z) ignores last 3 arguments -<li>fl_read_bitmapfile(), fl_read_pixmapfile() -<li>fl_addto_browser_chars() -<li>FL_MENU_BUTTON just draws normally -<li>fl_set_bitmapbutton_file(), fl_set_pixmapbutton_file() -<li>FL_CANVAS objects -<li>FL_DIGITAL_CLOCK (comes out analog) -<li>fl_create_bitmap_cursor(), fl_set_cursor_color() -<li>fl_set_dial_angles() -<li>fl_show_oneliner() -<li>fl_set_choice_shortcut(a,b,c) -<li>command log -<li>Only some of file selector is emulated -<li>FL_DATE_INPUT -<li>fl_pup*() (all these functions) -<li>textbox object (should be easy but I had no sample programs) -<li>xyplot object +<p>fdesign outputs a setting of a "fdui" instance variable to the main +window. I did not emulate this because I wanted all instance variables +to be hidden. You can store the same information in the +<tt>user_data()</tt> field of a window. To do this, search through +the fdesign output for all occurances of "->fdui" and edit to use +"->user_data()" instead. This will require casts and is not trivial. + +<p>The prototype for the functions passed to <tt>fl_add_timeout()</tt> +and <tt>fl_set_idle_callback()</tt> callback are different. + +<p><b>All the following XForms calls are missing:</b><p> + +<ul> + <li><tt>FL_REVISION</tt>, <tt>fl_library_version()</tt> + <li><tt>FL_RETURN_DBLCLICK</tt> (use <tt>Fl::event_clicks()</tt>) + <li><tt>fl_add_signal_callback()</tt> + <li><tt>fl_set_form_atactivate()</tt> & <tt>fl_set_form_atdeactivate()</tt> + <li><tt>fl_set_form_property()</tt> + <li><tt>fl_set_app_mainform()</tt>, <tt>fl_get_app_mainform()</tt> + <li><tt>fl_set_form_minsize()</tt>, <tt>fl_set_form_maxsize()</tt> + <li><tt>fl_set_form_event_cmask()</tt>, <tt>fl_get_form_event_cmask()</tt> + <li><tt>fl_set_form_dblbuffer()</tt>, <tt>fl_set_object_dblbuffer()</tt> (use an + <tt>Fl_Double_Window</tt> instead) + <li><tt>fl_adjust_form_size()</tt> + <li><tt>fl_register_raw_callback()</tt> + <li><tt>fl_set_object_bw()</tt>, <tt>fl_set_border_width()</tt> + <li><tt>fl_set_object_resize()</tt>, <tt>fl_set_object_gravity()</tt> + <li><tt>fl_set_object_shortcutkey()</tt> + <li><tt>fl_set_object_automatic()</tt> + <li><tt>fl_get_object_bbox()</tt> (maybe FLTK should do this) + <li><tt>fl_set_object_prehandler()</tt>, <tt>fl_set_object_posthandler()</tt> + <li><tt>fl_enumerate_fonts()</tt> + <li>Most drawing functions + <li><tt>fl_set_coordunit()</tt> (FLTK uses pixels all the time) + <li><tt>fl_ringbell()</tt> + <li><tt>fl_gettime()</tt> + <li><tt>fl_win*()</tt> (all these functions) + <li><tt>fl_initialize(argc,argv,x,y,z)</tt> ignores last 3 arguments + <li><tt>fl_read_bitmapfile()</tt>, <tt>fl_read_pixmapfile()</tt> + <li><tt>fl_addto_browser_chars()</tt> + <li><tt>FL_MENU_BUTTON</tt> just draws normally + <li><tt>fl_set_bitmapbutton_file()</tt>, <tt>fl_set_pixmapbutton_file()</tt> + <li><tt>FL_CANVAS</tt> objects + <li><tt>FL_DIGITAL_CLOCK</tt> (comes out analog) + <li><tt>fl_create_bitmap_cursor()</tt>, <tt>fl_set_cursor_color()</tt> + <li><tt>fl_set_dial_angles()</tt> + <li><tt>fl_show_oneliner()</tt> + <li><tt>fl_set_choice_shortcut(a,b,c) + <li>command log + <li>Only some of file selector is emulated + <li><tt>FL_DATE_INPUT</tt> + <li><tt>fl_pup*()</tt> (all these functions) + <li>textbox object (should be easy but I had no sample programs) + <li>xyplot object </ul> -<h2>Additional notes for porting old Forms programs</h2> +<h2>Additional Notes</h2> -<p>These notes were written for porting programs written with the -older GL version of Forms. Most of these problems are the same ones +These notes were written for porting programs written with the older +IRISGL version of Forms. Most of these problems are the same ones encountered when going from old Forms to XForms: -<h4>Does not go into background</h4> +<h3>Does Not Run In Background</h3> -The GL library always forked when you created the first window, unless +The IRISGL library always forked when you created the first window, unless "foreground()" was called. FLTK acts like "foreground()" is called all the time. If you really want the fork behavior do "if (fork()) exit(0)" right at the start of your program. -<h4>You cannot use GL windows or fl_queue</h4> +<h3>You Cannot Use IRISGL windows or fl_queue</h3> -<P>If a Forms (not XForms) program if you wanted your own window for -displaying things you would create a GL window and draw in it, +If a Forms (not XForms) program if you wanted your own window for +displaying things you would create a IRISGL window and draw in it, periodically calling Forms to check if the user hit buttons on the -panels. If the user did things to the GL window, you would find this -out by having the value FL_EVENT returned from the call to Forms. +panels. If the user did things to the IRISGL window, you would find +this out by having the value FL_EVENT returned from the call to Forms. <p>None of this works with FLTK. Nor will it compile, the necessary calls are not in the interface. <p>You have to make a subclass of <a -href=Fl_Gl_Window.html>Fl_Gl_Window</a> and write a draw() method and -handle() method. This may require anywhere from a trivial to a major -rewrite. See the example program <a href=shape.C.html>shape.C</a> for -how this is structured. +href="#Fl_Gl_Window"><tt>Fl_Gl_Window</tt></a> and write a <tt>draw()</tt> +method and <tt>handle()</tt> method. This may require anywhere from a trivial +to a major rewrite. <p>If you draw into the overlay planes you will have to also write a -draw_overlay() routine and call redraw_overlay() on the gl window. +<tt>draw_overlay()</tt> method and call <tt>redraw_overlay()</tt> on the +OpenGL window. -<p>One easy way to hack your program so it works is to make the draw() -and handle() methods on your window set some static variables, storing -what event happened. Then in the main loop of your program, call -Fl::wait() and then check these variables, acting on them as -though they are events read from fl_queue. +<p>One easy way to hack your program so it works is to make the +<tt>draw()</tt> and <tt>handle()</tt> methods on your window set some +static variables, storing what event happened. Then in the main loop +of your program, call <tt>Fl::wait()</tt> and then check these +variables, acting on them as though they are events read from +<tt>fl_queue</tt>. -<h4>You must use OpenGL to draw everything</h4> +<h3>You Must Use OpenGL to Draw Everything</h3> -<p>The file <FL/gl.h> defines replacements for a lot of gl calls, -translating them to OpenGL. There are much better translators -available that you might want to investigate. +<p>The file <tt><FL/gl.h></tt> defines replacements for a lot of +IRISGL calls, translating them to OpenGL. There are much better +translators available that you might want to investigate. -<h4>You cannot make Forms subclasses</h4> +<h3>You Cannot Make Forms Subclasses</h3> -Programs that call fl_make_object or directly setting the handle -routine will not compile. You have to rewrite them to use a subclass -of Fl_Widget. It is important to note that the handle() method is not -exactly the same as the handle() function of Forms. Where a Forms -handle() returned non-zero, your handle() must call do_callback(). -And your handle() must return non-zero if it "understood" the event. +Programs that call <tt>fl_make_object</tt> or directly setting the +handle routine will not compile. You have to rewrite them to use a +subclass of <tt>Fl_Widget</tt>. It is important to note that the +<tt>handle()</tt> method is not exactly the same as the +<tt>handle()</tt> function of Forms. Where a Forms <tt>handle()</tt> +returned non-zero, your <tt>handle()</tt> must call +<tt>do_callback()</tt>. And your <tt>handle()</tt> must return non-zero +if it "understood" the event. <p>An attempt has been made to emulate the "free" widget. This appears to work quite well. It may be quicker to modify your subclass @@ -187,34 +198,64 @@ into a "free" widget, since the "handle" functions match. <p>If your subclass draws into the overlay you are in trouble and will have to rewrite things a lot. -<h4>You cannot use <device.h></h4> +<h3>You Cannot Use <device.h></h3> If you have written your own "free" widgets you will probably get a lot of errors about "getvaluator". You should substitute: -<table> -<tr><td align=center>Forms <td align=center>FLTK -<tr><td>MOUSE_X <td>Fl::event_x_root() -<tr><td>MOUSE_Y<td> Fl::event_y_root() -<tr><td>LEFTSHIFTKEY,RIGHTSHIFTKEY<td> Fl::event_shift() -<tr><td>CAPSLOCKKEY<td> Fl::event_capslock() -<tr><td>LEFTCTRLKEY,RIGHTCTRLKEY<td> Fl::event_ctrl() -<tr><td>LEFTALTKEY,RIGHTALTKEY<td> Fl::event_alt() -<tr><td>MOUSE1,RIGHTMOUSE<td> Fl::event_state()&(1<<10) -<tr><td>MOUSE2,MIDDLEMOUSE<td> Fl::event_state()&(1<<9) -<tr><td>MOUSE3,LEFTMOUSE<td> Fl::event_state()&(1<<8) +<table border=1> +<tr> + <th align=center>Forms</th> + <th align=center>FLTK</th> +</tr> +<tr> + <td>MOUSE_X</td> + <td>Fl::event_x_root()</td> +</tr> +<tr> + <td>MOUSE_Y</td> + <td>Fl::event_y_root()</td> +</tr> +<tr> + <td>LEFTSHIFTKEY,RIGHTSHIFTKEY</td> + <td>Fl::event_shift()</td> +</tr> +<tr> + <td>CAPSLOCKKEY</td> + <td>Fl::event_capslock()</td> +</tr> +<tr> + <td>LEFTCTRLKEY,RIGHTCTRLKEY</td> + <td>Fl::event_ctrl()</td> +</tr> +<tr> + <td>LEFTALTKEY,RIGHTALTKEY</td> + <td>Fl::event_alt()</td> +</tr> +<tr> + <td>MOUSE1,RIGHTMOUSE</td> + <td>Fl::event_state()&FL_BUTTON3</td> +</tr> +<tr> + <td>MOUSE2,MIDDLEMOUSE</td> + <td>Fl::event_state()&FL_BUTTON2</td> +</tr> +<tr> + <td>MOUSE3,LEFTMOUSE</td> + <td>Fl::event_state()&FL_BUTTON1</td> +</tr> </table> -<p>Anything else in getvaluator and you are on your own... +Anything else in <tt>getvaluator</tt> and you are on your own... -<h4>Font numbers are different</h4> +<h3>Font Numbers Are Different</h3> The "style" numbers have been changed because I wanted to insert bold-italic versions of the normal fonts. If you use Times, Courier, or Bookman to display any text you will get a different font out of -FLTK. If you are really desperate to fix this use the following code:<ul> +FLTK. If you are really desperate to fix this use the following code: -<pre> +<ul><pre> fl_font_name(3,"*courier-medium-r-no*"); fl_font_name(4,"*courier-bold-r-no*"); fl_font_name(5,"*courier-medium-o-no*"); diff --git a/documentation/functions.html b/documentation/functions.html index 6dfe9a0cf..8d1ddbf1c 100644 --- a/documentation/functions.html +++ b/documentation/functions.html @@ -3,620 +3,837 @@ <H1 ALIGN=RIGHT>B - Function Reference</H1> -When we created the window and box widgets - and widgets inside the window. - Here a single -<a href=Fl_Box.html>Fl_Box</a> is created. The arguments to the -constructor are a value for the <a href=Fl_Widget.html#box>box()</a> -property (most constructors do not have this), values for <a -href=Fl_Widget.html#xywh>x(), y(), w(), h()</a> to define the position -and size of the box, and a value for <a -href=Fl_Widget.html#label>label()</a> to define the text printed in the -box. +This appendix describes all of the <tt>fl_</tt> functions and +<tt>Fl::</tt> methods. For a description of the FLTK widgets, see <a +href="#widgets">Appendix A</a>. -<p>All the widgets have several attributes and there is a method for -setting and getting the current value of each of them. -<Code>box->labelsize(36)</tt> sets the <a -href=Fl_Widget.html#labelsize>labelsize()</a> to 36. You could get -the value with <tt>box->labelsize()</tt>. Often you have to set -many properties, so you will be relieved to know that almost all of -these methods are trivial inline functions. +<H2>Functions</H2> -<P><a href=Fl_Widget.html#labelfont><tt>labelfont()</tt></a> is -set to a symbolic value which is compiled into a constant integer, 3 -in this case. All properties that cannot be described by a single -small number use a 1-byte index into a table. This makes the widget -smaller, allows the actual definition of the property to be deferred -until first use, and you can redefine existing entries to make global -style changes. +<h3><a name="fl_color_chooser">int fl_color_chooser(const char*, double &r, double &g, double &b)<br> +int fl_color_chooser(const char *, uchar &r, uchar &g, uchar &b)</a></h3> -<p><a -href=Fl_Widget.html#labeltype><tt>labeltype(FL_SHADOW_LABEL)</tt></a> -also stores a 1-byte symbolic value, in this case indicating a -procedure to draw drop shadows under the letters should be called to -draw the label. +The double version takes RGB values in the range 0.0 to 1.0. The +uchar version takes RGB values in the range 0 to 255. -<p>The constructor for widgets adds them as children of the "current -group" (usually a window). <tt>window->end()</tt> stops adding -them to this window. For more control over the construction of -objects, you can end() the window immediately, and then add the -objects with <a -href=Fl_Group.html#add><tt>window->add(box)</tt></a>. You can -also do <a href=Fl_Group.html#begin><tt>window->begin()</tt></a> -to switch what window new objects are added to. +<center><img src="fl_color_chooser.jpg"></center> -<p><a href=Fl_Window.html#show><Code>window->show()</tt></a> finally -puts the window on the screen. It is not until this point that the X -server is opened. FLTK provides some <i>optional</i> and rather -simple command-line parsing if you call <a -href=Fl.html#show>show(argv,argc)</a>. If you don't want this, just -call show() with no arguments, and <i>the unused argument code is not -linked into your program, making it smaller!</i> +<p><tt>fl_color_chooser()</tt> pops up a window to let the user pick an +arbitrary RGB color. They can pick the hue and saturation in the "hue +box" on the left (hold down CTRL to just change the saturation), and +the brighness using the vertical slider. Or they can type the 8-bit +numbers into the RGB <a +href="#Fl_Value_Input"><tt>Fl_Value_Input</tt></a> fields, or drag the +mouse across them to adjust them. The pull-down menu lets the user set +the input fields to show RGB, HSV, or 8-bit RGB (0 to 255). -<p><a href=Fl.html#run><tt>Fl::run()</tt></a> makes FLTK -enter a loop to update the screen and respond to events. By -default when the user closes the last window FLTK exits by calling <a -href=Fl.html><tt>exit(0)</tt></a>. <i>run() does not -actually return, it is declared to return an int so you can end your -main() function with "return Fl::run()" and outwit the stupid compiler -made by a certain very large software company.</i> +<p>This returns non-zero if the user picks ok, and updates the RGB +values. If the user picks cancel or closes the window this returns +zero and leaves RGB unchanged. -<p>The following command compiles this program, assuming the FLTK -library has been put in /usr/local/lib and the header files in -/usr/local/include/FL: +<p>If you use the color chooser on an 8-bit screen, it will allocate +all the available colors, leaving you no space to exactly represent +the color the user picks! You can however use <a +href="#fl_rectf"><tt>fl_rectf()</tt></a> to fill a region with a +simulated color using dithering. +<h3><a name="fl_show_colormap">int fl_show_colormap(int oldcol)</a></h3> +<tt>fl_show_colormap()</tt> pops up a panel of the 256 colors you +can access with <a href="#fl_color"><tt>fl_color()</tt></a> and lets the +user pick one of them. It returns the new color index, or the old one +if the user types ESC or clicks outside the window. +<center><img src="fl_show_colormap.gif"></center> +<h3><a name="fl_message">void fl_message(const char *, ...)</a></h3> +Displays a printf-style message in a pop-up box with an "OK" +button, waits for the user to hit the button. The message will wrap +to fit the window, or may be many lines by putting <tt>\n</tt> characters into +it. The enter key is a shortcut for the OK button. +<center><img src="fl_message.gif"></center> +<h3><a name="fl_">void fl_alert(const char *, ...)</a></h3> +Same as <tt>fl_message()</tt> except for the "!" symbol. +<center><img src="fl_alert.gif"></center> +<h3><a name="fl_ask">int fl_ask(const char *, ...)</a></h3> +Displays a printf-style message in a pop-up box with an "Yes" and "No" +button and waits for the user to hit a button. The return value is 1 +if the user hits Yes, 0 if they pick No. The enter key is a shortcut +for Yes and ESC is a shortcut for No. +<center><img src="fl_ask.gif"></center> +<h3><a name="fl_choice">int fl_choice(const char *q, const char *b0, const char *b1, const char *b2, ...)</a></h3> +Shows the message with three buttons below it marked with the strings +<tt>b0</tt>, <tt>b1</tt>, and <tt>b2</tt>. Returns 0, 1, or 2 +depending on which button is hit. ESC is a shortcut for button 0 and +the enter key is a shortcut for button 1. Notice the "misordered" +position of the buttons. You can hide buttons by passing <tt>NULL</tt> +as their labels. +<center><img src="fl_choice.gif"></center> +<h3><a name="fl_input">const char *fl_input(const char *label, const char *deflt = 0, ...)</a></h3> +Pops up a window displaying a string, lets the user edit it, and return +the new value. The cancel button returns <tt>NULL</tt>. <i>The +returned pointer is only valid until the next time <tt>fl_input()</tt> +is called</i>. Due to back-compatability, the arguments to any printf +commands in the label are after the default value. +<center><img src="fl_input.gif"></center> +<h3><a name="fl_password">const char *fl_password(const char *label, const char *deflt = 0, ...)</a></h3> +Same as <tt>fl_input()</tt> except an <a +href="#Fl_Secret_Input"><tt>Fl_Secret_Input</tt></a> field is used. - -<p>The first thing your program should do is construct one or more -trees of <tt>Fl_Widgets</tt>. The base widget of each of these is -an <tt>Fl_Window</tt> widget. The constructors for widgets -automatically add them as children of the most recent created window -widget (use window->end() to stop this). Constructing the widgets -<i>does not require the display to be open and does not open it</i>, -unless you purposely open it to get information such as the width of a -font. +<center><img src="fl_password.gif"></center> -<p><tt>Fl_Window</tt>s are displayed on the screen with -<tt>Fl_Window::show()</tt>. For the first window you may also use -<tt>Fl_Window::show(argc,argv)</tt> and FLTK will automatically -parse some startup arguments such as -display. +<h3><a name="fl_message_font">void fl_message_font(Fl_Font fontid, uchar size)</a></h3> -<p>Then the program repeatedly calls <tt>Fl::wait()</tt>. Each -time "something happens" <tt>Fl::wait()</tt> returns, usually after -a block of X events have been read and processed. It is often useful -for a program to check global state after each event, and FLTK makes -this easy by leaving the main loop under your control. +Change the font and font size used for the messages in all the popups. -<p>Each widget has a <i>single</i> "callback". This is a function that -is called when something happens (such as the user pressing a button). -FLTK avoids all the complexities of signals/slots by having only a -single callback. Instead a when() method on the object selects when -the callback is done (ie. when a slider is moved or when the mouse is -released). +<h3><a name="fl_message_icon">Fl_Widget *fl_message_icon()</a></h3> -<p>The callback is passed a pointer to the widget and a void* user_data -field. This is redundant, as the user_data can be determined from the -widget, but was done for XForms compatability and to make the same -callbacks useful for menu items. Typically you want to turn the -callback into a method on some C++ object. A simple way is to use the -user_data as a pointer to the object. A more common but harder to -understand way is to store the object in the <i>parent</i> widget's -user_data field, since usually all the controls on a window are for the -same object, this lets you use the user_data for an abitrary method -argument. +Returns a pointer to the box at the left edge of all the popups. You +can alter the font, color, or label (including making it a Pixmap), +before calling the functions. -<p>To display graphic data, you must <i>subclass</i> either -<tt>Fl_Window</tt> or <tt>Fl_Widget</tt> and define the virtual -<tt>draw()</tt> method. This can use functions defined in -<FL/fl_draw.H>, or can use system-specific calls such as Xlib. If -the data being displayed changes, your main program calls the -<tt>redraw()</tt> method on your widget, and FLTK will call -<tt>draw()</tt> while waiting for the next event. Subclassing -<tt>Fl_Window</tt> or <tt>Fl_Widget</tt> is so easy that I felt -it unnecessary to provide the "canvas" widget that most toolkits have. +<h3><a name="fl_file_chooser">char *fl_file_chooser(const char * message, const char *pattern, const char *fname)</a></h3> -<p>If your program needs to monitor another device (such as stdin) you -can provide a callback routine for when it becomes ready, by using -<tt>Fl::add_fd(i)</tt>. If your program needs something to happen -at regular intervals you can define a timeout callback with <tt><a -href=Fl.html#add_timeout>Fl::add_timeout(time)</a></tt>. +FLTK provides a "tab completion" file chooser that makes it easy to +choose files from large directories. This file chooser has several +unique features, the major one being that the Tab key completes +filenames like it does in Emacs or tcsh, and the list always shows all +possible completions. -<p>Building a large hierarchy is made much easier with <i>fluid</i> -(the Fast Light User Interface Designer). This is a program that lets -you interactively design the widget layout and set all the properties -visually. It outputs C++ source code that you compile and link with -your program. All you have to write is the main loop and any -callbacks. +<center><img src="filechooser.gif"></center> -</BODY> -</HTML> -<HTML> -<BODY> +<tt>fl_file_chooser()</tt> pops up the file chooser, waits for the user +to pick a file or Cancel, and then returns a pointer to that filename +or <tt>NULL</tt> if Cancel is chosen. -This chapter demonstrates the basics of FLTK programming with examples. +<p><tt>message</tt> is a string used to title the window. -<H2>Compiling a FLTK Program</H2> +<p><tt>pattern</tt> is used to limit the files listed in a directory to +those matching the pattern. This matching is done by <a +href="#filename_match"><tt>filename_match()</tt></a>. Use +<tt>NULL</tt> to show all files. -<H3>Include Files</H3> +<p><tt>fname</tt> is a default filename to fill in the chooser with. If +this is <tt>NULL</tt> then the last filename that was choosen is used (unless +that had a different pattern, in which case just the last directory +with no name is used). The first time the file chooser is called this +defaults to a blank string. -<H3>Library Files</H3> +<p>The returned value points at a static buffer that is only good +until the next time <tt>fl_file_chooser()</tt> is called. -<H2>A "Hello, World" Program</H2> +<h3><a name="fl_file_chooser_callback">void fl_file_chooser_callback(void (*cb)(const char *))</a></h3> -<H3>Creating the Window</H3> +Set a function that is called every time the user clicks a file in the +currently popped-up file chooser. This could be used to preview the +contents of the file. It has to be reasonably fast, and cannot create +FLTK windows. -<H3>The Main Loop</H3> +<h3><a name="filename_list">int filename_list(const char *d, dirent ***list)</a></h3> -</BODY> -</HTML> -<title>FLTK example: ask.C</title> -<h2>ask.C</h2> - -<p><img src = ask.C.gif align=top> - -<pre> -#include <stdio.h> -#include <string.h> -#include <FL/Fl.H> -#include <FL/Fl_Window.H> -#include <FL/Fl_Input.H> -#include <FL/Fl_Button.H> -#include <FL/Fl_Return_Button.H> - -int get_string(char*buffer, const char *from) { - Fl_Window window(320,75); - window.set_modal(); - Fl_Input input(60, 40, 250, 25,"Input:"); - input.value(buffer); - Fl_Button cancel(60, 10,80, 25,"cancel"); - Fl_Return_Button ok(150, 10,80, 25,"OK"); - window.end(); - window.show(); - for (;;) { - Fl::wait(); - Fl_Widget *o; - while (o = Fl::readqueue()) { - if (o == &ok) { - strcpy(buffer, input.value()); - return 1; - } else if (o == &cancel || o == &window) { - return 0; - } - } - } -} +This is a portable and const-correct wrapper for the +<tt>fl_scandir</tt> function. <tt>d</tt> is the name of a directory +(it does not matter if it has a trailing slash or not). For each file +in that directory a "dirent" structure is created. The only portable +thing about a dirent is that dirent.d_name is the nul-terminated file +name. An array of pointers to these dirents is created and a pointer +to the array is returned in <tt>*list</tt>. The number of entries is +given as a return value. If there is an error reading the directory a +number less than zero is returned, and <tt>errno</tt> has the reason +(<tt>errno</tt> does not work under WIN32). The files are sorted in +"alphanumeric" order, where an attempt is made to put unpadded numbers +in consecutive order. -int main(int argc, char **argv) { - char buffer[128]; - if (get_string(buffer, argv[1])) { - puts(buffer); - return 0; - } else { - return 1; // exit with error - } -} -</pre> - -<p>Widgets don't need to have <a -href=Fl_Widget.html#callback>callback()</a> set. The <a -href=Fl_Widget.html#default_callback>default callback</a> puts a -pointer to the widget on a "queue" from which it can later be read -with <a href=Fl.html#readqueue>Fl::readqueue()</a>. This was -done for Forms compatibility but it is useful for <a -href=Fl_Window.html#modal>modal windows</a>. In this example the -"get_string" function puts up a modal window and loops until one of -the buttons is pushed. - -<a href=Fl.html#wait>Fl::wait()</a> does exactly one cycle of -what Fl::run() does repeatedly: it updates the screen and then waits -for and responds to an event (or several events if they are all ready -at the same time). It then returns, allowing the user program to -check any state information it wants to after each group of events. -One thing the user program can check is <a -href=Fl.html#readqueue>Fl::readqueue()</a> which returns each -object without a callback that was triggered. It returns null when -the queue is empty. It is possible for more than one object to be on -the queue (or the same object several times) so if your program wants -to read the queue it should always read it until empty and ignore -unrecognized widgets (don't look at them as they may have been -deleted). - -<P><a href=Fl_Window.html#modal>modal()</a> on a window prevents any -interaction with other program windows below it, and prevents the user -from raising a program window above it (well, it tries, but X is -broken). It won't make any difference in this program because there -is only one window, but this allows the "get_string" function to be -used as subroutine by a larger program and have the expected behavior. - -<P>This program also demonstrates that FLTK widgets may be constructed -as C++ automatic objects (local variables). You have to be careful -about <a href=Fl_Widget.html#destructor>destruction</a>, however. -Always make sure all automatic children are destructed before the -container (by declaring the children <i>after</i> the container), -since the destructor for a container will attempt to delete all -remaining children, and you don't want to delete automatic objects. - -<p><a href = shape.C.html>[Next example]</a> -<br><a href = index.html>[back to contents]</a> -<title>FLTK example: button.C</title> -<h2>button.C</h2> - -<p><img src= button.C.gif align=top> - -<pre> -#include <stdlib.h> -#include <stdio.h> -#include <FL/Fl.H> -#include <FL/Fl_Window.H> -#include <FL/Fl_Button.H> - -void beepcb(Fl_Widget *, void *) { - printf("\007"); fflush(stdout); -} +<p>You can free the returned list of files with the following code: -void exitcb(Fl_Widget *, void *) { - exit(0); -} +<ul><pre> +for (int i = return_value; i > 0;) free((void*)(list[--i])); +free((void*)list); +</pre></ul> -int main(int argc, char ** argv) { - Fl_Window *window = new Fl_Window(320,65); - window->begin(); - Fl_Button *b1 = new Fl_Button(20, 20, 80, 25, "Beep"); - b1->callback(beepcb,0); - Fl_Button *b2 = new Fl_Button(120,20, 80, 25, "no op"); - Fl_Button *b3 = new Fl_Button(220,20, 80, 25, "Exit"); - b3->callback(exitcb,0); - window->end(); - window->show(argc,argv); - return Fl::run(); -} -</pre> +<h3><a name="filename_isdir">int filename_isdir(const char *f)</a></h3> -<p>In this example we make some button widgets and make them do -something through callbacks. +Returns non-zero if the file exists and is a directory. -<P>All widgets have a single <a -href=Fl_Widget.html#callback>callback()</a> function. It is called in -response to an event on that widget, exactly which event depends on -the type of widget. The function takes two arguments: a pointer to -the widget (you will usually need to cast this to the correct -subclass) and a void* pointer to a piece of arbitrary user_data. +<h3><a name="filename_name">const char *filename_name(const char *f)</a></h3> -<P>You don't have to give all the widgets a callback, as the "no op" b2 -widget demonstrates. What these do is described in the next program. +Returns a pointer to the character after the last slash, or to the +start of the filename if there is none. -<p><a href = ask.C.html>[Next example]</a> -<br><a href = index.html>[back to contents]</a> -<title>FLTK methods</title> +<h3><a name="filename_ext">const char *filename_ext(const char *f)</a></h3> -<h2>#include <FL/Fl.H></h2> +Returns a pointer to the last period in <tt>filename_name(f)</tt>, or +a pointer to the trailing nul if none. -<p>You will have to include at least this header file in your main -code so that you can call the methods described here. +<h3><a name="filename_setext">char *filename_setext(char *f, const char *ext)</a></h3> -<h2>Initialization</h2> +Does <tt>strcpy(filename_ext(f), ext ? ext : "")</tt>. Returns a +pointer to <tt>f</tt>. -<p><i>You can construct all your widgets (and menus and boxtypes and -images and other FLTK types) without "initializing".</i> The -constructors do not require a connection to the X display. This makes -it a lot easier, especially if your program has a mode where it does -not use a gui, and guarantees that code you don't use is not linked -in. +<h3><a name="filename_expand">int filename_expand(char *out, const char *in)</a></h3> -<p>FLTK is usually "initialized" when you show() the first window. At -this time the X display is opened and everything is set up so the -calls described in the rest of this document work. A few other calls -can open the X display, amoung them are fl_width() to measure the -size of a font. Be careful that the following calls are done before -the display is opened, if not you will get lots of strange X errors. +Splits <tt>in</tt> at each slash character. Replaces any occurrance of +<tt>$X</tt> with <tt>getenv("X")</tt> (leaving it as <tt>$X</tt> if the +environment variable does not exist). Replaces any occurances of +<tt>~X</tt> with user <tt>X</tt>'s home directory (leaving it as +<tt>~X</tt> if the user does not exist). Any resulting double slashes +cause everything before the second slash to be deleted. Copies the +result to <tt>out</tt> (<tt>in</tt> and <tt>out</tt> may be the same +buffer). Returns non-zero if any changes were made. <i>In true retro +programming style, it is up to you to provide a buffer big enough for +the result. 1024 characters should be enough.</i> -<p>Most of these "initialization" calls are to get around stupid X -things. I have tried to make these as simple to call as possible and -they have no effect on systems which aren't as badly designed as X. -But you should call them to make your program as portable as possible. +<h3><a name="filename_absolute">int filename_absolute(char *out, const char *in)</a></h3> -<a name=visual> -</ul><h4><tt>int Fl::visual(int)</tt></h4><ul> +If <tt>in</tt> does not start with a slash, this prepends the current +working directory to <tt>in</tt> and then deletes any occurances of +<tt>.</tt> and </tt>x/..</tt> from the result, which it copies to +<tt>out</tt> (<tt>in</tt> and <tt>out</tt> may be the same buffer). +Returns non-zero if any changes were made. <i>In true retro +programming style, it is up to you to provide a buffer big enough for +the result. 1024 characters should be enough.</i> -Selects an X visual so that your graphics are drawn correctly. This -does nothing if the default visual satisfies the capabilities, or if -no visual satisfies the capabilities, or on systems that don't have -such brain-dead notions. +<h3><a name="filename_match">int filename_match(const char *f, const char *pattern)</a></h3> -<p>Only the following combinations do anything useful: +Returns true if <tt>f</tt> matches <tt>pattern</tt>. The following syntax +is used by <tt>pattern</tt>: <ul> -<p><li><tt>Fl::visual(FL_RGB)</tt> + <li><tt>*</tt> matches any sequence of 0 or more characters. -<br>Full/true color (if there are several depths FLTK chooses the -largest). Do this if you use <a -href=images.html#fl_draw_image>fl_draw_image</a> for much better -(non-dithered) output. + <li><tt>?</tt> matches any single character. -<p><li><tt>Fl::visual(FL_RGB8)</tt> + <li><tt>[set]</tt> matches any character in the set. Set + can contain any single characters, or a-z to represent a range. To + match ] or - they must be the first characters. To match ^ or ! they + must not be the first characters. -<br>Full color with at least 24 bits of color. FL_RGB will always -pick this if available, but if not it will happily return a -less-than-24 bit deep visual. This call fails if 24 bits are not -available. + <li><tt>[^set]</b> or <b>[!set]</tt> matches any character + not in the set. -<p><li><tt>Fl::visual(FL_DOUBLE|FL_INDEX)</tt> + <li><tt>{X|Y|Z}</b> or <b>{X,Y,Z}</tt> matches any one of + the subexpressions literally. -<br>Hardware double buffering. Call this if you are going to use -<a href=Fl_Double_Window.html>Fl_Double_Window</a>. + <li><tt>\x</tt> quotes the character x so it has no special + meaning. -<p><li><tt>Fl::visual(FL_DOUBLE|FL_RGB)</tt> -<li><tt>Fl::visual(FL_DOUBLE|FL_RGB8)</tt> + <li><tt>x</tt> all other characters must be matched exactly. +</ul> -<br>Hardware double buffering and full color. +<H2>Fl:: Methods</H2> -</ul> +<h3><a name="add_fd">static void Fl::add_fd(int fd, void (*cb)(int, void *), void * = 0)<br> +static void Fl::add_fd(int fd, int when, void (*cb)(int, void *), void * = 0)</a><br> +<a name="remove_fd">static void Fl::remove_fd(int)</a></h3> -<p>This returns true if the system has the capabilities by default or -FLTK suceeded in turing them on. Your program will still work even if -this returns false (it just won't look as good). +Add file descriptor <tt>fd</tt> to listen to. When the <tt>fd</tt> +becomes ready for reading the callback is done. The callback is passed +the <tt>fd</tt> and the arbitrary <tt>void *</tt> argument. +<tt>Fl::wait()</tt> will return immediately after calling the callback. -<p>See <a href=x.html#visuals>here</a> for ways to select the visual -using your own code. +<p>The second version takes a <tt>when</tt> bitfield, with the bits +<tt>FL_READ</tt>, <tt>FL_WRITE</tt>, and <tt>FL_EXCEPT</tt> defined, to +indicate when the callback should be done. -<a name=gl_visual> -</ul><h4><tt>int Fl::gl_visual(int)</tt></h4><ul> +<p>There can only be one callback of each type for a file descriptor. +<tt>Fl::remove_fd()</tt> gets rid of <i>all</i> the callbacks for a +given file descriptor. -This does the same thing as Fl::visual(int) but also requires OpenGL -drawing to work. This <i>must</i> be done if you want to draw in -normal windows with OpenGL with <a href=Fl_Gl_Window.html#gl_start>gl_start() -and gl_end()</a>. It may be useful to call this so your X windows use -the same visual as an <a href=Fl_Gl_Window.html>Fl_Gl_Window</a>, on -some servers the windows will drag around easier then. +<p>Under UNIX <i>any</i> file descriptor can be monitored (files, +devices, pipes, sockets, etc.) Due to limitations in Microsoft Windows, +WIN32 applications can only monitor sockets. -<p>See <a href=Fl_Gl_Window.html#mode>Fl_Gl_Window</a> for a list of -additional values for the argument. +<h3><a name="add_handler">static void Fl::add_handler(int (*f)(int))</h3> -</ul><h4><tt>void Fl::own_colormap();</tt></h4><ul> +Install a function to parse unrecognized events. If FLTK cannot figure +out what to do with an event, it calls each of these functions (most +recent first) until one of them returns non-zero. If none of them +returns non zero then the event is ignored. Events that cause this to +be called are: -Makes FLTK use it's own X colormap. This may make FLTK display -better and will reduce conflicts with other programs that want lots of -colors. However the colors may flash as you drag the cursor between -windows. +<ul> -<p>This does nothing if the current visual is not colormapped or on -MSWindows (even though it probably should if your display is in 8-bit -mode). + <li><tt>FL_SHORTCUT</tt> events that are not recognized by any + widget. This lets you provide global shortcut keys. -</ul><h4><tt>void Fl::get_system_colors();</tt></h4><ul> + <li>System events that FLTK does not recognize. See <a + href="#fl_xevent"><tt>fl_xevent</tt></a>. -Read the user preference colors from the system and use them to call -Fl::foreground(), Fl::background(), and Fl::background2(). This is -done by Fl_Window::show(argc,argv) before applying the -fg and -bg -switches. + <li><i>Some</i> other events when the widget FLTK selected + returns zero from its <tt>handle()</tt> method. Exactly which + ones may change in future versions, however. -<p>Currently this only works on MSWindows. In future versions on X it -may read the KDE or Gnome setup, but for now it does nothing. +</ul> -</ul><h4><tt>void Fl::background(uchar, uchar, uchar);</tt></h4><ul> +<h3><a name="add_idle">static Fl::add_idle(void (*cb)(void *), void *)</a></h3> -Changes <tt>fl_color(FL_GRAY)</tt> to the given color, and changes -the gray ramp from 32 to 56 to black to white. These are the colors -used as backgrounds by almost all widgets and used to draw the edges -of all the boxtypes. +Adds a callback function that is called by <tt>Fl::wait()</tt> when there +is nothing to do. This can be used for background +processing. -</ul><h4><tt>void Fl::foreground(uchar, uchar, uchar);</tt></h4><ul> +<p><i>Warning: this can absorb all your machine's time!</i> -Changes <tt>fl_color(FL_BLACK)</tt>. Also changes -<tt>FL_INACTIVE_COLOR</tt> and <tt>FL_SELECTION_COLOR</tt> to -be a ramp between this and <tt>FL_WHITE</tt>. +<p>You can have multiple idle callbacks. To remove an idle callback +use <a href="#remove_idle"><tt>Fl::remove_idle()</tt></a>. -</ul><h4><tt>void Fl::background2(uchar, uchar, uchar);</tt></h4><ul> +<p>Only <tt>Fl::wait()</tt> calls the idle callbacks. +<tt>Fl::wait(time)</tt>, <tt>Fl::check()</tt>, and <tt>Fl::ready()</tt> +ignore them so that these functions may be called by the idle callbacks +themselves without having to worry about recursion. -Changes <tt>fl_color(FL_WHITE)</tt> and the same colors as -Fl::foreground(). This color is used as a background by Fl_Input and -other text widgets. +<p>The idle callback can call any FLTK functions. However if you call +something that calls <tt>Fl::wait()</tt> (such as a message pop-up) you +should first remove the idle callback so that it does not recurse. + +<h3><a name="add_timeout">static void Fl::add_timeout(float t, void (*cb)(void *),void *v=0)</a></h3> + +Add a one-shot timeout callback. The timeout will happen as soon as +possible after <tt>t</tt> seconds after the last time <tt>wait()</tt> +was called. The optional <tt>void *</tt> argument is passed to the +callback. + +<p>This code will print "TICK" each second on stdout, no matter what +else the user or program does: + +<ul><pre> +void callback(void *) { + printf("TICK\n"); + Fl::add_timeout(1.0,callback); +} + +main() { + Fl::add_timeout(1.0,callback); + Fl::run(); +} +</pre></ul> + +<h3><a name="arg">static int Fl::arg(int argc, char **argv, int &i)</a></h3> + +Consume a single switch from <tt>argv</tt>, starting at word +</tt>i</tt>. Returns the number of words eaten (1 or 2, or 0 if it is +not recognized) and adds the same value to <tt>i</tt>. You can use this +function if you prefer to control the incrementing through the +arguments yourself. -</ul><h4><tt>int Fl::args(int argc, char** argv, int -&i, int (*callback)(int,char**,int&)=0)</tt></h4><ul> +<h3><a name="args">static int Fl::args(int argc, char **argv, int &i, int (*callback)(int, char**,int &)=0)<br> +void Fl::args(int argc, char **argv)</a></h3> -<p>FLTK provides an <i>entirely optional</i> command-line switch -parser. You don't have to call it if you don't like them! -Everything it can do can be done with other calls to FLTK. +FLTK provides an <i>entirely optional</i> command-line switch parser. +You don't have to call it if you don't like them! Everything it can do +can be done with other calls to FLTK. -<p>To use the switch parser, call Fl::args(...) near the start of +<p>To use the switch parser, call <tt>Fl::args(...)</tt> near the start of your program. This does <i>not</i> open the display, instead switches -that need the display open are stashed into static variables. Then -you <i>must</i> display your first window by calling <a -href=#show>Fl_Window::show(argc,argv)</a>, which will do anything +that need the display open are stashed into static variables. Then +you <i>must</i> display your first window by calling +<a href="#Fl_Window.show">window->show(argc,argv)</a>, which will do anything stored in the static variables. -<p><i>callback</i> lets you define your own switches. It is called -with the same argc and argv, and with <i>i</i> the index of each word. +<p><tt>callback</tt> lets you define your own switches. It is called +with the same <tt>argc</tt> and <tt>argv</tt>, and with <tt>i</tt> the index of each word. The callback should return zero if the switch is unrecognized, and not -change i. It should return non-zero if the switch is recognized, and -add at least 1 to i (it can add more to consume words after the +change <tt>i</tt>. It should return non-zero if the switch is recognized, and +add at least 1 to <tt>i</tt> (it can add more to consume words after the switch). This function is called before any other tests, so you can override any FLTK switch. -<p>On return <i>i</i> is set to the index of the first non-switch. +<p>On return <tt>i</tt> is set to the index of the first non-switch. This is either: -<p><ul> - -<li>The first word that does not start with '-'. +<ul> -<li>The word '-' (used by many programs to name stdin as a file) + <li>The first word that does not start with '-'. -<li>The first word <i>after</i> '--' + <li>The word '-' (used by many programs to name stdin as a file) -<li>The first unrecognized switch (return value is 0). + <li>The first unrecognized switch (return value is 0). -<li>argc + <li><tt>argc</tt> </ul> -<p>The return value is <i>i</i> unless an unrecognized switch is +The return value is <tt>i</tt> unless an unrecognized switch is found, in which case it is zero. If your program takes no arguments other than switches you should produce an error if the return value is -less than argc. - -<p>All switches may be abbreviated to one letter and case is ignored: - -<p><tt><b>-display host:n.n</b> </tt>The X display to use (ignored -by MSWindows). - -<p><tt><b>-geometry WxH+X+Y</b> </tt>The window position and size -will be modified according the the standard X geometry string. - -<p><tt><b>-name string</b> Fl_Window::xclass(string)</tt> will be -done to the window, this will change it's icon. +less than <tt>argc</tt>. -<p><tt><b>-title string</b> Fl_Window::label(string)</tt> will be -done to the window, changing both it's title and the icontitle. +<p>All switches may be abbreviated to two letters and case is ignored: -<p><tt><b>-iconic</b> Fl_Window::iconize()</tt> will be done to -the window. - -<p><tt><b>-bg color</b> </tt>XParseColor is used to lookup the -passed color and then Fl::background() is done. On MSWindows -only color names of the form "#xxxxxx" are understood. +<ul> -<p><tt><b>-bg2 color</b> </tt>XParseColor is used to lookup the -passed color and then Fl::background2() is done. + <li><tt>-display host:n.n</tt> The X display to use (ignored + under WIN32). -<p><tt><b>-fg color</b> </tt>XParseColor is used to lookup the -passed color and then Fl::foreground() is done. + <li><tt>-geometry WxH+X+Y</tt> The window position and size + will be modified according the the standard X geometry string. -</ul><h4><tt>int Fl::arg(int argc, char** argv, int &i)</tt></h4><ul> + <li><tt>-name string</tt> Fl_Window::xclass(string) will be + done to the window, possibly changing its icon. -Consume a single switch from argv, starting at word i. Returns the -number of words eaten (1 or 2, or 0 if it is not recognized) and adds -the same value to i. You can use this function if you prefer to -control the incrementing through the arguments yourself. + <li><tt>-title string</tt> Fl_Window::label(string) will be + done to the window, changing both its title and the icontitle. -</ul><h4><tt>void Fl::args(int argc, char** argv)</tt></h4><ul> + <li><tt>-iconic</tt> Fl_Window::iconize() will be done to + the window. -This method is useful if your program does not have command line -switches of it's own. It parses all the switches, and if any are not -recognized it calls <tt>Fl::abort(Fl::help)</tt>. + <li><tt>-bg color</tt> XParseColor is used to lookup the + passed color and then Fl::background() is done. Under WIN32 + only color names of the form "#xxxxxx" are understood. -</ul><h4><tt>const char* const Fl::help;</tt></h4><ul> + <li><tt>-bg2 color</tt> XParseColor is used to lookup the + passed color and then Fl::background2() is done. -A string descibing the switches understood by Fl::arg(), useful for -printing as an error message. + <li><tt>-fg color</tt> XParseColor is used to lookup the + passed color and then Fl::foreground() is done. -<a name=show> -</ul><h4><tt>int Fl_Window::show(int argc, char** argv)</tt></h4><ul> +</ul> -show() a window and set the <tt>XA_WM_COMMAND</tt> attribute to -the passed argc/argv. If this is the first time this has been called -since Fl::args() or Fl::arg(), the results of those switches are used -to set the xclass(), label(), and other attributes of this window. +The second form of <tt>Fl::args()</tt> is useful if your program does +not have command line switches of its own. It parses all the switches, +and if any are not recognized it calls <tt>Fl::abort(Fl::help)</tt>. -<p>If Fl::args() or Fl::arg() have never been called, this calls -Fl::args(argc,argv) automatically. This is convienent for very small -programs that just want to put up a single window and take no -switches. +<h3><a name="background">static void Fl::background(uchar, uchar, uchar)</a></h3> -</ul> +Changes <tt>fl_color(FL_GRAY)</tt> to the given color, and changes +the gray ramp from 32 to 56 to black to white. These are the colors +used as backgrounds by almost all widgets and used to draw the edges +of all the boxtypes. -<h2>Running</h2> +<h3><a name="background2">static void Fl::background2(uchar, uchar, uchar)</a></h3> -After FLTK is "initialized" by calling show() on some window, you get -FLTK to wait for and respond to events by calling the following -methods: +Changes <tt>fl_color(FL_WHITE)</tt> and the same colors as +<tt>Fl::foreground()</tt>. This color is used as a background by +<tt>Fl_Input</tt> and other text widgets. -<a name=run> -</ul><h4><tt>int Fl::run()</tt></h4><ul> +<h3><a name="belowmouse">static Fl_Widget *Fl::belowmouse() const<br> +static void Fl::belowmouse(Fl_Widget *)</h3> -Runs FLTK until there are no windows displayed, and then returns a zero. -Fl::run() is <i>exactly equivalent to:</i> +Get or set the widget that is below the mouse. This is for +highlighting buttons. It is not used to send <tt>FL_PUSH</tt> or +<tt>FL_MOVE</tt> directly, for several obscure reasons, but those +events typically go to this widget. This is also the first widget +tried for <tt>FL_SHORTCUT</tt> events. -<ul><tt><pre> -while (Fl::wait()); -return 0; -</pre></tt></ul> +<p>If you change the belowmouse widget, the previous one and all +parents (that don't contain the new widget) are sent <tt>FL_LEAVE</tt> +events. Changing this does <i>not</i> send <tt>FL_ENTER</tt> to this +or any widget, because sending <tt>FL_ENTER</tt> is supposed to +<i>test</i> if the widget wants the mouse (by it returning non-zero +from <tt>handle()</tt>). -<A name=wait> -</ul><h4><tt>int Fl::wait()</tt></h4><ul> +<h3><a name="box_dh">static int Fl::box_dh(Fl_Boxtype)</a></h3> -Calls the idle function if any, then calls any pending timeout -functions, then calls <a href=#flush>Fl::flush()</a>. If there are -any windows displayed it then waits some time for events (zero if -there is an idle(), the shortest timeout if there are any timeouts, or -forever) and calls the handle() function on those events, and then -returns non-zero. +Returns the height offset for the given boxtype. -<p>Your program can check it's global state and update things after -each call to Fl::wait(), which can be very useful in complex programs. +<h3><a name="box_dw">static int Fl::box_dw(Fl_Boxtype)</a></h3> -<p>If there are no windows (this is checked after the idle and -timeouts are called) then Fl::wait() returns zero without waiting for -any events. Your program can either exit at this point, or call -show() on some window so the UI can continue to operate. +Returns the width offset for the given boxtype. -</ul><h4><tt>float Fl::wait(float time)</tt></h4><ul> +<h3><a name="box_dx">static int Fl::box_dx(Fl_Boxtype)</a></h3> -Wait only a certain amount of time for anything to happen. This does -the same as wait() except if the given time (in seconds) passes it -returns. The return value is how much time remains. If the return -value is zero or negative then the entire time period elapsed. +Returns the X offset for the given boxtype. -<p>If you do several wait(time) calls in a row, the subsequent ones -are measured from when the first one is called, even if you do -time-consuming calculations after they return. This allows you to -accurately make something happen at regular intervals. This code will -accurately call A() once per second (as long as it takes less than a -second to execute): +<h3><a name="box_dy">static int Fl::box_dy(Fl_Boxtype)</a></h3> -<ul><tt><pre> -for (;;) { - for (float time = 1.0; time > 0; ) time = Fl::wait(time); - A(); -} -</pre></tt></ul> +Returns the Y offset for the given boxtype. -</ul><h4><tt>int Fl::check()</tt></h4><ul> +<h3><a name="check">static int Fl::check()</a></h3> -This does the same thing as Fl::wait(0), except because it does not +This does the same thing as <tt>Fl::wait(0)</tt>, except because it does not have to return the elapsed time value it can be implemented faster on certain systems. Use this to interrupt a big calculation: -<ul><tt><pre> +<ul><pre> while (!calculation_done()) { calculate(); Fl::check(); if (user_hit_abort_button()) break; } -</pre></tt></ul> +</pre></ul> -<p>This returns non-zero if any windows are displayed, and 0 if no +This returns non-zero if any windows are displayed, and 0 if no windows are displayed. -</ul><h4><tt>int Fl::ready();</tt></h4><ul> +<h3><a name="damage">static int Fl::damage()</a></h3> + +If true then <a href="#flush"><tt>flush()</tt></a> will do something. + +<h3><a name="display">static void Fl::display(const char *)</a></h3> + +Sets the X display to use for all windows. This function is ignored +under WIN32. + +<h3><a name="enable_symbols">static void Fl::enable_symbols()</a></h3> + +Enables the symbol drawing code. + +<h3><a name="event_button">static int Fl::event_button()</a></h3> + +Returns which mouse button was pressed. This returns garbage if the +most recent event was not a <tt>FL_PUSH</tt> or <tt>FL_RELEASE</tt> +event. + +<h3><a name="event_clicks">int Fl::event_clicks()<br> +void Fl::event_clicks(int)</a></h3> + +The first form returns non-zero if the most recent <tt>FL_PUSH</tt> or +<tt>FL_KEYBOARD</tt> was a "double click". Returns N-1 for N clicks. +A double click is counted if the same button is pressed again while +<tt>event_is_click()</tt> is true. + +<p>The second form directly sets the number returned by +<tt>Fl::event_clicks()</tt>. This can be used to set it to zero so +that later code does not think an item was double-clicked. + +<h3><a name="event_inside">int Fl::event_inside(const Fl_Widget *) const<br> +int Fl::event_inside(int x, int y, int w, int h)</a></h3> + +Returns non-zero if the current <tt>event_x</tt> and <tt>event_y</tt> +put it inside the widget or inside an arbitrary bounding box. You +should always call this rather than doing your own comparison so you +are consistent about edge effects. + +<h3><a name="event_is_click">int Fl::event_is_click()<br> +void Fl::event_is_click(0)</a></h3> + +The first form returns non-zero if the mouse has not moved far enough +and not enough time has passed since the last <tt>FL_PUSH</tt> or +<tt>FL_KEYBOARD</tt> event for it to be considered a "drag" rather than +a "click". You can test this on <tt>FL_DRAG</tt>, <tt>FL_RELEASE</tt>, +and <tt>FL_MOVE</tt> events. + +The second form clears the value returned by +<tt>Fl::event_is_click()</tt>. Useful to prevent the <i>next</i> click +from being counted as a double-click or to make a popup menu pick an +item with a single click. Don't pass non-zero to this. + +<h3><a name="event_key">int Fl::event_key()<br> +int Fl::event_key(int)</a><br> +<a name="get_key">int Fl::get_key(int)</a></h3> + +<tt>Fl::event_key()</tt> returns which key on the keyboard was last pushed. + +<p><tt>Fl::event_key(int)</tt> returns true if the given key was held +down (or pressed) <i>during</i> the last event. This is constant until +the next event is read from the server. + +<p><tt>Fl::get_key(int)</tt> returns true if the given key is held down +<i>now</i>. Under X this requires a round-trip to the server and is +<i>much</i> slower than <tt>Fl::event_key(int)</tt>. + +<p>Keys are identified by the <i>unshifted</i> values. FLTK defines a +set of symbols that should work on most modern machines for every key +on the keyboard: + +<ul> + + <li>All keys on the main keyboard producing a printable ASCII + character use the value of that ASCII character (as though shift, + ctrl, and caps lock were not on). The space bar is 32. + + <li>All keys on the numeric keypad producing a printable ASCII + character use the value of that ASCII character plus + <tt>FL_KP</tt>. The highest possible value is + <tt>FL_KP_Last</tt> so you can range-check to see if something is + on the keypad. + + <li>All numbered function keys use the number on the function key plus + <tt>FL_F</tt>. The highest possible number is + <tt>FL_F_Last</tt>, so you can range-check a value. + + <li>Buttons on the mouse are considered keys, and use the button + number (where the left button is 1) plus <tt>FL_Button</tt>. + + <li>All other keys on the keypad have a symbol: <tt>FL_Escape, + FL_BackSpace, FL_Tab, FL_Enter, FL_Print, FL_Scroll_Lock, FL_Pause, + FL_Insert, FL_Home, FL_Page_Up, FL_Delete, FL_End, FL_Page_Down, + FL_Left, FL_Up, FL_Right, FL_Down, FL_Shift_L, FL_Shift_R, + FL_Control_L, FL_Control_R, FL_Caps_Lock, FL_Alt_L, FL_Alt_R, + FL_Meta_L, FL_Meta_R, FL_Menu, FL_Num_Lock, FL_KP_Enter</tt>. Be + careful not to confuse these with the very similar, but all-caps, + symbols used by <a href="#event_state"><tt>Fl::event_state()</tt></a>. + +</ul> + +On X <tt>Fl::get_key(FL_Button+n)</tt> does not work. + +<p>On WIN32 <tt>Fl::get_key(FL_KP_Enter)</tt> and +<tt>Fl::event_key(FL_KP_Enter)</tt> do not work. + +<h3><a name="event_length">char *Fl::event_length()</a></h3> + +Returns the length of the text in <tt>Fl::event_text()</tt>. There +will always be a nul at this position in the text. However there may +be a nul before that if the keystroke translates to a nul character or +you paste a nul character. + +<h3><a name="event_state">ulong Fl::event_state()<br> +unsigned int Fl::event_state(ulong)</h3> + +This is a bitfield of what shift states were on and what mouse buttons +were held down during the most recent event. The second version +returns non-zero if any of the passed bits are turned on. The legal +bits are: + +<ul> + <li><tt>FL_SHIFT</tt> + <li><tt>FL_CAPS_LOCK</tt> + <li><tt>FL_CTRL</tt> + <li><tt>FL_ALT</tt> + <li><tt>FL_NUM_LOCK</tt> + <li><tt>FL_META</tt> + <li><tt>FL_SCROLL_LOCK</tt> + <li><tt>FL_BUTTON1</tt> + <li><tt>FL_BUTTON2</tt> + <li><tt>FL_BUTTON3</tt> +</ul> + +X servers do not agree on shift states, and FL_NUM_LOCK, FL_META, +and FL_SCROLL_LOCK may not work. The values were selected to match +the XFree86 server on Linux. In addition there is a bug in the way +X works so that the shift state is not correctly reported until the +first event <i>after</i> the shift key is pressed or released. + +<h3><a name="event_text">char *Fl::event_text()</a></h3> + +Returns the ASCII text (in the future this may be UTF-8) produced by +the last <tt>FL_KEYBOARD</tt> or <tt>FL_PASTEM</tt> or possibly other +event. A zero-length string is returned for any keyboard function keys +that do not produce text. This pointer points at a static buffer and is +only valid until the next event is processed. + +<p>Under X this is the result of calling <tt>XLookupString()</tt>. + +<h3><a name="event_x">static int Fl::event_x()<br> +<a name="event_y">static int Fl::event_y()</a></h3> + +Returns the mouse position of the event relative to the <tt>Fl_Window</tt> it +was passed to. + +<h3><a name="event_x_root">static int Fl::event_x_root()<br> +<a name="event_y_root">static int Fl::event_y_root()</a></h3> + +Returns the mouse position on the screen of the event. To find the +absolute position of an <tt>Fl_Window</tt> on the screen, use the difference +between <tt>event_x_root(),event_y_root()</tt> and +<tt>event_x(),event_y()</tt>. + +<h3><a name="first_window">static Fl_Window *Fl::first_window()</a></h3> + +Returns the first top-level window in the widget hierarchy. -Returns non-zero if there are pending timeouts or X events or file -descriptors. This does <i>not</i> call Fl::flush() or any callbacks, -which is useful if your program is in a state where such callbacks are -illegal: +<h3><a name="flush">static void Fl::flush()</a></h3> -<ul><tt><pre> +Causes all the windows that need it to be redrawn and graphics forced +out through the pipes. This is what <tt>wait()</tt> does before +looking for events. + +<h3><a name="focus">static Fl_Widget *Fl::focus() const<br> +static void Fl::focus(Fl_Widget *)</a></h3> + +Get or set the widget that will receive <tt>FL_KEYBOARD</tt> events. + +<p>If you change <tt>Fl::focus()</tt>, the previous widget and all +parents (that don't contain the new widget) are sent +<tt>FL_UNFOCUS</tt> events. Changing the focus does <i>not</i> send +<tt>FL_FOCUS</tt> to this or any widget, because sending +<tt>FL_FOCUS</tt> is supposed to <i>test</i> if the widget wants the +focus (by it returning non-zero from <tt>handle()</tt>). + +<h3><a name="foreground">static void Fl::foreground(uchar, uchar, uchar)</a></h3> + +Changes <tt>fl_color(FL_BLACK)</tt>. Also changes +<tt>FL_INACTIVE_COLOR</tt> and <tt>FL_SELECTION_COLOR</tt> to +be a ramp between this and <tt>FL_WHITE</tt>. + +<h3><a name="free_color">static void Fl::free_color(Fl_Color, int overlay = 0)</a></h3> + +Frees the specified color from the colormap, if applicable. If +<tt>overlay</tt> is non-zero then the color is freed from the overlay +colormap. + +<h3><a name="get_color">static unsigned Fl::get_color(Fl_Color)<br> +static void Fl::get_color(Fl_Color, uchar &r, uchar &g, uchar &b)</a></h3> + +Returns the color index or RGB value for the given FLTK color index. + +<h3><a name="get_font">static const char *Fl::get_font(int face)</h4> + +Get the string for this face. This string is different for each face. +Under X this value is passed to XListFonts to get all the sizes of +this face. + +<h3><a name="get_font_name">static const char *Fl::get_font_name(int face, int *attributes = 0)</a></h3> + +Get a human-readable string describing the family of this face. This +is useful if you are presenting a choice to the user. There is no +guarantee that each face has a different name. The return value +points to a static buffer that is overwritten each call. + +<p>The integer pointed to by <tt>attributes</tt> (if the pointer is not +zero) is set to zero, <tt>FL_BOLD</tt> or <tt>FL_ITALIC</tt> or +<tt>FL_BOLD | FL_ITALIC</tt>. To locate a "family" of fonts, search +forward and back for a set with non-zero attributes, these faces along +with the face with a zero attribute before them constitute a family. + +<h3><a name="get_font_sizes">int get_font_sizes(int face, int *&sizep)</a></h3> + +Return an array of sizes in <tt>sizep</tt>. The return value is the +length of this array. The sizes are sorted from smallest to largest +and indicate what sizes can be given to <tt>fl_font()</tt> that will be +matched exactly (<tt>fl_font()</tt> will pick the closest size for +other sizes). A zero in the first location of the array indicates a +scalable font, where any size works, although the array may list sizes +that work "better" than others. Warning: the returned array points at +a static buffer that is overwritten each call. Under X this will open +the display. + +<h3><a name="get_mouse">static void Fl::get_mouse(int &x, int &y)</a></h3> + +Return where the mouse is on the screen by doing a round-trip query to +the server. You should use <tt>Fl::event_x_root()</tt> and +<tt>Fl::event_y_root()</tt> if possible, but this is necessary if you +are not sure if a mouse event has been processed recently (such as to +position your first window). If the display is not open, this will +open it. + +<h3><a name="get_system_colors">static void Fl::get_system_colors()</a></h3> + +Read the user preference colors from the system and use them to call +<tt>Fl::foreground()</tt>, <tt>Fl::background()</tt>, and +<tt>Fl::background2()</tt>. This is done by +<tt>Fl_Window::show(argc,argv)</tt> before applying the -fg and -bg +switches. + +<p>Currently this only does something on WIN32. In future versions for +X it may read the window manager (KDE, Gnome, etc.) setup as well. + +<h3><a name="gl_visual">static int Fl::gl_visual(int)</a></h3> + +This does the same thing as <a +href="#visual"><tt>Fl::visual(int)</tt></a> but also requires OpenGL +drawing to work. This <i>must</i> be done if you want to draw in +normal windows with OpenGL with <a +href="#gl_start"><tt>gl_start()</tt></a> and <tt>gl_end()</tt>. It may +be useful to call this so your X windows use the same visual as an <a +href="#Fl_Gl_Window"><tt>Fl_Gl_Window</tt></a>, which on some servers +will reduce colormap flashing. + +<p>See <a href="#Fl_Gl_Window.mode"><tt>Fl_Gl_Window</tt></a> for a +list of additional values for the argument. + +<h3><a name="grab">static void Fl::grab(Fl_Window &)<br> +static Fl_Window *Fl::grab()</h3> + +This is used when pop-up menu systems are active. Send all events to +the passed window no matter where the pointer or focus is (including in +other programs). The window <i>does not have to be +<tt>shown()</tt></i>, this lets the <tt>handle()</tt> method of a +"dummy" window override all event handling and allows you to map and +unmap a complex set of windows (under both X and WIN32 <i>some</i> +window must be mapped because the system interface needs a window id). + +<p><tt>Fl::event_x()</tt> and <tt>Fl::event_y()<.tt> are undefined if +the passed widget is not a mapped <tt>Fl_Window</tt>. Use +<tt>Fl::event_x_root()</tt> and <tt>Fl::event_y_root()</tt> instead. + +<p><i>Be careful that your program does not enter an infinite loop +while <tt>grab()</tt> is on. On X this will lock up your screen!</i> + +<p>The second function returns the current grab window, or <tt>NULL</tt> if +none. + +<h3><a name="h">static int Fl::h()</a></h3> + +Returns the height of the screen in pixels. + +<h3><a name="handle">static int Fl::handle(int, Fl_Window *)</a></h3> + +Sends the event to a window for processing. Returns non-zero if any +widget uses the event. + +<h3><a name="help">static const char *Fl::help</a></h3> + +This is the usage string that is displayed if <tt>Fl::args()</tt> +detects an invalid argument on the command-line. + +<h3><a name="modal">static Fl_Window *Fl::modal()</h3> + +The <tt>modal()</tt> window has its <tt>handle()</tt> method called for +all events, and no other windows will have <tt>handle()</tt> called. +If <a href="#grab"><tt>grab()</tt></a> has been done then this is equal +to <tt>grab()</tt>. Otherwise this is the most recently +<tt>shown()</tt> window with <a +href="#Fl_Window.modal"><tt>modal()</tt></a> true, or <tt>NULL</tt> if +there are no <tt>modal()</tt> windows <tt>shown()</tt>. + +<h3><a name="next_window">static Fl_Window *Fl::next_window(Fl_Window *)</a></h3> + +Returns the next top-level window in the widget hierarchy. + +<h3><a name="own_colormap">static void Fl::own_colormap()</a></h3> + +Makes FLTK use its own colormap. This may make FLTK display +better and will reduce conflicts with other programs that want lots of +colors. However the colors may flash as you move the cursor between +windows. + +<p>This does nothing if the current visual is not colormapped. + +<h3><a name="paste">static void Fl::paste(Fl_Widget *receiver)</a></h3> + +Set things up so the receiver widget will be called with an <a +href="#FL_PASTE"><tt>FL_PASTE</tt></a> event some time in the future. +The reciever should be prepared to be called <i>directly</i> by this, +or for it to happen <i>later</i>, or possibly <i>not at all</i>. This +allows the window system to take as long as necessary to retrieve the +paste buffer (or even to screw up completely) without complex and +error-prone synchronization code in FLTK. + +<h3><a name="pushed">static Fl_Widget *Fl::pushed() const<br> +static void Fl::pushed(Fl_Widget *)</h3> + +Get or set the widget that is being pushed. <tt>FL_DRAG</tt> or +<tt>FL_RELEASE</tt> (and any more <tt>FL_PUSH</tt>) events will be sent +to this widget. + +<p>If you change the pushed widget, the previous one and all parents +(that don't contain the new widget) are sent <tt>FL_RELEASE</tt> +events. Changing this does <i>not</i> send <tt>FL_PUSH</tt> to this or +any widget, because sending <tt>FL_PUSH</tt> is supposed to <i>test</i> +if the widget wants the mouse (by it returning non-zero from +<tt>handle()</tt>). + +<h3><a name="readqueue">static Fl_Widget *Fl::readqueue()</a></h3> + +All <tt>Fl_Widgets</tt> that don't have a callback defined use a +default callback that puts a pointer to the widget in this queue, and +this method reads the oldest widget out of this queue. + +<h3><a name="ready">static int Fl::ready()</a></h3> + +Returns non-zero if there are pending timeouts or events or file +descriptors. This does <i>not</i> call <tt>Fl::flush()</tt> or any +callbacks, which is useful if your program is in a state where such +callbacks are illegal: + +<ul><pre> while (!calculation_done()) { calculate(); if (Fl::ready()) { @@ -625,144 +842,225 @@ while (!calculation_done()) { if (user_hit_abort_button()) break; } } -<a name=add_timeout> -</pre></tt></ul> +</pre></ul> -</ul><h4><tt>void Fl::add_timeout(float t,void (*cb)(void*),void* v=0); -<br>void Fl::remove_timeout(void (*cb)(void*), void* = 0);</tt></h4><ul> +<h3><a name="redraw">static void Fl::redraw()</a></h3> -Add or remove a one-shot timeout callback. The timeout will happen as -soon as possible after <i>t</i> seconds after the last time wait() was -called. The optional void* argument is passed to the callback. It is -harmless to remove a timeout callback that no longer exists. +Redraws all widgets. -<p>This code will print "TICK" each second on stdout, no matter what -else the user or program does: +<h3><a name="release">static void Fl::release()</a></h3> -<ul><tt><pre> -void callback(void *) { - printf("TICK\n"); - Fl::add_timeout(1.0,callback); -} -main() {... - Fl::add_timeout(1.0,callback); - Fl::run(); -} -</pre></tt></ul> +Turn off the <tt>grab()</tt> behavior. -<a name=idle> -</ul><h4><tt>void Fl::set_idle(void (*cb)());</tt></h4><ul> +<h3><a name="remove_idle">static void Fl::remove_idle(void (*cb)(void *), void *= 0)</a></h3> -If the idle callback is set it will be called by Fl::wait() and -Fl::wait() will return immediately. This can be used for background -processing. <i>This will absorb all your machine's time!</i> There is -only one idle callback, changing it will replace the old one. To turn -off the idle processing use Fl::set_idle(0). +Removes the specified idle callback. -<p>Only Fl::wait(void) calls the idle callback. Fl::wait(time), -Fl::check(), and Fl::ready() ignore it. This is so that these -functions may be called by the idle callback itself without having to -worry about recursion. +<h3><a name="remove_timeout">static void Fl::remove_timeout(void (*cb)(void *), void *= 0)</a></h3> -<p>The idle callback can call any FLTK functions. However if you call -something that calls Fl::wait() (such as a message pop-up) you should -first set the idle callback to zero so it does not recurse. +Removes a timeout callback. It is harmless to remove a timeout callback +that no longer exists. -<a name=flush> -</ul><h4><tt>void Fl::flush()</tt></h4><ul> +<h3><a name="run">static Fl::run()</a></h3> -Causes all the windows that need it to be redrawn and graphics forced -out through the pipes. This is what wait() does before looking for -events. +Runs FLTK until there are no windows displayed, and then returns a zero. +<tt>Fl::run()</tt> is <i>exactly equivalent to:</i> -</ul><h4><tt>int Fl::damage()</tt></h4><ul> +<ul><pre> +while (Fl::wait()); +return 0; +</pre></ul> -If true then <a href=#flush>flush()</a> will do something. +<h3><a name="selection">static void Fl::selection(Fl_Widget *owner, const char *stuff, int len)<br> +static const char* Fl::selection()<BR> +static int Fl::selection_length()</a></h3> -<a name=readqueue> -</ul><h4><tt>Fl_Widget *Fl::readqueue();</tt></h4><ul> +The first form changes the current selection. The block of text is +copied to an internal buffer by FLTK (be careful if doing this in +response to an <tt>FL_PASTE</tt> as this <i>may</i> be the same buffer +returned by <tt>event_text()</tt>). The <tt>selection_owner()</tt> +widget is set to the passed owner (possibly sending +<tt>FL_SELECTIONCLEAR</tt> to the previous owner). -All Fl_Widgets that don't have a callback defined use a default callback -that puts a pointer to the widget in this queue, and this method reads -the oldest widget out of this queue. +The second form looks at the buffer containing the current selection. +The contents of this buffer are undefined if this program does not own +the current selection. -<a name=add_fd> -</ul> -<h2>Listening to other file descriptors (Unix only)</h2> +<h3><a name="selection_owner">static Fl_Widget *Fl::selection_owner() const<BR> +static void Fl::selection_owner(Fl_Widget *)</a></h3> -<h4><tt> -void Fl::add_fd(int fd, void (*cb)(int, void*), void* = 0);<br> -void Fl::add_fd(int fd, int when, void (*cb)(int, void*), void* = 0);<br> -void Fl::remove_fd(int);</tt></h4><ul> +The single-argument <tt>selection_owner(x)</tt> call can be used to +move the selection to another widget or to set the owner to +<tt>NULL</tt>, without changing the actual text of the selection. +<tt>FL_SELECTIONCLEAR</tt> is sent to the previous selection owner, if +any. -Add file descriptor <i>fd</i> to listen to. When the fd becomes ready -for reading the callback is done. The callback is passed the fd and -the arbitrary void* argument. Fl::wait() will return immediately -after calling the callback. +<p><i>Copying the buffer every time the selection is changed is +obviously wasteful, especially for large selections. An interface will +probably be added in a future version to allow the selection to be made +by a callback function. The current interface will be emulated on top +of this.</i> -<p>The second version takes a <i>when</i> bitfield, with the bits -FL_READ, FL_WRITE, and FL_EXCEPT defined, to indicate when the -callback should be done. This probably only works on Unix. +<h3><a name="set_boxtype">static void Fl::set_boxtype(Fl_Boxtype, Fl_Box_Draw_F *, uchar, uchar, uchar, uchar)<br> +static void Fl::set_boxtype(Fl_Boxtype, Fl_Boxtype from)</a></h3> -<p>There can only be one callback of each type for a file descriptor. -Fl::remove_fd() gets rid of <i>all</i> the callbacks for a given file -descriptor. +The first form sets the function to call to draw a specific boxtype. + +<p>The second form copies the <tt>from</tt> boxtype. + +<h3><a name="set_color">static void Fl::set_color(Fl_Color, uchar r, uchar g, uchar b)</a></h3> + +Sets an entry in the <tt>fl_color</tt> index table. You can set +it to any 8-bit RGB color. The color is not allocated until +<tt>fl_color(i)</tt> is used. + +<h3><a name="set_font">static int Fl::set_font(int face, const char *)<br> +static int Fl::set_font(int face, int from)</a></h3> + +The first form changes a face. The string pointer is simply stored, +the string is not copied, so the string must be in static memory. + +<p>The second form copies one face to another. + +<h3><a name="set_fonts">int Fl::set_fonts(const char * = 0)</a></h3> + +FLTK will open the display, and add every font on the server to the +face table. It will attempt to put "families" of faces together, so +that the normal one is first, followed by bold, italic, and bold +italic. + +<p>The optional argument is a string to describe the set of fonts to +add. Passing <tt>NULL</tt> will select only fonts that have the ISO8859-1 +character set (and are thus usable by normal text). Passing "-*" will +select all fonts with any encoding as long as they have normal X font +names with dashes in them. Passing "*" will list every font that +exists (on X this may produce some strange output). Other values may +be useful but are system dependent. With WIN32 <tt>NULL</tt> selects fonts +with ISO8859-1 encoding and non-<tt>NULL</tt> selects all fonts. + +<p>The return value is how many faces are in the table after this is done. + +<h3><a name="set_labeltype">static void Fl::set_labeltype(Fl_Labeltype, Fl_Label_Draw_F *, Fl_Label_Measure_F *)<br> +static void Fl:set_labeltype(Fl_Labeltype, Fl_Labeltype from)</a></h3> + +The first form sets the functions to call to draw and measure a +specific labeltype. + +<p>The second form copies the <tt>from</tt> labeltype. + +<h3><a name="test_shortcut">int Fl::test_shortcut(ulong) const</a></h3> + +Test the current event, which must be an <tt>FL_KEYBOARD</tt> or +<tt>FL_SHORTCUT</tt>, against a shortcut value (described in <a +href="#Fl_Button.shortcut"><tt>Fl_Button</tt></a>). Returns non-zero +if there is a match. Not to be confused with +<a href="#Fl_Widge.test_shortcut"><tt>Fl_Widget::test_shortcut()</tt></a>. + +<h3><a name="visual">static int Fl::visual(int)</a></h3> + +Selects a visual so that your graphics are drawn correctly. This +does nothing if the default visual satisfies the capabilities, or if +no visual satisfies the capabilities, or on systems that don't have +such brain-dead notions. + +<p>Only the following combinations do anything useful: + +<ul> + + <li><tt>Fl::visual(FL_RGB)</tt> + + <br>Full/true color (if there are several depths FLTK chooses + the largest). Do this if you use <a href="#fl_draw_image"> + <tt>fl_draw_image</tt></a> for much better (non-dithered) + output. + <br> + + <li><tt>Fl::visual(FL_RGB8)</tt> + + <br>Full color with at least 24 bits of color. <tt>FL_RGB</tt> will always + pick this if available, but if not it will happily return a + less-than-24 bit deep visual. This call fails if 24 bits are not + available. + <br> + + <li><tt>Fl::visual(FL_DOUBLE|FL_INDEX)</tt> + + <br>Hardware double buffering. Call this if you are going to use + <a href="#Fl_Double_Window"><tt>Fl_Double_Window</tt></a>. + <br> + + <li><tt>Fl::visual(FL_DOUBLE|FL_RGB)</tt> + <li><tt>Fl::visual(FL_DOUBLE|FL_RGB8)</tt> + + <br>Hardware double buffering and full color. + <br> </ul> -<h2>Exiting</h2> - -When all windows are closed Fl::wait() and Fl::run() return zero. If -your main() routine then returns the program exits. You can also call -exit(0) at any time in your program. <i>You do not need to do any -cleanup code for FLTK.</i> In particular you do not have to destroy -any widgets you have created. FLTK also does not sneak any atexit -functions in on you either. You will need to do<tt> -#include <stdlib.h> </tt>to call exit(). - -<p>To stop a window from closing, or conversely to make the closing of -a particular window exit the program you must change the callback() -function. Here is a typical use: - -<ul><tt><pre> -static void main_window_cb(Fl_Widget*, void*) { - if (document_changed()) { - if (!fl_ask("Exit without saving changes?")) return; - // window will not go away as hide() has not been called... - } - exit(0); -} +This returns true if the system has the capabilities by default or +FLTK suceeded in turing them on. Your program will still work even if +this returns false (it just won't look as good). -...somewhere in main(): - main_window->callback(window_cb); -</pre></tt></ul> +<h3><a name="w">static int Fl::w()</a></h3> -<a name=fatal> -</ul><h4><tt>void (*Fl::warning)(const char*,...); -<br>void (*Fl::error)(const char*,...); -<br>void (*Fl::fatal)(const char*,...);</tt></h4><ul> +Returns the width of the screen in pixels. -FLTK will call these to print messages when unexpected conditions -occur. By default they fprintf to stderr, and Fl::error and Fl::fatal -call exit(1). You can override the behavior by setting the function -pointers to your own routines. +<h3><a name="wait">static int wait()<br> +static double wait(double time)</a></h3> -<p>Supposedly Fl::warning means that there was a recoverable problem, -the display may be messed up but the user can probably keep working -(all X protocol errors call this). Fl::error means there is a -recoverable error, but the display is so messed up it is unlikely the -user can continue (very little calls this now). Fl::fatal must not -return, as FLTK is in an unusable state (however your version may be -able to use longjmp or an exception to continue, as long as it does -not call FLTK again). +Calls the idle function if any, then calls any pending timeout +functions, then calls <a href="#flush"><tt>Fl::flush()</tt></a>. If there are +any windows displayed it then waits some time for events (zero if +there is an idle(), the shortest timeout if there are any timeouts, or +forever) and calls the handle() function on those events, and then +returns non-zero. + +<p>Your program can check its global state and update things after +each call to <tt>Fl::wait()</tt>, which can be very useful in complex programs. + +<p>If there are no windows (this is checked after the idle and +timeouts are called) then <tt>Fl::wait()</tt> returns zero without waiting for +any events. Your program can either exit at this point, or call +<tt>show()</tt> on some window so the GUI can continue to operate. -</ul><p><a href = index.html>(back to contents)</a> -<title>FLTK example: hello.C</title> -<h2>hello.C</h2> +The second form of <tt>Fl::wait()</tt> waits only a certain amount of +time for anything to happen. This does the same as <tt>wait()</tt> +except if the given time (in seconds) passes it returns. The return +value is how much time remains. If the return value is zero or +negative then the entire time period elapsed. +<p>If you do several <tt>wait(time)</tt> calls in a row, the subsequent ones +are measured from when the first one is called, even if you do +time-consuming calculations after they return. This allows you to +accurately make something happen at regular intervals. This code will +accurately call <tt>A()</tt> once per second (as long as it takes less than a +second to execute): -<p><a href = button.C.html>[Next example]</a> -<br><a href = index.html>[back to contents]</a> +<ul><pre> +for (;;) { + for (float time = 1.0; time > 0; ) time = Fl::wait(time); + A(); +} +</pre></ul> + +<h3><a name="warning">static void (*Fl::warning)(const char *, ...)</a><br> +<a name="error">static void (*Fl::error)(const char *, ...)</a><br> +<a name="fatal">static void (*Fl::fatal)(const char *, ...)</a></h3> + +FLTK will call these to print messages when unexpected conditions +occur. By default they <tt>fprintf</tt> to <tt>stderr</tt>, and +<tt>Fl::error</tt> and <tt>Fl::fatal</tt> call <tt>exit(1)</tt>. You +can override the behavior by setting the function pointers to your own +routines. + +<p><tt>Fl::warning</tt> means that there was a recoverable problem, the +display may be messed up but the user can probably keep working (all X +protocol errors call this). <tt>Fl::error</tt> means there is a +recoverable error, but the display is so messed up it is unlikely the +user can continue (very little calls this now). <tt>Fl::fatal</tt> +must not return, as FLTK is in an unusable state, however your version +may be able to use <tt>longjmp</tt> or an exception to continue, as +long as it does not call FLTK again. </BODY> </HTML> diff --git a/documentation/glut.html b/documentation/glut.html index 3cbfdb50e..643f66dc2 100644 --- a/documentation/glut.html +++ b/documentation/glut.html @@ -3,143 +3,192 @@ <H1 ALIGN=RIGHT><A NAME="glut">D - GLUT Compatibility</A></H1> -You should be able to compile existing Glut source code by -including <FL/glut.H> instead of <GL/glut.h>. This can be done by -editing the source, by changing the -I switches to the compiler, or by -providing a symbolic link from GL/glut.h to FL/glut.H. +This appendix describes the GLUT compatibility header file supplied with +FLTK. -<p>All files calling glut procedures must be compiled with C++. You may +<H2>Using the GLUT Compatibility Header File</H2> + +You should be able to compile existing GLUT source code by including +<tt><FL/glut.H></tt> instead of <tt><GL/glut.h></tt>. This can +be done by editing the source, by changing the <tt>-I</tt> switches to +the compiler, or by providing a symbolic link from <tt>GL/glut.h</tt> +to <tt>FL/glut.H</tt>. + +<p><i>All files calling GLUT procedures must be compiled with C++</i>. You may have to alter them slightly to get them to compile without warnings, and you may have to rename them to get make to use the C++ compiler. -I was unable to get some calls to glu to compile without adding some -casts, apparently due to errors in the glu header files. -<p>You must link with -lFl. If you call any glut drawing functions -that fltk does not emulate (<code>glutExtensionsSupported(), glutWire*(), -glutSolid*(), and glutStroke*()</code>), you will also have to link with --lglut, <i>after</i> -lFl. +<p>You must link with the FLTK library. If you call any GLUT drawing +functions that FLTK does not emulate +(<tt>glutExtensionsSupported()</tt>, <tt>glutWire*()</tt>, +<tt>glutSolid*()</tt>, and <tt>glutStroke*()</tt>), you will also have +to link with the GLUT library (<i>after</i> the FLTK library!) -<p>Most of glut.H is inline functions. You should take a look at it -(and maybe at glut.C in the fltk source) if you are having trouble -porting your Glut program. +<p>Most of <tt>FL/glut.H</tt> is inline functions. You should take a +look at it (and maybe at <tt>test/glut.cxx</tt> in the FLTK source) if +you are having trouble porting your GLUT program. <p>This has been tested with most of the demo programs that come with -the Glut 3.3 distribution. +the GLUT 3.3 distribution. <h2>Known Problems</h2> +The following functions and/or arguments to functions are missing, +and you will have to replace them or comment them out for your code to +compile: + <ul> -<li>The following functions and/or arguments to functions are missing, -and you will have to replace them or comment them out for your code to -compile:<ul> - -<li><code>glutLayerGet(GLUT_LAYER_IN_USE)</code> -<li><code>glutLayerGet(GLUT_HAS_OVERLAY)</code> -<li><code>glutSetColor(), glutGetColor(), glutCopyColormap()</code> -<li><code>glutInitDisplayMode(GLUT_STEREO)</code> -<li><code>glutInitDisplayMode(GLUT_LUMINANCE)</code> -<li><code>glutPushWindow()</code> -<li><code>glutWarpPointer()</code> -<li>Spaceball, buttonbox, dials, tablet functions, <code>glutDeviceGet()</code> -<li><code>glutWindowStatusFunc()</code> -<li><code>glutGet(GLUT_WINDOW_NUM_CHILDREN)</code> -<li><code>glutGet(GLUT_SCREEN_WIDTH_MM)</code> -<li><code>glutGet(GLUT_SCREEN_HEIGHT_MM)</code> -<li><code>glutGet(GLUT_ELAPSED_TIME)</code> -<li><code>glutVideoResize()</code> missing. + <li><tt>glutLayerGet(GLUT_LAYER_IN_USE)</tt> + <li><tt>glutLayerGet(GLUT_HAS_OVERLAY)</tt> + <li><tt>glutSetColor(), glutGetColor(), glutCopyColormap()</tt> + <li><tt>glutInitDisplayMode(GLUT_STEREO)</tt> + <li><tt>glutInitDisplayMode(GLUT_LUMINANCE)</tt> + <li><tt>glutPushWindow()</tt> + <li><tt>glutWarpPointer()</tt> + <li>Spaceball, buttonbox, dials, tablet functions, + <tt>glutDeviceGet()</tt> + <li><tt>glutWindowStatusFunc()</tt> + <li><tt>glutGet(GLUT_WINDOW_NUM_CHILDREN)</tt> + <li><tt>glutGet(GLUT_SCREEN_WIDTH_MM)</tt> + <li><tt>glutGet(GLUT_SCREEN_HEIGHT_MM)</tt> + <li><tt>glutGet(GLUT_ELAPSED_TIME)</tt> + <li><tt>glutVideoResize()</tt> missing. </ul> -<li>Most of the symbols/enumerations have different values than -Glut uses. This will break code that relies on the actual values. +Most of the symbols/enumerations have different values than +GLUT uses. This will break code that relies on the actual values. The only symbols guaranteed to have the same values are true/false -pairs like <code>GLUT_DOWN</code> and <code>GLUT_UP</code>, mouse -buttons <code>GLUT_LEFT_BUTTON, GLUT_MIDDLE_BUTTON, -GLUT_RIGHT_BUTTON</code>, and <code>GLUT_KEY_F1</code> thru -<code>F12</code>. +pairs like <tt>GLUT_DOWN</tt> and <tt>GLUT_UP</tt>, mouse +buttons <tt>GLUT_LEFT_BUTTON, GLUT_MIDDLE_BUTTON, +GLUT_RIGHT_BUTTON</tt>, and <tt>GLUT_KEY_F1</tt> thru +<tt>F12</tt>. -<li><i>The strings passed as menu labels are not copied</i>. +<p>The strings passed as menu labels are not copied. -<li><code>glutPostRedisplay()</code> does not work if called from -inside a display function. You must use <code>glutIdleFunc()</code> +<p><tt>glutPostRedisplay()</tt> does not work if called from +inside a display function. You must use <tt>glutIdleFunc()</tt> if you want your display to update continuously. -<li><code>glutSwapBuffers()</code> does not work from inside a display -function. This is on purpose, because fltk swaps the buffers for you. +<p><tt>glutSwapBuffers()</tt> does not work from inside a display +function. This is on purpose, because FLTK swaps the buffers for you. -<li><code>glutUseLayer()</code> does not work well, and should only be +<p><tt>glutUseLayer()</tt> does not work well, and should only be used to initialize transformations inside a resize callback. You -should redraw overlays by using <code>glutOverlayDisplayFunc()</code>. +should redraw overlays by using <tt>glutOverlayDisplayFunc()</tt>. -<li>Overlays are cleared before the overlay display function is -called. <code>glutLayerGet(GLUT_OVERLAY_DAMAGED)</code> always -returns true, this fixed some glut overlay programs. You must rewrite -your code so that gl_color() is used to choose colors in an overlay, -or you will get random overlay colors. +<p>Overlays are cleared before the overlay display function is called. +<tt>glutLayerGet(GLUT_OVERLAY_DAMAGED)</tt> always returns true for +compatibility with some GLUT overlay programs. You must rewrite your +code so that <tt>gl_color()</tt> is used to choose colors in an +overlay, or you will get random overlay colors. -<li><code>glutSetCursor(GLUT_CURSOR_FULL_CROSSHAIR)</code> just +<p><tt>glutSetCursor(GLUT_CURSOR_FULL_CROSSHAIR)</tt> just results in a small crosshair. -<li>The fonts used by <code>glutBitmapCharacter() and -glutBitmapWidth()</code> may be different. +<p>The fonts used by <tt>glutBitmapCharacter() and +glutBitmapWidth()</tt> may be different. -<li><code>glutInit(argc,argv)</code> will consume different switches than glut +<p><tt>glutInit(argc,argv)</tt> will consume different switches than GLUT does. It accepts the switches recognized by <a -href=Fl.html>Fl_Window::arg()</a>, and will accept any -abbreviation of these switches (such as -d for -display). +href="#args"><tt>Fl::args()</tt></a>, and will accept any +abbreviation of these switches (such as "-di" for "-display"). -</ul> +<h2>Mixing GLUT and FLTK Code</h2> + +You can make your GLUT window a child of a <tt>Fl_Window</tt> with the +following scheme. The biggest trick is that GLUT insists on +<tt>show()</tt>'ing the window at the point it is created, which means the +<tt>Fl_Window</tt> parent window must already be shown. + +<ul> + + <li>Don't call <tt>glutInit()</tt>. + + <li>Create your <tt>Fl_Window</tt>, and any FLTK widgets. + Leave a blank area in the window for your GLUT window. + + <li><tt>show()</tt> the <tt>Fl_Window</tt>. Perhaps call + <tt>show(argc,argv)</tt>. -<h2>Mixing Glut code and Fltk code</h2> + <li>Call <tt>window->begin()</tt> so that the GLUT window will + be automatically added to it. -You can make your Glut window a child of a Fl_Window with the -following scheme. The biggest trick is that Glut insists on -show()'ing the window at the point it is created, which means the -Fl_Window parent window must already be show()n. + <li>Use <tt>glutInitWindowSize()</tt> and + <tt>glutInitWindowPosition()</tt> to set the location in the + parent window to put the GLUT window. -<p>Don't call glutInit(). + <li>Put your GLUT code next. It probably does not need many changes. + Call <tt>window->end()</tt> immediately after the <tt>glutCreateWindow()</tt>! -<p>Create your Fl_Window, and any fltk widgets. Leave a blank area in -the window for your glut window. + <li>You can call either <tt>glutMainLoop()</tt>, + <tt>Fl::run()</tt>, or loop calling <tt>Fl::wait()</tt> to run + the program. -<p>show() the Fl_Window. Perhaps call show(argc,argv). +</ul> + +<hr break> + +<h2><a name="Fl_Glut_Window">class Fl_Glut_Window</a></h2> -<p>Call window->begin() so the glut window will be automatically added -to it. +<hr> -<p>Use glutInitWindowSize() and glutInitWindowPosition() to set the -location in the parent window to put the glut window. +<h3>Class Hierarchy</h3> -<p>Put your glut code next. It probably does not need many changes. -Call window->end() immediately after the glutCreateWindow()! +<ul><pre> +<a href="#Fl_Gl_Window">Fl_Gl_Window</a> + | + +----<b>Fl_Glut_Window</b> +</pre></ul> -<p>You can call either glutMainLoop() or Fl::run() or loop calling -Fl::wait() to run the program. +<h3>Include Files</h3> -<h2>class Fl_Glut_Window : public <a href=Fl_Gl_Window.html>Fl_Gl_Window</a></h2> +<ul><pre> +#include <FL/glut.H> +</pre></ul> -Each Glut window is an instance of this class, which is a subclass of -<a href=Fl_Gl_Window.html>Fl_Gl_Window</a>. You may find it useful to -manipulate instances directly rather than use glut window id's. These +<h3>Description</h3> + +Each GLUT window is an instance of this class. You may find it useful to +manipulate instances directly rather than use GLUT window id's. These may be created without opening the display, and thus can fit better -into FL's method of creating windows. +into FLTK's method of creating windows. -<p>The current glut window is available in <code>Fl_Glut_Window -*glut_window</code>. +<p>The current GLUT window is available in the global variable +<tt>glut_window</tt>. -<p><code>new Fl_Glut_Window(...)</code> is the same as -<code>glutCreateWindow()</code> except it does not show() the window +<p><tt>new Fl_Glut_Window(...)</tt> is the same as +<tt>glutCreateWindow()</tt> except it does not <tt>show()</tt> the window or make the window current. -<p><code>window->make_current()</code> is the same as -<code>glutSetWindow(number)</code>. If the window has not had show() -called on it yet, some functions that assumme a gl context will not -work. If you do show() the window, call make_current() again to set -the context. +<p><tt>window->make_current()</tt> is the same as +<tt>glutSetWindow(number)</tt>. If the window has not had +<tt>show()</tt> called on it yet, some functions that assumme an OpenGL +context will not work. If you do <tt>show()</tt> the window, call +<tt>make_current()</tt> again to set the context. + +<p><tt>~Fl_Glut_Window()</tt> is the same as +<tt>glutDestroyWindow()</tt>. + +<h3>Methods</h3> + +<ul> + <li><a href="#Fl_Glut_Window.Fl_Glut_Window">Fl_Glut_Window</a> + <li><a href="#Fl_Glut_Window.~Fl_Glut_Window">~Fl_Glut_Window</a> +</ul> + +<h4><a name="Fl_Glut_Window.Fl_Glut_Window">Fl_Glut_Window::Fl_Glut_Window(int x, int y, int w, int h, const char *title = 0)<br> +Fl_Glut_Window::Fl_Glut_Window(int w, int h, const char *title = 0)</a></h4> + +The first constructor takes 4 int arguments to create the window with +a preset position and size. The second constructor with 2 arguments +will create the window with a preset size, but the window manager +will choose the position according to it's own whims. + +<h4><a name="Fl_Glut_Window.~Fl_Glut_Window">virtual Fl_Glut_Window::~Fl_Glut_Window()</a></h4> -<p><code>~Fl_Glut_Window()</code> is the same as -<code>glutDestroyWindow()</code>. +Destroys the GLUT window. </BODY> </HTML> diff --git a/documentation/intro.html b/documentation/intro.html index 39b73c225..7f3edffdb 100644 --- a/documentation/intro.html +++ b/documentation/intro.html @@ -78,7 +78,7 @@ has started being included on Linux distributions. <p>Here are some of the core features unique to FLTK: <ul> - <li>sizeof(Fl_Widget) == 48.</li> + <li>sizeof(Fl_Widget) == 40 to 48.</li> <li>The "core" (the "hello" program compiled & linked with a static FLTK library using gcc on a 486 and then stripped) is 39.5K.</li> @@ -112,9 +112,9 @@ has started being included on Linux distributions. <li>Text input fields with Emacs key bindings, X cut & paste, and foreign letter compose!</li> - <li>Compatability header file for the GLUT library.</li> + <li>Compatibility header file for the GLUT library.</li> - <li>Compatability header file for the XForms library.</li> + <li>Compatibility header file for the XForms library.</li> <li>Much too much to list here...</li> </ul> @@ -228,9 +228,11 @@ FLTK is available on the 'net in a bunch of locations: <dt>FTP</dt> -<dd><a href="ftp://ftp.easysw.com/pub/fltk">ftp://ftp.easysw.com/pub/fltk</a><br> -<a href="ftp://ftp.funet.fi/mirrors/ftp.easysw.com/pub/fltk">ftp://ftp.funet.fi/mirrors/ftp.easysw.com/pub/fltk</a><br> -<a href="ftp://ftp.northamerica.net/pub/ESP/fltk">ftp.northamerica.net/pub/ESP/fltk</a><br></dd> +<dd><a href="ftp://ftp.easysw.com/pub/fltk">ftp://ftp.easysw.com/pub/fltk</a></dd> + +<dd><a href="ftp://ftp.funet.fi/mirrors/ftp.easysw.com/pub/fltk">ftp://ftp.funet.fi/mirrors/ftp.easysw.com/pub/fltk</a></dd> + +<dd><a href="ftp://ftp.northamerica.net/pub/ESP/fltk">ftp.northamerica.net/pub/ESP/fltk</a><br></dd> <dt>EMail</dt> diff --git a/documentation/license.html b/documentation/license.html index 2dbaaa5e0..add40a768 100644 --- a/documentation/license.html +++ b/documentation/license.html @@ -5,7 +5,7 @@ <H2>GNU LIBRARY GENERAL PUBLIC LICENSE</H2> -<P>Version 2, June 1991<BR> +<P ALIGN=CENTER>Version 2, June 1991<BR> Copyright (C) 1991 Free Software Foundation, Inc.<BR> 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA<BR> Everyone is permitted to copy and distribute verbatim copies @@ -103,7 +103,7 @@ works together with the library. <P>Note that it is possible for a library to be covered by the ordinary General Public License rather than by this special one. -<H2>TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION</H2> +<H2 ALIGN=CENTER>TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION</H2> <STRONG>0.</STRONG> This License Agreement applies to any software library which contains a notice placed by the copyright holder or other authorized @@ -437,7 +437,7 @@ decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. -<H2>NO WARRANTY</H2> +<H2 ALIGN=CENTER>NO WARRANTY</H2> <P><STRONG>15.</STRONG> BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO @@ -462,7 +462,7 @@ FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. -<H2>END OF TERMS AND CONDITIONS</H2> +<H2 ALIGN=CENTER>END OF TERMS AND CONDITIONS</H2> </BODY> </HTML> diff --git a/documentation/opengl.html b/documentation/opengl.html index e26895a2c..f566d30ad 100644 --- a/documentation/opengl.html +++ b/documentation/opengl.html @@ -1,486 +1,360 @@ <HTML> <BODY> -<H1 ALIGN=RIGHT><A NAME="opengl">7 - Using OpenGL</A></H1> +<H1 ALIGN=RIGHT><A NAME="opengl">9 - Using OpenGL</A></H1> This chapter discusses using FLTK for your OpenGL applications. -<H2>The OpenGL Widget</H2> +<h2>Using OpenGL in FLTK</h2> -<H2>Making a Simple OpenGL Wrapper Widget</H2> +The easiest way to make an OpenGL display is to subclass <a +href="#Fl_Gl_Window"><tt>Fl_Gl_Window</tt></a>. Your subclass must +implement a <tt>draw()</tt> method which uses OpenGL calls to draw the +display. Your main program should call <tt>redraw()</tt> when the +display needs to change, and (somewhat later) FLTK will call +<tt>draw()</tt>. -<H2>A Simple Flight Simulator</H2> +<p>With a bit of care you can also use OpenGL to draw into normal FLTK +windows. This is mostly useful because you can use Gourand shading for +drawing your widgets. To do this you use the <a +href="#gl_start"><tt>gl_start()</tt></a> and <a +href="#gl_finish"><tt>gl_finish()</tt></a> functions around your OpenGL +code. -<H2>Using FLTK with OpenGL Optimizer</H2> +<p>You must include FLTK's <tt><FL/gl.h></tt> header file. It will include +the file <tt><GL/gl.h></tt>, define some extra drawing functions +provided by FLTK, and include the <tt><windows.h></tt> header file needed +by WIN32 applications. -<H2>Using OpenGL Optimizer for the Flight Simulator</H2> +<h2>Making a Subclass of Fl_Gl_Window</h2> -</BODY> -</HTML> -<title>Using OpenGL in Fltk</title> - -<h2>Using OpenGL in Fltk<br>#include <FL/gl.h></h2> - -The easiest way to make an OpenGL display is to subclass Fl_Gl_Window. -Your subclass should implement a draw() method which uses OpenGL calls -to draw the display. Your main program should call w->redraw() when -the display needs to change, and (somewhat later) fltk will call -draw(). - -<p>With a bit of care you can also use OpenGL to draw into normal fltk -windows. This is mostly useful because you can access Gourand shading -for drawing your widgets. To do this you use the <a -href=#gl_start>gl_start() and gl_finish()</a> functions around your -OpenGL code. - -<p>You must include fltk's <FL/gl.h> header file. It will include -the file <GL/gl.h>, plus it defines some extra drawing functions -provided by fltk, and also gets around a horrid screwup by our friends -in Seattle. - -<h2>Sample code for subclassing Fl_Gl_Window</h2> +To make a subclass of Fl_Gl_Window, you must provide: -<p><pre> - class MyWindow : public Fl_Gl_Window { - void draw(); - int handle(int); - public: - MyWindow(int X, int Y, int W, int H, const char* L) - : Fl_Gl_Window(X,Y,W,H,L) {} - }; +<ul> - void MyWindow::draw() { - if (!valid()) { - ... set up projection, viewport, etc ... - ... window size is in w() and h(). - ... valid() is turned on by fltk after draw() returns - } - ... draw ... - } + <li>A class definition. + <li>A <tt>draw()</tt> method. + <li>A <tt>handle()</tt> method (if you need to recieve input from + the user). +</ul> - int MyWindow::handle(int event) { - switch(event) { - case FL_PUSH: - ... mouse down event ... - ... position in Fl::event_x() and Fl::event_y() - return 1; - case FL_DRAG: - ... mouse moved while down event ... - return 1; - case FL_RELEASE: - ... mouse up event ... - return 1; - case FL_KEYBOARD: - ... keypress, key is in Fl::event_key(), ascii in Fl::event_text() - return 1; - default: - // tell fltk that I don't understand other events - return 0; - } - } -</pre> +<h3>Defining the Subclass</h3> -<p>When handle() is called, the glx context is not set up! If your -display changes, you should call redraw() and let draw() do the work. -Don't call any gl functions from inside handle()! +To define the subclass you just subclass <tt>Fl_Gl_Window</tt> class: -<p>This may mean you cannot call some OpenGl stuff like hit detection. -You can fix this by doing: +<ul><pre> +class MyWindow : public Fl_Gl_Window { + void draw(); + int handle(int); -<p><pre> - case FL_PUSH: - make_current(); // make glx context current - if (!valid()) { - ... set up projection exactly the same as draw ... - valid(1); // stop it from doing this next time - } - ... ok to call NON-DRAWING OpenGL code here, such as hit - detection ... -</pre> +public: + MyWindow(int X, int Y, int W, int H, const char *L) + : Fl_Gl_Window(X, Y, W, H, L) {} +}; +</pre></ul> -<p>Your main program can now create one of your windows by doing "new -MyWindow(...)". You can also use <a href=fluid.html>fluid</a>: +The <tt>draw()</tt> and <tt>handle()</tt> methods are described below. Like +any widget, you can include additional private and public data in your class +(such as scene graph information, etc.) -<ol> -<li>Put your class definition in a MyWindow.H file. -<li>In fluid create a box object, resize & place where you want. -<li>In the control panel, fill in the "class" field with MyWindow.H. -This will make fluid produce constructors for your new class. -<li>In the "extra code" put "#include "MyWindow.H"", so that the fluid -output file will compile. -</ol> +<h3>The draw() Method</H3> -<p>You must put glwindow->show() in your main code after calling -show() on the window containing the gl window. - -<p><hr> -<h2>class Fl_Gl_Window : public <a href=Fl_Window.html>Fl_Window</a></h2> - -<p>An Fl_Gl_Window sets things up so OpenGL works, and also keeps an -OpenGL "context" for that window, so that changes to the lighting and -projection may be reused between redraws. Fl_Gl_Window also flushes -the OpenGL streams and swaps buffers after draw() returns. - -<p>Fl_Gl_Window::draw() is a pure virtual method. You must subclass -Fl_Gl_Window and provide an implementation for draw(). You may also -provide an implementation of draw_overlay() if you want to draw into -the overlay planes. You can avoid reinitializing the viewport and -lights and other things by checking valid() at the start of draw() and -only doing the initialization if it is false. - -<p>The draw() method can <i>only</i> use OpenGL calls. Do not attempt to -call X, any of the functions in <FL/fl_draw.H>, or glX directly. Do -not call gl_start() or gl_finish(). - -<h2>Methods:</h2> - -<h4><code>Fl_Gl_Window::Fl_Gl_Window(int W, int H, const char *l=0); -<br>Fl_Gl_Window::Fl_Gl_Window(int X, int Y, int W, int H, const char -*l=0)</code></h4><ul> - -The constructors. Fl_Gl_Window::mode() defaults to -<code>FL_RGB|FL_DOUBLE|FL_DEPTH</code>. - -<a name=mode> -</ul><h4><code>const int Fl_Gl_Window::mode() const; -<br>int Fl_Gl_Window::mode(int);</code></h4><ul> - -Set or change the OpenGL capabilites of the window. The value can be -any of the following or'd together: - -<p><ul> -<li><code>FL_RGB</code> - Color (not indexed) -<li><code>FL_RGB8</code> - Color with at least 8 bits of each color -<li><code>FL_INDEX</code> - Indexed mode -<li><code>FL_SINGLE</code> - not double buffered -<li><code>FL_DOUBLE</code> - double buffered -<li><code>FL_ACCUM</code> - accumulation buffer -<li><code>FL_ALPHA</code> - alpha channel in color -<li><code>FL_DEPTH</code> - depth buffer -<li><code>FL_STENCIL</code> - stencil buffer -<li><code>FL_MULTISAMPLE</code> - multisample antialiasing -</ul> +The <tt>draw()</tt> method is where you actually do your OpenGL drawing: -<p><code>FL_RGB</code> and <code>FL_SINGLE</code> have a -value of zero, they are "on" <i>unless</i> you give -<code>FL_INDEX</code> or <code>FL_DOUBLE</code>. - -<p>If the desired combination cannot be done, fltk will try turning off -the <code>FL_MULTISAMPLE</code>. If this also fails show() will call -Fl::error() and not show the window. - -<p>You can change the mode while the window is displayed. This -is most useful for turning double-buffering on and off. <i>Under -X this will cause the old X window to be destroyed and a new one -created. If this is a top-level window this will unfortunately also -cause the window to blink, raise to the top, and be de-iconized, and -the xid() will change, possibly breaking other code. It is best to -make the GL window a child of another window if you wish to do this!</i> - -</ul><h4><code>int Fl_Gl_Window::mode(const int *);</code></h4><ul> - -<p><i>This call only works on systems using glX.</i> This value is -passed unchanged to glXChooseVisual(), superceeding the value -calculated from mode(int). See "man glXChooseVisual" if you wish to -construct your own mode. Fltk assummes that the pointer is to static -const data, and caches the pointer with the found visual. -glXChooseVisual is not called until show() or can_do() -is called. To restore the use of mode(int), call -<code>mode((int*)0)</code>. - -</ul><h4><code>static int Fl_Gl_Window::can_do(int); -<br>static int Fl_Gl_Window::can_do(const int *mode); -<br>int Fl_Gl_Window::can_do() const;</code></h4><ul> - -Returns non-zero if show() will not call Fl::error() if called with -the given or current mode. - -</ul><h4><code>char Fl_Gl_Window::valid() const; -<br>void Fl_Gl_Window::invalidate(); -<br>void Fl_Gl_Window::valid(char i);</code></h4><ul> - -<code>Fl_Gl_Window::valid()</code> is turned off when fltk creates a -new context for this window and by the window resizing, and is turned -on <i>after</i> draw() is called. You can use this inside your draw() -method to avoid unneccessarily initializing the OpenGL context. Just -do this: - -<ul><pre><code>void mywindow::draw() { +<ul><pre> +void MyWindow::draw() { if (!valid()) { - glViewport(0,0,w(),h()); - glFrustum(...); - glLight(...); - ...other initilization... + ... set up projection, viewport, etc ... + ... window size is in w() and h(). + ... valid() is turned on by FLTK after draw() returns } - ... draw your geometry here ... + ... draw ... } -</code></pre></ul> - -<p>You can also turn valid() off yourself (for instance if you know -the current projection has changed). To do this call -<code>invalidate()</code>. - -<p>You can turn valid() on by calling valid(1). You should only do -this after fixing the transformation inside a draw() or after -make_current(). This is done automatically after draw() returns. - -</ul><h4><code>void Fl_Gl_Window::ortho();</code></h4><ul> - -Set the projection so 0,0 is in the lower left of the window and each -pixel is 1 unit wide/tall. If you are drawing 2D images, your draw() -method may want to call this if valid() is false. - -</ul><h4><code>void Fl_Gl_Window::make_current(); -<br>void Fl_Gl_Window::make_overlay_current(); -<br>void Fl_Gl_Window::swap_buffers();</code></h4><ul> - -These functions can be used to set the current GL context to a window -and draw into it incrementally, rather than using the draw() method. -You will also need to call make_current() to do OpenGL feedback or hit -detection in response to events. After calling make_current(), be -sure to test valid(), and if false, initialize the transformation and -call valid(1). - -</ul><h4><code>void Fl_Gl_Window::hide(); -<br>Fl_Gl_Window::~Fl_Gl_Window();</code></h4><ul> +</pre></ul> + +<h3>The handle() Method</h3> + +The <tt>handle()</tt> method handles mouse and keyboard events for the +window: + +<ul><pre> +int MyWindow::handle(int event) { + switch(event) { + case FL_PUSH: + ... mouse down event ... + ... position in Fl::event_x() and Fl::event_y() + return 1; + case FL_DRAG: + ... mouse moved while down event ... + return 1; + case FL_RELEASE: + ... mouse up event ... + return 1; + case FL_FOCUS : + case FL_UNFOCUS : + ... Return 1 if you want keyboard events, 0 otherwise + return 1; + case FL_KEYBOARD: + ... keypress, key is in Fl::event_key(), ascii in Fl::event_text() + ... Return 1 if you understand/use the keyboard event, 0 otherwise... + return 1; + default: + // tell FLTK that I don't understand other events + return 0; + } +} +</pre></ul> -Hiding the window or destroying it also destroys the OpenGL context it -uses. +When <tt>handle()</tt> is called, the OpenGL context is not set up! If your +display changes, you should call <tt>redraw()</tt> and let <tt>draw()</tt> do the work. +Don't call any OpenGL drawing functions from inside <tt>handle()</tt>! -</ul><h2>Fl_Gl_Window overlay</h2> +<p>You can call some OpenGL stuff like hit detection and texture loading +functions by doing: -GL hardware typically provides some overlay bit planes, which are very -useful for drawing UI controls atop your 3D graphics. If the overlay -hardware is not provided, fltk tries to simulate the overlay, this works -pretty well if your graphics are double buffered, but not very well -for single-buffered. +<ul><pre> + case FL_PUSH: + make_current(); // make OpenGL context current + if (!valid()) { + ... set up projection exactly the same as draw ... + valid(1); // stop it from doing this next time + } + ... ok to call NON-DRAWING OpenGL code here, such as hit + detection, loading textures, etc... +</pre></ul> -</ul><h4><code>int Fl_Gl_Window::can_do_overlay();</code></h4><ul> +Your main program can now create one of your windows by doing <tt>new +MyWindow(...)</tt>. You can also use <a href="#fluid">fluid</a> by: -Returns true if the hardware overlay is possible. If this is false, -fltk will try to simulate the overlay, with significant loss of update -speed. Calling this will cause fltk to open the display. +<ol> + <li>Put your class definition in a MyWindow.H file. -</ul><h4><code>void Fl_Gl_Window::redraw_overlay();</code></h4><ul> + <li>In fluid create a box object, resize & place where you want. -Call this if what is drawn in the overlay needs to change, this will -cause draw_overlay to be called at a later time. Initially the -overlay is clear, if you want the window to display something in the -overlay when it first appears, you must call this immediately after -you show() your window. + <li>In the control panel, fill in the "class" field with MyWindow.H. + This will make fluid produce constructors for your new class. -</ul><h4><code>virtual void Fl_Gl_Window::draw_overlay();</code></h4><ul> + <li>In the "extra code" put <tt>#include "MyWindow.H"</tt>, so + that the fluid output file will compile. -You must implement this virtual function if you want to draw into the -overlay. The overlay is cleared before this is called. You should -draw anything that is not clear, using OpenGl. You must use -gl_color(i) to choose colors (it allocates them from the colormap -using system-specific calls), and remember that you are in an indexed -OpenGL mode and drawing anything other than flat-shaded will probably -not work. +</ol> -<p>Both this function and Fl_Gl_Window::draw() must check -Fl_Gl_Window::valid(), and set the same transformation. If you don't -your code may not work on other systems. Depending on the OS, and on -whether overlays are real or simulated, the OpenGL context may be the -same or different between the overlay and main window. +You must put <tt>glwindow->show()</tt> in your main code after calling +<tt>show()</tt> on the window containing the OpenGL window. -</ul><p><hr> -<a name=gl_start> -<h2>Using OpenGL in normal Fltk windows</h2> +<h2>Using OpenGL in Normal FLTK Windows</h2> -<p>You can put OpenGL code into an <a -href=subclass.html#draw>Fl_Widget::draw()</a> method or into the code -for a <a href=Boxtypes.html>boxtype</a> or other places, with some care. +You can put OpenGL code into an <a +href="#draw"><tt>Fl_Widget::draw()</tt></a> method or into the code for +a <a href="#boxtypes">boxtype</a> or other places with some care. <p>Most important, before you show <i>any</i> windows (including those -that don't have OpenGL drawing) you must initialize fltk/X so that it +that don't have OpenGL drawing) you must initialize FLTK so that it knows it is going to use OpenGL. You may use any of the symbols -described for <a href=#mode>Fl_Gl_Window::mode()</a> to describe how -you intend to use OpenGL: +described for <a +href="#Fl_Gl_Window.mode"><tt>Fl_Gl_Window::mode()</tt></a> to describe +how you intend to use OpenGL: -<ul><p><code> Fl::gl_visual(FL_RGB);</code></ul> +<ul><pre> +Fl::gl_visual(FL_RGB); +</pre></ul> -<p>You can then put OpenGL drawing code anywhere you can draw normally +You can then put OpenGL drawing code anywhere you can draw normally by surrounding it with: -<ul><p><code>gl_start();</code><br> -<i>... put your OpenGL code here ...</i><br> -<code>gl_finish();</code></ul> +<ul><pre> +gl_start(); +... put your OpenGL code here ... +gl_finish(); +</pre></ul> -<p>gl_start() and gl_finish() set up a GL context with an orthographic -projection so that 0,0 is the lower-left corner of the window and each -pixel is one unit. The current clipping is reproduced with OpenGL -scissor commands. These also synchronize the OpenGL graphics stream -with the drawing done by other X or fltk functions. +<a name="gl_start"><tt>gl_start()</tt></a> and <a +name="gl_finish"><tt>gl_finish()</tt></a> set up an OpenGL context with +an orthographic projection so that 0,0 is the lower-left corner of the +window and each pixel is one unit. The current clipping is reproduced +with OpenGL <tt>glScissor()</tt> commands. These also synchronize the +OpenGL graphics stream with the drawing done by other X, WIN32, or FLTK +functions. <p>The same context is reused each time. If your code changes the -projection transformation or anything else you should use glPush/glPop -to put the state back before calling gl_finish(). +projection transformation or anything else you should use +<tt>glPushMatrix()</tt> and <tt>glPopMatrix()</tt> functions to put the +state back before calling <tt>gl_finish()</tt>. -<p>You may want to use <code>Fl_Window::current()->h()</code> to get -the drawable height so you can flip the coordinate system. +<p>You may want to use <tt>Fl_Window::current()->h()</tt> to get +the drawable height so you can flip the Y coordinates. -<p>Unfortunately there are a bunch of limitations you must adhere to for -maximum portability:<ul> +<p>Unfortunately, there are a bunch of limitations you must adhere to for +maximum portability: -<li>You must choose a default visual with <a -href=Fl.html#gl_visual>Fl::gl_visual()</a>. +<ul> -<li>You cannot pass FL_DOUBLE to Fl::gl_visual(). + <li>You must choose a default visual with <a + href="#gl_visual"><tt>Fl::gl_visual()</tt></a>. -<li>You cannot use Fl_Double_Window (or Fl_Overlay_Window). + <li>You cannot pass <tt>FL_DOUBLE</tt> to <tt>Fl::gl_visual()</tt>. + + <li>You cannot use <tt>Fl_Double_Window</tt> or + <tt>Fl_Overlay_Window</tt>. </ul> -<p>Do <i>not</i> call gl_start()/gl_finish() when drawing an -Fl_Gl_Window! +Do <i>not</i> call <tt>gl_start()</tt> or <tt>gl_finish()</tt> when drawing +into an <tt>Fl_Gl_Window</tt>! -</ul><p><hr> -<a name=drawing> -<h2>OpenGL drawing functions -<br>#include <FL/gl_draw.H></h2> +<h2>OpenGL drawing functions</h2> -Fltk provides some useful gl drawing functions. They can be freely -mixed with any OpenGL calls, and are defined by including <FL/gl.H> -(which you should include instead of the OpenGL header <GL/gl.h>). +FLTK provides some useful OpenGL drawing functions. They can be freely +mixed with any OpenGL calls, and are defined by including +<tt><FL/gl.H></tt> (which you should include instead of the OpenGL +header <tt><GL/gl.h></tt>). -</ul><h4><code>void gl_color(Fl_Color);</code></h4><ul> +<h3>void gl_color(Fl_Color)</h3> -Set the current color to a fltk color index. <i>For color-index modes -it will use fl_xpixel(c), which is only right if this window uses the -default X colormap</i>. +Set the current color to a FLTK color index. <i>For color-index modes +it will use <tt>fl_xpixel(c)</tt>, which is only right if this window +uses the default colormap!</i> -</ul><h4><code>void gl_rect(int x,int y,int w,int h); -<br>void gl_rectf(int x,int y,int w,int h);</code></h4><ul> +<h3>void gl_rect(int x, int y, int w, int h)<br> +void gl_rectf(int x, int y, int w, int h)</h3> -Outline or fill a rectangle with the current color. If ortho() has -been called, then the rectangle will exactly fill the pixel rectangle -passed. +Outline or fill a rectangle with the current color. If +<tt>ortho()</tt> has been called, then the rectangle will exactly fill +the pixel rectangle passed. -</ul><h4><code>void gl_font(Fl_Font fontid, int size);</code></h4><ul> +<h3>void gl_font(Fl_Font fontid, int size)</h3> -Set the "current GL font" to the same font you get by calling -<a href=Draw.html#fl_font>fl_font()</a>. +Set the "current OpenGL font" to the same font you get by calling +<a href="#fl_font"><tt>fl_font()</tt></a>. -</ul><h4><code>int gl_height(); -<br>int gl_descent(); -<br>float gl_width(const char *); -<br>float gl_width(const char *, int n); -<br>float gl_width(uchar);</code></h4><ul> +<h3>int gl_height()<br> +int gl_descent()<br> +float gl_width(const char *)<br> +float gl_width(const char *, int n)<br> +float gl_width(uchar)</h3> -Return information about the current GL font. +Return information about the current OpenGL font. -</ul><h4><code>void gl_draw(const char *); -<br>void gl_draw(const char *, int n);</code></h4><ul> +<h3>void gl_draw(const char *)<br> +void gl_draw(const char *, int n)</h3> -Draw a null-terminated string or an array of <i>n</i> characters in -the current GL font at the current glRasterPos. +Draw a nul-terminated string or an array of <tt>n</tt> characters in +the current OpenGL font at the current <tt>glRasterPos</tt>. -</ul><h4><code>void gl_draw(const char *, int x, int y); -<br>void gl_draw(const char *, int n, int x, int y);</code></h4><ul> +<h3>void gl_draw(const char *, int x, int y)<br> +void gl_draw(const char *, int n, int x, int y)<br> +void gl_draw(const char *, float x, float y)<br> +void gl_draw(const char *, int n, float x, float y)</h3> -Draw a null-terminated string or an array of <i>n</i> characters in -the current GL font at the given position. +Draw a nul-terminated string or an array of <tt>n</tt> characters in +the current OpenGL font at the given position. -</ul><h4><code>void gl_draw(const char *, int x, int y, int w, int h, Fl_Align);</code></h4><ul> +<h3>void gl_draw(const char *, int x, int y, int w, int h, Fl_Align)</h3> Draw a string formatted into a box, with newlines and tabs expanded, other control characters changed to ^X, and aligned with the edges or -center. Exactly the same output as <a href=Draw.html#fl_draw>fl_draw()</a>. +center. Exactly the same output as <a href="#fl_draw"><tt>fl_draw()</tt></a>. -</ul> -<p><a href = index.html>(back to contents)</a> -<title>Fltk example: shape.C</title> -<h2>shape.C</h2> +<h2>Using OpenGL Optimizer with FLTK</h2> -<p>Of course GL is no fun unless you can draw your own graphics. This -is done with a subclass that you create: +<a href="http://www.sgi.com/software/optimizer">OpenGL Optimizer</a> is +a scene graph toolkit for OpenGL available from Silicon Graphics for +IRIX and Microsoft Windows. Versions are in the works for Solaris and +HP-UX. It allows you to view large scenes without writing a lot of +OpenGL code. + +<h3>OptimizerWindow Class Definition</h3> -<p><img src = shape.C.gif align=top> +To use OpenGL Optimizer with FLTK you'll need to create a subclass of +<tt>Fl_Gl_Widget</tt> that includes several state variables: -<pre> -#include <FL/Fl.H> -#include <FL/Fl_Window.H> -#include <FL/Fl_Hor_Slider.H> -#include <FL/math.h> -#include <FL/gl.h> -#include <FL/Fl_Gl_Window.H> +<ul><pre> +class OptimizerWindow : public Fl_Gl_Window { + csContext *context_; // Initialized to 0 and set by draw()... + csDrawAction *draw_action_; // Draw action... + csGroup *scene_; // Scene to draw... + csCamara *camera_; // Viewport for scene... -class shape_window : public Fl_Gl_Window { void draw(); + public: - int sides; - shape_window(int x,int y,int w,int h,const char *l=0); + OptimizerWindow(int X, int Y, int W, int H, const char *L) + : Fl_Gl_Window(X, Y, W, H, L) { + context_ = (csContext *)0; + draw_action_ = (csDrawAction *)0; + scene_ = (csGroup *)0; + camera_ = (csCamera *)0; + } + + void scene(csGroup *g) { scene_ = g; redraw(); } + + void camera(csCamera *c) { + camera_ = c; + if (context_) { + draw_action_->setCamera(camera_); + camera_->draw(draw_action_); + redraw(); + } + } }; +</ul><pre> -shape_window::shape_window(int x,int y,int w,int h,const char *l) : -Fl_Gl_Window(x,y,w,h,l) { - sides = 3; -} +<H3>The camera() Method</H3> -void shape_window::draw() { - // the valid() property may be used to avoid reinitializing your - // GL transformation for each redraw: - if (!valid()) { - valid(1); - glLoadIdentity(); - glViewport(0,0,w(),h()); +The <tt>camera()</tt> method sets the camera (projection and viewpoint) +to use when drawing the scene. The scene is redrawn after this call. + +<h3>The draw() Method</h3> + +The <tt>draw()</tt> method performs the needed initialization +and does the actual drawing: + +<ul><pre> +void OptimizerWindow::draw() { + if (!context_) { + // This is the first time we've been asked to draw; create the + // Optimizer context for the scene... + + context_ = new csContext(fl_display, fl_visual); + context_->ref(); + context_->makeCurrent(fl_display, fl_window); + + ... perform other context setup as desired ... + + // Then create the draw action to handle drawing things... + + draw_action_ = new csDrawAction; + if (camera_) { + draw_action_->setCamera(camera_); + camera_->draw(draw_action_); + } } - // draw an amazing graphic: - glClear(GL_COLOR_BUFFER_BIT); - glColor3f(.5,.6,.7); - glBegin(GL_POLYGON); - for (int i=0; i<sides; i++) { - double ang = i*2*M_PI/sides; - glVertex3f(cos(ang),sin(ang),0); + + if (!valid()) { + // Update the viewport for this context... + context_->setViewport(0, 0, w(), h()); } - glEnd(); -} -// when you change the data, as in this callback, you must call redraw(): -void sides_cb(Fl_Widget *o, void *p) { - shape_window *sw = (shape_window *)p; - sw->sides = int(((Fl_Slider *)o)->value()); - sw->redraw(); -} + // Clear the window... -int main(int argc, char **argv) { + context_->clear(csContext::COLOR_CLEAR | csContext::DEPTH_CLEAR, + 0.0f, // Red + 0.0f, // Green + 0.0f, // Blue + 1.0f); // Alpha - Fl_Window window(300, 330); + // Then draw the scene (if any)... - shape_window sw(10, 10, 280, 280); - window.resizable(&sw); + if (scene_) + draw_action_->apply(scene_); +} +</pre></ul> - Fl_Hor_Slider slider(50, 295, window.w()-60, 30, "Sides:"); - slider.align(FL_ALIGN_LEFT); - slider.callback(sides_cb,&sw); - slider.value(sw.sides); - slider.step(1); - slider.bounds(3,40); +<H3>The scene() Method</H3> - window.show(argc,argv); - - return Fl::run(); -} -</pre> - -<p>To do your own drawing, you must subclass <a -href=Fl_Gl_Window.html>Fl_Gl_Window</a>. The virtual method <a -href=subclass.html#draw>draw()</a> is called when the window should -update. You can only draw into the window inside a draw() method. -You call the method <a href=Fl_Widget.html#redraw>redraw()</a> on the -window to indicate that draw() needs to be called. It won't actually -be called until <a href=Fl.html#wait>Fl::wait()</a> is called. - -<P>The window may be made a child of another window, as it is here. -This is done by add()ing it to a parent before you show() it. <i>If -you don't want to make a child window, be sure to end() the previous -window!</i> The Fl_Gl_Window constructor automatically does end() so -you don't accidentally add children to it. - -<p>The files <FL/math.h> and <FL/gl.h> are wrappers for the -normal header files. You should use them to port to MSWindows because -the MicroSoft header files have errors or ommisions in them. - -<p><a href = index.html>[back to contents]</a> +The <tt>scene()</tt> method sets the scene to be drawn. The scene is +a collection of 3D objects in a <tt>csGroup</tt>. The scene is redrawn +after this call. + +</BODY> +</HTML> diff --git a/documentation/osissues.html b/documentation/osissues.html index f9cd36991..3e651511e 100644 --- a/documentation/osissues.html +++ b/documentation/osissues.html @@ -1,184 +1,171 @@ <HTML> <BODY> -<H1 ALIGN=RIGHT>F - Operating System Specific Issues</H1 +<H1 ALIGN=RIGHT><A NAME="osissues">F - Operating System Issues</A></H1> -</BODY> -</HTML> -<title>Fltk X-specific interface</title> -<h2>Fltk X-specific interface</h2> +This appendix describes the X and WIN32 specific interfaces in FLTK. -<b>#include <FL/x.H></b> +<h2>X-Specific Interface</h2> -<p>On Unix/X you can include this file to access fltk's X-specific -functions. Be warned that some of the structures and calls in it are -subject to change in future version of fltk. Try to avoid doing this -so your code is portable. +<ul><pre> +#include <FL/x.H> +</pre></ul> -<p><hr> +On X you can include this file to access FLTK's X-specific functions. +Be warned that some of the structures and calls in it are subject to +change in future version of FLTK. Try to avoid doing this so your code +is portable. -<h2>Handling other X events</h2> +<h3>Handling Other X Events</h3> -<a name=add_handler> -</ul><h4><code>void Fl::add_handler(int (*f)(int));</code></h4><ul> +<h4><a name="add_handler">void Fl::add_handler(int (*f)(int))</a></h4> -Install a function to parse unrecognized events. If fltk cannot figure +Installs a function to parse unrecognized events. If FLTK cannot figure out what to do with an event, it calls each of these functions (most recent first) until one of them returns non-zero. If none of them -returns non zero then the event is ignored. +returns non-zero then the event is ignored. -<p>Fltk calls this for any X events it does not recognize, or X events -with a window id that fltk does not recognize. You can look at the X -event with the <a href=#fl_xevent><code>fl_xevent</code></a>. +<p>FLTK calls this for any X events it does not recognize, or X events +with a window id that FLTK does not recognize. You can look at the X +event with the <a href="#fl_xevent"><tt>fl_xevent</tt></a> variable. <p>The argument is zero for unrecognized X events. These handlers are also called for global shortcuts and some other events that the widget they were passed to did not handle. In this case the argument is -non-zero (for instance FL_SHORTCUT). +non-zero (for example <tt>FL_SHORTCUT</tt>). -<a name=fl_xevent> -</ul><h4><code>extern XEvent* fl_xvent;</code></h4><ul> +<h4><a name="fl_xevent">extern XEvent *fl_xvent</a></h4> -The most current X event. +The most recent X event. -<a name=fl_event_time> -</ul><h4><code>extern ulong fl_event_time;</code></h4><ul> +<h4><a name="fl_event_time">extern ulong fl_event_time</a></h4> This is the time stamp from the most recent X event that reported it (not all do). Many X calls (like cut and paste) need this value. -</ul><h4><code>Window fl_xid(const Fl_Window*);</code></h4><ul> +<h4><a name="fl_xid">Window fl_xid(const Fl_Window *)</a></h4> -Returns the xid for a window, or zero if not shown(). +Returns the XID for a window, or zero if not <tt>shown()</tt>. -</ul><h4><code>Fl_Window* fl_find(ulong xid);</code></h4><ul> +<h4><a name="fl_find">Fl_Window *fl_find(ulong xid)</a></h4> -<p>Return the Fl_Window that corresponds to the given xid, or -null if not found. This uses a cache so it is slightly faster than -iterating through the windows yourself. +Returns the <tt>Fl_Window</tt> that corresponds to the given XID, or +<tt>NULL</tt> if not found. This uses a cache so it is slightly faster +than iterating through the windows yourself. -</ul><h4><code>int fl_handle(const XEvent&);</code></h4><ul> +<h4><a name="fl_handle">int fl_handle(const XEvent &)</a></h4> -This call allows you to supply the X events to fltk, which may allow -fltk to cooperate with another toolkit or library. The return value -is true if fltk understood the event (if the window does not belong to -fltk and the add_handler() functions all ignore it this returns +This call allows you to supply the X events to FLTK, which may allow +FLTK to cooperate with another toolkit or library. The return value +is true if FLTK understood the event (if the window does not belong to +FLTK and the <tt>add_handler()</tt> functions all ignore it this returns false). <p>Besides feeding events your code should call <a -href=Fl.html#flush>Fl::flush()</a> periodically so that fltk redraws -it's windows. +href="#flush"><tt>Fl::flush()</tt></a> periodically so that FLTK +redraws its windows. <p>This function will call the callback functions. It will not return until they complete. In particular if a callback pops up a modal -window (by calling <a href=utilities.html#fl_ask>fl_ask()</a>, for +window (by calling <a href="#fl_ask"><tt>fl_ask()</tt></a>, for instance) it will not return until the modal function returns. -</ul> -<p><hr> +<h3>Drawing using Xlib</h3> -<a name=draw> -<h2>Drawing using Xlib</h2> +The following global variables are set before +<tt>Fl_Widget::draw()</tt> is called, or by <a +href="#Fl_Window.make_current"><tt>Fl_Window::make_current()</tt></a>: -</ul><h4><code> -extern Display* fl_display;<br> -extern Window fl_window;<br> -extern GC fl_gc;<br> -extern int fl_screen;<br> -extern XVisualInfo* fl_visual;<br> -extern Colormap fl_colormap;</code></h4><ul> +<ul><pre> +extern Display *fl_display; +extern Window fl_window; +extern GC fl_gc; +extern int fl_screen; +extern XVisualInfo *fl_visual; +extern Colormap fl_colormap; +</pre></ul> -These global variables are set before Fl_Widget::draw() is called, or -by <a href=Fl_Window.html#make_current>Fl_Window::make_current()</a> You must use them to produce Xlib calls. Don't attempt to change them. A typical X drawing call is written like this: -<ul><p><code>XDrawSomething(fl_display, fl_window, fl_gc, ...);</code></ul> +<ul><pre> +XDrawSomething(fl_display, fl_window, fl_gc, ...); +</pre></ul> -<p>Other information such as the position or size of the X window can be +Other information such as the position or size of the X window can be found by looking at <a -href=Fl_Window.html#make_current><code>Fl_Window::current()</code></a>, -which returns a pointer to the Fl_Window being drawn. - -</ul><h4><code>unsigned long fl_xpixel(Fl_Color i);</code></h4><ul> +href="#Fl_Window.make_current"><tt>Fl_Window::current()</tt></a>, which +returns a pointer to the <tt>Fl_Window</tt> being drawn. -Returns the X pixel number used to draw the given fltk color index. -This is the X pixel that <a href=Draw.html#fl_color>fl_color(i)</a> would use. +<h4><a name="fl_xpixel">unsigned long fl_xpixel(Fl_Color i)<br> +unsigned long fl_xpixel(uchar r, uchar g, uchar b)</a></h4> -</ul><h4><code>unsigned long fl_xpixel(uchar r, uchar g, uchar -b);</code></h4><ul> +Returns the X pixel number used to draw the given FLTK color index or +RGB color. This is the X pixel that <a +href="#fl_color"><tt>fl_color()</tt></a> would use. -Return the X pixel number used to draw the given rgb color. This is -the X pixel that <a href=Draw.html#fl_rgbcolor>fl_color(r,g,b)</a> would use. - -</ul><h4><code>extern XFontStruct* fl_xfont;</code></h4><ul> +<h4><a name="fl_xfont">extern XFontStruct *fl_xfont</a></h4> Points at the font selected by the most recent <a -href=Draw.html#fl_font>fl_font(font,size)</a>. This is not -necessarily the current font of fl_gc (that's not set until <a -href=Draw.html#text>fl_draw(const char*,...)</a> is called). - -</ul> +href="#fl_font"><tt>fl_font()</tt></a>. This is not necessarily the +current font of <tt>fl_gc</tt>, which is not set until <a +href="#fl_draw"><tt>fl_draw()</tt></a> is called. -<p><hr> +<h3>Changing the Display, Screen, or X Visual</h3> -<a name=visuals> -<h2>Changing the display, screen, or X visual</h2> +FLTK uses only a single display, screen, X visual, and X colormap. This +greatly simplifies its internal structure and makes it much smaller and +faster. You can change which it uses by setting global variables +<i>before the first <tt>Fl_Window::show()</tt> is called</i>. You may +also want to call <a href="#visual">Fl::visual()</a>, which is a +portable interface to get a full color and/or double buffered visual. -<p>Fltk uses only a single display, screen, X visual, and X colormap. -This greatly simplifies it's internal structure and makes it much -smaller and faster. You can change which it uses by setting global -variables <i>before the first Fl_Window::show() is called</i>. -You may also want to call <a -href=Fl.html#visual>Fl::visual(int)</a>, which is a portable interface -to get a full color and/or double buffered visual. - -</ul><h4><code>int Fl::display(const char *)</code></h4><ul> +<h4><a name="display">int Fl::display(const char *)</a></h4> Set which X display to use. This actually does -<code>setenv("DISPLAY", x)</code> so that child programs will -display on the same screen if called with exec(). This must be done -before the display is opened. This call is provided on MSWindows, but -it just sets the environment variable and has no other effect. +<tt>putenv("DISPLAY=...")</tt> so that child programs will display on +the same screen if called with <tt>exec()</tt>. This must be done +before the display is opened. This call is provided under WIN32 but +it has no effect. -</ul><h4><code>extern Display* fl_display;</code></h4><ul> +<h4><a name="fl_display">extern Display *fl_display</a></h4> The open X display. This is needed as an argument to most Xlib calls. -Don't attempt to change it! This is zero before the display is opened. +Don't attempt to change it! This is <tt>NULL</tt> before the display is opened. -</ul><h4><code>void fl_open_display();</code></h4><ul> +<h4><a name="fl_open_display">void fl_open_display()</a></h4> -Open the display. Does nothing if it is already open. This will make -sure <code>fl_display</code> is non-zero. You should call this if you +Opens the display. Does nothing if it is already open. This will make +sure <tt>fl_display</tt> is non-zero. You should call this if you wish to do X calls and there is a chance that your code will be called -before the first show() of a window. +before the first <tt>show()</tt> of a window. -<p>This may call Fl::abort() if there is an error opening the display. +<p>This may call <tt>Fl::abort()</tt> if there is an error opening the display. -</ul><h4><code>void fl_close_display();</code></h4><ul> +<h4><a name="fl_close_display">void fl_close_display()</a></h4> This closes the X connection. You do <i>not</i> need to call this to exit, and in fact it is faster to not do so! It may be useful to call this if you want your program to continue without the X connection. -You cannot open the display again, and probably cannot call any fltk +You cannot open the display again, and probably cannot call any FLTK functions. -</ul><h4><code>extern int fl_screen;</code></h4><ul> +<h4><a name="fl_screen">extern int fl_screen</a></h4> -Which screen to use. This is set by fl_open_display() to the default -screen. You can change it by setting this to a different value -immediately afterwards. It can also be set by changing the last -number in the Fl::display() string: host:0,#. +Which screen number to use. This is set by <tt>fl_open_display()</tt> +to the default screen. You can change it by setting this to a +different value immediately afterwards. It can also be set by changing +the last number in the <tt>Fl::display()</tt> string to "host:0,#". -</ul><h4><code>extern XVisualInfo* fl_visual;<br> -extern Colormap fl_colormap;</code></h4><ul> +<h4><a name="fl_visual">extern XVisualInfo *fl_visual</a><br> +<a name="fl_colormap">extern Colormap fl_colormap</a></h4> -<p>The visual and colormap that fltk will use for all windows. These -are set by fl_open_display() to the default visual and colormap. You -can change them before calling show() on the first window. Typical -code for changing the default visual: +The visual and colormap that FLTK will use for all windows. These +are set by <tt>fl_open_display()</tt> to the default visual and colormap. You +can change them before calling <tt>show()</tt> on the first window. Typical +code for changing the default visual is: -<ul><code><pre> +<ul><pre> Fl::args(argc, argv); // do this first so $DISPLAY is set fl_open_display(); fl_visual = find_a_good_visual(fl_display, fl_screen); @@ -186,50 +173,32 @@ if (!fl_visual) Fl::abort("No good visual"); fl_colormap = make_a_colormap(fl_display, fl_visual->visual, fl_visual->depth); // it is now ok to show() windows: window->show(argc, argv); -</pre></code></ul> - -</ul> +</pre></ul> -<p><hr> -<a name=window> -<h2>Using a subclass of Fl_Window for special X stuff</h2> +<h3>Using a Subclass of Fl_Window for Special X Stuff</h3> -Fltk can manage an X window on a different screen, visual and/or -colormap, you just can't use fltk's drawing routines to draw into it. -But you can write your own draw() method that uses Xlib calls only. +FLTK can manage an X window on a different screen, visual and/or +colormap, you just can't use FLTK's drawing routines to draw into it. +But you can write your own <tt>draw()</tt> method that uses Xlib +(and/or OpenGL) calls only. -<p>Fltk can also manage xid's provided by other libraries or programs, +<p>FLTK can also manage XID's provided by other libraries or programs, and call those libraries when the window needs to be redrawn. <p>To do this, you need to make a subclass of <a -href=Fl_Window.html>Fl_Window</a> and override some of these virtual +href="#Fl_Window"><tt>Fl_Window</tt></a> and override some of these virtual functions: -</ul><h4><code>virtual void Fl_Window::show()</code></h4><ul> - -<p>If the window is already shown() this must cause it to be raised, -this can usually be done by calling Fl_Window::show(). If not shown() -your implementation must call either Fl_X::set_xid() or -Fl_X::make_xid(): - -<h4><code>Fl_X* Fl_X::set_xid(Fl_Window*, Window xid);</code></h4><ul> - -Allocate a hidden structure called an Fl_X, put the xid into it, and -set a pointer to it from the Fl_Window. This causes -Fl_Window::shown() to return true. +<h4>virtual void Fl_Window::show()</h4> -</ul><h4><code>void Fl_X::make_xid(Fl_Window*, XVisualInfo* = -fl_visual, Colormap = fl_colormap);</code></h4><ul> +If the window is already <tt>shown()</tt> this must cause it to be raised, +this can usually be done by calling <tt>Fl_Window::show()</tt>. If not <tt>shown()</tt> +your implementation must call either <tt>Fl_X::set_xid()</tt> or +<tt>Fl_X::make_xid()</tt>. -This static method does the most onerous parts of creating an X window, -including setting the label, resize limitations, etc. It then does -set_xid with this new window and maps the window. - -</ul> +<p>An example: -<p>Example: - -<pre> +<ul><pre> void MyWindow::show() { if (shown()) {Fl_Window::show(); return;} // you must do this! fl_open_display(); // necessary if this is first window @@ -243,47 +212,60 @@ void MyWindow::show() { } Fl_X::make_xid(this, visual, colormap); } -</pre> +</pre></ul> + +<h4>Fl_X *Fl_X::set_xid(Fl_Window *, Window xid)</h4> + +Allocate a hidden structure called an <tt>Fl_X</tt>, put the XID into it, and +set a pointer to it from the <tt>Fl_Window</tt>. This causes +<tt>Fl_Window::shown()</tt> to return true. + +<h4>void Fl_X::make_xid(Fl_Window *, XVisualInfo *= fl_visual, Colormap = fl_colormap)</h4> + +This static method does the most onerous parts of creating an X window, +including setting the label, resize limitations, etc. It then does +<tt>Fl_X::set_xid()</tt> with this new window and maps the window. -</ul><h4><code>virtual void Fl_Window::flush()</code></h4><ul> +<h4>virtual void Fl_Window::flush()</h4> -This virtual function is called by Fl::flush() to update the window. -For fltk's own windows it does this by setting the global variables -fl_window and fl_gc and then calling the draw() method. For your own -windows you might just want to put all the drawing code in here. +This virtual function is called by <tt>Fl::flush()</tt> to update the +window. For FLTK's own windows it does this by setting the global +variables <tt>fl_window</tt> and <tt>fl_gc</tt> and then calling the +<tt>draw()</tt> method. For your own windows you might just want to +put all the drawing code in here. -<p>The X region that is a combination of all damage() calls done so -far is in <code>Fl_X::i(this)->region</code>. If null then -you should redraw the entire window. The undocumented function -<code>fl_clip_region(XRegion)</code> will initialize the fl clip stack -with a region or null for no clipping. You must set region to null -afterwards as fl_clip_region() now owns it and will delete it when -done. +<p>The X region that is a combination of all <tt>damage()</tt> calls +done so far is in <tt>Fl_X::i(this)->region</tt>. If <tt>NULL</tt> +then you should redraw the entire window. The undocumented function +<tt>fl_clip_region(XRegion)</tt> will initialize the FLTK clip stack +with a region or <tt>NULL</tt> for no clipping. You must set region to +<tt>NULL</tt> afterwards as <tt>fl_clip_region()</tt> now owns it and +will delete it when done. -<p>If <code>damage()==2</code> then only X expose events have -happened. This may be useful if you have an undamaged image (such as -a backing buffer) around. +<p>If <tt>damage() & FL_DAMAGE_EXPOSE</tt> then only X expose events +have happened. This may be useful if you have an undamaged image (such +as a backing buffer) around. <p>Here is a sample where an undamaged image is kept somewhere: -<pre> +<ul><pre> void MyWindow::flush() { fl_clip_region(Fl_X::i(this)->region); Fl_X::i(this)->region = 0; if (damage() != 2) {... draw things into backing store ...} ... copy backing store to window ... } -</pre> +</pre></ul> -</ul><h4><code>virtual void Fl_Window::hide()</code></h4><ul> +<h4>virtual void Fl_Window::hide()</h4> -Destroy the window server copy of the window. Usually you will -destroy contexts, pixmaps, or other resources used by the window, and -then call Fl_Window::hide() to get rid of the main window identified -by xid(). If you override this, you must also override the destructor -as shown: +Destroy the window server copy of the window. Usually you will destroy +contexts, pixmaps, or other resources used by the window, and then call +<tt>Fl_Window::hide()</tt> to get rid of the main window identified by +<tt>xid()</tt>. If you override this, you must also override the +destructor as shown: -<pre> +<ul><pre> void MyWindow::hide() { if (mypixmap) { XFreePixmap(fl_display,mypixmap); @@ -291,165 +273,183 @@ void MyWindow::hide() { } Fl_Window::hide(); // you must call this } -</pre> +</pre></ul> -</ul><h4><code>virtual void Fl_Window::~Fl_Window()</code></h4><ul> +<h4>virtual void Fl_Window::~Fl_Window()</h4> -Because of the way C++ works, if you override hide() you <i>must</i> -override the destructor as well (otherwise only the base class hide() +Because of the way C++ works, if you override <tt>hide()</tt> you <i>must</i> +override the destructor as well (otherwise only the base class <tt>hide()</tt> is called): -<pre> +<ul><pre> MyWindow::~MyWindow() { hide(); } -</pre> +</pre></ul> -</ul> +<h3>Setting the Icon of a Window</h3> -<p><a href = index.html>(back to contents)</a> -<title>Fltk MSWindows-specific interface</title> -<h2>#include <FL/x.H><br> -Fltk MSWindows-specific interface</h2> +FLTK currently supports setting a window's icon *before* it is shown using +the <tt>Fl_Window::icon()</tt> method. -The <FL/x.H> header file defines the interface to fltk's -MSWindows-specific functions. Be warned that some of the structures -and calls in it are subject to change in future version of fltk. Try -to avoid doing this so your code is portable. +<h4>void Fl_Window::icon(char *)</h4> + +Sets the icon for the window to the passed pointer. You will need to +cast the icon <tt>Pixmap</tt> to a <tt>char *</tt> when calling this +method. To set the icon using a bitmap compiled with your application +use: + +<ul><pre> +#include "icon.xbm" + +Pixmap p = XCreatePixmapFromBitmapData(fl_display, + DefaultRootWindow(fl_display), icon_bits, + icon_width, icon_height, + BlackPixel(fl_display, DefaultScreen(fl_display)), + WhitePixel(fl_display, DefaultScreen(fl_display)), + DefaultDepth(fl_display, DefaultScreen(fl_display))) + +window->icon((char *)p); +</ul></pre> -<p><hr> +<h2>WIN32-Specific Interface</h2> -<h2>Handling other MSWindows messages</h2> +<ul><pre> +#include <FL/x.H> +</pre></ul> -<p>A single WNDCLASSEX called "FLTK" is created. All -Fl_Windows are of this class. This window class is created the first -time Fl_Window::show() is called. +The <tt><FL/x.H></tt> header file defines the interface to FLTK's +WIN32-specific functions. Be warned that some of the structures +and calls in it are subject to change in future version of FLTK. Try +to avoid doing this so your code is portable. + +<h3>Handling Other WIN32 Messages</h3> + +By default a single WNDCLASSEX called "FLTK" is created. All +<tt>Fl_Windows</tt> are of this class unless you use +<tt>Fl_Window::xclass()</tt>. The window class is created the first +time <tt>Fl_Window::show()</tt> is called. -<p>You can probably combine fltk with other libraries that make their -own MSWindows window classes. The easiest way is to call Fl::wait(), it -will call DispatchMessage for all messages to the other windows. If +<p>You can probably combine FLTK with other libraries that make their +own WIN32 window classes. The easiest way is to call <tt>Fl::wait()</tt>, it +will call <tt>DispatchMessage</tt> for all messages to the other windows. If necessary you can let the other library take over (as long as it calls -DispatchMessage()), but you will have to arrange for the function -Fl::flush() to be called regularily (otherwise widgets will not -update), and timeouts and the idle function will not work. +<tt>DispatchMessage()</tt>), but you will have to arrange for the function +<tt>Fl::flush()</tt> to be called regularily so that widgets are updated, +timeouts are handled, and the idle functions are called. -<a name=fl_msg> -</ul><h4><code>extern MSG fl_msg;</code></h4><ul> +<h4><a name="fl_msg">extern MSG fl_msg</a></h4> -The most recent message read by GetMessage (which is called by -<a href=Fl.html#wait>Fl::wait()</a>. This may not be the most recent -message sent to an fltk window, because silly MSWindows calls the +The most recent message read by <tt>GetMessage</tt> (which is called by +<a href="#wait"><tt>Fl::wait()</tt></a>. This may not be the most +recent message sent to an FLTK window, because silly WIN32 calls the handle procedures directly for some events (sigh). -<a name=add_handler> -</ul><h4><code>void Fl::add_handler(int (*f)(int));</code></h4><ul> +<h4><a name="WIN32.add_handler">void Fl::add_handler(int (*f)(int))</a></h4> -Install a function to parse unrecognized messages sent to fltk -windows. If fltk cannot figure out what to do with a message, it +Install a function to parse unrecognized messages sent to FLTK +windows. If FLTK cannot figure out what to do with a message, it calls each of these functions (most recent first) until one of them returns non-zero. The argument passed to the fuctions is zero. If -all the handlers return zero then fltk calls DefWindowProc(...). - -</ul><h4><code>HWND fl_xid(const Fl_Window*);</code></h4><ul> - -Returns the window handle for a Fl_Window, or zero if not shown(). +all the handlers return zero then FLTK calls <tt>DefWindowProc()</tt>. -</ul><h4><code>Fl_Window* fl_find(HWND xid)</code></h4><ul> +<h4><a name="WIN32.fl_xid">HWND fl_xid(const Fl_Window *)</a></h4> -<p>Return the Fl_Window that corresponds to the given window handle, -or null if not found. This uses a cache so it is slightly faster than -iterating through the windows yourself. +Returns the window handle for a <tt>Fl_Window</tt>, or zero if not +<tt>shown()</tt>. -</ul> +<h4><a name="WIN32.fl_find">Fl_Window *fl_find(HWND xid)</a></h4> -<p><hr> +Return the <tt>Fl_Window</tt> that corresponds to the given window +handle, or <tt>NULL</tt> if not found. This uses a cache so it is +slightly faster than iterating through the windows yourself. -<a name=gdi> -<h2>Drawing things using the MSWindows GDI</h2> +<h3>Drawing Things Using the WIN32 GDI</h3> -<p>When the virtual function Fl_Widget::draw() is called, fltk has +When the virtual function <tt>Fl_Widget::draw()</tt> is called, FLTK has stashed in some global variables all the silly extra arguments you need to make a proper GDI call. These are: -</ul><h4><code> -extern HINSTANCE fl_display;<br> -extern HWND fl_window;<br> -extern HDC fl_gc;<br> -COLORREF fl_RGB();<br> -HPEN fl_pen();<br> -HBRUSH fl_brush();</code></h4><ul> - -These global variables are set before draw() is called, or by <a -href=Fl_Window.html#make_current>Fl_Window::make_current()</a> You can +<ul><pre> +extern HINSTANCE fl_display; +extern HWND fl_window; +extern HDC fl_gc; +COLORREF fl_RGB(); +HPEN fl_pen(); +HBRUSH fl_brush(); +</pre></ul> + +These global variables are set before <tt>draw()</tt> is called, or by <a +href="#Fl_Window.make_current"><tt>Fl_Window::make_current()</tt></a>. You can refer to them when needed to produce GDI calls. Don't attempt to change them. The functions return GDI objects for the current color -set by fl_color(), these are created as needed and cached. A typical +set by <tt>fl_color()</tt> and are created as needed and cached. A typical GDI drawing call is written like this: -<ul><p><code>DrawSomething(fl_gc, ..., fl_brush());</code></ul> - -<p>It may also be useful to refer to <a -href=Fl_Window.html#make_current><code>Fl_Window::current()</code></a> -to get the window's size or position. - -</ul> -<p><hr> -<h2>How to not get a MSDOS console window</h2> +<ul><pre> +DrawSomething(fl_gc, ..., fl_brush()); +</pre></ul> -MSWindows has a really stupid mode switch stored in the executables that -controls whether or not to make a console window (hint to Mr Gates: -why not leave it hidden until the program prints something?). +It may also be useful to refer to <a +href="#Fl_Window.make_current"><tt>Fl_Window::current()</tt></a> to get +the window's size or position. -<p>To not produce a "console" window when you run your program add the -following secret incantation to the Micro$oft linker: +<h3>Setting the Icon of a Window</h3> -<p><pre> /SUBSYSTEM:WINDOWS /ENTRY:mainCRTStartup</pre> +FLTK currently supports setting a window's icon *before* it is shown using +the <tt>Fl_Window::icon()</tt> method. -<p>Unfortunately this seems to completely disable stdin/stdout, even -if you run the program from a console. So don't do this until you -have debugged your program! +<h4>void Fl_Window::icon(char *)</h4> -<p><hr> -<h2>Other hints</h2> +Sets the icon for the window to the passed pointer. You will need to +cast the <tt>HICON</tt> handle to a <tt>char *</tt> when calling this +method. To set the icon using an icon resource compiled with your +application use: -<p>I use capital C as the extension for c++ source code, for instace -for Fluid output. Unfortunately there is no way to convince VC++ to -use this except to tell it to compile *everything* using C++ by -putting the switch "/TP" in the options. This makes it impossible to -combine old C code and fltk code. +<ul><pre> +window->icon((char *)LoadIcon(fl_display, MAKEINTRESOURCE(IDI_ICON))); +</ul></pre> -<p><hr> -<h2>Known bugs</h2> +<h3>How to Not Get a MSDOS Console Window</h3> -<p>If program is deactivated, Fl::wait() does not return until it is -activated again, even though many events are delivered to the program. -This can cause idle background processes to stop unexpectedly. This -also happens while the user is dragging or resizing windows or -otherwise holding the mouse down. I was forced to remove most of the -efficiency fltk uses for redrawing in order to get windows to update -while being moved. This is a design error in MSWindows and probably -impossible to get around. +WIN32 has a really stupid mode switch stored in the executables that +controls whether or not to make a console window. -<p>Fl_Gl_Window::can_do_overlay() returns true until the first time it -attempts to draw an overlay, and then correctly returns whether or not -there is overlay hardware. - -<p>Cut text contains ^J rather than ^M^J to break lines. This is a -feature, not a bug. +<p>To always get a console window you simply create a console +application (the "/SUBSYSTEM:CONSOLE" option for the linker). For a +GUI-only application create a WIN32 application (the +"/SUBSYSTEM:WINDOWS" option for the linker). -<p>I can't seem to get SetCapture (used by Fl::grab()) to work, and I -can't find a way to stop the main window title from turning gray while -menus are popped up. +<p>FLTK includes a <tt>WinMain()</tt> function that calls the ANSI +standard <tt>main()</tt> entry point for you. <i>This function creates +a console window when you use the debug version of the library.</i> -<p>glpuzzle program does not animate unless you resize it first. Unknown why. +<p>WIN32 applications without a console cannot write to <tt>stdout</tt> or +<tt>stderr</tt>, even if they are run from a console window. Any output +is silently thrown away. -<p>Fl_Window::fullscreen() not implemented (should take over the screen -without a title bar). Currently does maximize instead. +<h3>Known Bugs</h3> -<p>Import .bmp files into fluid. Wonko has the specs. +If a program is deactivated, <tt>Fl::wait()</tt> does not return until +it is activated again, even though many events are delivered to the +program. This can cause idle background processes to stop +unexpectedly. This also happens while the user is dragging or resizing +windows or otherwise holding the mouse down. I was forced to remove +most of the efficiency FLTK uses for redrawing in order to get windows +to update while being moved. This is a design error in WIN32 and +probably impossible to get around. -<p>Can't set icon of windows. +<p><tt>Fl_Gl_Window::can_do_overlay()</tt> returns true until the first +time it attempts to draw an overlay, and then correctly returns whether +or not there is overlay hardware. +<p>Cut text contains ^J rather than ^M^J to break lines. This is a +feature, not a bug. +<p><tt>SetCapture</tt> (used by <tt>Fl::grab()</tt>) doesn't work, and +the main window title bar turns gray while menus are popped up. +<p>FLUID does not support BMP files yet. +</BODY> +</HTML> diff --git a/documentation/preface.html b/documentation/preface.html index 5be3d0f99..61e06de5f 100644 --- a/documentation/preface.html +++ b/documentation/preface.html @@ -1,7 +1,7 @@ <HTML> <HEAD> <META NAME="Author" CONTENT="Michael Sweet"> - <META NAME="Copyright" CONTENT="Copyright 1998 by Bill Spizak and Others."> + <META NAME="Copyright" CONTENT="Copyright 1998-1999 by Bill Spizak and Others."> <META NAME="DocNumber" CONTENT="Revision 0"> <TITLE>FLTK 1.0 Programming Manual</TITLE> </HEAD> @@ -23,15 +23,18 @@ This manual is organized into the following chapters and appendices: <LI><A HREF="#basics">Chapter 2 - FLTK Basics</A> <LI><A HREF="#common">Chapter 3 - Common Widgets and Attributes</A> <LI><A HREF="#editor">Chapter 4 - Designing a Simple Text Editor</A> - <LI><A HREF="#subclasseing">Chapter 5 - Extending and Adding Widgets</A> - <LI><A HREF="#fluid">Chapter 6 - Programming With FLUID</A> - <LI><A HREF="#opengl">Chapter 7 - Using OpenGL</A> + <LI><A HREF="#drawing">Chapter 5 - Drawing Things in FLTK</A> + <LI><A HREF="#events">Chapter 6 - Handling Events</A> + <LI><A HREF="#subclassing">Chapter 7 - Extending and Adding Widgets</A> + <LI><A HREF="#fluid">Chapter 8 - Programming With FLUID</A> + <LI><A HREF="#opengl">Chapter 9 - Using OpenGL</A> <LI><A HREF="#widgets">Appendix A - Widget Reference</A> <LI><A HREF="#functions">Appendix B - Function Reference</A> <LI><A HREF="#enumerations">Appendix C - Enumeration Reference</A> <LI><A HREF="#glut">Appendix D - GLUT Compatibility</A> <LI><A HREF="#forms">Appendix E - Forms Compatibility</A> - <LI><A HREF="#license">Appendix F - Software License</A> + <LI><A HREF="#license">Appendix F - Operating System Issues</A> + <LI><A HREF="#license">Appendix G - Software License</A> </UL> <H2>Conventions</H2> @@ -63,7 +66,7 @@ The following abbreviations are used in this manual: <H2>Copyrights and Trademarks</H2> -FLTK is Copyright 1998 by Bill Spitzak and others. Use and distribution of FLTK is +FLTK is Copyright 1998-1999 by Bill Spitzak and others. Use and distribution of FLTK is governed by the GNU Library General Public License, located in <A HREF=#license>Appendix D</A>. diff --git a/documentation/subclassing.html b/documentation/subclassing.html index 414cca67b..7ed03ed7a 100644 --- a/documentation/subclassing.html +++ b/documentation/subclassing.html @@ -1,427 +1,338 @@ <HTML> <BODY> -<H1 ALIGN=RIGHT><A NAME="subclassing">5 - Adding and Extending Widgets</A></H1> +<H1 ALIGN=RIGHT><A NAME="subclassing">7 - Adding and Extending Widgets</A></H1> -This chapter describes how to add your own widgets or extend existing widgets in FLTK. +This chapter describes how to add your own widgets or extend existing +widgets in FLTK. <H2>Subclassing</H2> -<H2>Adding Syntax Highlighting to the Fl_Input Widget</H2> +New widgets are created by <i>subclassing</i> an existing FLTK widget, +typically <tt>Fl_Widget</tt> for controls and <tt>Fl_Group</tt> for +containers. -<H2>Drawing Functions</H2> +<p>A control widget typically interacts with the user to receive and/or +display a value of some sort. -<H3>Lines, Rectangles, and Curves, Oh, My!</H3> +<p>A container widget holds a list of child widgets and handles moving, +sizing, showing, or hiding them as needed. <tt>Fl_Group</tt> is the +main container widget class in FLTK, and all of the other containers +(<tt>Fl_Pack</tt>, <tt>Fl_Scroll</tt>, <tt>Fl_Tabs</tt>, <tt>Fl_Tile</tt>, +and <tt>Fl_Window</tt>) are subclasses of it. -<H3>Colors</H3> +<p>You can also subclass other existing widgets to provide a different look +or user-interface. For example, the button widgets are all subclasses of +<tt>Fl_Button</tt> since they all interact with the user via a mouse button +click. The only difference is the code that draws the face of the button. -<H3>Fonts</H3> +<H2>Making a Subclass of Fl_Widget</H2> -<H3>Images</H3> +Your subclasses can directly descend from <tt>Fl_Widget</tt> or any +subclass of <tt>Fl_Widget</tt>. <tt>Fl_Widget</tt> has only four +virtual methods, and overriding some or all of these may be necessary. -<H2><A NAME="Fl_Table">Writing a Table Widget</A></H2> +<H2>The Constructor</H2> -<H3>Methods</H3> +The constructor should access the following arguments: -<H3>Cut and Paste Support</H3> - -</BODY> -</HTML> -<title>Cut & paste</title> -<h2>Cut & paste</h2> - -Fltk provides routines to cut and paste ASCII text (in the future this -may be UTF-8) between applications. It may be possible to cut/paste -non-ascii data under X by using <a -href=events.html#add_handler>Fl::add_handler()</a>. - -</ul><h4><code>void Fl::paste(Fl_Widget *receiver)</code></h4><ul> - -<P>Set things up so the receiver widget will be called with an <a -href=events.html#paste>FL_PASTE</a> event some time in the future. -The reciever should be prepared to be called <i>directly</i> by this, -or for it to happen <i>later</i>, or possibly <i>not at all</i>. This -allows the window system to take as long as necessary to retrieve the -paste buffer (or even to screw up completely) without complex and -error-prone synchronization code in fltk. +<ul><pre> +MyClass(int x, int y, int w, int h, const char *label = 0); +</pre></ul> -</ul><h4><code>void Fl::selection(Fl_Widget *owner, const char *stuff, int len); -</code></h4><ul> +This will allow the class to be used in <a href="#fluid">Fluid</a> without +problems. -<p>Change the current selection. The block of text is copied to an -internal buffer by Fltk (be careful if doing this in response to an -FL_PASTE as this <i>may</i> be the same buffer returned by -event_text()). The selection_owner is set to the passed owner -(possibly sending FL_SELECTIONCLEAR to the previous owner). +<p>The constructor must call the constructor for the base class and +pass the same arguments: -</ul><h4><code>const char* Fl::selection(); -<br>int Fl::selection_length();</code></h4><ul> +<ul><pre> +MyClass::MyClass(int x, int y, int w, int h, const char *label) +: Fl_Widget(x, y, w, h, label) { +// do initialization stuff... +} +</pre></ul> -You can look at the buffer containing the current selection. Contents -of this buffer are undefined if this program does not own the X -selection. +<tt>Fl_Widget</tt>'s protected constructor sets <tt>x()</tt>, +<tt>y()</tt>, <tt>w()</tt>, <tt>h()</tt>, and <tt>label()</tt> to the +passed values and initializes the other instance variables to: + +<ul><pre> +type(0); +box(FL_NO_BOX); +color(FL_GRAY); +selection_color(FL_GRAY); +labeltype(FL_NORMAL_LABEL); +labelstyle(FL_NORMAL_STYLE); +labelsize(FL_NORMAL_SIZE); +labelcolor(FL_BLACK); +align(FL_ALIGN_CENTER); +callback(default_callback,0); +flags(ACTIVE|VISIBLE); +</pre></ul> -</ul><h4><code>Fl_Widget *Fl::selection_owner() const; -<br>void Fl::selection_owner(Fl_Widget *);</code></h4><ul> +<H2>Protected Methods of Fl_Widget</H2> -<p>The single-argument selection_owner(x) call can be used to move the -selection to another widget or to set the owner to NULL, without -changing the actual text of the selection. FL_SELECTIONCLEAR is sent -to the old selection owner, if any. +The following methods are provided for subclasses to use: +<ul> + <li><a name="#clear_visible">clear_visible</a> + <li><a name="#damage">damage</a> + <li><a name="#draw_box">draw_box</a> + <li><a name="#draw_label">draw_label</a> + <li><a name="#set_flag">set_flag</a> + <li><a name="#set_visible">set_visible</a> + <li><a name="#test_shortcut">test_shortcut</a> + <li><a name="#type">type</a> </ul> -<p><i>Copying the buffer every time the selection is changed is -obviously wasteful, especially for large selections. I expect an -interface will be added in a future version to allow the selection to -be made by a callback function. The current interface will be -emulated on top of this.</i> +<H3><a name="damage">void Fl_Widget::damage(uchar mask)<br> +void Fl_Widget::damage(uchar mask, int x, int y, int w, int h)<br> +uchar Fl_Widget::damage()</a></H3> -<title>Making a subclass of Fl_Widget</title> -</ul><h2>Making a subclass of Fl_Widget</h2> +The first form indicates that a partial update of the object is +needed. The bits in mask are OR'd into <tt>damage()</tt>. Your +<tt>draw()</tt> routine can examine these bits to limit what it is +drawing. The public method <tt>Fl_Widget::redraw()</tt> simply does +<tt>Fl_Widget::damage(FL_DAMAGE_ALL)</tt>. -<p>Your subclasses can directly descend from Fl_Widget or any -subclass of Fl_Widget. Fl_Widget has only four virtual methods, and -overriding some or all of these may be necessary. +<p>The second form indicates that a region is damaged. If only these +calls are done in a window (no calls to <tt>damage(n)</tt>) then FLTK +will clip to the union of all these calls before drawing anything. +This can greatly speed up incremental displays. The mask bits are or'd +into <tt>damage()</tt> unless this is a <tt>Fl_Window</tt> widget. -<p>Parts of this document: +<p>The third form returns the bitwise-OR of all <tt>damage(n)</tt> +calls done since the last <tt>draw()</tt>. The public method +<tt>redraw()</tt> does <tt>damage(FL_DAMAGE_ALL)</tt>, but the +implementation of your widget can call the private <tt>damage(n)</tt>. -<ul> +<H3><a name="draw_box">void Fl_Widget::draw_box() const<br> +</a>void Fl_Widget::draw_box(Fl_Boxtype b, ulong c) const</H3> -<li><a href=#constructor>Constructing your Fl_Widget</a> +The first form draws this widget's <tt>box()</tt>, using the dimensions +of the widget. -<li><a href=#protected>Protected methods of Fl_Widget</a> +The second form uses <tt>b</tt> as the box type and <tt>c</tt> as the +color for the box. -<li>Virtual functions to override: - -<ul> +<H3><a name="draw_label">void Fl_Widget::draw_label() const<br> +void Fl_Widget::draw_label(int x, int y, int w, int h) const<br> +void Fl_Widget::draw_label(int x, int y, int w, int h, Fl_Align align) const</a></H3> -<li><code><a href=#handle>int Fl_Widget::handle(int -event);</a></code> - -<li><code><a href=#draw>void Fl_Widget::draw();</a></code> +This is the usual function for a <tt>draw()</tt> method to call to draw +the widget's label. It does not draw the label if it is supposed to be +outside the box (on the assumption that the enclosing group will draw +those labels). -<li><code><a href=#resize>void -Fl_Widget::resize(int,int,int,int);</a></code> +<p>The second form uses the passed bounding box instead of the widget's +bounding box. This is useful so "centered" labels are aligned with some +feature, such as a moving slider. -<li><code><a href=#destructor>Fl_Widget::~Fl_Widget();</a></code> +<p>The third form draws the label anywhere. It acts as though +<tt>FL_ALIGN_INSIDE</tt> has been forced on, the label will appear +inside the passed bounding box. This is designed for parent groups to +draw labels with. -</ul> +<H3><a name="set_flag">void Fl_Widget::set_flag(SHORTCUT_LABEL)</a></H3> -<li><a href=#composite>Making a Composite/Group Widget</a> +If your constructor calls this it modifies <tt>draw_label()</tt> so +that '&' characters cause an underscore to be printed under the next +letter. -<li><a href=#window>Making a subclass of Fl_Window</a> +<H3><a name="set_visible">void Fl_Widget::set_visible()</a><br> +<a name="clear_visible">void Fl_Widget::clear_visible()</a></H3> -</ul> +Fast inline versions of <tt>Fl_Widget::hide()</tt> and +<tt>Fl_Widget::show()</tt>. These do not send the <tt>FL_HIDE</tt> and +<tt>FL_SHOW</tt> events to the widget. -<a name=constructor> -<h2>Constructing your Fl_Widget</h2> +<H3><a name="test_shortcut">int Fl_Widget::test_shortcut() const<br> +static int Fl_Widget::test_shortcut(const char *s)</a></H3> -I recommend your constructor be of this form: +The first version tests <tt>Fl_Widget::label()</tt> against the current +event (which should be a <tt>FL_SHORTCUT</tt> event). If the label +contains a '&' character and the character after it matches the key +press, this returns true. This returns false if the +<tt>SHORTCUT_LABEL</tt> flag is off, if the label is <tt>NULL</tt> or +does not have a '&' character in it, or if the keypress does not match +the character. -<p><pre> - Class(int x, int y, int w, int h, const char* label = 0); -</pre> +<p>The second version lets you do this test against an arbitrary string. -<p>This will allow the class name to be typed into <a -href=fluid.html>fluid</a> and it will produce the correct call. +<H3><a name="type">uchar Fl_Widget::type() const<br> +void Fl_Widget::type(uchar t)</a></H3> -<p>The constructor must call the constructor for the base class and -pass the same arguments. Fl_Widget's protected constructor sets x(), -y(), w(), h(), and label() to the passed values and initializes the -other instance variables to: - -<p><pre> - type(0); - box(FL_NO_BOX); - color(FL_GRAY); - selection_color(FL_GRAY); - labeltype(FL_NORMAL_LABEL); - labelstyle(FL_NORMAL_STYLE); - labelsize(FL_NORMAL_SIZE); - labelcolor(FL_BLACK); - align(FL_ALIGN_CENTER); - callback(default_callback,0); - flags(ACTIVE|VISIBLE); -</pre> - -<a name=protected> -<h2>Protected methods of Fl_Widget</h2> - -<p>These methods are provided for subclasses to use. - -</ul><h4><code>uchar Fl_Widget::type() const; -<br>void Fl_Widget::type(uchar); -</code></h4><ul> - -The property Fl_Widget::type() can return an arbitrary 8-bit -identifier, and can be set with the protected method type(uchar). -This value had to be provided for Forms compatability, but you can use +The property <tt>Fl_Widget::type()</tt> can return an arbitrary 8-bit +identifier, and can be set with the protected method <tt>type(uchar t)</tt>. +This value had to be provided for Forms compatibility, but you can use it for any purpose you want. Try to keep the value less than 100 to not interfere with reserved values. -<p>Fltk does not use RTTI (Run Time Typing Infomation), to enhance +<p>FLTK does not use RTTI (Run Time Typing Infomation), to enhance portability. But this may change in the near future if RTTI becomes standard everywhere. -<p>If you don't have RTTI you can use the clumsy fltk mechanisim, by -having type() have a unique value. These unique values must be -greater than the symbol FL_RESERVED_TYPE (which is 100). Grep through -the header files for "FL_RESERVED_TYPE" to find an unused number. If -you make a subclass of Fl_Group you must use FL_GROUP+n, and if you -make a subclass of Fl_Window you must use FL_WINDOW+n (in both cases n -is in the range 1-7). - -<a name=test_shortcut> -</ul><h4><code>void Fl_Widget::set_flag(SHORTCUT_LABEL);</code></h4><ul> - -If your constructor calls this it modifies draw_label() so that '&' -characters cause an underscore to be printed under the next letter. - -</ul><h4><code>int Fl_Widget::test_shortcut() const;<br> -static int Fl_Widget::test_shortcut(const char *);</code></h4><ul> - -The first version tests Fl_Widget::label() against the current event -(which should be a FL_SHORTCUT event). If the label contains a '&' -character and the character after it matches the key press, this -returns true. This returns false if the SHORTCUT_LABEL flag is off, -if the label is null or does not have a '&' character in it, or if the -keypress does not match the character. - -<p>The second version lets you do this test to an arbitrary string. - -</ul><h4><code>void Fl_Widget::x(short); -<br>void Fl_Widget::y(short); -<br>void Fl_Widget::w(short); -<br>void Fl_Widget::h(short);</code></h4><ul> - -You can directly clobber the values for <a -href=Fl_Widget.html#xywh>x(), y(), w(), and h()</a>. Make sure you -know what you are doing. This is most useful for temporarily -replacing the values before calling handle() or draw() on the base -class to "fool" it into working in a different area. - -<a name=damage> -</ul><h4><code>void Fl_Widget::damage(uchar mask);</code></h4><ul> - -Indicate that a partial update of the object is needed. The bits in -mask are or'd into damage(). Your draw() routine can examine these -bits to limit what it is drawing. The public method -Fl_Widget::redraw() simply does Fl_Widget::damage(-1). - -</ul><h4><code>void Fl_Widget::damage(uchar mask,int x,int y,int w,int -h);</code></h4><ul> - -Indicate that a region is damaged. If only these calls are done in a -window (no calls to damage(n)) then fltk will clip to the union of all -these calls before drawing anything. This can greatly speed up -incremental displays. The mask bits are or'd into damage() (unless -this is a Fl_Window, in which case they are forced to the value 6 for -internal reasons). - -</ul><h4><code>void Fl_Widget::clear_damage(uchar value = 0);</code></h4><ul> - -Directly set damage() to the passed value. This is provided for -kludges only. - -</ul><h4><code>uchar Fl_Widget::damage()</code></h4><ul> - -Return the bitwise-or of all damage(n) calls done since the last -draw(). The public method redraw() does damage(-1), but the -implementation of your widget can call the private damage(n). - -</ul><h4><code>void Fl_Widget::set_visible(); -<br>void Fl_Widget::clear_visible();</code></h4><ul> - -Fast inline versions of Fl_Widget::hide() and Fl_Widget::show(). -These do not send the FL_HIDE and FL_SHOW events to the widget. +<p>If you don't have RTTI you can use the clumsy FLTK mechanisim, by +having <tt>type()</tt> have a unique value. These unique values must +be greater than the symbol <tt>FL_RESERVED_TYPE</tt> (which is 100). +Look through the header files for <tt>FL_RESERVED_TYPE</tt> to find an +unused number. If you make a subclass of <tt>Fl_Group</tt> you must +use <tt>FL_GROUP + n</tt>, and if you make a subclass of +<tt>Fl_Window<tt> you must use <tt>FL_WINDOW + n</tt> (in both cases +<tt>n is in the range 1 to 7). -</ul><h4><code>void Fl_Widget::draw_box() const ;</code></h4><ul> +<H2>Handling Events</H2> -Draw this widget's box(), using the dimensions of the widget. +The virtual method <tt>int Fl_Widget::handle(int event)</tt> is called +to handle each event passed to the widget. It can: -</ul><h4><code>void Fl_Widget::draw_box(Fl_Boxtype b,ulong c) const -;</code></h4><ul> - -Pretend the box()==b and the color()==c and draw this widget's box. - -<a name=draw_label> -</ul><h4><code>void Fl_Widget::draw_label() const ;</code></h4><ul> - -This is the usual function for a draw() method to call to draw the -widget's label. It does not draw the label if it is supposed to be -outside the box (on the assumption that the enclosing group will draw -those labels). - -</ul><h4><code>void Fl_Widget::draw_label(int x,int y,int w,int h) const -;</code></h4><ul> - -Do the same thing except use the passed bounding box. This is useful -so "centered" labels are aligned with some feature, such as a moving -slider. - -</ul><h4><code>void Fl_Widget::draw_label(int x,int y,int w,int -h,Fl_Align align) const ;</code></h4><ul> - -Draw the label anywhere. It acts as though FL_ALIGN_INSIDE has been -forced on, the label will appear inside the passed bounding box. This -is designed for parent groups to draw labels with. - -</ul> -<a name=handle> -<h2>virtual int Fl_Widget::handle()</h2> - -The virtual method <b><code>int Fl_Widget::handle(int -event)</code></b> is called to handle each event passed to the widget. -It can:<ul> - -<li>Change the state of the widget. - -<li>Call <a href=Fl_Widget.html>Fl_Widget::redraw()</a> if the widget -needs to be redisplayed. +<ul> + <li>Change the state of the widget. -<li>Call <a href=#damage>Fl_Widget::damage(n)</a> if the widget needs -a partial-update (assumming you provide support for this in your -Fl_Widget::draw() method). + <li>Call <a href="#Fl_Widget.redraw"><tt>Fl_Widget::redraw()</tt></a> + if the widget needs to be redisplayed. -<li>Call <a href=Fl_Widget.html>Fl_Widget::do_callback()</a> if a -callback should be generated. + <li>Call <a + href="#Fl_Widget.damage"><tt>Fl_Widget::damage(n)</tt></a> if + the widget needs a partial-update (assumming you provide + support for this in your <tt>Fl_Widget::draw()</tt> method). -<li>Call Fl_Widget::handle() on child widgets. + <li>Call <a + href="#Fl_Widget.do_callback"><tt>Fl_Widget::do_callback()</tt></a> + if a callback should be generated. + <li>Call <tt>Fl_Widget::handle()</tt> on child widgets. </ul> -<p>Events are identified the small integer argument. Other -information about the most recent event is stored in static locations -and aquired by calling <a href=events.html><code>Fl::event_*()</code></a>. -This other information remains valid until another event is read from -the X server. +Events are identified by the integer argument. Other information about +the most recent event is stored in static locations and aquired by +calling the <a href="#events"><tt>Fl::event_*()</tt></a> functions. +This information remains valid until another event is handled. -<p>Here is a sample Fl_Widget::handle(), for a widget that acts as a +<p>Here is a sample <tt>handle()</tt> method for a widget that acts as a pushbutton and also accepts the keystroke 'x' to cause the callback: -<ul><pre>int Fl_Pushbutton::handle(int event) { +<ul><pre> +int MyClass::handle(int event) { switch(event) { case FL_PUSH: - highlight = 1; redraw(); + highlight = 1; + redraw(); return 1; - case FL_DRAG: - {int t = Fl::event_inside(this); - if (t != highlight) {highlight = t; redraw();}} + case FL_DRAG: { + int t = Fl::event_inside(this); + if (t != highlight) { + highlight = t; + redraw(); + } + } return 1; case FL_RELEASE: if (highlight) { - highlight = 0; redraw(); + highlight = 0; + redraw(); do_callback(); - // never do anything after a callback, so that the callback + // never do anything after a callback, as the callback // may delete the widget! } return 1; case FL_SHORTCUT: - if (Fl::event_key() == 'x') {do_callback(); return 1;} + if (Fl::event_key() == 'x') { + do_callback(); + return 1; + } return 0; default: return 0; - } } } </pre></ul> -<p>You must return non-zero if your handle() method used the event. -If you return zero it indicates to the parent that it can try sending -another widget the event. +You must return non-zero if your <tt>handle()</tt> method uses the +event. If you return zero it indicates to the parent widget that it can +try sending the event to another widget. -<p>It looks like it is best to make the handle() method public. +<H2>Drawing the Widget</H2> -<a name=draw> -<h2>virtual void Fl_Widget::draw()</h2> +The <tt>draw()</tt> virtual method is called when FLTK wants you to +redraw your widget. It will be called if and only if <tt>damage()</tt> +is non-zero, and <tt>damage()</tt> will be cleared to zero after it +returns. <tt>draw()</tt> should be declared protected, so that it can't +be called from non-drawing code. -<p>The virtual method Fl_Widget::draw() is called when fltk wants you -to redraw your widget. It will be called if and only if damage() is -non-zero, and damage() will be cleared to zero after it returns. -draw() should be declared protected, so that subclasses may call it -but it can't be called from non-drawing code. - -<p>damage() contains the bitwise-or of all the damage(n) calls to this +<p><tt>damage()</tt> contains the bitwise-OR of all the <tt>damage(n)</tt> calls to this widget since it was last drawn. This can be used for minimal update, -by only redrawing the parts whose bits are set. Fltk will turn +by only redrawing the parts whose bits are set. FLTK will turn <i>all</i> the bits on if it thinks the entire widget must be redrawn -(for instance due to an expose event). It is easiest to program to -handle this by pretending a bit (usually damage()&128) draw the -non-minimal-update parts of your widget (such as the box()). - -<p>Expose events (and the above damage(b,x,y,w,h)) will cause draw() -to be called with fltk's <a href=Draw.html#clipping>clipping</a> -turned on. You can greatly speed up redrawing in some cases by -testing <code>fl_clipped</code> and <code>fl_current_clip</code> -and skipping invisible parts. - -<p>The functions you can use to draw are described in <a -href=Draw.html><FL/fl_draw.H></a> or any of the protected -Fl_Widget::draw_* methods described above. - -<a name=resize> -<h2>virtual void Fl_Widget::resize(int,int,int,int);</h2> - -This is called when the widget is being resized or moved. The -arguments are the new position, width, and height. x(), y(), w(), and -h() still return the old size. You must call resize() on your -base class with the same arguments to get the widget size to actually -change. +(for instance due to an expose event). -<p>This should <i>not</i> call redraw(), at least if only the x() and -y() change. This is because group objects like <a -href=Fl_Scroll.html>Fl_Scroll</a> may have a more efficient way of -drawing the new position. +<p>Expose events (and the above <tt>damage(b,x,y,w,h)</tt>) will cause +<tt>draw()</tt> to be called with FLTK's <a +href="#clipping">clipping</a> turned on. You can greatly speed up +redrawing in some cases by testing <tt>fl_clipped</tt> and +<tt>fl_current_clip</tt> and skipping invisible parts. -<p>It may be useful to refer to the size the widget was constructed -at, these are stored in Fl_Widget::ix(), iy(), iw(), and ih(). +<p>Besides the protected methods described above, FLTK provide a large +number of basic drawing functions, which are described <a +href=#drawing>below</a>. -<p>Resize should be declared public. +<H2>Resizing the Widget</H2> -<a name=destructor> -<h2>virtual Fl_Widget::~Fl_Widget();</h2> +The <tt>resize(int x, int y, int w, int h)</tt> method is called when +the widget is being resized or moved. The arguments are the new +position, width, and height. <tt>x()</tt>, <tt>y()</tt>, <tt>w()</tt>, +and <tt>h()</tt> still remain the old size. You must call +<tt>resize()</tt> on your base class with the same arguments to get the +widget size to actually change. -We all know why the destructor must be virtual don't we? Don't forget -to make it public. +<p>This should <i>not</i> call <tt>redraw()</tt>, at least if only the +<tt>x()</tt> and <tt>y()</tt> change. This is because group objects +like <a href="#Fl_Scroll"><tt>Fl_Scroll</tt></a> may have a more +efficient way of drawing the new position. -<a name=composite> -<h2>Making a Composite/Group Widget</h2> +<H2>Making a Composite/Group Widget</H2> A "composite" widget contains one or more "child" widgets. To do this -you should subclass <a href=Fl_Group.html>Fl_Group</a> (it is +you should subclass <a href="#Fl_Group"><tt>Fl_Group</tt></a>. It is possible to make a composite object that is not a subclass of -Fl_Group, but this is very difficult). +<tt>Fl_Group</tt>, but you'll have to duplicate the code in <tt>Fl_Group</tt> +anyways. <p>Instances of the child widgets may be included in the parent: -<ul><pre>class MyClass : public Fl_Group { +<ul><pre> +class MyClass : public Fl_Group { Fl_Button the_button; Fl_Slider the_slider; ... }; </pre></ul> -<p>The constructor has to initialize these instances. They are -automatically add()ed to the group, since the Fl_Group constructor -does begin(). <i>Don't forget to call end():</i> - -<ul><pre>MyClass::MyClass(int x,int y,int w,int h) : - Fl_Group(x,y,w,h), - the_button(x+5,y+5,100,20), - the_slider(x,y+50,w,20) +The constructor has to initialize these instances. They are +automatically <tt>add()</tt>ed to the group, since the +<tt>Fl_Group</tt> constructor does <tt>begin()</tt>. <i>Don't forget +to call <tt>end()</tt> or use the <a href="#Fl_End"><tt>Fl_End</tt></a> +pseudo-class:</i> + +<ul><pre> +MyClass::MyClass(int x, int y, int w, int h) : + Fl_Group(x, y, w, h), + the_button(x + 5, y + 5, 100, 20), + the_slider(x, y + 50, w, 20) { ...(you could add dynamically created child widgets here)... end(); // don't forget to do this! } </pre></ul> -<p>The child widgets need callbacks. These will be called with a -pointer to the children, but the widget itself may be found in the -parent() pointer of the child. Usually these callbacks can be static -private methods, with a matching private method: +The child widgets need callbacks. These will be called with a pointer +to the children, but the widget itself may be found in the +<tt>parent()</tt> pointer of the child. Usually these callbacks can be +static private methods, with a matching private method: -<ul><pre>void MyClass::slider_cb(Fl_Widget* v, void *) { // static method +<ul><pre> +void MyClass::slider_cb(Fl_Widget* v, void *) { // static method ((MyClass*)(v->parent())->slider_cb(); } void MyClass::slider_cb() { // normal method @@ -429,31 +340,33 @@ void MyClass::slider_cb() { // normal method } </pre></ul> -<p>If you make the handle() method, you can quickly pass all the -events to the children (notice that you don't need to override -handle() if your composite widget does nothing other than pass events -to the children): +If you make the <tt>handle()</tt> method, you can quickly pass all the +events to the children using the <tt>Fl_Group::handle()</tt> method. +Note that you don't need to override <tt>handle()</tt> if your +composite widget does nothing other than pass events to the children: -<ul><pre>int MyClass::handle(int event) { +<ul><pre> +int MyClass::handle(int event) { if (Fl_Group::handle(event)) return 1; ... handle events that children don't want ... } </pre></ul> -<p>If you override draw() you need to draw all the children. If -redraw() or damage() is called on a child, damage(1) is done to the -group. Thus the 1 bit of damage() can be used to indicate that a -child needs to be drawn. It is fastest if you avoid drawing anything -else in this case: - -<ul><pre>int MyClass::draw() { - Fl_Widget*const* a = array(); - if (damage()==1) { // only redraw some children - for (int i=children(); i--; a++) update_child(**a); +If you override <tt>draw()</tt> you need to draw all the children. If +<tt>redraw()</tt> or <tt>damage()</tt> is called on a child, +<tt>damage(FL_DAMAGE_CHILD)</tt> is done to the group, so this bit of +<tt>damage()</tt> can be used to indicate that a child needs to be +drawn. It is fastest if you avoid drawing anything else in this case: + +<ul><pre> +int MyClass::draw() { + Fl_Widget *const*a = array(); + if (damage() == FL_DAMAGE_CHILD) { // only redraw some children + for (int i = children(); i --; a ++) update_child(**a); } else { // total redraw ... draw background graphics ... // now draw all the children atop the background: - for (int i=children_; i--; a++) { + for (int i = children_; i --; a ++) { draw_child(**a); draw_outside_label(**a); // you may not want to do this } @@ -461,59 +374,84 @@ else in this case: } </pre></ul> -<p>Fl_Group provides some protected methods to make drawing easier: +<tt>Fl_Group</tt> provides some protected methods to make drawing easier: + +<ul> + <li><a href="#draw_child">draw_child</a> + <li><a href="#draw_outside_label">draw_outside_label</a> + <li><a href="#update_child">update_child</a> +</ul> -</ul><h4><code>void Fl_Group::draw_outside_label(Fl_Widget&) const;</code></h4><ul> +<H3><a name="draw_child">void Fl_Group::draw_child(Fl_Widget&)</a></H3> -Draw the labels that are <i>not</i> drawn by <a -href=#draw_label>draw_label()</a>. If you want more control over the -label positions you might want to call child->draw_label(x,y,w,h,a). +This will force the child's <tt>damage()</tt> bits all to one and call +<tt>draw()</tt> on it, then clear the <tt>damage()</tt>. You should +call this on all children if a total redraw of your widget is +requested, or if you draw something (like a background box) that +damages the child. Nothing is done if the child is not +<tt>visible()</tt> or if it is clipped. -</ul><h4><code>void Fl_Group::draw_child(Fl_Widget&);</code></h4><ul> +<H3><a name="draw_outside_label">void Fl_Group::draw_outside_label(Fl_Widget&) const</a></H3> -This will force the child's damage() bits all to one and call draw() -on it, then clear the damage(). You should call this on all children -if a total redraw of your widget is requested, or if you draw -something (like a background box) that damages the child. Nothing is -done if the child is not visible() or if it is clipped. +Draw the labels that are <i>not</i> drawn by +<a href="#draw_label"><tt>draw_label()</tt></a>. If you want more control +over the label positions you might want to call +<tt>child->draw_label(x,y,w,h,a)</tt>. -</ul><h4><code>void Fl_Group::update_child(Fl_Widget&);</code></h4><ul> +<H3><a name="update_child">void Fl_Group::update_child(Fl_Widget&)</a></H3> -Draws the child only if it's damage() is non-zero. You should call -this on all the children if your own damage is equal to 1. Nothing is -done if the child is not visible() or if it is clipped. +Draws the child only if it's <tt>damage()</tt> is non-zero. You should +call this on all the children if your own damage is equal to +FL_DAMAGE_CHILD. Nothing is done if the child is not +<tt>visible()</tt> or if it is clipped. +<H2>Cut and Paste Support</H2> + +FLTK provides routines to cut and paste ASCII text (in the future this +may be UTF-8) between applications: + +<ul> + <li><a href="#paste">Fl::paste</a> + <li><a href="#selection">Fl::selection</a> + <li><a href="#selection_length">Fl::selection_length</a> + <li><a href="#selection_owner">Fl::selection_owner</a> </ul> -<a name=window> -<h2>Making a subclass of Fl_Window</h2> -<p>You may want your widget to be a subclass of Fl_Window. This can -be useful if your widget wants to occupy an entire window, and can +It may be possible to cut/paste non-ASCII data by using <a +href="#add_handler"><tt>Fl::add_handler()</tt></a>. + +<H2>Making a subclass of Fl_Window</H2> + +You may want your widget to be a subclass of <tt>Fl_Window</tt>. This +can be useful if your widget wants to occupy an entire window, and can also be used to take advantage of system-provided clipping, or to work with a library that expects a system window id to indicate where to draw. -<p>Subclassing Fl_Window is almost exactly like subclassing Fl_Widget, -in fact you can easily switch a subclass back and forth. Watch out -for the following differences: +<p>Subclassing <tt>Fl_Window</tt> is almost exactly like subclassing +<tt>Fl_Widget</tt>, in fact you can easily switch a subclass back and +forth. Watch out for the following differences: <ol> -<li>Fl_Window is a subclass of Fl_Group so <i>make sure your constructor -calls end()</i> (unless you actually want children added to your -window). - -<li>When handling events and drawing, the lower-left corner is at 0,0, -not x(),y() as in other Fl_Widgets. For instance, to draw a box -around the widget, call draw_box(0,0,w(),h()), rather than -draw_box(x(),y(),w(),h()). + <li><tt>Fl_Window</tt> is a subclass of <tt>Fl_Group</tt> so + <i>make sure your constructor calls <tt>end()</tt></i> (unless + you actually want children added to your window). + <li>When handling events and drawing, the upper-left corner is + at 0,0, not <tt>x(),y()</tt> as in other <tt>Fl_Widget</tt>s. + For instance, to draw a box around the widget, call + <tt>draw_box(0, 0, w(), h())</tt>, rather than + <tt>draw_box( x(), y(), w(), h())</tt>. </ol> -<p>You may also want to subclass Fl_Window in order to get access to -different X visuals or to change other X attributes of the windows, -<a href=x.html#window>See here for details</a>. +You may also want to subclass <tt>Fl_Window</tt> in order to get access to +different visuals or to change other attributes of the windows. See +<a href="#osissues">Appendix F - Operating System Issues</a> for more +information. + +</BODY> +</HTML> -<p><a href = index.html>(back to contents)</a> diff --git a/documentation/widgets.html b/documentation/widgets.html index c85824acd..109e62345 100644 --- a/documentation/widgets.html +++ b/documentation/widgets.html @@ -1,6 +1,11 @@ <HTML> <BODY> <H1 ALIGN=RIGHT>A - Widget Reference</H1> + +This appendix describes all of the widget classes in FLTK. For a +description of the <tt>fl_</tt> functions and <tt>Fl::</tt> methods, +see <a href="#functions"> Appendix B</a>. + </BODY> </HTML> |