Re: FAQ work

["Tshepang Lekhonkhobe" <tshepang gmail com>]

On 4/27/07, Tim Janik <timj imendio com> wrote:
> using svn blame gtkfaq.sgml and svn blame gtk-faq.sgml,
> it looks like gtkfaq.sgml is a fair bit older. if you
> can verify that gtk-faq.sgml contains everything from
> gtkfaq.sgml and more, we can remove gtkfaq.sgml from SVN.

Shown below are 2 differences I found between the two that are worth
looking at. The info was possibly removed because it was outdated.
Please verify:
"""
<!-- ----------------------------------------------------------------- -->
<sect1>When compiling programs with GTK+, I get compiler error
messages about not being able to find <tt/"glibconfig.h"/.
<p>
The header file "glibconfig.h" was moved to the directory
$exec_prefix/lib/glib/include/. $exec_prefix is the
directory that was specified by giving the --exec-prefix
flags to ./configure when compiling GTK+. It defaults to
$prefix, (specified with --prefix), which in turn defaults
to /usr/local/.

This was done because "glibconfig.h" includes architecture
dependent information, and the rest of the include files
are put in $prefix/include, which can be shared between different
architectures.

GTK+ includes a shell script, <tt/gtk-config/, that
makes it easy to find out the correct include paths.
The GTK+ tutorial includes an example of using <tt/gtk-config/
for simple compilation from the command line. For information
about more complicated configuration, see the file
docs/gtk-config.txt in the GTK+ distribution.

If you are trying to compile an old program, you may
be able to work around the problem by configuring it
with a command line like:

<tscreen><verb>
CPPFLAGS="-I/usr/local/include/glib/include" ./configure
</verb></tscreen>

for Bourne-compatible shells like bash, or for csh variants:

<tscreen><verb>
setenv CPPFLAGS "-I/usr/local/include/glib/include"
./configure
</verb></tscreen>

(Substitute the appropriate value of $exec_prefix for /usr/local.)
"""

on the question of GTK's threadsafety this removed:

"""
<!-- This is the old answer - TRG

Although GTK+, like many X toolkits, isn't thread safe, this does
not prohibit the development of multi-threaded applications with
GTK+.

Rob Browning (rlb cs utexas edu) describes threading techniques for
use with GTK+ (slightly edited):

There are basically two main approaches, the first is simple, and the
second complicated. In the first, you just make sure that all GTK+ (or
X) interactions are handled by one, and
only one, thread. Any other thread that wants to draw something has
to somehow notify the "GTK+" thread, and let it handle the
actual work.

The second approach allows you to call GTK+ (or X) functions from any
thread, but it requires some careful synchronization. The
basic idea is that you create an X protection mutex, and no one may
make any X calls without first acquiring this mutex.

Note that this is a little effort, but it allows you to be
potentially more efficient than a completely thread safe GTK+. You
get to decide the granularity of the thread locking. You also have to
make sure that the thread that calls <tt/gtk_main()/ is holding the lock when
it calls <tt/gtk_main()/.

The next thing to worry about is that since you were holding the
global mutex when you entered <tt/gtk_main()/, all callbacks will also be
holding it. This means that the callback must release it if it's
going to call any other code that might reacquire it. Otherwise
you'll get deadlock. Also, you must be holding the mutex when you
finally return from the callback.

In order to allow threads other than the one calling <tt/gtk_main/ to
get access to the mutex, we also need to register a work function
with GTK that allows us to release the mutex periodically.

Why can't GTK+ be thread safe by default?

Complexity, overhead, and manpower.  The proportion of threaded
programs is still reasonably small, and getting thread safety right is
both quite difficult and takes valuable time away from the main work
of getting a good graphics library finished.  It would be nice to have
GTK+ thread safe "out of the box", but that's not practical right now,
and it also might make GTK+ substantially less efficient if not handled
carefully.

Regardless, it's especially not a priority since relatively good
workarounds exist.
-->
"""

If the above two are not irrelevant anymore, then I assure that
gtkfaq.sgml can safely be removed.