Doxygen documentation - WP12 and WP13 - first step.

Converted the descriptive chapters of the html docs to doxygen format
and modified index.dox accordingly.

This checkin includes only trivial reformatting, no major rewriting.

Added a chapter "Migrating Code from FLTK 1.1 to 1.3".

All links on the main page are working now.

Todo:
  - Check doxygen error messages, rewrite pages (html tags, contents).
  - Fill the new "Migrating..." chapter.


git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@6224 ea41ed52-d2ee-0310-a9c1-e6b18d33e121

1 files changed, 740 insertions, 0 deletions

diff --git a/documentation/osissues.dox b/documentation/osissues.dox
new file mode 100644
index 000000000..43c13a38c
--- /dev/null
+++ b/documentation/osissues.dox
@@ -0,0 +1,740 @@
+/**
+
+ \page	osissues	F - Operating System Issues
+
+<P>This appendix describes the operating system specific interfaces in FLTK.
+
+<H2>Accessing the OS Interfaces</H2>
+
+<P>All programs that need to access the operating system
+specific interfaces must include the following header file:
+
+<UL><PRE>
+#include &lt;FL/x.H&gt;
+</PRE></UL>
+
+<P>Despite the name, this header file will define the
+appropriate interface for your environment. The pages that
+follow describe the functionality that is provided for each
+operating system.
+
+<CENTER><TABLE WIDTH="90%" BORDER="1" CELLPADDING="5" CELLSPACING="0" BGCOLOR="#cccccc">
+<TR>
+	<TD><B>WARNING:</B>
+
+	<P>The interfaces provided by this header file may
+	change radically in new FLTK releases. Use them only
+	when an existing generic FLTK interface is not
+	sufficient.</P>
+
+	</TD>
+</TR>
+</TABLE></CENTER>
+
+<H2>The UNIX (X11) Interface</H2>
+
+<P>The UNIX interface provides access to the X Window System
+state information and data structures.
+
+<H3>Handling Other X Events</H3>
+
+<H4><A name="add_handler">void Fl::add_handler(int (*f)(int))</A></H4>
+
+<P>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.
+
+<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 in the <A
+href="#fl_xevent"><TT>fl_xevent</TT></A> variable.</P>
+
+<P>The argument is the FLTK event type that was not handled, or
+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, for example
+<TT>FL_SHORTCUT</TT>.</P>
+
+<H4><A name="fl_xevent">extern XEvent *fl_xvent</A></H4>
+
+<P>This variable contains the most recent X event.
+
+<H4><A name="fl_event_time">extern ulong fl_event_time</A></H4>
+
+<P>This variable contains the time stamp from the most recent X
+event that reported it; not all events do. Many X calls like cut
+and paste need this value.
+
+<H4><A name="fl_xid">Window fl_xid(const Fl_Window *)</A></H4>
+
+<P>Returns the XID for a window, or zero if not <TT>shown()</TT>.
+
+<H4><A name="fl_find">Fl_Window *fl_find(ulong xid)</A></H4>
+
+<P>Returns the <TT>Fl_Window</TT> that corresponds to the given
+XID, or <TT>NULL</TT> if not found. This function uses a cache
+so it is slightly faster than iterating through the windows
+yourself.</P>
+
+<H4><A name="fl_handle">int fl_handle(const XEvent &amp;)</A></H4>
+
+<P>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 non-zero if FLTK understood the event. If the
+window does not belong to FLTK and the <TT>add_handler()</TT>
+functions all return 0, this function will return false.
+
+<P>Besides feeding events your code should call <A
+href="Fl.html#Fl.flush"><TT>Fl::flush()</TT></A>
+periodically so that FLTK redraws its windows.</P>
+
+<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="functions.html#fl_ask"><TT>fl_ask()</TT></A>, for
+instance, it will not return until the modal function
+returns.</P>
+
+<H3>Drawing using Xlib</H3>
+
+<P>The following global variables are set before <A
+HREF="subclassing.html#draw"><TT>Fl_Widget::draw()</TT></A> is
+called, or by <A
+href="Fl_Window.html#Fl_Window.make_current"><TT>Fl_Window::make_current()</TT></A>:
+
+<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>
+
+<P>You must use them to produce Xlib calls.  Don't attempt to change
+them. A typical X drawing call is written like this:
+
+<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 found by looking at <A
+href="Fl_Window.html#Fl_Window.make_current"><TT>Fl_Window::current()</TT></A>,
+which returns a pointer to the <TT>Fl_Window</TT> being drawn.
+
+<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>
+
+<P>Returns the X pixel number used to draw the given FLTK color
+index or RGB color. This is the X pixel that <A
+href="drawing.html#fl_color"><TT>fl_color()</TT></A> would use.
+
+<H4><A name="fl_parse_color">int fl_parse_color(const char* p, uchar&amp; r, uchar&amp; g, uchar&amp; b)</A></H4>
+
+<P>Convert a name into the red, green, and blue values of a color
+by parsing the X11 color names. On other systems, <tt>fl_parse_color</tt>
+can only convert names in hexadecimal encoding, for example <tt>#ff8083</tt>.
+ 
+<H4><A name="fl_xfont">extern XFontStruct *fl_xfont</A></H4>
+
+<P>Points to the font selected by the most recent <A
+href="drawing.html#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="drawing.html#text"><TT>fl_draw()</TT></A> is
+called. If FLTK was compiled with Xft support, <TT>fl_xfont</TT>
+will usually be 0 and <TT>fl_xftfont</TT> will contain a pointer 
+to the XftFont structure instead.
+
+<H4><A name="fl_xftfont">extern void *fl_xftfont</A></H4>
+
+<P>If FLTK was compiled with Xft support enabled, <tt>fl_xftfont</tt>
+Points to the xft font selected by the most recent <A
+href="drawing.html#fl_font"><TT>fl_font()</TT></A>. Otherwise 
+it will be 0. <tt>fl_xftfont</tt> should be cast to 
+<tt>XftFont*</tt>.
+
+<H3>Changing the Display, Screen, or X Visual</H3>
+
+<P>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="Fl.html#Fl.visual">Fl::visual()</A>, which is
+a portable interface to get a full color and/or double buffered
+visual.
+
+<H4><A name="display">int Fl::display(const char *)</A></H4>
+
+<P>Set which X display to use.  This actually does
+<TT>putenv(&quot;DISPLAY=...&quot;)</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 MacOS and WIN32 but it has no effect.
+
+<H4><A name="fl_display">extern Display *fl_display</A></H4>
+
+<P>The open X display. This is needed as an argument to most
+Xlib calls. Don't attempt to change it! This is <TT>NULL</TT>
+before the display is opened.
+
+<H4><A name="fl_open_display">void fl_open_display()</A></H4>
+
+<P>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 <TT>show()</TT> of a
+window.
+
+<P>This may call <TT>Fl::abort()</TT> if there is an error
+opening the display.</P>
+
+<H4><A name="fl_close_display">void fl_close_display()</A></H4>
+
+<P>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 functions.
+
+<H4><A name="fl_screen">extern int fl_screen</A></H4>
+
+<P>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 &quot;host:0.#&quot;.
+
+<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 <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><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);
+if (!fl_visual) Fl::abort(&quot;No good visual&quot;);
+fl_colormap = make_a_colormap(fl_display, fl_visual-&gt;visual, fl_visual-&gt;depth);
+// it is now ok to show() windows:
+window-&gt;show(argc, argv);
+</PRE></UL>
+
+<H3>Using a Subclass of Fl_Window for Special X Stuff</H3>
+
+<P>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, and call those libraries when the window needs to be
+redrawn.</P>
+
+<P>To do this, you need to make a subclass of <A
+href="Fl_Window.html#Fl_Window"><TT>Fl_Window</TT></A> and
+override some of these virtual functions:</P>
+
+<H4>virtual void Fl_Window::show()</H4>
+
+<P>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>.
+
+<P>An example:</P>
+
+<UL><PRE>
+void MyWindow::show() {
+  if (shown()) {Fl_Window::show(); return;}  // you must do this!
+  fl_open_display();	// necessary if this is first window
+  // we only calcualte the necessary visual colormap once:
+  static XVisualInfo *visual;
+  static Colormap colormap;
+  if (!visual) {
+    visual = figure_out_visual();
+    colormap = XCreateColormap(fl_display, RootWindow(fl_display,fl_screen),
+                               vis-&gt;visual, AllocNone);
+  }
+  Fl_X::make_xid(this, visual, colormap);
+}
+</PRE></UL>
+
+<H4>Fl_X *Fl_X::set_xid(Fl_Window *, Window xid)</H4>
+
+<P>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>
+
+<P>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.
+
+<H4>virtual void Fl_Window::flush()</H4>
+
+<P>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 <TT>damage()</TT>
+calls done so far is in <TT>Fl_X::i(this)-&gt;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> will own and delete it when
+done.</P>
+
+<P>If <TT>damage() &amp; 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>
+
+<P>Here is a sample where an undamaged image is kept somewhere:</P>
+
+<UL><PRE>
+void MyWindow::flush() {
+  fl_clip_region(Fl_X::i(this)-&gt;region);
+  Fl_X::i(this)-&gt;region = 0;
+  if (damage() != 2) {... draw things into backing store ...}
+  ... copy backing store to window ...
+}
+</PRE></UL>
+
+<H4>virtual void Fl_Window::hide()</H4>
+
+<P>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:
+
+<UL><PRE>
+void MyWindow::hide() {
+  if (mypixmap) {
+    XFreePixmap(fl_display,mypixmap);
+    mypixmap = 0;
+  }
+  Fl_Window::hide(); // you must call this
+}
+</PRE></UL>
+
+<H4>virtual void Fl_Window::~Fl_Window()</H4>
+
+<P>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):
+
+<UL><PRE>
+MyWindow::~MyWindow() {
+  hide();
+}
+</PRE></UL>
+
+<H3>Setting the Icon of a Window</H3>
+
+<P>FLTK currently supports setting a window's icon <b>before</b> it
+is shown using the <TT>Fl_Window::icon()</TT> method.
+
+<H4>void Fl_Window::icon(char *)</H4>
+
+<P>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 a monochrome icon using a bitmap compiled
+with your application use:
+
+<UL><PRE>
+#include &quot;icon.xbm&quot;
+
+fl_open_display(); // needed if display has not been previously opened
+
+Pixmap p = XCreateBitmapFromData(fl_display, DefaultRootWindow(fl_display),
+                                 icon_bits, icon_width, icon_height);
+
+window-&gt;icon((char *)p);
+</PRE></UL>
+
+<P>To use a multi-colored icon, the XPM format and library
+should be used as follows:
+
+<UL><PRE>
+#include &lt;X11/xpm.h&gt;
+#include &quot;icon.xpm&quot;
+
+fl_open_display();                // needed if display has not been previously opened
+
+Pixmap p, mask;
+
+XpmCreatePixmapFromData(fl_display, DefaultRootWindow(fl_display),
+                                 icon_xpm, &amp;p, &amp;mask, NULL);
+
+window-&gt;icon((char *)p);
+</PRE></UL>
+
+<p>When using the Xpm library, be sure to include it in the list
+of libraries that are used to link the application (usually
+"-lXpm").</p>
+
+<CENTER><TABLE WIDTH="90%" BORDER="1" CELLPADDING="5" CELLSPACING="0" BGCOLOR="#cccccc">
+<TR>
+	<TD><B>NOTE:</B>
+	
+	<P>You must call <A
+	HREF="Fl_Window.html#Fl_Window.show"><TT>Fl_Window::show(argc,
+	argv)</TT></A> for the icon to be used. The
+	<TT>Fl_Window::show()</TT> method does not bind the icon
+	to the window.
+
+	</TD>
+</TR>
+</TABLE></CENTER>
+
+<H3>X Resources</H3>
+
+<P>When the <A
+HREF="Fl_Window.html#Fl_Window.show"><TT>Fl_Window::show(argc,
+argv)</TT></A> method is called, FLTK looks for the following X
+resources:
+
+<UL>
+
+	<LI><TT>background</TT> - The default background color
+	for widgets (color).
+
+	<LI><TT>dndTextOps</TT> - The default setting for
+	drag and drop text operations (boolean).
+
+	<LI><TT>foreground</TT> - The default foreground (label)
+	color for widgets (color).
+
+	<LI><TT>scheme</TT> - The default scheme to use
+	(string).
+
+	<LI><TT>selectBackground</TT> - The default selection
+	color for menus, etc. (color).
+
+	<LI><TT>Text.background</TT> - The default background
+	color for text fields (color).
+
+	<LI><TT>tooltips</TT> - The default setting for
+	tooltips (boolean).
+
+	<LI><TT>visibleFocus</TT> - The default setting for
+	visible keyboard focus on non-text widgets (boolean).
+
+</UL>
+
+<P>Resources associated with the first window's <A
+HREF="Fl_Window.html#Fl_Window.xclass"><TT>Fl_Window::xclass()</TT></A>
+string are queried first, or if no class has been specified then
+the class "fltk" is used (e.g. <TT>fltk.background</TT>). If no
+match is found, a global search is done (e.g.
+<TT>*background</TT>).
+
+<H2>The Windows (WIN32) Interface</H2>
+
+<P>The Windows interface provides access to the WIN32 GDI
+state information and data structures.
+
+<H3>Handling Other WIN32 Messages</H3>
+
+<P>By default a single WNDCLASSEX called &quot;FLTK&quot; is
+created. All <TT>Fl_Window</TT>'s 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 WIN32 window classes. The easiest way is to call
+<TT>Fl::wait()</TT>, as 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
+<TT>DispatchMessage()</TT>, but you will have to arrange for the
+function <TT>Fl::flush()</TT> to be called regularly so that
+widgets are updated, timeouts are handled, and the idle
+functions are called.</P>
+
+<H4><A name="fl_msg">extern MSG fl_msg</A></H4>
+
+<P>This variable contains the most recent message read by
+<TT>GetMessage</TT>, which is called by <A
+href="Fl.html#Fl.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).
+
+<H4><A name="WIN32.add_handler">void Fl::add_handler(int (*f)(int))</A></H4>
+
+<P>Installs 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
+functions is the FLTK event that was not handled or zero for
+unknown messages. If all the handlers return zero then FLTK
+calls <TT>DefWindowProc()</TT>.
+
+<H4><A name="WIN32.fl_xid">HWND fl_xid(const Fl_Window *)</A></H4>
+
+<P>Returns the window handle for a <TT>Fl_Window</TT>, or zero
+if not <TT>shown()</TT>.
+
+<H4><A name="WIN32.fl_find">Fl_Window *fl_find(HWND xid)</A></H4>
+
+<P>Returns the <TT>Fl_Window</TT> that corresponds to the given
+window handle, or <TT>NULL</TT> if not found. This function uses
+a cache so it is slightly faster than iterating through the
+windows yourself.
+
+<H3><A name="WIN32.gdi">Drawing Things Using the WIN32 GDI</A></H3>
+
+<P>When the virtual function <A
+HREF="subclassing.html#draw"><TT>Fl_Widget::draw()</TT></A> is
+called, FLTK stores all the silly extra arguments you need to
+make a proper GDI call in some global variables:
+
+<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>
+
+<P>These global variables are set before <TT>draw()</TT> is
+called, or by <A
+href="Fl_Window.html#Fl_Window.make_current"><TT>Fl_Window::make_current()</TT></A>.
+You can refer to them when needed to produce GDI calls, but don't
+attempt to change them. The functions return GDI objects for
+the current color set by <TT>fl_color()</TT> and are created as
+needed and cached. A typical GDI drawing call is written like
+this:
+
+<UL><PRE>
+DrawSomething(fl_gc, ..., fl_brush());
+</PRE></UL>
+
+<P>It may also be useful to refer to <A
+href="Fl_Window.html#Fl_Window.make_current"><TT>Fl_Window::current()</TT></A>
+to get the window's size or position.
+
+<H3>Setting the Icon of a Window</H3>
+
+<P>FLTK currently supports setting a window's icon *before* it
+is shown using the <TT>Fl_Window::icon()</TT> method.
+
+<H4>void Fl_Window::icon(char *)</H4>
+
+<P>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:
+
+<UL><PRE>
+window-&gt;icon((char *)LoadIcon(fl_display, MAKEINTRESOURCE(IDI_ICON)));
+</PRE></UL>
+
+<P>You can also use the <TT>LoadImage()</TT> and related
+functions to load specific resolutions or create the icon from
+bitmap data.
+
+<CENTER><TABLE WIDTH="90%" BORDER="1" CELLPADDING="5" CELLSPACING="0" BGCOLOR="#cccccc">
+<TR>
+	<TD><B>NOTE:</B>
+	
+	<P>You must call <A
+	HREF="Fl_Window.html#Fl_Window.show"><TT>Fl_Window::show(argc,
+	argv)</TT></A> for the icon to be used. The
+	<TT>Fl_Window::show()</TT> method does not bind the icon
+	to the window.
+
+	</TD>
+</TR>
+</TABLE></CENTER>
+
+<H3>How to Not Get a MSDOS Console Window</H3>
+
+<P>WIN32 has a really stupid mode switch stored in the
+executables that controls whether or not to make a console
+window.
+
+<P>To always get a console window you simply create a console
+application (the &quot;/SUBSYSTEM:CONSOLE&quot; option for the
+linker). For a GUI-only application create a WIN32 application
+(the &quot;/SUBSYSTEM:WINDOWS&quot; option for the linker).</P>
+
+<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>
+
+<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.
+Additionally, WIN32 applications are run in the background by
+the console, although you can use "start /wait program" to run
+them in the foreground.</P>
+
+<H3>Known WIN32 Bugs and Problems</H3>
+
+<P>The following is a list of known bugs and problems in the WIN32
+version of FLTK:
+
+<UL>
+
+	<LI>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. We were
+	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.</LI>
+
+	<LI><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.</LI>
+
+	<LI><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.</LI>
+
+	<LI>Compilation with <TT>gcc 3.4.4</TT> and <TT>-Os</TT> exposes an
+	optimisation bug in gcc. The symptom is that when drawing
+	filled circles only the perimeter is drawn. This can for instance
+	be seen in the symbols demo. Other optimisation options such
+	as -O2 and -O3 seem to work OK. More details can be found
+	in STR#1656 </LI>
+</UL>
+
+<H2>The MacOS Interface</h2>
+
+<P>FLTK supports MacOS X using the Apple Carbon library. Older
+versions of MacOS are <I>not</I> supported.
+
+<H4>Control, Option, and Command Modifier Keys</H4>
+
+<P>FLTK maps the Mac 'control' key to <TT>FL_CTRL</TT>, the
+'option' key to <TT>FL_ALT</TT> and the 'Apple' key to
+<TT>FL_META</TT>. Keyboard events return the key name in
+<TT>Fl::event_key()</TT> and the keystroke translation in
+<TT>Fl::event_text()</TT>. For example, typing Option-Y on a Mac
+keyboard will set <TT>FL_ALT</TT> in <TT>Fl::event_state()</TT>,
+set <TT>Fl::event_key()</TT> to 'y' and return the Yen symbol in
+<TT>Fl::event_text()</TT>.
+
+<H4>WindowRef fl_xid(const Fl_Window *)</H4>
+
+<P>Returns the window reference for an <tt>Fl_Window</tt>, or
+<TT>NULL</TT> if the window has not been shown.
+
+<h4>Fl_Window *fl_find(WindowRef xid)</h4>
+
+<P>Returns the <tt>Fl_Window</tt> that corresponds to the give
+window handle, or <TT>NULL</TT> if not found. FLTK windows that
+are children of top-level windows share the WindowRef of the
+top-level window.
+
+<h3>Apple "Quit" Event</h3>
+
+<P>When the user press Cmd-Q or requests a termination of the
+application, OS X will send a "Quit" Apple Event. FLTK handles
+this event by sending an <tt>FL_CLOSE</tt> event to all open
+windows. If all windows close, the application will terminate.
+
+<h3>Apple "Open" Event</h3>
+
+Whenever the user drops a file onto an application icon, OS X
+generates an Apple Event of the type "Open". You can have FLTK
+notify you of an Open event by setting the <tt>fl_open_callback</tt>.
+
+<h4><a name=fl_open_callback>void fl_open_callback(void (*cb)(const char *))</a></h4>
+
+<tt>cb</tt> will be called with a single iUnix-style file name and path.
+If multiple files were dropped, <tt>fl_open_callback</tt> will be called
+multiple times.
+
+<h3>Drawing Things Using QuickDraw</h3>
+
+<P>When the virtual function <tt>Fl_Widget::draw()</tt> is
+called, FLTK has prepared the Window and CGrafPort for drawing.
+Clipping and offsets are prepared to allow correct subwindow
+drawing.
+
+<h3>Drawing Things Using Quartz</h3>
+
+<P>If the FLTK library was compiled using the configuration
+flag <tt>--enable-quartz</tt>, all code inside <tt>Fl_Widget::draw()</tt>
+is expected to call Quartz drawing functions instead of 
+QuickDraw. The Quartz coordinate system is flipped to match
+FLTK's coordinate system. The origin for all drawing is in the top
+left corner of the enclosing <tt>Fl_Window</tt>.
+
+<h3>Fl_Double_Window</h3>
+
+<P>OS X double-buffers all windows automatically. On OS X,
+<tt>Fl_Window</tt> and <tt>Fl_Double_Window</tt> are handled
+internally in the same way.
+
+<h3>Mac File System Specifics</h3>
+
+<h4>Resource Forks</h4>
+
+<P>FLTK does not access the resource fork of an application.
+However, a minimal resource fork must be created for OS X
+applications
+
+<CENTER><TABLE WIDTH="80%" BORDER="1" BGCOLOR="#cccccc" CELLPADDING="5">
+<TR><TD><B>Caution:</B>
+
+<P>When using UNIX commands to copy or move executables, OS X
+will NOT copy any resource forks! For copying and moving use
+CpMac and MvMac respectively. For creating a tar archive, all
+executables need to be stripped from their Resource Fork before
+packing, e.g. "DeRez fluid &gt; fluid.r". After unpacking the
+Resource Fork needs to be reattached, e.g. "Rez fluid.r -o
+fluid".
+</TD></TR></TABLE></CENTER>
+
+<P>It is advisable to use the Finder for moving and copying and
+Mac archiving tools like Sit for distribution as they will
+handle the Resource Fork correctly. 
+
+<h4>Mac File Paths</h4>
+
+<P>FLTK uses UNIX-style filenames and paths.
+
+<H3>Known MacOS Bugs and Problems</H3>
+
+<P>The following is a list of known bugs and problems in the
+MacOS version of FLTK:
+
+<UL>
+
+	<LI>Line styles are not well supported. This is due to
+	limitations in the QuickDraw interface.</LI>
+
+	<li>Nested subwindows are not supported, i.e. you can
+	have a <tt>Fl_Window</tt> widget inside a
+	<tt>Fl_Window</tt>, but not a <tt>Fl_Window</tt> inside a
+	<tt>Fl_Window</tt> inside a <tt>Fl_Window</tt>.</li>
+
+</UL>
+
+*/