diff --git a/documentation/enumerations.dox b/documentation/enumerations.dox index 281608f0a..090497d4f 100644 --- a/documentation/enumerations.dox +++ b/documentation/enumerations.dox @@ -8,305 +8,287 @@ \sa \ref FL/Enumerations.H. -

This appendix lists the enumerations provided in the +This appendix lists the enumerations provided in the header file, organized by section. Constants whose value is zero are marked with "(0)", this is often useful to know when programming. +\section enumerations_versions Version Numbers -

Version Numbers

- The FLTK version number is stored in a number of compile-time -constants: - -

Events

- Events are identified by an Fl_Event enumeration value. The +The FLTK version number is stored in a number of compile-time constants: + +\li FL_MAJOR_VERSION - The major release number, currently 1. +\li FL_MINOR_VERSION - The minor release number, currently 3. +\li FL_PATCH_VERSION - The patch release number, currently 0. +\li FL_VERSION - A combined floating-point version number for + the major, minor, and patch release numbers, currently 1.0300. + + +\section enumerations_events Events + +Events are identified by an Fl_Event enumeration value. The following events are currently defined: - -

Callback "When" Conditions

- The following constants determine when a callback is performed: - -

Fl::event_button() Values

-

The following constants define the button numbers for FL_PUSH and -FL_RELEASE events: +\li FL_NO_EVENT - No event (or an event fltk does not + understand) occurred (0). +\li FL_PUSH - A mouse button was pushed. +\li FL_RELEASE - A mouse button was released. +\li FL_ENTER - The mouse pointer entered a widget. +\li FL_LEAVE - The mouse pointer left a widget. +\li FL_DRAG - The mouse pointer was moved with a button pressed. +\li FL_FOCUS - A widget should receive keyboard focus. +\li FL_UNFOCUS - A widget loses keyboard focus. +\li FL_KEYBOARD - A key was pressed. +\li FL_CLOSE - A window was closed. +\li FL_MOVE - The mouse pointer was moved with no buttons pressed. +\li FL_SHORTCUT - The user pressed a shortcut key. +\li FL_DEACTIVATE - The widget has been deactivated. +\li FL_ACTIVATE - The widget has been activated. +\li FL_HIDE - The widget has been hidden. +\li FL_SHOW - The widget has been shown. +\li FL_PASTE - The widget should paste the contents of the + clipboard. +\li FL_SELECTIONCLEAR - The widget should clear any selections + made for the clipboard. +\li FL_MOUSEWHEEL - The horizontal or vertical mousewheel was turned. +\li FL_DND_ENTER - The mouse pointer entered a widget dragging data. +\li FL_DND_DRAG - The mouse pointer was moved dragging data. +\li FL_DND_LEAVE - The mouse pointer left a widget still dragging + data. +\li FL_DND_RELEASE - Dragged data is about to be dropped. -

+ +\section enumerations_when Callback "When" Conditions -

Fl::event_key() Values

- The following constants define the non-ASCII keys on the keyboard for -FL_KEYBOARD and FL_SHORTCUT events: - -

Fl::event_state() Values

- The following constants define bits in the Fl::event_state() - value: - -

Alignment Values

- The following constants define bits that can be used with -Fl_Widget::align() to control the positioning of the -label: - -

Fonts

- The following constants define the standard FLTK fonts: - + +\section enumerations_alignment Alignment Values -

Colors

+The following constants define bits that can be used with +Fl_Widget::align() +to control the positioning of the label: -

