<a name="Z836">Is there a widget that does            printing?</a>          </h2>          <p>            No. When people ask this question they are usually            looking for an abstract interface that draws either to            the screen or to a printer. There is nothing like that            in GTK+ right now. <tt class="CLASSNAME">            GnomeCanvas</tt> will probably have a feature like this            in a future version.          </p>          <p>            There is a <tt class="APPLICATION">gnome-print</tt>            library available, which handles many unpleasant            low-level details when dealing with fonts and            PostScript. It also comes with a printer-selection            dialog.          </p>        </div>        <div class="SECT2">          <h2 class="SECT2">            <a name="Z837">When I <tt class="FUNCTION">fork()</tt>,            I get a bunch of warnings and my program crashes.            What's going on?</a>          </h2>          <p>            There are two things to remember:          </p>          <ol type="1">            <li>              <p>                The child process must not try to use the GUI;                since it shares file descriptors with the parent,                including GTK+'s connection to the X server, GTK+                will become very confused.&#13;              </p>            </li>            <li>              <p>                The child process must be terminated with <tt                class="FUNCTION">_exit()</tt> rather than <tt                class="FUNCTION">exit()</tt>; calling <tt class=                 "FUNCTION">exit()</tt> will shut down GTK+ and                confuse the parent process. (GTK+ registers a                "cleanup" function using <tt class="FUNCTION">                atexit()</tt>.)&#13;              </p>            </li>          </ol>        </div>        <div class="SECT2">          <h2 class="SECT2">            <a name="Z838">When do I need to call <tt class=             "FUNCTION">gtk_widget_realize()</tt> vs. <tt class=             "FUNCTION">gtk_widget_show()</tt>?</a>          </h2>          <p>            <a href="z57.html#SEC-REALIZINGSHOWING">the section            called <i>Realizing, Mapping, and Showing</i> in the            chapter called <i>GTK+ Basics</i></a> goes into some            detail on this. But here is a brief summary.          </p>          <p>            Showing a widget implies mapping it eventually (to be            precise, it schedules the widget to be mapped when its            parent widgets are mapped). Mapping a widget means            calling <tt class="FUNCTION">gdk_window_show()</tt> to            display the widget's <span class="STRUCTNAME">            GdkWindow</span> on the screen (if it has a <span            class="STRUCTNAME">GdkWindow</span>, some widgets            don't). To map a widget you must first realize it.            Therefore showing a widget implies realizing it.            Therefore if you show a widget you don't need to            explicitly realize it with <tt class="FUNCTION">            gtk_widget_realize()</tt> because it will be realized            eventually anyway.          </p>          <p>            There's one exception, however. To <i class=            "FIRSTTERM">realize</i> a widget means to allocate X            server resources for it, most notably a <span class=             "STRUCTNAME">GdkWindow</span>. Some things you might            want to do require the <span class="STRUCTNAME">            GdkWindow</span> to exist, so you might want to force a            widget to be realized immediately. <tt class=            "FUNCTION">gtk_widget_realize()</tt> does this. Since            parent widgets must be realized before their children,            <tt class="FUNCTION">gtk_widget_realize()</tt> will            immediately realize all of a widget's parents as well.            One of these parents must be a toplevel window, or            realization will not be possible.          </p>          <p>            If you force-realize a widget, you still have to call            <tt class="FUNCTION">gtk_widget_show()</tt> since            realization does not map the widget.          </p>          <p>            A good but not foolproof rule of thumb: if you are            using <span class="STRUCTNAME">            GTK_WIDGET(widget)-&gt;window</span>, you will need            <span class="STRUCTNAME">widget</span> to be realized.          </p>          <p>            However, it should be noted that force-realizing a            widget is always a mildly bad idea; it is inefficient            and uncomfortably low-level. In many cases you can work            around the need to do so.          </p>        </div>        <div class="SECT2">          <h2 class="SECT2">            <a name="Z839">When creating a pixmap, I get the            warning: <tt class="APPLICATION">Creating pixmap from            xpm with NULL window and colormap</tt>. What's            wrong?</a>          </h2>          <p>            Creating a pixmap requires a colormap. <tt class=             "FUNCTION">gdk_pixmap_create_from_xpm_d()</tt> requires            a <span class="STRUCTNAME">GdkWindow</span> argument in            order to extract a colormap. You are probably trying to            use the <span class="STRUCTNAME">window</span> field of            an unrealized widget, which is <span class=            "STRUCTNAME">NULL</span>. You might try the newer            function, <tt class="FUNCTION">            gdk_pixmap_colormap_create_from_xpm_d()</tt> which            accepts a colormap argument; if you pass in a colormap,            its window argument can be <span class="STRUCTNAME">            NULL</span>. However, using Imlib instead is a still            better solution; Imlib's pixmap routines are faster            anyway.          </p>        </div>        <div class="SECT2">          <h2 class="SECT2">            <a name="Z840">How can I separate the GUI from the rest            of my application?</a>          </h2>          <p>            For a variety of reasons, an application's graphical            interface tends to be an exceptionally volatile and            ever-changing piece of software. It's the focus of most            user requests for change. It is difficult to plan and            execute well the first time around---often you will            discover that some aspect of it is unpleasant to use            only after you have written it. Making things worse,            graphical interfaces are not portable across machines;            Gnome works on X windows, but if your application is            useful, it won't be long before someone wants to run            your application on another system, or have a            command-line version, or have a web-based interface.            You might even want to have two interfaces in the same            version---perhaps the GUI, and a scripting language            such as Guile.          </p>          <p>            In practical terms, this means that any large            application should have a radical separation between            its various <i class="FIRSTTERM">frontends</i>, or            interfaces, and the <i class="FIRSTTERM">backend</i>.            The backend should contain all the ``hard parts'': your            algorithms and data structures, the real work done by            the application. Think of it as an abstract ``model''            being displayed to and manipulated by the user.          </p>          <p>            Each frontend should be a ``view'' and a            ``controller.'' As a ``view,'' the frontend must note            any changes in the backend, and change the display            accordingly. As a ``controller,'' the frontend must            allow the user to relay requests for change to the            backend (it defines how manipulations of the frontend            translate into changes in the model).          </p>          <p>            There are many ways to discipline yourself to keep your            application separated. A couple of useful ideas:          </p>          <ul>            <li>              <p>                Write the backend as a library; if this becomes                undesirable for any reason, you can always                statically link.&#13;              </p>            </li>            <li>              <p>                Write at least two frontends from the start; one or                both can be ugly prototypes, you just want to get                an idea how to structure the backend. Remember,                frontends should be easy; the backend has the hard                parts.&#13;              </p>            </li>          </ul>          <p>            If one of your frontends is Gnome- or GTK+- based, an            excellent choice for the other is an interactive Guile            terminal. Your non-expert end users probably won't use            it, but it's a great debugging tool; you can prototype            and test the backend using easy-to-write Guile            bindings, and add the graphical controls only when            things are working. When you're done, you'll have a            scriptable application almost for free.          </p>          <p>            If your application can potentially be run in batch            mode, command line and web interfaces are also            relatively easy to write, useful for debugging, and            will keep you disciplined.          </p>          <p>            Finally, if your project is large enough to justify the            bother and complexity, consider using a cross-platform            frontend layer to share code between GUI frontends on            different platforms. This approach is taken by Mozilla            (<a href="http://www.mozilla.org" target=            "_top">http://www.mozilla.org</a>), and the AbiSource            office suite (<a href="http://www.abisource.com"            target="_top">http://www.abisource.com</a>). It might            be interesting to have a look at their code.          </p>        </div>        <div class="SECT2">          <h2 class="SECT2">            <a name="Z841">I don't like the default appearance of            [some widget]. How do I change its appearance?</a>          </h2>          <p>            Don't program your preferences. GTK+ unfortunately has            all sorts of look and feel settings that the programmer            can affect. For example, you can change the appearance            of the ``expanders'' in a <tt class="CLASSNAME">            GtkCTree</tt>---they can be triangles, squares, or            circles. By default they are squares. You change them            by calling <tt class="FUNCTION">            gtk_ctree_set_expander_style()</tt>.          </p>          <p>            There's no good reason to call this function in an            application. Ever. Think about why you would call            it---because you happen to like that expander style            better. It's a purely cosmetic issue. However, if you            do call it, you've just made your application's look            and feel different from that of every other            application. This is <i class="EMPHASIS">harmful</i>,            because it confuses users and even gives them a sense            that your application is ``unprofessional'' or ``not            quite right.''          </p>          <p>            ``But I want my favorite expanders!,'' you might whine.            Don't despair. There is a correct way to handle this            situation. Variable aspects of look and feel should be            configurable <i class="EMPHASIS">at runtime</i> by <i            class="EMPHASIS">users</i>. What's more, it should be            configurable <i class="EMPHASIS">globally</i>, for <i            class="EMPHASIS">all applications at once</i>. GTK+            provides themes for precisely this purpose.          </p>          <p>            Unfortunately themes do not yet cover all aspects of            look and feel, and so the temptation remains to            hard-code these in your application. You must resist.            If you are dead-set against the default expander style,            or the default dialog position, or whatever, then do            the work to make it configurable on the library level            and submit that code to the GTK+ or Gnome maintainers.          </p>          <p>            You have to do this on the library level---think about            it. If you provide an application-specific way to            configure look and feel, nothing has really been            gained; if someone does like a particular expander            style, they have to go through each program deciding if            and how the style can be changed. Some programs will            invariably be ``stuck'' with the default, since the            authors of those programs didn't make it configurable.            The resulting mess is very annoying to users.          </p>          <p>            Gnome already has solutions for a number of common            cases. For example, GTK+ lets you pop up a dialog at            the mouse pointer, in the center of the screen, or            wherever the window manager wants; there is no reason            you should pick your favorite and use it in your            application. Thus <tt class="CLASSNAME">            GnomeDialog</tt> loads a user preference for the            dialog's initial position. This preference can be set            from the Gnome control center.          </p>        </div>        <div class="SECT2">          <h2 class="SECT2">            <a name="Z842">Thanks for the lecture, but I have a