gtk-unused.sgml 108 KB
Newer Older
1
<!-- ##### SECTION ./tmpl/gtkaccelgroup.sgml:Long_Description ##### -->
2 3 4
<para>

</para>
5 6


7
<!-- ##### SECTION ./tmpl/gtkaccelgroup.sgml:See_Also ##### -->
Owen Taylor's avatar
Owen Taylor committed
8 9 10 11 12
<para>

</para>


13
<!-- ##### SECTION ./tmpl/gtkaccelgroup.sgml:Short_Description ##### -->
Owen Taylor's avatar
Owen Taylor committed
14 15 16



17 18
<!-- ##### SECTION ./tmpl/gtkaccelgroup.sgml:Title ##### -->
Keyboard Accelerators
Owen Taylor's avatar
Owen Taylor committed
19 20


21
<!-- ##### SECTION ./tmpl/gtkarg.sgml:Long_Description ##### -->
22
<para>
23 24 25
All the functions in here are marked a Non-public.
We describe it anyway because it is occasionally useful
to understand how the work is done.
26 27
</para>
<para>
28 29 30 31
Arguments are a way of describing a named parameter to a function.
They have two important roles within gtk+:
<itemizedlist>
<listitem>
32
<para>
33 34 35 36 37
they describe <wordasword>object properties</wordasword>.
This means that they present an interface to get and set a named-type
for any type of object in a consistent way.
(All the relevant functions to do this start with gtk_object_set
or gtk_object_get).
38
</para>
39 40
</listitem>
<listitem>
41
<para>
42 43 44 45 46 47 48 49 50
they describe <wordasword>signal arguments</wordasword>.
This is a lot less often needed but still useful.
Usually if you are just emitting or creating a particular signal
it is more convenient to just use gtk_signal_emit() or gtk_signal_new().
However if you are writing a function to emit or create an arbitrary
signal, you must use gtk_signal_emitv() or gtk_signal_newv().
</para>
</listitem>
</itemizedlist>
51
</para>
52

53 54 55 56

<!-- ##### SECTION ./tmpl/gtkarg.sgml:See_Also ##### -->
<para>
#GtkObject.
57 58 59
</para>


60 61
<!-- ##### SECTION ./tmpl/gtkarg.sgml:Short_Description ##### -->
Utility function to manipulate lists of named, typed arguments.
62 63


64 65
<!-- ##### SECTION ./tmpl/gtkarg.sgml:Title ##### -->
Implementation of Object Properties
66

67 68

<!-- ##### SECTION ./tmpl/gtkbindings.sgml:Long_Description ##### -->
Owen Taylor's avatar
Owen Taylor committed
69
<para>
70

Owen Taylor's avatar
Owen Taylor committed
71 72 73
</para>


74
<!-- ##### SECTION ./tmpl/gtkbindings.sgml:See_Also ##### -->
Jonathan Blandford's avatar
Jonathan Blandford committed
75 76 77 78 79
<para>

</para>


80
<!-- ##### SECTION ./tmpl/gtkbindings.sgml:Short_Description ##### -->
Havoc Pennington's avatar
Havoc Pennington committed
81 82 83



84 85 86 87 88
<!-- ##### SECTION ./tmpl/gtkbindings.sgml:Title ##### -->
Bindings


<!-- ##### SECTION ./tmpl/gtkcellrenderer.sgml:Long_Description ##### -->
89 90 91 92 93
<para>

</para>


94
<!-- ##### SECTION ./tmpl/gtkcellrenderer.sgml:See_Also ##### -->
95 96 97 98 99
<para>

</para>


100
<!-- ##### SECTION ./tmpl/gtkcellrenderer.sgml:Short_Description ##### -->
Owen Taylor's avatar
Owen Taylor committed
101 102 103



104 105 106 107 108
<!-- ##### SECTION ./tmpl/gtkcellrenderer.sgml:Title ##### -->
GtkCellRenderer


<!-- ##### SECTION ./tmpl/gtkcellrendererpixbuf.sgml:Long_Description ##### -->
109 110 111 112 113
<para>

</para>


114
<!-- ##### SECTION ./tmpl/gtkcellrendererpixbuf.sgml:See_Also ##### -->
Owen Taylor's avatar
Owen Taylor committed
115 116 117 118 119
<para>

</para>


120
<!-- ##### SECTION ./tmpl/gtkcellrendererpixbuf.sgml:Short_Description ##### -->
121 122 123



124 125 126 127 128
<!-- ##### SECTION ./tmpl/gtkcellrendererpixbuf.sgml:Title ##### -->
GtkCellRendererPixbuf


<!-- ##### SECTION ./tmpl/gtkcellrenderertext.sgml:Long_Description ##### -->
129 130 131 132 133
<para>

</para>


134
<!-- ##### SECTION ./tmpl/gtkcellrenderertext.sgml:See_Also ##### -->
135 136 137 138 139
<para>

</para>


140 141 142 143 144 145 146 147 148
<!-- ##### SECTION ./tmpl/gtkcellrenderertext.sgml:Short_Description ##### -->



<!-- ##### SECTION ./tmpl/gtkcellrenderertext.sgml:Title ##### -->
GtkCellRendererText


<!-- ##### SECTION ./tmpl/gtkcellrenderertextpixbuf.sgml:Long_Description ##### -->
149 150 151 152 153
<para>

</para>


154
<!-- ##### SECTION ./tmpl/gtkcellrenderertextpixbuf.sgml:See_Also ##### -->
Havoc Pennington's avatar
Havoc Pennington committed
155 156 157 158 159
<para>

</para>


160 161 162 163 164 165 166 167 168
<!-- ##### SECTION ./tmpl/gtkcellrenderertextpixbuf.sgml:Short_Description ##### -->



<!-- ##### SECTION ./tmpl/gtkcellrenderertextpixbuf.sgml:Title ##### -->
GtkCellRendererTextPixbuf