The Fl_Color enumeration type holds a FLTK color value. +\li FL_ALIGN_CENTER - The label is centered (0). +\li FL_ALIGN_TOP - The label is top-aligned. +\li FL_ALIGN_BOTTOM - The label is bottom-aligned. +\li FL_ALIGN_LEFT - The label is left-aligned. +\li FL_ALIGN_RIGHT - The label is right-aligned. +\li FL_ALIGN_CLIP - The label is clipped to the widget. +\li FL_ALIGN_WRAP - The label text is wrapped as needed. +\li FL_ALIGN_TOP_LEFT +\li FL_ALIGN_TOP_RIGHT +\li FL_ALIGN_BOTTOM_LEFT +\li FL_ALIGN_BOTTOM_RIGHT +\li FL_ALIGN_LEFT_TOP +\li FL_ALIGN_RIGHT_TOP +\li FL_ALIGN_LEFT_BOTTOM +\li FL_ALIGN_RIGHT_BOTTOM +\li FL_ALIGN_INSIDE - 'or' this with other values to put + label inside the widget. + + +\section enumerations_fonts Fonts + +The following constants define the standard FLTK fonts: + +\li FL_HELVETICA - Helvetica (or Arial) normal (0). +\li FL_HELVETICA_BOLD - Helvetica (or Arial) bold. +\li FL_HELVETICA_ITALIC - Helvetica (or Arial) oblique. +\li FL_HELVETICA_BOLD_ITALIC - Helvetica (or Arial) bold-oblique. +\li FL_COURIER - Courier normal. +\li FL_COURIER_BOLD - Courier bold. +\li FL_COURIER_ITALIC - Courier italic. +\li FL_COURIER_BOLD_ITALIC - Courier bold-italic. +\li FL_TIMES - Times roman. +\li FL_TIMES_BOLD - Times bold. +\li FL_TIMES_ITALIC - Times italic. +\li FL_TIMES_BOLD_ITALIC - Times bold-italic. +\li FL_SYMBOL - Standard symbol font. +\li FL_SCREEN - Default monospaced screen font. +\li FL_SCREEN_BOLD - Default monospaced bold screen font. +\li FL_ZAPF_DINGBATS - Zapf-dingbats font. + + +\section enumerations_colors Colors + +The Fl_Color enumeration type holds a FLTK color value. Colors are either 8-bit indexes into a virtual colormap or 24-bit RGB color values. Color indices occupy the lower 8 bits of the value, while RGB colors occupy the upper 24 bits, for a byte organization of RGBI. -

Color Constants

+\subsection enumerations_color_constants Color Constants -

Constants are defined for the user-defined foreground and background +Constants are defined for the user-defined foreground and background colors, as well as specific colors and the start of the grayscale ramp and color cube in the virtual colormap. Inline functions are provided to retrieve specific grayscale, color cube, or RGB color values. -

The following color constants can be used to access the user-defined +The following color constants can be used to access the user-defined colors: -

- -

The following color constants can be used to access the colors from the +The following color constants can be used to access the colors from the FLTK standard color cube: -

+ +\section enumerations_cursors Cursors -

The inline methods for getting a grayscale, color cube, or -RGB color value are described in Appendix B - Function -Reference. - -

Cursors

- -

The following constants define the mouse cursors that are available in +The following constants define the mouse cursors that are available in FLTK. The double-headed arrows are bitmaps provided by FLTK on X, the others are provided by system-defined -cursors.

+cursors. - +\section enumerations_file_when FD "When" Conditions -

FD "When" Conditions

+\li FL_READ - Call the callback when there is data to be + read. +\li FL_WRITE - Call the callback when data can be written + without blocking. +\li FL_EXCEPT - Call the callback if an exception occurs on + the file. - - -

Damage Masks

- The following damage mask bits are used by the standard FLTK widgets: - +\li FL_DAMAGE_CHILD - A child needs to be redrawn. +\li FL_DAMAGE_EXPOSE - The window was exposed. +\li FL_DAMAGE_SCROLL - The Fl_Scroll widget was scrolled. +\li FL_DAMAGE_OVERLAY - The overlay planes need to be redrawn. +\li FL_DAMAGE_USER1 - First user-defined damage bit. +\li FL_DAMAGE_USER2 - Second user-defined damage bit. +\li FL_DAMAGE_ALL - Everything needs to be redrawn.
[Index]    diff --git a/documentation/forms.dox b/documentation/forms.dox index 4706571fb..2c442f212 100644 --- a/documentation/forms.dox +++ b/documentation/forms.dox @@ -2,172 +2,205 @@ \page forms E - Forms Compatibility -

This appendix describes the Forms compatibility included with FLTK. -

Importing Forms Layout Files

+This appendix describes the Forms compatibility included with FLTK. + +\section forms_importing Importing Forms Layout Files + FLUID 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. -

You will need to edit your main code considerably to get it to link + +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 compatibility header, -.

-

Using the Compatibility Header File

- You should be able to compile existing Forms or XForms source code by -changing the include directory 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 +have more immediate luck with the forms compatibility header, +. + +\section forms_using Using the Compatibility Header File + +You should be able to compile existing Forms or XForms source code by +changing the include directory 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. -

You will also have to compile your Forms or XForms program using a + +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.

-

