mirror of https://github.com/fltk/fltk
691 lines
23 KiB
HTML
691 lines
23 KiB
HTML
<HTML>
|
|
<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_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.
|
|
|
|
<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_opendisplay(); // 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>Drawing Things Using the WIN32 GDI</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>
|
|
|
|
</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>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.
|
|
|
|
<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>
|