<!-- ##### SECTION ./tmpl/gtkcellrenderertoggle.sgml:Long_Description ##### -->
Havoc Pennington's avatar
Havoc Pennington committed
169 170 171 172 173
<para>

</para>


174
<!-- ##### SECTION ./tmpl/gtkcellrenderertoggle.sgml:See_Also ##### -->
175 176 177 178 179
<para>

</para>


180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254
<!-- ##### SECTION ./tmpl/gtkcellrenderertoggle.sgml:Short_Description ##### -->



<!-- ##### SECTION ./tmpl/gtkcellrenderertoggle.sgml:Title ##### -->
GtkCellRendererToggle


<!-- ##### SECTION ./tmpl/gtkclipboard.sgml:Long_Description ##### -->
  <para>
    The #GtkClipboard object represents a clipboard of data shared
    between different processes or between different widgets in
    the same process. Each clipboard is identified by a name encoded as a
    #GdkAtom. (Conversion to and from strings can be done with
    gdk_atom_intern() and gdk_atom_name().) The default clipboard
    corresponds to the CLIPBOARD atom; another commonly used clipboard
    is the PRIMARY clipboard, which, in X, traditionally contains
    the currently selected text. 
  </para>
  <para>
    To support having a number of different formats on the clipboard
    at the same time, the clipboard mechanism allows providing
    callbacks instead of the actual data.  When you set the contents
    of the clipboard, you can either supply the data directly (via
    functions like gtk_clipboard_set_text()), or you can supply a
    callback to be called at a later time when the data is needed (via
    gtk_clipboard_set_with_data() or gtk_clipboard_set_with_owner().)
    Providing a callback also avoids having to make copies of the data
    when it is not needed.
  </para>
  <para>
    gtk_clipboard_set_with_data() and gtk_clipboard_set_with_owner()
    are quite similar; the choice between the two depends mostly on
    which is more convenient in a particular situation.
    The former is most useful when you want to have a blob of data
    with callbacks to convert it into the various data types that you
    advertise. When the @clear_func you provided is called, you
    simply free the data blob. The latter is more useful when the
    contents of clipboard reflect the internal state of a @GObject
    (As an example, for the PRIMARY clipboard, when an entry widget
    provides the clipboard's contents the contents are simply the
    text within the selected region.) If the contents change, the
    entry widget can call gtk_clipboard_set_with_owner() to update
    the timestamp for clipboard ownership, without having to worry
    about @clear_func being called.
  </para>
  <para>
    Requesting the data from the clipboard is essentially
    asynchronous. If the contents of the clipboard are provided within
    the same process, then a direct function call will be made to
    retrieve the data, but if they are provided by another process,
    then the data needs to be retrieved from the other process, which
    may take some time. To avoid blocking the user interface, the call
    to request the selection, gtk_clipboard_request_contents() takes a
    callback that will be called when the contents are received (or
    when the request fails.) If you don't want to deal with providing
    a separate callback, you can also use gtk_clipboard_wait_for_contents().
    What this does is run the Glib main loop recursively waiting for
    the contents. This can simplify the code flow, but you still have
    to be aware that other callbacks in your program can be called
    while this recursive mainloop is running.
  </para>
  <para>
    Along with the functions to get the clipboard contents as an
    arbitrary data chunk, there are also functions to retrieve
    it as text, gtk_clipboard_request_text() and
    gtk_clipboard_wait_for_text(). These functions take care of
    determining which formats are advertised by the clipboard
    provider, asking for the clipboard in the best available format
    and converting the results into the UTF-8 encoding. (The standard
    form for representing strings in GTK+.)
  </para>


<!-- ##### SECTION ./tmpl/gtkclipboard.sgml:See_Also ##### -->
255
<para>
256 257 258 259 260 261 262 263 264
<variablelist>

<varlistentry>
<term>#GtkSelection</term>
<listitem><para>@GtkClipboard provides a high-level wrapper around the
	    lower level routines that deal with X selections. It is
	    also possibly to directly manipulate the X selections,
	    though it is seldom necessary to do so.</para></listitem>
</varlistentry>
265

266
</variablelist>
267 268 269
</para>


270 271 272 273 274 275 276 277 278
<!-- ##### SECTION ./tmpl/gtkclipboard.sgml:Short_Description ##### -->
Storing data on Clipboards.


<!-- ##### SECTION ./tmpl/gtkclipboard.sgml:Title ##### -->
Clipboards


<!-- ##### SECTION ./tmpl/gtkdebug.sgml:Long_Description ##### -->
279
<para>
280

281 282 283
</para>


284
<!-- ##### SECTION ./tmpl/gtkdebug.sgml:See_Also ##### -->
285
<para>
286

287
</para>
288 289


290 291 292 293 294 295 296 297 298
<!-- ##### SECTION ./tmpl/gtkdebug.sgml:Short_Description ##### -->



<!-- ##### SECTION ./tmpl/gtkdebug.sgml:Title ##### -->
Debugging


<!-- ##### SECTION ./tmpl/gtkdnd.sgml:Long_Description ##### -->
299
<para>
300 301 302 303 304 305 306 307 308 309 310
GTK+ has a rich set of functions for doing inter-process
communication via the drag-and-drop metaphore. GTK+
can do drag and drop (DND) via multiple protocols.
The currently supported protocols are the Xdnd and
Motif protocols.

As well as the functions listed here, applications
may need to use some facilities provided for
<link linkend="gtk-Selections">Selections</link>.
Also, the Drag and Drop API makes use of signals
in the #GtkWidget class.
311 312 313
</para>


314
<!-- ##### SECTION ./tmpl/gtkdnd.sgml:See_Also ##### -->
315
<para>
316

317 318 319
</para>


320 321 322 323 324 325
<!-- ##### SECTION ./tmpl/gtkdnd.sgml:Short_Description ##### -->
Functions for controlling drag and drop handling.


<!-- ##### SECTION ./tmpl/gtkdnd.sgml:Title ##### -->
Drag and Drop
Havoc Pennington's avatar
Havoc Pennington committed
326 327