Although FLTK was designed to be compatible with the GL Forms +files. + +Although FLTK was designed to be compatible with the GL Forms library (version 0.3 or so), XForms has bloated severely and it's interface is 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.

-

To use any new features of FLTK, you should rewrite your code to not +unused, or that was not X-specific. + +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 expected and -even Digital Domain's inhouse code still uses forms.H a lot.

-

Problems You Will Encounter

-

Many parts of XForms use X-specific structures like XEvent - in their interface. I did not emulate these! Unfortunately these +even Digital Domain's inhouse code still uses forms.H a lot. + +\section forms_problems Problems You Will Encounter + +Many parts of XForms use X-specific structures like XEvent +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.

-

Fl_Free widgets emulate +programs. You will need to rewrite these to use FLTK subclasses. + +Fl_Free widgets emulate the old 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.

-

Fl_Timer widgets are +programs that change the handle() function on widgets, but you +will still need to rewrite things. + +Fl_Timer widgets are provided to emulate the XForms timer. These work, but are quite inefficient and inaccurate compared to using -Fl::add_timeout().

-

All instance variables are hidden. If you directly refer to +Fl::add_timeout(). + +All instance variables are hidden. 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()".

-

const char * arguments to most FLTK methods are simply -stored, while Forms would strdup() the passed string. This is +"boxtype" with "box()". + +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 Fl_Output - widget.

-

The default fonts and sizes are matched to the older GL version of +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 Fl_Output +widget. + +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.

-

fdesign outputs a setting of a "fdui" instance variable to the main +does. + +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() +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.

-

The prototype for the functions passed to fl_add_timeout() - and fl_set_idle_callback() callback are different.

-

All the following XForms calls are missing:

- -

Additional Notes

