summaryrefslogtreecommitdiff
path: root/documentation/src/forms.dox
diff options
context:
space:
mode:
Diffstat (limited to 'documentation/src/forms.dox')
-rw-r--r--documentation/src/forms.dox68
1 files changed, 34 insertions, 34 deletions
diff --git a/documentation/src/forms.dox b/documentation/src/forms.dox
index c2379e983..bb6279934 100644
--- a/documentation/src/forms.dox
+++ b/documentation/src/forms.dox
@@ -1,7 +1,7 @@
/**
<!-- Warning: \p .fd does not work but <tt>.fd</tt> does -->
- \page forms Forms Compatibility
+ \page forms Forms Compatibility
This appendix describes the Forms compatibility included with FLTK.
@@ -27,7 +27,7 @@ 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
with the output from FLUID. If you are not interested in this you may
-have more immediate luck with the forms compatibility header, <FL/forms.H>.
+have more immediate luck with the forms compatibility header, <FL/forms.H>.
\section forms_using Using the Compatibility Header File
@@ -42,31 +42,31 @@ without changes.
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.
+files.
Although FLTK was designed to be compatible with the GL Forms
library (version 0.3 or so), XForms has bloated severely and its
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.
+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 <tt>forms.H</tt> a lot.
+even Digital Domain's inhouse code still uses <tt>forms.H</tt> a lot.
\section forms_problems Problems You Will Encounter
Many parts of XForms use X-specific structures like \c 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.
+programs. You will need to rewrite these to use FLTK subclasses.
Fl_Free widgets emulate the \e old Forms "free" widget.
It may be useful for porting programs that change the \c handle()
-function on widgets, but you will still need to rewrite things.
+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
@@ -77,33 +77,33 @@ the \p x, \p y, \p w, \p h, \p 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 <tt>"->x"</tt>
with <tt>"->x()"</tt>, etc.
-Replace <tt>"boxtype"</tt> with <tt>"box()"</tt>.
+Replace <tt>"boxtype"</tt> with <tt>"box()"</tt>.
<tt>const char *</tt> arguments to most FLTK methods are simply
stored, while Forms would \c strdup() the passed string. This is
most noticeable with the label of widgets. Your program must always
pass static data such as a string constant or malloc'd buffer to
\c label(). If you are using labels to display program output you
-may want to try the Fl_Output widget.
+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.
+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 \c user_data()
field of a window. To do this, search through the fdesign output for all
occurrences of <tt>"->fdui"</tt> and edit to use <tt>"->user_data()"</tt>
-instead. This will require casts and is not trivial.
+instead. This will require casts and is not trivial.
The prototype for the functions passed to \c fl_add_timeout()
-and \c fl_set_idle_callback() callback are different.
+and \c fl_set_idle_callback() callback are different.
<B>All the following XForms calls are missing:</B>
\li \c FL_REVISION, \c fl_library_version()
-\li \c FL_RETURN_DBLCLICK (use Fl::event_clicks())
+\li \c FL_RETURN_DBLCLICK (use Fl::event_clicks())
\li \c fl_add_signal_callback()
\li \c fl_set_form_atactivate() \c fl_set_form_atdeactivate()
\li \c fl_set_form_property()
@@ -111,38 +111,38 @@ and \c fl_set_idle_callback() callback are different.
\li \c fl_set_form_minsize(), \c fl_set_form_maxsize()
\li \c fl_set_form_event_cmask(), \c fl_get_form_event_cmask()
\li \c fl_set_form_dblbuffer(), \c fl_set_object_dblbuffer()
- (use an Fl_Double_Window instead)
+ (use an Fl_Double_Window instead)
\li \c fl_adjust_form_size()
\li \c fl_register_raw_callback()
\li \c fl_set_object_bw(), \c fl_set_border_width()
\li \c fl_set_object_resize(), \c fl_set_object_gravity()
\li \c fl_set_object_shortcutkey()
\li \c fl_set_object_automatic()
-\li \c fl_get_object_bbox() (maybe FLTK should do this)
+\li \c fl_get_object_bbox() (maybe FLTK should do this)
\li \c fl_set_object_prehandler(), \c fl_set_object_posthandler()
\li \c fl_enumerate_fonts()
-\li Most drawing functions
-\li \c fl_set_coordunit() (FLTK uses pixels all the time)
+\li Most drawing functions
+\li \c fl_set_coordunit() (FLTK uses pixels all the time)
\li \c fl_ringbell()
\li \c fl_gettime()
-\li \c fl_win*() (all these functions)
-\li \c fl_initialize(argc,argv,x,y,z) ignores last 3 arguments
+\li \c fl_win*() (all these functions)
+\li \c fl_initialize(argc,argv,x,y,z) ignores last 3 arguments
\li \c fl_read_bitmapfile(), \c fl_read_pixmapfile()
\li \c fl_addto_browser_chars()
-\li \c FL_MENU_BUTTON just draws normally
+\li \c FL_MENU_BUTTON just draws normally
\li \c fl_set_bitmapbutton_file(), \c fl_set_pixmapbutton_file()
-\li \c FL_CANVAS objects
-\li \c FL_DIGITAL_CLOCK (comes out analog)
+\li \c FL_CANVAS objects
+\li \c FL_DIGITAL_CLOCK (comes out analog)
\li \c fl_create_bitmap_cursor(), \c fl_set_cursor_color()
\li \c fl_set_dial_angles()
\li \c fl_show_oneliner()
-\li \c fl_set_choice_shortcut(a,b,c)
-\li command log
-\li Only some of file selector is emulated
+\li \c fl_set_choice_shortcut(a,b,c)
+\li command log
+\li Only some of file selector is emulated
\li \c FL_DATE_INPUT
-\li \c fl_pup*() (all these functions)
-\li textbox object (should be easy but I had no sample programs)
-\li xyplot object
+\li \c 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
@@ -166,15 +166,15 @@ 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.
+calls are not in the interface.
You have to make a subclass of Fl_Gl_Window and write a \c draw() method
and \c handle() method. This may require anywhere from a trivial to a
-major rewrite.
+major rewrite.
If you draw into the overlay planes you will have to also write a
\c draw_overlay() method and call \c redraw_overlay() on the
-OpenGL window.
+OpenGL window.
One easy way to hack your program so it works is to make the \c draw()
and \c handle() methods on your window set some static variables, storing
@@ -186,7 +186,7 @@ they are events read from \c fl_queue.
The file <FL/gl.h> defines replacements for a lot of IRISGL
calls, translating them to OpenGL. There are much better translators
-available that you might want to investigate.
+available that you might want to investigate.
\par You Cannot Make Forms Subclasses
@@ -200,10 +200,10 @@ 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.
+"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.
+have to rewrite things a lot.
\par You Cannot Use <device.h>