328 329
<!-- ##### SECTION ./tmpl/gtkenums.sgml.sgml:Long_Description ##### -->
<para>
330

331
</para>
Havoc Pennington's avatar
Havoc Pennington committed
332

333

334
<!-- ##### SECTION ./tmpl/gtkenums.sgml.sgml:See_Also ##### -->
335
<para>
336

337 338
</para>

339

340
<!-- ##### SECTION ./tmpl/gtkenums.sgml.sgml:Short_Description ##### -->
Havoc Pennington's avatar
Havoc Pennington committed
341 342 343



344 345 346 347 348
<!-- ##### SECTION ./tmpl/gtkenums.sgml.sgml:Title ##### -->
gtkenums.sgml


<!-- ##### SECTION ./tmpl/gtkenums.sgml:Long_Description ##### -->
Havoc Pennington's avatar
Havoc Pennington committed
349 350 351 352 353
<para>

</para>


354
<!-- ##### SECTION ./tmpl/gtkenums.sgml:See_Also ##### -->
355
<para>
356

357 358 359
</para>


360 361
<!-- ##### SECTION ./tmpl/gtkenums.sgml:Short_Description ##### -->
Public enumerated types used throughout GTK+.
362 363


364 365 366 367 368
<!-- ##### SECTION ./tmpl/gtkenums.sgml:Title ##### -->
Standard Enumerations


<!-- ##### SECTION ./tmpl/gtkfeatures.sgml:Long_Description ##### -->
369
<para>
370 371 372
This section describes the variables and functions available to test the
version of the GTK+ library in use.
FIXME: probably merge with other general stuff.
373
</para>
374 375 376


<!-- ##### SECTION ./tmpl/gtkfeatures.sgml:See_Also ##### -->
377
<para>
378

379 380 381
</para>


382 383
<!-- ##### SECTION ./tmpl/gtkfeatures.sgml:Short_Description ##### -->
variables and functions to check the GTK+ version.
384 385


386 387 388
<!-- ##### SECTION ./tmpl/gtkfeatures.sgml:Title ##### -->
Version Information

389

390 391 392 393 394 395 396
<!-- ##### SECTION ./tmpl/gtkgc.sgml:Long_Description ##### -->
<para>
These functions provide access to a shared pool of #GdkGC objects.
When a new #GdkGC is needed, gtk_gc_get() is called with the required depth,
colormap and #GdkGCValues. If a #GdkGC with the required properties already
exists then that is returned. If not, a new #GdkGC is created.
When the #GdkGC is no longer needed, gtk_gc_release() is called.
397 398 399
</para>


400
<!-- ##### SECTION ./tmpl/gtkgc.sgml:See_Also ##### -->
Havoc Pennington's avatar
Havoc Pennington committed
401 402 403 404 405
<para>

</para>


406 407
<!-- ##### SECTION ./tmpl/gtkgc.sgml:Short_Description ##### -->
provides access to a shared pool of #GdkGC objects.
Owen Taylor's avatar
Owen Taylor committed
408 409


410 411
<!-- ##### SECTION ./tmpl/gtkgc.sgml:Title ##### -->
Graphics Contexts
Owen Taylor's avatar
Owen Taylor committed
412

413 414

<!-- ##### SECTION ./tmpl/gtkiconfactory.sgml:Long_Description ##### -->
Owen Taylor's avatar
Owen Taylor committed
415
<para>
416 417 418 419 420 421 422 423 424 425 426 427
 An icon factory manages a collection of #GtkIconSet; a #GtkIconSet manages a
 set of variants of a particular icon (i.e. a #GtkIconSet contains variants for
 different sizes and widget states). Icons in an icon factory are named by a
 stock ID, which is a simple string identifying the icon. Each #GtkStyle has a
 list of #GtkIconFactory derived from the current theme; those icon factories
 are consulted first when searching for an icon. If the theme doesn't set a
 particular icon, GTK+ looks for the icon in a list of default icon factories,
 maintained by gtk_icon_factory_add_default() and
 gtk_icon_factory_remove_default(). Applications with icons should add a default
 icon factory with their icons, which will allow themes to override the icons
 for the application.
</para>
Owen Taylor's avatar
Owen Taylor committed
428

429 430 431 432 433
<para>
To display an icon, always use gtk_style_lookup_icon_set() on the widget that
will display the icon, or the convenience function
gtk_widget_render_icon(). These functions take the theme into account when
looking up the icon to use for a given stock ID.
Owen Taylor's avatar
Owen Taylor committed
434 435 436
</para>


437
<!-- ##### SECTION ./tmpl/gtkiconfactory.sgml:See_Also ##### -->
438 439 440 441 442
<para>

</para>


443
<!-- ##### SECTION ./tmpl/gtkiconfactory.sgml:Short_Description ##### -->
444

445
Manipulating stock icons
446 447


448 449
<!-- ##### SECTION ./tmpl/gtkiconfactory.sgml:Title ##### -->
Themeable Stock Images
Owen Taylor's avatar
Owen Taylor committed
450 451


452
<!-- ##### SECTION ./tmpl/gtkimcontextsimple.sgml:Long_Description ##### -->
453 454 455 456 457
<para>

</para>


458
<!-- ##### SECTION ./tmpl/gtkimcontextsimple.sgml:See_Also ##### -->
459 460 461 462 463
<para>

</para>


464
<!-- ##### SECTION ./tmpl/gtkimcontextsimple.sgml:Short_Description ##### -->
465 466


Havoc Pennington's avatar
Havoc Pennington committed
467

468 469
<!-- ##### SECTION ./tmpl/gtkimcontextsimple.sgml:Title ##### -->
GtkIMContextSimple
Havoc Pennington's avatar
Havoc Pennington committed
470 471


472
<!-- ##### SECTION ./tmpl/gtkliststore.sgml:Long_Description ##### -->
473 474 475 476 477
<para>

</para>


478
<!-- ##### SECTION ./tmpl/gtkliststore.sgml:See_Also ##### -->
Owen Taylor's avatar
Owen Taylor committed
479 480 481 482 483
<para>