- These notes were written for porting programs written with the older +This will require casts and is not trivial. + +The prototype for the functions passed to fl_add_timeout() +and fl_set_idle_callback() callback are different. + +All the following XForms calls are missing: + +\li FL_REVISION, fl_library_version() +\li FL_RETURN_DBLCLICK (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 + +\section forms_notes Additional Notes + +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: -

Does Not Run In Background

- The IRISGL library always forked when you created the first window, + +\par Does Not Run In Background + +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. -

You Cannot Use IRISGL Windows or fl_queue

- If a Forms (not XForms) program if you wanted your own window for + +\par You Cannot Use IRISGL Windows or fl_queue + +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 IRISGL window, you would find this out by having the value FL_EVENT returned from the call to Forms. -

None of this works with FLTK. Nor will it compile, the necessary -calls are not in the interface.

-

You have to make a subclass of -Fl_Gl_Window and write a draw() method and -handle() method. This may require anywhere from a trivial to a -major rewrite.

-

If you draw into the overlay planes you will have to also write a -draw_overlay() method and call redraw_overlay() on the -OpenGL window.

-

One easy way to hack your program so it works is to make the -draw() and handle() methods on your window set some + +None of this works with FLTK. Nor will it compile, the necessary +calls are not in the interface. + +You have to make a subclass of +Fl_Gl_Window and write a draw() method and +handle() method. This may require anywhere from a trivial to a +major rewrite. + +If you draw into the overlay planes you will have to also write a +draw_overlay() method and call redraw_overlay() on the +OpenGL window. + +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.

-

You Must Use OpenGL to Draw Everything

-

The file defines replacements for a lot of IRISGL +of your program, call Fl::wait() and then check these +variables, acting on them as though they are events read from +fl_queue. + +\par You Must Use OpenGL to Draw Everything + +The file defines replacements for a lot of IRISGL calls, translating them to OpenGL. There are much better translators -available that you might want to investigate.

-

You Cannot Make Forms Subclasses

- Programs that call fl_make_object or directly setting the +available that you might want to investigate. + +\par You Cannot Make Forms Subclasses + +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. -

An attempt has been made to emulate the "free" widget. This appears +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. + +An attempt has been made to emulate the "free" widget. This appears to work quite well. It may be quicker to modify your subclass into a -"free" widget, since the "handle" functions match.

-

If your subclass draws into the overlay you are in trouble and will -have to rewrite things a lot.

-

You Cannot Use

- If you have written your own "free" widgets you will probably get a +"free" widget, since the "handle" functions match. + +If your subclass draws into the overlay you are in trouble and will +have to rewrite things a lot. + +\par You Cannot Use + +If you have written your own "free" widgets you will probably get a lot of errors about "getvaluator". You should substitute: -
+ +
+
@@ -178,10 +211,14 @@ lot of errors about "getvaluator". You should substitute: -
FormsFLTK
MOUSE_XFl::event_x_root()
MOUSE_YFl::event_y_root()
MOUSE1,RIGHTMOUSEFl::event_state()
MOUSE2,MIDDLEMOUSEFl::event_state()
MOUSE3,LEFTMOUSEFl::event_state()
- Anything else in getvaluator and you are on your own... -

Font Numbers Are Different

- The "style" numbers have been changed because I wanted to insert + + + +Anything else in getvaluator and you are on your own... + +\par Font Numbers Are Different + +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: diff --git a/documentation/glut.dox b/documentation/glut.dox index cdbb1616e..9d1e32898 100644 --- a/documentation/glut.dox +++ b/documentation/glut.dox @@ -2,117 +2,155 @@ \page glut D - GLUT Compatibility -

This appendix describes the GLUT compatibility header file supplied with FLTK. FLTK's GLUT compatibility is based on the original GLUT 3.7 and the follow-on FreeGLUT 2.4.0 libraries.

-

Using the GLUT Compatibility Header File

-

You should be able to compile existing GLUT source code by including instead of . 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.

-

All files calling GLUT procedures must be compiled with C++. 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.

-

You must link with the FLTK library. Most of FL/glut.H is inline functions. You should take a look at it (and maybe at test/glpuzzle.cxx in the FLTK source) if you are having trouble porting your GLUT program.

-

This has been tested with most of the demo programs that come with the GLUT and FreeGLUT distributions.

-

Known Problems

-

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: -

- 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 -GLUT_DOWN and GLUT_UP, mouse buttons -GLUT_LEFT_BUTTON, GLUT_MIDDLE_BUTTON, GLUT_RIGHT_BUTTON, and -GLUT_KEY_F1 thru F12. -

The strings passed as menu labels are not copied.

-

glutPostRedisplay() does not work if called from inside a -display function. You must use glutIdleFunc() if you want -your display to update continuously.

-

glutSwapBuffers() does not work from inside a display -function. This is on purpose, because FLTK swaps the buffers for you.

-

glutUseLayer() does not work well, and should only be used +This appendix describes the GLUT compatibility header file supplied with +FLTK. FLTK's GLUT compatibility is based on the original GLUT 3.7 and +the follow-on FreeGLUT 2.4.0 libraries. + +\section glut_using Using the GLUT Compatibility Header File + +You should be able to compile existing GLUT source code by including + instead of . 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. + +All files calling GLUT procedures must be compiled with C++. 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. + +You must link with the FLTK library. Most of FL/glut.H +is inline functions. You should take a look at it (and maybe at +test/glpuzzle.cxx in the FLTK source) if you are having trouble +porting your GLUT program. + +This has been tested with most of the demo programs that come with +the GLUT and FreeGLUT distributions. + +\section glut_known_problems Known Problems + +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: + +\li glutGet(GLUT_ELAPSED_TIME) +\li glutGet(GLUT_SCREEN_HEIGHT_MM) +\li glutGet(GLUT_SCREEN_WIDTH_MM) +\li glutGet(GLUT_WINDOW_NUM_CHILDREN) +\li glutInitDisplayMode(GLUT_LUMINANCE) +\li glutLayerGet(GLUT_HAS_OVERLAY) +\li glutLayerGet(GLUT_LAYER_IN_USE) +\li glutPushWindow() +\li glutSetColor(), glutGetColor(), glutCopyColormap() +\li glutVideoResize() missing. +\li glutWarpPointer() +\li glutWindowStatusFunc() +\li Spaceball, buttonbox, dials, and tablet functions + +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 +GLUT_DOWN and GLUT_UP, mouse buttons +GLUT_LEFT_BUTTON, GLUT_MIDDLE_BUTTON, GLUT_RIGHT_BUTTON, and +GLUT_KEY_F1 thru F12. + +The strings passed as menu labels are not copied. + +glutPostRedisplay() does not work if called from inside a +display function. You must use glutIdleFunc() if you want +your display to update continuously. + +glutSwapBuffers() does not work from inside a display +function. This is on purpose, because FLTK swaps the buffers for you. + +glutUseLayer() does not work well, and should only be used to initialize transformations inside a resize callback. You should -redraw overlays by using glutOverlayDisplayFunc().

-

Overlays are cleared before the overlay display function is called. -glutLayerGet(GLUT_OVERLAY_DAMAGED) always returns true for +redraw overlays by using glutOverlayDisplayFunc(). + +Overlays are cleared before the overlay display function is called. +glutLayerGet(GLUT_OVERLAY_DAMAGED) always returns true for compatibility with 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.

-

glutSetCursor(GLUT_CURSOR_FULL_CROSSHAIR) just results in a -small crosshair.

-

The fonts used by glutBitmapCharacter() and glutBitmapWidth() - may be different.

-

glutInit(argc,argv) will consume different switches than +code so that gl_color() is used to choose colors in an +overlay, or you will get random overlay colors. + +glutSetCursor(GLUT_CURSOR_FULL_CROSSHAIR) just results in a +small crosshair. + +The fonts used by glutBitmapCharacter() and glutBitmapWidth() +may be different. + +glutInit(argc,argv) will consume different switches than GLUT does. It accepts the switches recognized by -Fl::args(), and will accept any abbreviation of these -switches (such as "-di" for "-display").

-

Mixing GLUT and FLTK Code

- 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 shown. - +Fl::args(), and will accept any abbreviation of these +switches (such as "-di" for "-display"). + +\section glut_mixing Mixing GLUT and FLTK Code + +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 shown. + +\li Don't call glutInit(). +\li Create your Fl_Window, and any FLTK widgets. Leave a + blank area in the window for your GLUT window. +\li show() the Fl_Window. Perhaps call + show(argc,argv). +\li Call window->begin() so that the GLUT window will be + automatically added to it. +\li Use glutInitWindowSize() and glutInitWindowPosition() + to set the location in the parent window to put the GLUT window. +\li Put your GLUT code next. It probably does not need many changes. + Call window->end() immediately after the + glutCreateWindow()! +\li You can call either glutMainLoop(), Fl::run(), + or loop calling Fl::wait() to run the program. +
\section glut_Fl_Glut_Window class Fl_Glut_Window
-

Class Hierarchy

+ +\subsection glut_class_hierarchy Class Hierarchy + \code -Fl_Gl_Window +Fl_Gl_Window | - +----Fl_Glut_Window + +----Fl_Glut_Window \endcode -

Include Files

+\subsection glut_include_files Include Files \code #include \endcode -

Description

- Each GLUT window is an instance of this class. You may find it useful +\subsection glut_description Description + +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 +These may be created without opening the display, and thus can fit better into FLTK's method of creating windows. -

The current GLUT window is available in the global variable -glut_window.

-

new Fl_Glut_Window(...) is the same as -glutCreateWindow() except it does not show() the window + +The current GLUT window is available in the global variable +glut_window.

+ +new Fl_Glut_Window(...) is the same as +glutCreateWindow() except it does not show() the window or make the window current.

-

window->make_current() is the same as -glutSetWindow(number). If the window has not had show() - called on it yet, some functions that assumme an OpenGL context will -not work. If you do show() the window, call make_current() - again to set the context.

-

~Fl_Glut_Window() is the same as glutDestroyWindow() -.

-

Members

-The Fl_Glut_Window class contains several public members that can + +window->make_current() is the same as glutSetWindow(number). +If the window has not had show() called on it yet, some functions +that assumme an OpenGL context will not work. +If you do show() the window, call make_current() +again to set the context.

+ +~Fl_Glut_Window() is the same as glutDestroyWindow(). + +\subsection glut_members Members + +The Fl_Glut_Window class contains several public members that can be altered directly: +
@@ -169,25 +207,33 @@ be altered directly:
member
-

Methods

- -

+\subsection glut_methods Methods + +\li Fl_Glut_Window +\li ~Fl_Glut_Window +\li make_current + + Fl_Glut_Window::Fl_Glut_Window(int x, int y, int w, int h, const char -*title = 0) -
Fl_Glut_Window::Fl_Glut_Window(int w, int h, const char *title = 0) -

- The first constructor takes 4 int arguments to create the window with +*title = 0)
+Fl_Glut_Window::Fl_Glut_Window(int w, int h, const char *title = 0) + +\par +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. -

virtual -Fl_Glut_Window::~Fl_Glut_Window()

- Destroys the GLUT window. -

void Fl_Glut_Window::make_current()

+ + +virtual Fl_Glut_Window::~Fl_Glut_Window() + +\par +Destroys the GLUT window. + + +void Fl_Glut_Window::make_current() + +\par Switches all drawing functions to the GLUT window.