faqs.html

gtk_text program sample&eg

            <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