</para>


484
<!-- ##### SECTION ./tmpl/gtkliststore.sgml:Short_Description ##### -->
485

486 487


488 489 490
<!-- ##### SECTION ./tmpl/gtkliststore.sgml:Title ##### -->
GtkListStore

Owen Taylor's avatar
Owen Taylor committed
491

492 493 494 495 496 497 498 499
<!-- ##### SECTION ./tmpl/gtkmain.sgml:Long_Description ##### -->
<para>
GTK uses an event oriented programming model. While conventional C programs
have control over the program flow all the time this does not apply to 
applications written using GTK. Instead you set up some objects and 
register some functions (<quote>callbacks</quote>) to be called whenever 
some event occurs and give control to the GTK mainloop (e.g. by calling 
gtk_main).
Owen Taylor's avatar
Owen Taylor committed
500 501
</para>

502 503 504 505 506 507 508 509
<example>
<title> Typical <function>main</function> function for a GTK application</title>
<programlisting>
int 
main (int argc, char **argv)
{
  /* Initialize i18n support */
  gtk_set_locale ();
Owen Taylor's avatar
Owen Taylor committed
510

511 512
  /* Initialize the widget set */
  gtk_init (&amp;argc, &amp;argv);
513

514 515
  /* Create the main window */
  mainwin = gtk_window_new (GTK_WINDOW_TOPLEVEL);
516

517 518
  /* Set up our GUI elements */
  ...
519

520 521
  /* Show the application window */
  gtk_widget_showall (mainwin);
522

523 524
  /* Let the user interact with our application */
  gtk_main ();
525

526 527 528 529 530
  /* The user lost interest */
  gtk_exit (0);
}
</programlisting>
</example>
531

532

533 534
<!-- ##### SECTION ./tmpl/gtkmain.sgml:See_Also ##### -->
<para>
535
</para>
536

537

538 539
<!-- ##### SECTION ./tmpl/gtkmain.sgml:Short_Description ##### -->
Mainloop and event handling
Owen Taylor's avatar
Owen Taylor committed
540 541


542 543
<!-- ##### SECTION ./tmpl/gtkmain.sgml:Title ##### -->
General
Owen Taylor's avatar
Owen Taylor committed
544

545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581

<!-- ##### SECTION ./tmpl/gtkmarshal.sgml:Long_Description ##### -->
<refsect2>
<title>What are Signal Marshallers?</title>
<para>
Marshals are functions which all have the same prototype:
they take a #GtkObject, a #GtkSignalFunc, a #gpointer,
and an array of argument values.
The functions are names gtk_marshall_RETURNTYPE__PARAMTYPE1_PARAMTYPE2....
</para>
<para>
They then call a native function:  the GtkObject is the first
parameter passed in.  The arguments are passed in the native
calling convention:  chars, shorts, ints, longs may be packed
on the stack, or tucked in registers:  it doesn't matter
because the same calling convention will be generated
inside the gtkmarshal code as is expected where you define
your handlers.
</para>
<para>
So the function named:
<programlisting>
gtk_marshal_BOOL__POINTER_INT_INT_UINT(GtkObject*, GtkSignalFunc, gpointer, GtkArg*);
</programlisting>
will call the #GtkSignalFunc assuming it was a function with signature:
<programlisting>
gboolean sigfunc(gpointer,gint,gint,guint);
</programlisting>
</para>
</refsect2>
<refsect2>
<title>Writing Custom Marshals</title>
<para>
Marshals are primarily used as arguments to gtk_signal_new().
Sometimes, you may find that a marshaller you need isn't available
in the standard list.  Then you have to write your own.
</para>
582
<para>
583 584 585 586 587 588 589
If you wish to define a signal with a new type of argument list.
Suppose you want 2 pointers and 2 integers.
You would write:
<programlisting>
typedef int (*GtkSignal_INT__POINTER_POINTER_INT_INT)(
			gpointer, gpointer, gint, gint
);
590

591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607
void marshal_INT__POINTER_POINTER_INT_INT(GtkObject*    object,
					   GtkSignalFunc func,
					   gpointer      func_data,
                                           GtkArg*       args)
{
	GtkSignal_NONE__POINTER_POINTER_INT_INT rfunc;
	gint* return_val;
	return_val = GTK_RETLOC_INT(args[4]);
	rfunc = (GtkSignal_INT__POINTER_POINTER_INT_INT)func;
	*return_val = (*rfunc)(object,
                               GTK_VALUE_POINTER(args[0]),
                               GTK_VALUE_POINTER(args[1]),
                               GTK_VALUE_INT(args[2]),
                               GTK_VALUE_INT(args[3]),
                               func_data);
}
</programlisting>
608
</para>
609
</refsect2>
610 611


612
<!-- ##### SECTION ./tmpl/gtkmarshal.sgml:See_Also ##### -->
613
<para>
614 615 616 617 618 619 620
<variablelist>

<varlistentry>
<term>#GtkSignal</term>
<listitem><para>The signal handling functions (of which marshallers are 
really an implementation detail).</para></listitem>
</varlistentry>
621

622
</variablelist>
623 624 625
</para>


626 627
<!-- ##### SECTION ./tmpl/gtkmarshal.sgml:Short_Description ##### -->
Functions to adapt C structures to native calling convention.
Havoc Pennington's avatar
Havoc Pennington committed
628 629


630 631
<!-- ##### SECTION ./tmpl/gtkmarshal.sgml:Title ##### -->
Signal Marshallers
Havoc Pennington's avatar
Havoc Pennington committed
632

633 634

<!-- ##### SECTION ./tmpl/gtkmenufactory.sgml:Long_Description ##### -->
635
<para>
636

637 638 639
</para>


640
<!-- ##### SECTION ./tmpl/gtkmenufactory.sgml:See_Also ##### -->
Owen Taylor's avatar
Owen Taylor committed
641 642 643 644 645
<para>

</para>


