1998-02-04 03:18:53 +00:00
|
|
|
Notes about the inner workings of the widget system of GTK+
|
|
|
|
===========================================================
|
|
|
|
|
1998-02-01 08:22:51 +00:00
|
|
|
This file contains some notes as to how the widget system does
|
|
|
|
and should work. It consists of three parts:
|
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
I) A description of the meaning of the various flags
|
|
|
|
|
|
|
|
II) A list of invariants about the states of the widgets.
|
1998-02-01 08:22:51 +00:00
|
|
|
(Throughout this document, we refer to the states of the
|
1998-02-04 03:18:53 +00:00
|
|
|
widgets by referring to the flags for GtkWidget)
|
1998-02-01 08:22:51 +00:00
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
III) Some notes about the ways that a widget changes states
|
1998-02-01 08:22:51 +00:00
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
IV) A list of responsibilities of various widget signals when
|
1998-02-01 08:22:51 +00:00
|
|
|
the states change.
|
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
Any action necessary to maintain the invariants in II which is not
|
|
|
|
explicitly mentioned in IV), is the responsibility of the core GTK
|
|
|
|
code, which is roughly defined as:
|
1998-02-01 08:22:51 +00:00
|
|
|
|
|
|
|
gtkobject.c
|
|
|
|
gtkwidget.c
|
|
|
|
gtkcontainer.c
|
|
|
|
gtkmain.c
|
1998-02-03 23:31:21 +00:00
|
|
|
gtksignal.c
|
|
|
|
|
|
|
|
Section II is mostly of interest to those maintaining GTK, the
|
|
|
|
other sections may also be interesting to people writing
|
|
|
|
new widgets.
|
|
|
|
|
1998-02-04 03:18:53 +00:00
|
|
|
Main outline:
|
|
|
|
- Owen Taylor <owt1@cornell.edu>
|
1998-02-11 00:40:20 +00:00
|
|
|
1998/02/03
|
1998-02-04 03:18:53 +00:00
|
|
|
|
|
|
|
Flag descriptions:
|
|
|
|
- Tim Janik <timj@gimp.org>
|
1998-02-11 00:40:20 +00:00
|
|
|
1998/02/04
|
1998-02-03 23:31:21 +00:00
|
|
|
|
|
|
|
I. Flags
|
|
|
|
--------
|
|
|
|
|
1998-02-04 03:18:53 +00:00
|
|
|
GtkObject:
|
|
|
|
|
|
|
|
GTK_DESTROYED:
|
|
|
|
This flagged is set for a GtkObject right before its
|
|
|
|
destruction code is executed. Its main use is the
|
2006-10-08 05:07:55 +00:00
|
|
|
prevention of multiple destruction invocations.
|
1998-02-04 03:18:53 +00:00
|
|
|
|
|
|
|
GTK_FLOATING:
|
|
|
|
This flag reflects the fact that the holder of the
|
|
|
|
initial reference count is unknown. Refer to refcounting.txt
|
|
|
|
for further details.
|
|
|
|
|
|
|
|
GTK_RESERVED_1:
|
|
|
|
GTK_RESERVED_2:
|
|
|
|
Reserved flags.
|
|
|
|
|
|
|
|
|
|
|
|
GtkWidget, public flags:
|
|
|
|
|
|
|
|
GTK_TOPLEVEL:
|
1998-02-12 02:40:30 +00:00
|
|
|
Widgets without a real parent, as there are GtkWindows and
|
1998-02-04 03:18:53 +00:00
|
|
|
GtkMenus have this flag set throughout their lifetime.
|
|
|
|
Toplevel widgets always contain their own GdkWindow.
|
|
|
|
|
|
|
|
GTK_NO_WINDOW:
|
|
|
|
This flag is indicative for a widget that does not provide
|
|
|
|
its own GdkWindow. Visible action (e.g. drawing) is performed
|
1998-02-12 02:40:30 +00:00
|
|
|
on the parent's GdkWindow.
|
1998-02-04 03:18:53 +00:00
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
GTK_REALIZED:
|
1998-02-04 03:18:53 +00:00
|
|
|
Set by gtk_widget_realize, unset by gtk_widget_unrealize.
|
|
|
|
Relies on ((widget->parent && widget->parent->window)
|
|
|
|
|| GTK_WIDGET_TOPLEVEL (widget));
|
|
|
|
Means: widget has an associated GdkWindow (XWindow).
|
1998-02-03 23:31:21 +00:00
|
|
|
|
|
|
|
GTK_MAPPED:
|
1998-02-04 03:18:53 +00:00
|
|
|
Set by gtk_widget_map, unset by gtk_widget_unmap.
|
|
|
|
May only be set if GTK_WIDGET_REALIZED (widget).
|
|
|
|
Means: gdk_window_show() has been called on the widgets window(s).
|
1998-02-03 23:31:21 +00:00
|
|
|
|
|
|
|
GTK_VISIBLE:
|
1998-02-04 03:18:53 +00:00
|
|
|
Set by gtk_widget_show.
|
|
|
|
Implies that a widget will be flagged GTK_MAPPED as soon as its
|
|
|
|
parent is mapped.
|
1998-02-03 23:31:21 +00:00
|
|
|
!GTK_VISIBLE:
|
1998-02-04 03:18:53 +00:00
|
|
|
Set by gtk_widget_hide.
|
|
|
|
Implies that a widget is not onscreen, therefore !GTK_MAPPED.
|
|
|
|
|
2001-07-19 14:57:15 +00:00
|
|
|
GTK_CHILD_VISIBLE
|
|
|
|
Set by gtk_widget_set_child_visible, and if FALSE indicates that
|
|
|
|
the widget should not be mapped even if the parent is mapped
|
|
|
|
and visible. Containers like GtkNotebook use this flag.
|
|
|
|
A private flag, not a public flag, so if you need to check
|
|
|
|
this flag, you should call gtk_widget_get_child_visible().
|
2006-10-08 05:07:55 +00:00
|
|
|
(Should be very rarely necessary.)
|
2001-07-19 14:57:15 +00:00
|
|
|
|
1998-02-04 03:18:53 +00:00
|
|
|
GTK_SENSITIVE:
|
|
|
|
Set and unset by gtk_widget_set_sensitive.
|
1998-02-12 02:40:30 +00:00
|
|
|
The sensitivity of a widget determines whether it will receive
|
1998-02-04 03:18:53 +00:00
|
|
|
certain events (e.g. button or key presses). One premise for
|
|
|
|
the widgets sensitivity is to have GTK_SENSITIVE set.
|
|
|
|
|
|
|
|
GTK_PARENT_SENSITIVE:
|
|
|
|
Set and unset by gtk_widget_set_sensitive operations on the
|
|
|
|
parents of the widget.
|
|
|
|
This is the second premise for the widgets sensitivity. Once
|
|
|
|
it has GTK_SENSITIVE and GTK_PARENT_SENSITIVE set, its state is
|
|
|
|
effectively sensitive. This is expressed (and can be examined) by
|
|
|
|
the GTK_WIDGET_IS_SENSITIVE macro.
|
|
|
|
|
|
|
|
GTK_CAN_FOCUS:
|
|
|
|
There are no directly corresponding functions for setting/unsetting
|
|
|
|
this flag, but it can be affected by the GtkWidget::has_focus argument
|
|
|
|
via gtk_widget_set_arg.
|
1998-02-12 02:40:30 +00:00
|
|
|
This flag determines whether a widget is able to handle focus grabs.
|
1998-02-04 03:18:53 +00:00
|
|
|
|
|
|
|
GTK_HAS_FOCUS:
|
|
|
|
This flag will be set by gtk_widget_grab_focus for widgets that also
|
1998-02-12 02:40:30 +00:00
|
|
|
have GTK_CAN_FOCUS set. The flag will be unset once another widget
|
1998-02-04 03:18:53 +00:00
|
|
|
grabs the focus.
|
|
|
|
|
|
|
|
GTK_CAN_DEFAULT:
|
|
|
|
GTK_HAS_DEFAULT:
|
|
|
|
These two flags are mostly equal in functionality to their *_FOCUS
|
1998-02-12 02:40:30 +00:00
|
|
|
counterparts, but for the default widget.
|
1998-02-03 23:31:21 +00:00
|
|
|
|
1998-02-04 03:18:53 +00:00
|
|
|
GTK_HAS_GRAB:
|
|
|
|
Set by gtk_grab_add, unset by gtk_grab_remove.
|
|
|
|
Means: widget is in the grab_widgets stack, and will be the preferred
|
|
|
|
one for receiving events other than ones of cosmetic value.
|
|
|
|
|
|
|
|
GTK_BASIC:
|
1998-02-12 02:40:30 +00:00
|
|
|
The GTK_BASIC flag is an attempt at making a distinction
|
|
|
|
between widgets that handle user input e.g. key/button presses
|
|
|
|
and those that don't. Subsequent parent<->child relation ships
|
|
|
|
of non `basic' widgets should be avoided. The checking for
|
|
|
|
this is currently not properly enforced in the code. For
|
|
|
|
example GtkButton is a non `basic' widget, that will therefore
|
|
|
|
disallow to act as a container for another GtkButton. Now the
|
|
|
|
gnit is, one can add a GtkHBox (which is a `basic' widget) to
|
|
|
|
the first button, and put the second into the box.
|
1998-02-28 14:35:55 +00:00
|
|
|
|
|
|
|
GTK_RESERVED_3:
|
|
|
|
|
|
|
|
GTK_RC_STYLE:
|
|
|
|
This flag indicates that its style has been looked up through
|
|
|
|
the rc mechanism. It does not imply that the widget actually
|
|
|
|
had a style defined through the rc mechanism.
|
|
|
|
|
1998-02-04 03:18:53 +00:00
|
|
|
|
|
|
|
GtkWidget, private flags:
|
|
|
|
|
|
|
|
GTK_USER_STYLE:
|
|
|
|
A widget is flagged to have a user style, once gtk_widget_set_style
|
|
|
|
has been invoked for it. The use of this flag is to tell widgets
|
2006-10-08 05:07:55 +00:00
|
|
|
which share a global user style from the ones which got a certain
|
1998-02-04 03:18:53 +00:00
|
|
|
style assign from outside the toolkit.
|
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
GTK_RESIZE_PENDING:
|
1998-02-04 03:18:53 +00:00
|
|
|
First, this is only valid for GtkContainers.
|
1998-02-03 23:31:21 +00:00
|
|
|
[some of the code should move to gtkcontainer.c therefore]
|
1998-02-04 03:18:53 +00:00
|
|
|
Relies on GTK_WIDGET_REALIZED(widget)
|
1998-02-03 23:31:21 +00:00
|
|
|
[this is not really enforced throughout the code, but should
|
2006-10-08 05:07:55 +00:00
|
|
|
be. it only requires a few checks for GTK_WIDGET_REALIZED and
|
1998-02-03 23:31:21 +00:00
|
|
|
minor changes to gtk_widget_unrealize, we can then remove the check
|
|
|
|
in gtk_widget_real_destroy]
|
1998-02-04 03:18:53 +00:00
|
|
|
Means: there is an idle handler waiting for the container to
|
1998-02-03 23:31:21 +00:00
|
|
|
resize it.
|
|
|
|
|
|
|
|
GTK_RESIZE_NEEDED:
|
1998-02-04 03:18:53 +00:00
|
|
|
Relies on GTK_WIDGET_REALIZED(widget)
|
|
|
|
[this is not really enforced throughout the code, but should
|
|
|
|
be. once this is done special checking in gtk_widget_real_destroy
|
|
|
|
can be avoided]
|
|
|
|
Means: a widget has been added to the resize_widgets list of
|
1998-02-03 23:31:21 +00:00
|
|
|
its _toplevel_ container (keep this in mind for GtkViewport).
|
2006-10-08 05:07:55 +00:00
|
|
|
Remark: this flag is also used internally by gtkwindow.c during
|
1998-02-04 03:18:53 +00:00
|
|
|
the evaluation of resizing worthy widgets.
|
1998-02-03 23:31:21 +00:00
|
|
|
|
|
|
|
GTK_LEAVE_PENDING:
|
1998-02-04 03:18:53 +00:00
|
|
|
A widget is flagged as such if there is a leave_notify event
|
|
|
|
pending for it. It will receive this event regardless of a grab
|
|
|
|
through another widget or its current sensitivity.
|
1998-02-03 23:31:21 +00:00
|
|
|
[this should be made relying on GTK_REALIZED]
|
|
|
|
|
1998-02-04 03:18:53 +00:00
|
|
|
GTK_HAS_SHAPE_MASK:
|
|
|
|
Set by gtk_widget_shape_combine_mask if a widget got a shape mask
|
|
|
|
assigned (making use of the X11 shaped window extension).
|
|
|
|
|
|
|
|
GTK_IN_REPARENT:
|
|
|
|
During the act of reparentation widgets which are already
|
|
|
|
realized and will be added to an already realized parent need
|
|
|
|
to have this flag set to prevent natural unrealization on the
|
|
|
|
process of getting unparented.
|
|
|
|
|
2002-02-18 22:08:41 +00:00
|
|
|
GTK_NEED_REQUEST:
|
|
|
|
This flag is set if the widget doesn't have an up to date
|
|
|
|
requisition. If this flag is set, we must actually emit ::size-request
|
|
|
|
when gtk_widget_size_request() is called. Otherwise, we can
|
|
|
|
simply widget->requisition. We keep track of this all the time
|
2006-10-08 05:07:55 +00:00
|
|
|
however, widgets with this flag set are only added to the resize
|
2002-02-18 22:08:41 +00:00
|
|
|
queue if they are viewable.
|
|
|
|
|
|
|
|
GTK_NEED_ALLOCATION:
|
|
|
|
This flag is set if the widget doesn't have an up to date
|
|
|
|
allocation. If this flag is set, we must actually emit ::size-allocate
|
|
|
|
when gtk_widget_size_allocate() is called, even if the new allocation
|
|
|
|
is the same as the current allocation.
|
|
|
|
|
1998-02-04 03:18:53 +00:00
|
|
|
Related Macros:
|
1998-02-03 23:31:21 +00:00
|
|
|
|
|
|
|
GTK_WIDGET_DRAWABLE:
|
1998-02-12 02:40:30 +00:00
|
|
|
This macro examines whether a widget is flagged as GTK_WIDGET_VISIBLE
|
1998-02-04 03:18:53 +00:00
|
|
|
and GTK_WIDGET_MAPPED.
|
|
|
|
Means: it _makes sense_ to draw in a widgets window.
|
1998-02-03 23:31:21 +00:00
|
|
|
|
1998-02-04 03:18:53 +00:00
|
|
|
GTK_WIDGET_IS_SENSITIVE:
|
|
|
|
This macro tells the real sensitivity state of a widget. It returns
|
1998-02-12 02:40:30 +00:00
|
|
|
whether both the widget and all its parents are in sensitive state.
|
1998-02-03 23:31:21 +00:00
|
|
|
|
|
|
|
|
|
|
|
II. Invariants:
|
|
|
|
---------------
|
|
|
|
|
|
|
|
This section describes various constraints on the states of
|
|
|
|
the widget:
|
|
|
|
|
|
|
|
In the following
|
|
|
|
|
|
|
|
A => B means if A is true, than B is true
|
|
|
|
A <=> B means A is true, if and only if B is true
|
1998-02-04 03:18:53 +00:00
|
|
|
(equivalent to A => B and A <= B)
|
1998-02-03 23:31:21 +00:00
|
|
|
|
|
|
|
|
|
|
|
1) GTK_WIDGET_DESTROYED (widget) => !GTK_WIDGET_REALIZED (widget)
|
|
|
|
=> !GTK_WIDGET_VISIBLE (widget)
|
1998-02-01 08:22:51 +00:00
|
|
|
[ The latter is not currently in place, but it should be ]
|
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
2) GTK_WIDGET_MAPPED (widget) => GTK_WIDGET_REALIZED (widget)
|
1998-02-01 08:22:51 +00:00
|
|
|
|
|
|
|
3) if GTK_WIDGET_TOPLEVEL (widget):
|
|
|
|
GTK_WIDGET_VISIBLE (widget) <=> GTK_WIDGET_MAPPED (widget)
|
|
|
|
|
|
|
|
4) if !GTK_WIDGET_TOPLEVEL (widget):
|
|
|
|
widget->parent && GTK_WIDGET_REALIZED (widget->parent) <=>
|
|
|
|
GTK_WIDGET_REALIZED (widget)
|
|
|
|
|
|
|
|
5) if !GTK_WIDGET_TOPLEVEL (widget):
|
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
GTK_WIDGET_MAPPED (widget) => GTK_WIDGET_VISIBLE (widget)
|
2001-07-19 14:57:15 +00:00
|
|
|
=> GTK_WIDGET_CHILD_VISIBLE (widget)
|
1998-02-03 23:31:21 +00:00
|
|
|
=> GTK_WIDGET_REALIZED (widget)
|
|
|
|
|
|
|
|
widget->parent && GTK_WIDGET_MAPPED (widget->parent) &&
|
2001-07-19 14:57:15 +00:00
|
|
|
GTK_WIDGET_VISIBLE (widget) && GTK_WIDGET_CHILD_VISIBLE
|
|
|
|
=> GTK_WIDGET_MAPPED (widget)
|
1998-02-01 08:22:51 +00:00
|
|
|
|
|
|
|
Note:, the definition
|
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
[ GTK_WIDGET_DRAWABLE = GTK_WIDGET_VISIBLE && GTK_WIDGET_MAPPED
|
2000-12-11 17:47:24 +00:00
|
|
|
is made in gtkwidget.h, but by 3) and 5),
|
1998-02-01 08:22:51 +00:00
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
GTK_WIDGET_MAPPED => GTK_WIDGET_VISIBLE
|
|
|
|
]
|
|
|
|
|
1998-02-12 02:40:30 +00:00
|
|
|
6) GTK_REDRAW_PENDING => GTK_WIDGET_REALIZED
|
|
|
|
GTK_RESIZE_PENDING => "
|
|
|
|
GTK_LEAVE_PENDING => "
|
|
|
|
GTK_RESIZE_NEEDED => "
|
1998-02-01 08:22:51 +00:00
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
III. How states are changed:
|
|
|
|
----------------------------
|
1998-02-01 08:22:51 +00:00
|
|
|
|
|
|
|
How can the user control the state of a widget:
|
|
|
|
-----------------------------------------------
|
|
|
|
|
|
|
|
(In the following, set flag means set the flag, do appropriate
|
|
|
|
actions, and enforce above invariants)
|
|
|
|
|
|
|
|
gtk_widget_show:
|
|
|
|
if !GTK_DESTROYED sets GTK_VISIBLE
|
|
|
|
|
|
|
|
gtk_widget_hide:
|
|
|
|
if !GTK_VISIBLE for widget
|
|
|
|
|
|
|
|
gtk_widget_destroy:
|
|
|
|
sets GTK_DESTROYED
|
|
|
|
For a top-level widget
|
|
|
|
|
|
|
|
gtk_widget_realize:
|
|
|
|
if !GTK_DESTROYED sets GTK_REALIZED
|
2006-10-08 05:07:55 +00:00
|
|
|
- Calling gtk_widget_realize when the widget is not a descendant
|
1998-02-01 08:22:51 +00:00
|
|
|
of a toplevel is an ERROR.
|
|
|
|
|
|
|
|
gtk_container_add (container, widget) [ and container-specific variants ]
|
|
|
|
Sets widget->parent
|
|
|
|
|
|
|
|
gtk_container_remove (container, widget)
|
|
|
|
unsets widget->parent
|
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
gtk_widget_reparent (widget, new_parent)
|
|
|
|
Equivalent to removing widget from old parent and adding it to
|
|
|
|
the new parent, except that the widget will not be temporarily
|
|
|
|
unrealized if both the old parent and the new parent are realized.
|
1998-02-01 08:22:51 +00:00
|
|
|
|
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
gtk_widget_unrealize
|
|
|
|
gtk_widget_map
|
|
|
|
gtk_widget_unmap
|
1998-02-01 08:22:51 +00:00
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
These functions are not meant to be used by applications - they
|
|
|
|
are used only by GTK and widgets to enforce invariants on the
|
|
|
|
state.
|
1998-02-01 08:22:51 +00:00
|
|
|
|
|
|
|
When The X window corresponding to a GTK window is destroyed:
|
|
|
|
-------------------------------------------------------------
|
|
|
|
|
|
|
|
gtk_widget_destroy is called (as above).
|
|
|
|
|
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
|
|
|
|
IV. Responsibilities of widgets
|
1998-02-01 08:22:51 +00:00
|
|
|
--------------------------------
|
|
|
|
|
|
|
|
Adding to a container
|
|
|
|
---------------------
|
|
|
|
|
|
|
|
When a widget is added to a container, the container:
|
|
|
|
|
2001-07-19 14:57:15 +00:00
|
|
|
1) calls gtk_widget_set_parent_window (widget, window) if
|
1998-02-01 08:22:51 +00:00
|
|
|
the widget is being added to something other than container->window
|
2001-07-19 14:57:15 +00:00
|
|
|
2) calls gtk_widget_set_parent (widget, container)
|
1998-02-01 08:22:51 +00:00
|
|
|
|
|
|
|
Removing from a container
|
|
|
|
-------------------------
|
|
|
|
|
|
|
|
When a widget is removed to a container, the container:
|
|
|
|
|
|
|
|
1) Calls gtk_widget_unparent (widget)
|
1998-04-14 01:09:25 +00:00
|
|
|
2) Queues a resize.
|
1998-02-01 08:22:51 +00:00
|
|
|
|
|
|
|
Notes:
|
|
|
|
|
|
|
|
gtk_widget_unparent unrealizes the widget except in the
|
1998-02-03 23:31:21 +00:00
|
|
|
special case GTK_IN_REPARENT is set.
|
1998-02-01 08:22:51 +00:00
|
|
|
|
|
|
|
|
|
|
|
At widget creation
|
|
|
|
------------------
|
|
|
|
|
|
|
|
Widgets are created in an unrealized state.
|
|
|
|
|
|
|
|
1) The widget should allocate and initialize needed data structures
|
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
|
1998-02-01 08:22:51 +00:00
|
|
|
The Realize signal
|
|
|
|
------------------
|
|
|
|
|
2006-10-08 05:07:55 +00:00
|
|
|
When a widget receives the "realize" signal it should:
|
1998-02-01 08:22:51 +00:00
|
|
|
|
|
|
|
NO_WINDOW widgets: (probably OK to use default handler)
|
|
|
|
|
|
|
|
1) set the realized flag
|
|
|
|
2) set widget->window
|
|
|
|
widget->window = gtk_widget_get_parent_window (widget);
|
2009-10-14 01:02:14 +00:00
|
|
|
g_object_ref (widget->window);
|
1998-02-01 08:22:51 +00:00
|
|
|
3) attach the widget's style
|
|
|
|
|
|
|
|
widget->style = gtk_style_attach (widget->style, widget->window);
|
|
|
|
|
|
|
|
widget with window(s)
|
|
|
|
|
|
|
|
1) set the REALIZED flag
|
|
|
|
2) create windows with the parent obtained from
|
|
|
|
gtk_widget_get_parent_window (widget);
|
|
|
|
3) attach the widget's style
|
|
|
|
4) set the background color for the new window based on the style
|
|
|
|
|
|
|
|
The Map signal
|
|
|
|
--------------
|
|
|
|
|
|
|
|
1) Set the MAPPED flag
|
1998-02-03 23:31:21 +00:00
|
|
|
2) If the widget has any windows, gdk_window_show those windows
|
1998-04-14 01:09:25 +00:00
|
|
|
3) call gtk_widget_map for all child widgets that are
|
2001-07-19 14:57:15 +00:00
|
|
|
VISIBLE, CHILD_VISIBLE and !MAPPED. (A widget will only
|
|
|
|
be !CHILD_VISIBLE if the container set it that way, so
|
|
|
|
most containers will not have to check this.)
|
1998-02-01 08:22:51 +00:00
|
|
|
3) Do any other functions related to putting the widget onscreen.
|
|
|
|
(for instance, showing extra popup windows...)
|
|
|
|
|
|
|
|
The Unmap signal
|
|
|
|
----------------
|
|
|
|
|
|
|
|
When a widget receives the unmap signal, it must:
|
|
|
|
|
|
|
|
1) If the widget has a window, gdk_window_hide that window,
|
|
|
|
2) If the widget does not have a window, unmap all child widgets
|
|
|
|
3) Do any other functions related to taking the widget offscreen
|
|
|
|
(for instance, removing popup windows...)
|
Added gdk_text/string_extents() - too calculate all the metrics at once of
Tue Jul 21 12:42:01 1998 Owen Taylor <otaylor@redhat.com>
* gdk/gdk.h gdk/gdkfont.c: Added gdk_text/string_extents() -
too calculate all the metrics at once of a string, including
things which weren't calculated before.
* gtk/Makefile.am gtk/gtk.h gtk/gtktearoffmenu.[ch]: New
MenuItem type, that when put as the first thing in a
menu, makes the menu tearoff. Currently drawn as a
dashed line.
* gtk/gtkmenuitem.h gtk/gtkcheckmenuitem.c: Added a flag
"hide_on_activate" to the MenuItem class structure to allow
check and radio buttons to be changed with <Space> without
hiding the menu.
* gtk/gtkaccellabel.[ch]: Added new capabilities to set
a underline_group and underline_mods for the label -
accelerators added in the underline group matching
underline_mods will be displayed as an underline character.
This doesn't work - Save As needs to be underlined
as Save _As.
* gtk/gtkitemfactory.c:
- Create a AccelGroup for each MenuShell we create.
- If an '&' appears before a character 'c' in the path,
then make 'c' an accelerator in the menu's accel group,
and if the menuitem is menubar <alt>C an accelerator
in the itemfactory's accel group.
* gtk/gtklabel.[ch]: Add support for a pattern arg -
which is a string. If an '_' appears in this string,
the corresponding position in the label is underlined.
Add gtk_label_parse_uline() convenience function which
takes a string with embedded underlines, sets the
pattern and label, and returns the accelerator keyval.
* gtk/gtkmenu.[ch]: Make menus no longer a toplevel widget.
Instead, they create a GtkWindow and add themselves
to that. (When torn off, another new feature, they
create another GtkWindow to hold the torn off menu)
New function gtk_menu_set_tearoff_state()
* gtk/gtkenums.h gtk/gtkmenushell.[ch] gtk/gtkenums.h:
Added action signals for keyboard navigation of menus.
* gtk/gtkmenushell.c: Key press handler which activates
bindings for navigation, and accelerators, for handling
underline accelerators. Exported functions to select
and activate menu items in a menushell.
* gtk/testgtk.c: Added a new "Item Factory" test which
tests GtkItemFactory and the new keyboard navigation
of menus.
1998-08-12 16:49:13 +00:00
|
|
|
4) Unset GTK_MAPPED
|
1998-02-01 08:22:51 +00:00
|
|
|
|
|
|
|
|
|
|
|
The Unrealize signal
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
When a widget receives the unrealize signal, it must
|
|
|
|
|
|
|
|
1) For any windows other than widget->window do:
|
|
|
|
|
|
|
|
gdk_window_set_user_data (window, NULL);
|
|
|
|
gdk_window_destroy (window);
|
|
|
|
|
|
|
|
2) Call the parent's unrealize handler
|
|
|
|
|
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
The Widget class unrealize handler will take care of unrealizing
|
|
|
|
all children if necessary. [should this be made consistent with
|
|
|
|
unmap???]
|
1998-02-01 08:22:51 +00:00
|
|
|
|
|
|
|
|
|
|
|
The Destroy Signal
|
|
|
|
------------------
|
|
|
|
|
|
|
|
Commentary:
|
|
|
|
|
|
|
|
The destroy signal probably shouldn't exist at all. A widget
|
|
|
|
should merely be unrealized and removed from its parent
|
|
|
|
when the user calls gtk_widget_destroy or a GDK_DESTROY event
|
|
|
|
is received. However, a large body of code depends on
|
|
|
|
getting a definitive signal when a widget goes away.
|
|
|
|
|
|
|
|
That could be put in the finalization step, but, especially
|
|
|
|
with language bindings, the cleanup step may need to refer
|
|
|
|
back to the widget. (To use gtk_widget_get_data, for instance)
|
|
|
|
If it does so via a pointer in a closure (natural for
|
|
|
|
Scheme, or Perl), then the finalization procedure will never
|
|
|
|
be called.
|
|
|
|
|
|
|
|
Also, if we made that the finalization step, we would have
|
|
|
|
to propagate the GDK_DESTROY event in any case, since it is
|
|
|
|
at that point at which user-visible actions need to be taken.
|
|
|
|
|
|
|
|
|
|
|
|
When a widget receives the destroy signal, it must:
|
|
|
|
|
|
|
|
1) If the widget "owns" any widgets other than its child
|
|
|
|
widgets, (for instance popup windows) it should
|
1998-02-03 23:31:21 +00:00
|
|
|
call gtk_widget_destroy () for them.
|
1998-02-01 08:22:51 +00:00
|
|
|
|
|
|
|
2) Call the parent class's destroy handler.
|
|
|
|
|
|
|
|
|
|
|
|
The "destroy" signal will only be received once. A widget
|
|
|
|
will never receive any other signals after the destroy
|
2006-10-08 05:07:55 +00:00
|
|
|
signal (but see the section on "Finalize" below)
|
1998-02-01 08:22:51 +00:00
|
|
|
|
|
|
|
The widget must handle calls to all publically accessible
|
|
|
|
functions in an innocuous manner even after a "destroy"
|
|
|
|
signal. (A widget can assume that it will not be realized
|
|
|
|
after a "destroy" signal is received, which may simplify
|
|
|
|
handling this requirement)
|
|
|
|
|
|
|
|
|
|
|
|
The Finalize Pseudo-signal
|
|
|
|
--------------------------
|
|
|
|
|
|
|
|
The finalize pseudo-signal is received after all references
|
|
|
|
to the widget have been removed. The finalize callback
|
|
|
|
cannot make any GTK calls with the widget as a parameter.
|
|
|
|
|
|
|
|
1) Free any memory allocated by the widget. (But _not_
|
|
|
|
the widget structure itself.
|
|
|
|
|
1998-02-03 23:31:21 +00:00
|
|
|
2) Call the parent class's finalize signal
|
1998-02-01 08:22:51 +00:00
|
|
|
|
|
|
|
|
|
|
|
A note on chaining "destroy" signals and finalize signals:
|
|
|
|
---------------------------------------------------------
|
|
|
|
|
|
|
|
This is done by code like:
|
|
|
|
|
|
|
|
if (GTK_OBJECT_CLASS (parent_class)->destroy)
|
|
|
|
(* GTK_OBJECT_CLASS (parent_class)->destroy) (object);
|
|
|
|
|
|
|
|
It may not be completely obvious why this works. Note
|
|
|
|
that parent_class is a static variable on a per-class
|
|
|
|
basis. So say: we have
|
|
|
|
|
|
|
|
GtkFoo <- GtkBar <- GtkWidget <-GtkObject
|
|
|
|
|
|
|
|
And that Foo, Widget, and Object all have destructors, but
|
|
|
|
not Bar.
|
|
|
|
|
|
|
|
Then gtk_foo_destroy will call gtk_widget_destroy (because
|
|
|
|
it was not overridden in the Bar class structure) and
|
|
|
|
gtk_widget_destroy will call gtk_object_destroy because
|
|
|
|
the parent_class variable referenced by gtk_foo_destroy is the
|
|
|
|
static variable in gtkwidget.c: GtkObjectClass.
|