+Mon May 11 17:54:44 BST 1998 Tony Gale <gale@gtk.org>
+
+ * gtkfaq.sgml: add question on multi-threading,
+ minor URL cleanups.
+
Mon May 11 09:56:45 1998 Tim Janik <timj@gtk.org>
* configure.in (cflags_set): preserve automake CFLAGS.
+Mon May 11 17:54:44 BST 1998 Tony Gale <gale@gtk.org>
+
+ * gtkfaq.sgml: add question on multi-threading,
+ minor URL cleanups.
+
Mon May 11 09:56:45 1998 Tim Janik <timj@gtk.org>
* configure.in (cflags_set): preserve automake CFLAGS.
+Mon May 11 17:54:44 BST 1998 Tony Gale <gale@gtk.org>
+
+ * gtkfaq.sgml: add question on multi-threading,
+ minor URL cleanups.
+
Mon May 11 09:56:45 1998 Tim Janik <timj@gtk.org>
* configure.in (cflags_set): preserve automake CFLAGS.
+Mon May 11 17:54:44 BST 1998 Tony Gale <gale@gtk.org>
+
+ * gtkfaq.sgml: add question on multi-threading,
+ minor URL cleanups.
+
Mon May 11 09:56:45 1998 Tim Janik <timj@gtk.org>
* configure.in (cflags_set): preserve automake CFLAGS.
+Mon May 11 17:54:44 BST 1998 Tony Gale <gale@gtk.org>
+
+ * gtkfaq.sgml: add question on multi-threading,
+ minor URL cleanups.
+
Mon May 11 09:56:45 1998 Tim Janik <timj@gtk.org>
* configure.in (cflags_set): preserve automake CFLAGS.
+Mon May 11 17:54:44 BST 1998 Tony Gale <gale@gtk.org>
+
+ * gtkfaq.sgml: add question on multi-threading,
+ minor URL cleanups.
+
Mon May 11 09:56:45 1998 Tim Janik <timj@gtk.org>
* configure.in (cflags_set): preserve automake CFLAGS.
+Mon May 11 17:54:44 BST 1998 Tony Gale <gale@gtk.org>
+
+ * gtkfaq.sgml: add question on multi-threading,
+ minor URL cleanups.
+
Mon May 11 09:56:45 1998 Tim Janik <timj@gtk.org>
* configure.in (cflags_set): preserve automake CFLAGS.
<!-- NOTE: Use only one author tag, otherwise sgml2txt barfs - TRG -->
<author>Nathan Froyd, Tony Gale, Shawn T. Amundson.
-<date>April 6nd 1998
+<date>May 11th 1998
<abstract>
This document is intended to answer questions that are likely to be
frequently asked by programmers using GTK+ or people who are just
<p>
Ask on gtk-list for suggestions. There are at least four IRC
-clients already under development
+clients already under development.
<itemize>
<item>girc. (Included with GNOME)
$prefix, (specified with --prefix), which in turn defaults
to /usr/local/.
-<p> This was done because "glibconfig.h" includes architecture
+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.
-<p> GTK+ includes a shell script, <tt/gtk-config/, that
+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.
-<p> If you are trying to compile an old program, you may
+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
+CPPFLAGS="-I/usr/local/include/glib/include" ./configure
</verb></tscreen>
-<p>
for Bourne-compatible shells like bash, or for csh variants:
<tscreen><verb>
-setenv CPPFLAGS "-I/usr/local/include/glib/include
+setenv CPPFLAGS "-I/usr/local/include/glib/include"
./configure
</verb></tscreen>
-<p>
(Substitute the appropriate value of $exec_prefix for /usr/local.)
<!-- ----------------------------------------------------------------- -->
Yes. There is
<itemize>
<item>a C++ wrapper for GTK+ called gtk--. You can find the home page at:
-<verb>
-http://www.cs.tut.fi/~p150650/gtk/gtk--.html
-</verb>
-The FTP site is:
-<verb>
-ftp://ftp.gtk.org/pub/gtk/gtk--/
-</verb>
+<htmlurl url="http://www.cs.tut.fi/~p150650/gtk/gtk--.html"
+name="http://www.cs.tut.fi/~p150650/gtk/gtk--.html">.
+The FTP site is
+<htmlurl url="ftp://ftp.gtk.org/pub/gtk/gtk--"
+name="ftp://ftp.gtk.org/pub/gtk/gtk--">.
<p>
<item>There are two Objective-c bindings currently in development:
</itemize>
<p>
<item>Perl bindings
-<verb>
-ftp://ftp.gtk.org/pub/gtk/perl
-</verb>
-
-<item>Guile bindings. The home page is at:
-<verb>
-http://www.ping.de/sites/zagadka/guile-gtk/
-</verb>
+<htmlurl url="ftp://ftp.gtk.org/pub/gtk/perl"
+name="ftp://ftp.gtk.org/pub/gtk/perl">
+<P>
+<item>Guile bindings. The home page is at
+<htmlurl url="http://www.ping.de/sites/zagadka/guile-gtk"
+name="http://www.ping.de/sites/zagadka/guile-gtk">.
By the way, Guile is the GNU Project's implemention of R4RS Scheme (the
standard). If you like Scheme, you may want to take a look at this.
<p>
The basics of the system, including callbacks, work fine.
The current development is in
-http://www.ens-lyon.fr/~dmonniau/arcs/
+<htmlurl url="http://www.ens-lyon.fr/~dmonniau/arcs"
+name="http://www.ens-lyon.fr/~dmonniau/arcs">
</quote>
<item>
-Several python-gtk interfaces have been done. python-gtk is at:
-<verb>
-http://www.acs.ucalgary.cs/~nashceme/python-gtk/
-</verb>
-If you try python-gtk and don't like it, there's also pygtk located at:
-<verb>
-ftp://ftp.gtk.org/pub/gtk/python/
-</verb>
-
+Several python bindings have been done:
+<p>
+<itemize>
+<item>pygtk is at
+<htmlurl url="http://www.daa.com.au/~james/pygtk"
+name="http://www.daa.com.au/~james/pygtk"> and
+<htmlurl url="ftp://ftp.gtk.org/pub/gtk/python"
+name="ftp://ftp.gtk.org/pub/gtk/python">
+<item>python-gtk is at
+<htmlurl url="http://www.ucalgary.ca/~nascheme/python-gtk"
+name="http://www.ucalgary.ca/~nascheme/python-gtk">
+</itemize>
+<p>
<item>
-There's a OpenGL/Mesa widget available for GTK+. Grab it at:
-<verb>
-http://www.sakuranet.or.jp/~aozasa/shige/doc/comp/gtk/gtkGL/files-en.html
-</verb>
+There's a OpenGL/Mesa widget available for GTK+. Grab it at
+<htmlurl url="http://www.sakuranet.or.jp/~aozasa/shige/doc/comp/gtk/gtkGL/files-en.html"
+name="http://www.sakuranet.or.jp/~aozasa/shige/doc/comp/gtk/gtkGL/files-en.html">
</itemize>
`GtkVSeparator
</verb>
+<!-- ----------------------------------------------------------------- -->
+<sect1>Is GTK+ thread safe? How do I write multi-threaded GTK+ applications?
+<p>
+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 gtk_main is holding the lock when
+it calls gtk_main.
+
+The next thing to worry about is that since you were holding the
+global mutex when you entered 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 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.
+
<!-- ----------------------------------------------------------------- -->
<sect1>How can I prevent redrawing and resizing while I change multiple widgets?
<p>
speed since it will prevent resizing of the entire widget hierarchy.
<!-- ----------------------------------------------------------------- -->
-<sect1>How do I catch a double click event in a list widget?
+<sect1>How do I catch a double click event (in a list widget, for example)?
<p>
Tim Janik wrote to gtk-list (slightly modified):
/* something else */
}
</verb></tscreen>
-
+
+and, Owen Taylor wrote:
+
+Note that a single button press will be received beforehand, and
+if you are doing this for a button, you will therefore also get a
+"clicked" signal for the button. (This is going to be true for
+any toolkit, since computers aren't good at reading one's
+mind.)
+
<!-- ----------------------------------------------------------------- -->
<sect1>How do I find out about the selection of a GtkList?
<p>
<!-- NOTE: Use only one author tag, otherwise sgml2txt barfs - TRG -->
<author>Nathan Froyd, Tony Gale, Shawn T. Amundson.
-<date>April 6nd 1998
+<date>May 11th 1998
<abstract>
This document is intended to answer questions that are likely to be
frequently asked by programmers using GTK+ or people who are just
<p>
Ask on gtk-list for suggestions. There are at least four IRC
-clients already under development
+clients already under development.
<itemize>
<item>girc. (Included with GNOME)
$prefix, (specified with --prefix), which in turn defaults
to /usr/local/.
-<p> This was done because "glibconfig.h" includes architecture
+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.
-<p> GTK+ includes a shell script, <tt/gtk-config/, that
+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.
-<p> If you are trying to compile an old program, you may
+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
+CPPFLAGS="-I/usr/local/include/glib/include" ./configure
</verb></tscreen>
-<p>
for Bourne-compatible shells like bash, or for csh variants:
<tscreen><verb>
-setenv CPPFLAGS "-I/usr/local/include/glib/include
+setenv CPPFLAGS "-I/usr/local/include/glib/include"
./configure
</verb></tscreen>
-<p>
(Substitute the appropriate value of $exec_prefix for /usr/local.)
<!-- ----------------------------------------------------------------- -->
Yes. There is
<itemize>
<item>a C++ wrapper for GTK+ called gtk--. You can find the home page at:
-<verb>
-http://www.cs.tut.fi/~p150650/gtk/gtk--.html
-</verb>
-The FTP site is:
-<verb>
-ftp://ftp.gtk.org/pub/gtk/gtk--/
-</verb>
+<htmlurl url="http://www.cs.tut.fi/~p150650/gtk/gtk--.html"
+name="http://www.cs.tut.fi/~p150650/gtk/gtk--.html">.
+The FTP site is
+<htmlurl url="ftp://ftp.gtk.org/pub/gtk/gtk--"
+name="ftp://ftp.gtk.org/pub/gtk/gtk--">.
<p>
<item>There are two Objective-c bindings currently in development:
</itemize>
<p>
<item>Perl bindings
-<verb>
-ftp://ftp.gtk.org/pub/gtk/perl
-</verb>
-
-<item>Guile bindings. The home page is at:
-<verb>
-http://www.ping.de/sites/zagadka/guile-gtk/
-</verb>
+<htmlurl url="ftp://ftp.gtk.org/pub/gtk/perl"
+name="ftp://ftp.gtk.org/pub/gtk/perl">
+<P>
+<item>Guile bindings. The home page is at
+<htmlurl url="http://www.ping.de/sites/zagadka/guile-gtk"
+name="http://www.ping.de/sites/zagadka/guile-gtk">.
By the way, Guile is the GNU Project's implemention of R4RS Scheme (the
standard). If you like Scheme, you may want to take a look at this.
<p>
The basics of the system, including callbacks, work fine.
The current development is in
-http://www.ens-lyon.fr/~dmonniau/arcs/
+<htmlurl url="http://www.ens-lyon.fr/~dmonniau/arcs"
+name="http://www.ens-lyon.fr/~dmonniau/arcs">
</quote>
<item>
-Several python-gtk interfaces have been done. python-gtk is at:
-<verb>
-http://www.acs.ucalgary.cs/~nashceme/python-gtk/
-</verb>
-If you try python-gtk and don't like it, there's also pygtk located at:
-<verb>
-ftp://ftp.gtk.org/pub/gtk/python/
-</verb>
-
+Several python bindings have been done:
+<p>
+<itemize>
+<item>pygtk is at
+<htmlurl url="http://www.daa.com.au/~james/pygtk"
+name="http://www.daa.com.au/~james/pygtk"> and
+<htmlurl url="ftp://ftp.gtk.org/pub/gtk/python"
+name="ftp://ftp.gtk.org/pub/gtk/python">
+<item>python-gtk is at
+<htmlurl url="http://www.ucalgary.ca/~nascheme/python-gtk"
+name="http://www.ucalgary.ca/~nascheme/python-gtk">
+</itemize>
+<p>
<item>
-There's a OpenGL/Mesa widget available for GTK+. Grab it at:
-<verb>
-http://www.sakuranet.or.jp/~aozasa/shige/doc/comp/gtk/gtkGL/files-en.html
-</verb>
+There's a OpenGL/Mesa widget available for GTK+. Grab it at
+<htmlurl url="http://www.sakuranet.or.jp/~aozasa/shige/doc/comp/gtk/gtkGL/files-en.html"
+name="http://www.sakuranet.or.jp/~aozasa/shige/doc/comp/gtk/gtkGL/files-en.html">
</itemize>
`GtkVSeparator
</verb>
+<!-- ----------------------------------------------------------------- -->
+<sect1>Is GTK+ thread safe? How do I write multi-threaded GTK+ applications?
+<p>
+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 gtk_main is holding the lock when
+it calls gtk_main.
+
+The next thing to worry about is that since you were holding the
+global mutex when you entered 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 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.
+
<!-- ----------------------------------------------------------------- -->
<sect1>How can I prevent redrawing and resizing while I change multiple widgets?
<p>
speed since it will prevent resizing of the entire widget hierarchy.
<!-- ----------------------------------------------------------------- -->
-<sect1>How do I catch a double click event in a list widget?
+<sect1>How do I catch a double click event (in a list widget, for example)?
<p>
Tim Janik wrote to gtk-list (slightly modified):
/* something else */
}
</verb></tscreen>
-
+
+and, Owen Taylor wrote:
+
+Note that a single button press will be received beforehand, and
+if you are doing this for a button, you will therefore also get a
+"clicked" signal for the button. (This is going to be true for
+any toolkit, since computers aren't good at reading one's
+mind.)
+
<!-- ----------------------------------------------------------------- -->
<sect1>How do I find out about the selection of a GtkList?
<p>
projects / ~andy / gtk / commitdiff