646
<!-- ##### SECTION ./tmpl/gtkmenufactory.sgml:Short_Description ##### -->
647 648


649 650 651 652 653 654

<!-- ##### SECTION ./tmpl/gtkmenufactory.sgml:Title ##### -->
Menu Factory


<!-- ##### SECTION ./tmpl/gtkprivate.sgml:Long_Description ##### -->
655 656 657 658 659
<para>

</para>


660
<!-- ##### SECTION ./tmpl/gtkprivate.sgml:See_Also ##### -->
661
<para>
662

663 664
</para>

665

666
<!-- ##### SECTION ./tmpl/gtkprivate.sgml:Short_Description ##### -->
667 668 669



670 671 672 673 674
<!-- ##### SECTION ./tmpl/gtkprivate.sgml:Title ##### -->
Private Information


<!-- ##### SECTION ./tmpl/gtkrc.sgml:Long_Description ##### -->
675
<para>
676 677 678
GTK+ provides resource file mechanism for configuring
various aspects of the operation of a GTK+ program
at runtime.
679 680
</para>

681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709
<refsect2><title>Default files</title>
<para>
An application can cause GTK+ to parse a specific RC
file by calling gtk_rc_parse(). In addition to this,
certain files will be read at the end of gtk_init().
Unless modified, the files looked for will be <filename>.gtkrc</filename>
in the users home directory, and 
<filename>$localstatedir/gtk/gtkrc</filename> 
(<literal>$localstatedir</literal> defaults to 
<filename>/usr/local/etc</filename>).
</para>
<para>
The set of these <firstterm>default</firstterm> files
can be retrieved with gtk_rc_get_default_files()
and modified with gtk_rc_add_default_file() and
gtk_rc_set_default_files().
</para>
<para>
For each default file, in addition to the file itself,
GTK+ will look for a locale-specific file that will
be parsed in addition to the main file. For instance,
if <literal>LANG</literal> is set to <literal>ja_JP.ujis</literal>,
when loading the default file <filename>~/.gtkrc</filename>
then GTK+ looks for <filename>~/.gtkrc.ja_JP.ujis</filename>,
<filename>~/.gtkrc.ja_JP</filename>, and
<filename>~/.gtkrc.ja</filename>, and parses the
first one it finds.
</para>
</refsect2>
710

711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768
<refsect2><title>Pathnames and patterns</title>
<para>
A resource file defines a number of styles and key bindings and
attaches them to particular widgets. The attachment is done
by the <literal>widget</literal>, <literal>widget_class</literal>,
and <literal>class</literal> declarations. As an example
of such a statement:
<programlisting>
widget "mywindow.*.GtkEntry" style "my-entry-class"
</programlisting>
attaches the style <literal>"my-entry-class"</literal>
to all widgets whose <firstterm>widget class</firstterm>
matches the <firstterm>pattern</firstterm>
<literal>"mywindow.*.GtkEntry"</literal>.
</para>
<para>
The patterns here are given in the standard shell glob
syntax. The <literal>"?"</literal> wildcard matches
any character, while <literal>"*"</literal> matches
zero or more of any character. The three types of
matching are against the widget path, the
<firstterm>class path</firstterm> and the class
heirarchy. Both the widget and the class paths consists of a
<literal>"."</literal> separated list of all the
parents of the widget and the widget itself from
outermost to innermost. The difference is that in
the widget path, the name assigned by
<function>gtk_widget_set_name()</function> is used
if present, otherwise the class name of the widget, while
for the widget path, the class name is always used.
</para>
<para>
So, if you have a <classname>GtkEntry</classname> named
<literal>"myentry"</literal>, inside of a of a window
named <literal>"mywindow"</literal>, then the
widget path is:
<programlisting>
"mwindow.GtkHBox.myentry"
</programlisting>
while the class path is:
<programlisting>
"GtkWindow.GtkHBox.GtkEntry"
</programlisting>
</para>
<para>
Matching against class is a little different. The pattern
match is done against all class names in the widgets
class heirarchy (not the layout heirarchy) in sequence, so the
pattern:
<programlisting>
class "GtkButton" style "my-style"
</programlisting>
will match not just <classname>GtkButton</classname> widgets,
but also <classname>GtkToggleButton</classname> and
<classname>GtkCheckButton</classname> widgets, since
those classes derive from <classname>GtkButton</classname>.
</para>
</refsect2>
769

770 771 772 773 774 775 776
<refsect2><title>Toplevel declarations</title>
<para>
An RC file is a text file which is composed of a sequence
of declarations. '#' characters delimit comments and
the portion of a line after a '#' is ignored when parsing
an RC file.
</para>
777

778
<para>
779
The possible toplevel declarations are:
780

781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845
<variablelist>
  <varlistentry>
    <term><literal>binding <replaceable>name</replaceable>
     { ... }</literal></term>
    <listitem>
      <para>Declare a binding set</para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>class <replaceable>pattern</replaceable> 
          [ style | binding [ : <replaceable>priority</replaceable> ]]
          <replaceable>name</replaceable></literal></term>
    <listitem>
     <para>Specify a style or binding set for a particular
     branch of the inheritance heirarchy.</para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>include <replaceable>filename</replaceable></literal></term>
    <listitem>
      <para>Parse another file at this point</para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>module_path <replaceable>path></replaceable></literal></term>
    <listitem>
      <para>Sets a path (a list of directories separated
      by colons) that will be searched for theme engines referenced in
      RC files.</para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>pixmap_path <replaceable>path></replaceable></literal></term>
    <listitem>
      <para>Sets a path (a list of directories separated
      by colons) that will be searched for pixmaps referenced in
      RC files.</para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>style <replaceable>name</replaceable> [ =
    <replaceable>parent</replaceable> ] { ... }</literal></term>
    <listitem>
      <para>Declare a style</para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>widget <replaceable>pattern</replaceable> 
          [ style | binding [ : <replaceable>priority</replaceable> ]]
          <replaceable>name</replaceable></literal></term>
    <listitem>
     <para>Specify a style or binding set for a particular
     group of widgets by matching on the widget pathname.</para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>widget_class <replaceable>pattern</replaceable> 
          [ style | binding [ : <replaceable>priority</replaceable> ]]
          <replaceable>name</replaceable></literal></term>
    <listitem>
     <para>Specify a style or binding set for a particular
     group of widgets by matching on the class pathname.</para>
    </listitem>
  </varlistentry>
