diff options
| author | Fabien Costantini <fabien@onepost.net> | 2008-10-14 22:12:25 +0000 |
|---|---|---|
| committer | Fabien Costantini <fabien@onepost.net> | 2008-10-14 22:12:25 +0000 |
| commit | 497afccb07164373e0de6639e754d7d691f1926f (patch) | |
| tree | 449d0b92ceb05f39617fe8fc2876d16eecde7460 /documentation/osissues.html | |
| parent | e08fffdfe08bbc9320e39a15d162b6501abd4925 (diff) | |
Doxygen pdf man: First version added in documentation/fltk.pdf, old doc removed, images, dox files moved to a new src directory.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@6431 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Diffstat (limited to 'documentation/osissues.html')
| -rw-r--r-- | documentation/osissues.html | 745 |
1 files changed, 0 insertions, 745 deletions
diff --git a/documentation/osissues.html b/documentation/osissues.html deleted file mode 100644 index b0512edcf..000000000 --- a/documentation/osissues.html +++ /dev/null @@ -1,745 +0,0 @@ -<HTML> -<HEAD> - <TITLE>F - Operating System Issues</TITLE> -</HEAD> -<BODY> - -<H1 ALIGN="RIGHT"><A NAME="osissues">F - Operating System Issues</A></H1> - -<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 <FL/x.H> -</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 &)</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& r, uchar& g, uchar& 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("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 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 "host:0.#". - -<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("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></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->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)->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() & 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)->region); - Fl_X::i(this)->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 "icon.xbm" - -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->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 <X11/xpm.h> -#include "icon.xpm" - -fl_open_display(); // needed if display has not been previously opened - -Pixmap p, mask; - -XpmCreatePixmapFromData(fl_display, DefaultRootWindow(fl_display), - icon_xpm, &p, &mask, NULL); - -window->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 "FLTK" 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->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 "/SUBSYSTEM:CONSOLE" option for the -linker). For a GUI-only application create a WIN32 application -(the "/SUBSYSTEM:WINDOWS" 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 > 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> - -</BODY> -</HTML> |