@ -864,6 +864,17 @@ you want the window to hide and then reappear at a new position,
@@ -864,6 +864,17 @@ you want the window to hide and then reappear at a new position,
you should have your program set the hotspot itself just before
<tt>show()</tt>.
<P>The <B>Border</B> button turns the window manager border on
or off. On most window managers you will have to close the
window and reopen it to see the effect.
<H4>X Class (text field)</H4>
<P>The string typed into here is passed to the X window manager
as the class. This can change the icon or window decorations.
On most (all?) window managers you will have to close the window
it) is almost identical to the panel for any other Fl_Widget.
There are three extra items:</P>
<H4>Border</H4>
<P>This button turns the window manager border on or off. On
most window managers you will have to close the window and
reopen it to see the effect.
<H4>xclass</H4>
<H3><Aname="images">Images</A></H3>
<P>The string typed into here is passed to the X window manager
as the class. This can change the icon or window decorations.
On most (all?) window managers you will have to close the window
and reopen it to see the effect.
<H3><Aname="images">Image Labels</A></H3>
<P>Selecting "Image..." off the label style pull-down
menu will bring up a file chooser from which you pick the image
file. If an image has already been chosen, you can change the
image used by picking "Image..." again. The name of
the image will appear in the "label" field, but you
can't edit it.</P>
<P>The <I>contents</I> of the image file are written to the
<TT>.cxx</TT> file, so if you wish to distribute the C code, you
only need to copy the <TT>.cxx</TT> file, not the images. If
many widgets share the same image then only one copy is
written.</P>
<P>The <I>contents</I> of the image files in the <B>Image</B>
and <B>Inactive</B> text fields are written to the <TT>.cxx</TT>
file. If many widgets share the same image then only one copy is
written. Since the image data is embedded in the generated
source code, you need only distribute the C++ code and not the
image files themselves.</P>
<P>However the <I>filename</I>is stored in the <TT>.fl</TT>
file, so to read the <TT>.fl</TT> file you need the image files
as well. Filenames are relative to the location the
<TT>.fl</TT> file is (not necessarily the current directory). I
<P>However, the <I>filenames</I> are stored in the <TT>.fl</TT>
file so you will need the image files as well to read the
<TT>.fl</TT> file. Filenames are relative to the location of the
<TT>.fl</TT> file and not necessarily the current directory. We
recommend you either put the images in the same directory as the
<TT>.fl</TT> file, or use absolute path names.</P>
<H4>Notes for all image types</H4>
<H4>Notes for All Image Types</H4>
<P>FLUID runs using the default visual of your X server. This
may be 8 bits, which will give you dithered images. You may get
@ -1151,78 +1143,84 @@ and source X pixmap. Thus once you have put an image on a
@@ -1151,78 +1143,84 @@ and source X pixmap. Thus once you have put an image on a
widget, it is nearly free to put the same image on many other
widgets.</P>
<P>If you are using a painting program to edit an image: the
only way to convince FLUID to read the image file again is to
remove the image from all widgets that are using it (including
ones in closed windows), which will cause it to free its
internal copy, and then set the image again. You may find it
easier to exit FLUID and run it again.</P>
<P>If you edit an image at the same time you are using it in FLUID,
the only way to convince FLUID to read the image file again is to
remove the image from all widgets that are using it or re-load the
<TT>.fl</TT> file.</P>
<P>Don't rely on how FLTK crops images that are outside the
widget, as this may change in future versions! The cropping of
inside labels will probably be unchanged.</P>
<P>To more accurately place images, make a new "box"
widget and put the image in that as the label. This is also how
you can put both an image and text label on the same widget. If
your widget is a button, and you want the image inside it, you
must change the button's boxtype to <TT>FL_UP_FRAME</TT> (or
another frame), otherwise when it is pushed it will erase the
image.</P>
widget and put the image in that as the label.</P>
<H4>XBM (X bitmap files)</H4>
<H4>XBM (X Bitmap) Files</H4>
<P>FLUID will read X bitmap files. These files have C source
code to define a bitmap. Sometimes they are stored with the
".h" or ".bm" extension rather than the
standard ".xbm".
<P>FLUID reads X bitmap files which use C source code to define
a bitmap. Sometimes they are stored with the ".h" or
".bm" extension rather than the standard
".xbm" extension.
<P>FLUID will output code to construct an Fl_Bitmap widget and
use it to label the widget. The '1' bits in the bitmap are
drawn using the label color of the widget. You can change the
color in FLUID. The '0' bits are transparent.</P>
<P>FLUID writes code to construct an Fl_Bitmap image and use it
to label the widget. The '1' bits in the bitmap are drawn using
the label color of the widget. You can change this color in the
FLUID widget attributes panel. The '0' bits are transparent.</P>
<P>The program "bitmap" on the X distribution does an
ok job of editing bitmaps.</P>
<H4>XPM (X pixmap files)</H4>
<P>FLUID will read X pixmap files as used by the libxpm library.
These files have C source code to define a pixmap. The
filenames usually have a ".xpm" extension.
<P>FLUID will output code to construct an Fl_Pixmap widget and
use it to label the widget. The label color of the widget is
ignored, even for 2-color images that could be a bitmap.</P>
<P>XPM files can mark a single color as being transparent.
Currently FLTK and FLUID simulate this transparency rather
badly. It will use the color() of the widget as the background,
and all widgets using the same pixmap are assumed to have the
same color. This may be fixed in the future or on non-X
systems.</P>
<P>I have not found any good editors for small iconic pictures.
Michael R Sweet
23 years ago