</variablelist>
846
</para>
847
</refsect2>
848

849 850 851 852 853 854 855 856 857 858 859 860 861
<refsect2><title>Styles</title>
<para>
A RC style is specified by a <literal>style</literal> 
declaration in a RC file, and then bound to widgets
with a <literal>widget</literal>, <literal>widget_class</literal>,
or <literal>class</literal> declaration. All styles
applying to a particular widget are composited together
with <literal>widget</literal> declarations overriding
<literal>widget_class</literal> declarations which, in
turn, override <literal>widget</literal> declarations.
Within each type of declaration, later declarations override
earlier ones.
</para>
862 863

<para>
864 865
Within a <literal>style</literal> declaration, the possible
elements are:
866

867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943
<variablelist>
  <varlistentry>
    <term><literal>bg[<replaceable>state</replaceable>] =
      <replaceable>color</replaceable></literal></term>
     <listitem>
       <para>
         Set color used for the background of most widgets.
       </para>
     </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>fg[<replaceable>state</replaceable>] =
      <replaceable>color</replaceable></literal></term>
     <listitem>
       <para>
         Set color used for the foreground of most widgets.
       </para>
     </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>base[<replaceable>state</replaceable>] =
      <replaceable>color</replaceable></literal></term>
     <listitem>
       <para>
         Set color used for the background of widgets displaying
         editable text. This color is used for the background
         of, among others, #GtkText, #GtkEntry, #GtkList, and #GtkClist.
       </para>
     </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>text[<replaceable>state</replaceable>] =
      <replaceable>color</replaceable></literal></term>
     <listitem>
       <para>
         Set color used for foreground of widgets using
         <literal>base</literal> for the background color.
       </para>
     </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>bg_text[<replaceable>state</replaceable>] =
      <replaceable>color</replaceable></literal></term>
     <listitem>
       <para>
         Set a background pixmap to be used in place of
         the <literal>bg</literal> color (or for #GtkText,
         in place of the <literal>base</literal> color.
       </para>
     </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>font = <replaceable>font</replaceable></literal></term>
     <listitem>
       <para>
         Set the font for a widget.
       </para>
     </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>fontset = <replaceable>font</replaceable></literal></term>
     <listitem>
       <para>
         Set the fontset for a widget. Overrides any
         <literal>font</literal> declarations.
       </para>
     </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>stock[<replaceable>"stock-id"</replaceable>] = { <replaceable>icon source specifications</replaceable> }</literal></term>
     <listitem>
       <para>
        Defines the icon for a stock item.
       </para>
     </listitem>
  </varlistentry>
</variablelist>
944
</para>
945 946 947
<para>
The colors and background pixmaps are specified as a function of the
state of the widget. The states are:
948

949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002
<variablelist>
  <varlistentry>
    <term><literal>NORMAL</literal></term>
    <listitem>
      <para>
        A color used for a widget in its normal state
      </para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>ACTIVE</literal></term>
    <listitem>
      <para>
        A variant of the <literal>NORMAL</literal> color used when the
        widget is in the %GTK_STATE_ACTIVE state, and also for
        the trough of a ScrollBar, tabs of a NoteBook
        other than the current tab and similar areas.
        Frequently, this should be a darker variant
        of the <literal>NORMAL</literal> color.
      </para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>PRELIGHT</literal></term>
    <listitem>
      <para>
        A color used for widgets in the %GTK_STATE_PRELIGHT state. This
        state is the used for Buttons and MenuItems
        that have the mouse cursor over them, and for 
        their children.
      </para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>SELECTED</literal></term>
    <listitem>
      <para>
        A color used to highlight data selected by the user.
        for instance, the selected ListItems in a List widget, and the
        selection in an Editable widget.
      </para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term><literal>INSENSITIVE</literal></term>
    <listitem>
      <para>
        A color used for the background of widgets that have
        been set insensitive with gtk_widget_set_sensitive()
      </para>
    </listitem>
  </varlistentry>
</variablelist>
</para>
1003

Owen Taylor's avatar
Owen Taylor committed
1004
<para>
1005 1006 1007 1008 1009 1010 1011 1012
Colors can be specified as a string <literal>"&hash;rrrrggggbbbb"</literal>,
<literal>"&hash;rrrgggbbb"</literal>, <literal>"&hash;rrggbb"</literal>,
or <literal>"&hash;rgb"</literal>, where <literal>r</literal>
<literal>g</literal>, and <literal>b</literal> are
hex digits, or they can be specified as a triplet of floats
<literal>{ <replaceable>r</replaceable>, <replaceable>g</replaceable>,
<replaceable>b</replaceable>}</literal>.
</para>
Owen Taylor's avatar
Owen Taylor committed
1013

1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036
<para>
In a <literal>stock</literal> definition, icon sources are specified as a
4-tuple of image filename, text direction, widget state, and size, in that
order.  Each icon source specifies an image filename to use with a given
direction, state, and size. The <literal>*</literal> character can be used as a
wildcard, and if direction/state/size are omitted they default to
<literal>*</literal>. So for example, the following specifies different icons to
use for left-to-right and right-to-left languages:
<programlisting>
stock["my-stock-item"] = 
{
  { "itemltr.png", LTR, *, * },
  { "itemrtl.png", RTL, *, * }
}
</programlisting>
This could be abbreviated as follows:
<programlisting>
stock["my-stock-item"] = 
{
  { "itemltr.png", LTR },
  { "itemrtl.png", RTL }
}
</programlisting>
Owen Taylor's avatar
Owen Taylor committed
1037 1038
</para>

1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053
<para>
You can specify custom icons for specific sizes, as follows:
<programlisting>
stock["my-stock-item"] = 
{
  { "itemmenusize.png", *, *, "gtk-menu" },
  { "itemtoolbarsize.png", *, *, "gtk-large-toolbar" }
  { "itemgeneric.png" } /* implicit *, *, * as a fallback */
}
</programlisting>
The sizes that come with GTK+ itself are <literal>"gtk-menu"</literal>,
<literal>"gtk-small-toolbar"</literal>, <literal>"gtk-large-toolbar"</literal>,
<literal>"gtk-button"</literal>, <literal>"gtk-dialog"</literal>. Applications
can define other sizes.
</para>
Owen Taylor's avatar
Owen Taylor committed
1054

1055
<para>
1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066
It's also possible to use custom icons for a given state, for example:
You can specify custom icons for specific sizes, as follows:
<programlisting>
stock["my-stock-item"] = 
{
  { "itemprelight.png", *, PRELIGHT },
  { "iteminsensitive.png", *, INSENSITIVE }, 
  { "itemgeneric.png" } /* implicit *, *, * as a fallback */
}
</programlisting>
</para>
1067

1068 1069 1070 1071 1072 1073 1074
<para>
When selecting an icon source to use, GTK+ will consider text direction most
important, state second, and size third. It will select the best match based on
those criteria. If an attribute matches exactly (e.g. you specified
<literal>PRELIGHT</literal> or specified the size), GTK+ won't modify the image;
if the attribute matches with a wildcard, GTK+ will scale or modify the image to
match the state and size the user requested.
1075 1076
</para>

1077
</refsect2>
1078

1079
<refsect2><title>Key bindings</title>
1080
<para>
1081 1082 1083
Key bindings allow the user to specify actions to be 
taken on particular key presses. The form of a binding
set declaration is:
1084 1085
</para>

1086 1087 1088 1089 1090 1091 1092 1093 1094
<programlisting>
binding <replaceable>name</replaceable> {
  bind <replaceable>key</replaceable> { 
    <replaceable>signalname</replaceable> (<replaceable>param</replaceable>, ...)
    ...
  }
  ...
}
</programlisting>
1095

1096
<para>
1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149
<replaceable>key</replaceable> is a string consisting of a 
series of modifiers followed by the name of a key. The
modifiers can be:
<simplelist>
<member><literal>&lt;alt&gt;</literal></member>
<member><literal>&lt;control&gt;</literal></member>
<member><literal>&lt;mod1&gt;</literal></member>
<member><literal>&lt;mod2&gt;</literal></member>
<member><literal>&lt;mod3&gt;</literal></member>
<member><literal>&lt;mod4&gt;</literal></member>
<member><literal>&lt;mod5&gt;</literal></member>
<member><literal>&lt;release&gt;</literal></member>
<member><literal>&lt;shft&gt;</literal></member>
<member><literal>&lt;shift&gt;</literal></member>
</simplelist>
<literal>&lt;shft&gt;</literal> is an alias for 
<literal>&lt;shift&gt;</literal> and 
<literal>&lt;alt&gt;</literal> is an alias for
<literal>&lt;mod1&gt;</literal>.
</para>

<para>
The action that is bound to the key is a sequence
of signal names (strings) followed by parameters for 
each signal. The signals must be action signals.
(See gtk_signal_new()). Each parameter can be
a float, integer, string, or unquoted string
representing an enumeration value. The types of
the parameters specified must match the types of the 
parameters of the signal.
</para>

<para>
Binding sets are connected to widgets in the
same manner as styles, with one addition. 
A priority can be specified for each pattern,
and within each type of pattern, binding sets
override other binding sets first by priority,
and only then by order of specification. (Later
overrides earlier). The priorities that can
be specified are (highest to lowest):
<simplelist>
<member><literal>HIGHEST</literal></member>
<member><literal>RC</literal></member>
<member><literal>APPLICATION</literal></member>
<member><literal>GTK</literal></member>
<member><literal>LOWEST</literal></member>
</simplelist>
<literal>RC</literal> is the default for bindings
read from an RC file, <literal>APPLICATION</literal>
should be used for bindings an application sets
up, and <literal>GTK</literal> is used for bindings
that GTK+ creates internally.
1150
</para>
1151
</refsect2>
1152 1153


1154
<!-- ##### SECTION ./tmpl/gtkrc.sgml:See_Also ##### -->
1155
<para>
1156

1157 1158 1159
</para>


1160 1161
<!-- ##### SECTION ./tmpl/gtkrc.sgml:Short_Description ##### -->
Routines for handling resource files
Havoc Pennington's avatar
Havoc Pennington committed
1162 1163


1164 1165
<!-- ##### SECTION ./tmpl/gtkrc.sgml:Title ##### -->
Resource Files
Havoc Pennington's avatar
Havoc Pennington committed
1166

1167

1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184
<!-- ##### SECTION ./tmpl/gtkselection.sgml:Long_Description ##### -->

<para>
The selection mechanism provides the basis for different types
of IPC between processes. In particular, drag and drop and
#GtkClipboard work via selections. You will very seldom or
never need to use most of the functions in this section directly;
#GtkClipboard provides a nicer interface to the same functionality.
</para>
<para>
Some of the datatypes defined this section are used in
the #GtkClipboard and drag-and-drop API's as well. The
#GtkTargetEntry structure and #GtkTargetList objects represent
lists of data types that are supported when sending or
receiving data. The #GtkSelectionData object is used to
store a chunk of data along with the data type and other
associated information.
1185 1186 1187
</para>


1188
<!-- ##### SECTION ./tmpl/gtkselection.sgml:See_Also ##### -->
Havoc Pennington's avatar
Havoc Pennington committed
1189
<para>
1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202
<variablelist>

<varlistentry>
<term>#GtkWidget</term>
<listitem><para>Much of the operation of selections happens via
             signals for #GtkWidget. In particular, if you are
             using the functions in this section, you may need
             to pay attention to ::selection_get,
             ::selection_received,  and :selection_clear_event
             signals.</para></listitem>
</varlistentry>

</variablelist>
Havoc Pennington's avatar
Havoc Pennington committed
1203 1204 1205 1206

</para>


1207 1208
<!-- ##### SECTION ./tmpl/gtkselection.sgml:Short_Description ##### -->
Functions for handling inter-process communication via selections.
Havoc Pennington's avatar
Havoc Pennington committed
1209 1210


1211 1212
<!-- ##### SECTION ./tmpl/gtkselection.sgml:Title ##### -->
Selections
Havoc Pennington's avatar
Havoc Pennington committed
1213

Owen Taylor's avatar
Owen Taylor committed
1214

1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263
<!-- ##### SECTION ./tmpl/gtksignal.sgml:Long_Description ##### -->
<refsect2>
<title>What are signals?</title>
<para>
Signals are a way to get notification when something happens
and to customize object behavior according to the
user's needs.
Every <WordAsWord>signal</WordAsWord> is uniquely identified by a name,
"class_name::signal_name", where signal_name might be something like
"clicked" and class_name might be "GtkButton".  Note that some other class
may also define a "clicked" callback, so long as it doesn't derive from
#GtkButton.
</para>
<para>
When they are created, they are also assigned a unique positive integer,
the signal id (1 is the first signal id- 0 is used to flag an error).
Each is also tied to an array of types that describes
the prototype of the function pointer(s) (handlers) you may
connect to the signal.  Finally, every signal has
a default handler that is given by a function pointer
in its class structure:  it is run by default whenever the
signal is emitted.  (It is possible that a signal will
be emitted and a user-defined handler will prevent the default handler
from being run.)
</para>
<para>
Signals are used by everyone, but they are only
created on a per class basis-- so you should call
call gtk_signal_new() unless you are writing
a new #GtkObject type.  However, if you want to make a new signal
for an existing type, you may use gtk_object_class_user_signal_new()
to create a signal that doesn't correspond to a class's builtin
methods.
</para>
</refsect2>
<refsect2>
<title>How are signals used?</title>
<para>
There are two basic actions in the signal handling game.
If you want notification of an event, you must <Emphasis>connect</Emphasis>
a function pointer and a data pointer to that signal;  the data pointer
will be passed as the last argument to the function (so long as you
are using the default marshalling functions).
You will receive a connection id, a unique positive integer
corresponding to that attachment.
</para>
<para>
Functions that want to notify the user of certain actions,
<Emphasis>emit</Emphasis> signals.
Owen Taylor's avatar
Owen Taylor committed
1264
</para>
1265 1266 1267 1268
</refsect2>
<refsect2>
<title>Basic Terminology</title>
<variablelist>
Owen Taylor's avatar
Owen Taylor committed
1269

1270 1271 1272 1273 1274 1275 1276 1277 1278 1279
<varlistentry>
<term>signal</term>
<listitem><para>A class method, e.g. GtkButton::clicked.
More precisely it is a unique class-branch/signal-name pair.
This means you may not define a signal handler for a class which
derives from GtkButton that is called clicked,
but it is okay to share signals names if they are separate in
the class tree.
</para></listitem>
</varlistentry>
Owen Taylor's avatar
Owen Taylor committed
1280

1281 1282 1283 1284 1285 1286
<varlistentry>
<term>default handler</term>
<listitem><para>The object's internal method which is invoked
when the signal is emitted.</para>
</listitem>
</varlistentry>
1287

1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298
<varlistentry>
<term>user-defined handler</term>
<listitem><para>A function pointer and data connected
to a signal (for a particular object).</para>
<para>There are really two types: those which are connected
normally, and those which are connected by one 
of the connect_after functions.  The connect_after handlers
are always run after the default handler.</para>
<para>Many toolkits refer to these as <wordasword>callbacks</wordasword>.</para>
</listitem>
</varlistentry>
1299

1300 1301 1302 1303 1304 1305 1306
<varlistentry>
<term>emission</term>
<listitem><para>the whole process of emitting a signal,
including the invocation of all
the different handler types mentioned above.</para>
</listitem>
</varlistentry>
1307

1308 1309 1310 1311 1312 1313 1314 1315
<varlistentry>
<term>signal id</term>
<listitem><para>The unique positive (nonzero) integer
used to identify a signal.  It can be used instead of 
a name to many functions for a slight performance
improvement.</para>
</listitem>
</varlistentry>
Havoc Pennington's avatar
Havoc Pennington committed
1316

1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327
<varlistentry>
<term>connection id</term>
<listitem><para>The unique positive (nonzero) integer
used to identify the connection of a user-defined handler
to a signal.  Notice that it is allowed to connect the
same function-pointer/user-data pair twice, so
there is no guarantee that a function-pointer/user-data
maps to a unique connection id.
</para>
</listitem>
</varlistentry>
Havoc Pennington's avatar
Havoc Pennington committed
1328

1329 1330
</variablelist>
</refsect2>
Havoc Pennington's avatar
Havoc Pennington committed
1331

1332
<refsect2><title>A brief note on how they work.</title>
1333
<para>
1334 1335 1336 1337 1338 1339 1340 1341 1342
The functions responsible for translating an array of #GtkArgs
to your C compiler's normal semantics are called Marshallers.
They are identified by
gtk_marshal_return_value__parameter_list()
for example a C function returning a gboolean and taking a gint
can be invoked by using gtk_marshal_BOOL__INT().
Not all possibly combinations of return/params are available,
of course, so if you are writing a #GtkObject with parameters
you might have to write a marshaller.
1343
</para>
1344
</refsect2>
1345 1346


1347
<!-- ##### SECTION ./tmpl/gtksignal.sgml:See_Also ##### -->
Owen Taylor's avatar
Owen Taylor committed
1348
<para>
1349 1350 1351 1352 1353 1354
<variablelist>

<varlistentry>
<term>#GtkObject</term>
<listitem><para>The base class for things which emit signals.</para></listitem>
</varlistentry>
Owen Taylor's avatar