Gtk.Widget

const Gtk = imports.gi.Gtk;

let widget = new Gtk.Widget({
    app_paintable: value,
    can_default: value,
    can_focus: value,
    double_buffered: value,
    events: value,
    expand: value,
    halign: value,
    has_default: value,
    has_focus: value,
    has_tooltip: value,
    height_request: value,
    hexpand: value,
    hexpand_set: value,
    is_focus: value,
    margin: value,
    margin_bottom: value,
    margin_left: value,
    margin_right: value,
    margin_top: value,
    name: value,
    no_show_all: value,
    opacity: value,
    parent: value,
    receives_default: value,
    sensitive: value,
    style: value,
    tooltip_markup: value,
    tooltip_text: value,
    valign: value,
    vexpand: value,
    vexpand_set: value,
    visible: value,
    width_request: value,
});
  

GtkWidget is the base class all widgets in GTK+ derive from. It manages the widget lifecycle, states and style.

<refsect2 id="geometry-management"> <title>Height-for-width Geometry Management</title> <para> GTK+ uses a height-for-width (and width-for-height) geometry management system. Height-for-width means that a widget can change how much vertical space it needs, depending on the amount of horizontal space that it is given (and similar for width-for-height). The most common example is a label that reflows to fill up the available width, wraps to fewer lines, and therefore needs less height.

Height-for-width geometry management is implemented in GTK+ by way of five virtual methods: <itemizedlist> <listitem>Gtk.WidgetClass.get_request_mode()</listitem> <listitem>Gtk.WidgetClass.get_preferred_width()</listitem> <listitem>Gtk.WidgetClass.get_preferred_height()</listitem> <listitem>Gtk.WidgetClass.get_preferred_height_for_width()</listitem> <listitem>Gtk.WidgetClass.get_preferred_width_for_height()</listitem> </itemizedlist>

There are some important things to keep in mind when implementing height-for-width and when using it in container implementations.

The geometry management system will query a widget hierarchy in only one orientation at a time. When widgets are initially queried for their minimum sizes it is generally done in two initial passes in the Gtk.SizeRequestMode chosen by the toplevel.

For example, when queried in the normal Gtk.SizeRequestMode.height_for_width mode: First, the default minimum and natural width for each widget in the interface will be computed using Gtk.get_preferred_width. Because the preferred widths for each container depend on the preferred widths of their children, this information propagates up the hierarchy, and finally a minimum and natural width is determined for the entire toplevel. Next, the toplevel will use the minimum width to query for the minimum height contextual to that width using Gtk.get_preferred_height_for_width, which will also be a highly recursive operation. The minimum height for the minimum width is normally used to set the minimum size constraint on the toplevel (unless Gtk.set_geometry_hints is explicitly used instead).

After the toplevel window has initially requested its size in both dimensions it can go on to allocate itself a reasonable size (or a size previously specified with Gtk.set_default_size). During the recursive allocation process it's important to note that request cycles will be recursively executed while container widgets allocate their children. Each container widget, once allocated a size, will go on to first share the space in one orientation among its children and then request each child's height for its target allocated width or its width for allocated height, depending. In this way a Gtk.Widget will typically be requested its size a number of times before actually being allocated a size. The size a widget is finally allocated can of course differ from the size it has requested. For this reason, Gtk.Widget caches a small number of results to avoid re-querying for the same sizes in one allocation cycle.

See <link linkend="container-geometry-management">GtkContainer's geometry management section</link> to learn more about how height-for-width allocations are performed by container widgets.

If a widget does move content around to intelligently use up the allocated size then it must support the request in both #GtkSizeRequestModes even if the widget in question only trades sizes in a single orientation.

For instance, a Gtk.Label that does height-for-width word wrapping will not expect to have Gtk.WidgetClass.get_preferred_height() called because that call is specific to a width-for-height request. In this case the label must return the height required for its own minimum possible width. By following this rule any widget that handles height-for-width or width-for-height requests will always be allocated at least enough space to fit its own content.

Here are some examples of how a Gtk.SizeRequestMode.height_for_width widget generally deals with width-for-height requests, for Gtk.WidgetClass.get_preferred_height() it will do: <programlisting><![CDATA[ static void foo_widget_get_preferred_height (GtkWidget *widget, gint *min_height, gint *nat_height) { if (i_am_in_height_for_width_mode) { gint min_width;

GTK_WIDGET_GET_CLASS (widget)->get_preferred_width (widget, &min_width, NULL); GTK_WIDGET_GET_CLASS (widget)->get_preferred_height_for_width (widget, min_width, min_height, nat_height); } else { ... some widgets do both. For instance, if a GtkLabel is rotated to 90 degrees it will return the minimum and natural height for the rotated label here. } } ]]></programlisting>

And in Gtk.WidgetClass.get_preferred_width_for_height() it will simply return the minimum and natural width:

<programlisting><![CDATA[ static void foo_widget_get_preferred_width_for_height (GtkWidget *widget, gint for_height, gint *min_width, gint *nat_width) { if (i_am_in_height_for_width_mode) { GTK_WIDGET_GET_CLASS (widget)->get_preferred_width (widget, min_width, nat_width); } else { ... again if a widget is sometimes operating in width-for-height mode (like a rotated GtkLabel) it can go ahead and do its real width for height calculation here. } } ]]></programlisting>

Often a widget needs to get its own request during size request or allocation. For example, when computing height it may need to also compute width. Or when deciding how to use an allocation, the widget may need to know its natural size. In these cases, the widget should be careful to call its virtual methods directly, like this: <example> <title>Widget calling its own size request method.</title> <programlisting> GTK_WIDGET_GET_CLASS(widget)-&gt;get_preferred_width (widget), &min, &natural); </programlisting> </example>

It will not work to use the wrapper functions, such as Gtk.get_preferred_width inside your own size request implementation. These return a request adjusted by Gtk.SizeGroup and by the Gtk.WidgetClass.adjust_size_request() virtual method. If a widget used the wrappers inside its virtual method implementations, then the adjustments (such as widget margins) would be applied twice. GTK+ therefore does not allow this and will warn if you try to do it.

Of course if you are getting the size request for <emphasis>another</emphasis> widget, such as a child of a container, you <emphasis>must</emphasis> use the wrapper APIs. Otherwise, you would not properly consider widget margins, Gtk.SizeGroup, and so forth. </para> </refsect2> <refsect2 id="style-properties"> <title>Style Properties</title> <para> <structname>GtkWidget</structname> introduces <firstterm>style properties</firstterm> - these are basically object properties that are stored not on the object, but in the style object associated to the widget. Style properties are set in <link linkend="gtk-Resource-Files">resource files</link>. This mechanism is used for configuring such things as the location of the scrollbar arrows through the theme, giving theme authors more control over the look of applications without the need to write a theme engine in C. </para> <para> Use Gtk.install_style_property to install style properties for a widget class, Gtk.find_style_property or Gtk.list_style_properties to get information about existing style properties and Gtk.style_get_property, Gtk.style_get or Gtk.style_get_valist to obtain the value of a style property. </para> </refsect2> <refsect2 id="GtkWidget-BUILDER-UI"> <title>GtkWidget as GtkBuildable</title> <para> The GtkWidget implementation of the GtkBuildable interface supports a custom &lt;accelerator&gt; element, which has attributes named key, modifiers and signal and allows to specify accelerators. </para> <example> <title>A UI definition fragment specifying an accelerator</title> <programlisting><![CDATA[ <object class="GtkButton"> <accelerator key="q" modifiers="GDK_CONTROL_MASK" signal="clicked"/> </object> ]]></programlisting> </example> <para> In addition to accelerators, <structname>GtkWidget</structname> also support a custom &lt;accessible&gt; element, which supports actions and relations. Properties on the accessible implementation of an object can be set by accessing the internal child "accessible" of a <structname>GtkWidget</structname>. </para> <example> <title>A UI definition fragment specifying an accessible</title> <programlisting><![CDATA[ <object class="GtkButton" id="label1"/> <property name="label">I am a Label for a Button</property> </object> <object class="GtkButton" id="button1"> <accessibility> <action action_name="click" translatable="yes">Click the button.</action> <relation target="label1" type="labelled-by"/> </accessibility> <child internal-child="accessible"> <object class="AtkObject" id="a11y-button1"> <property name="accessible-name">Clickable Button</property> </object> </child> </object> ]]></programlisting> </example> <para> Finally, GtkWidget allows style information such as style classes to be associated with widgets, using the custom &lt;style&gt; element: <example> <title>A UI definition fragment specifying an style class</title> <programlisting><![CDATA[ <object class="GtkButton" id="button1"> <style> <class name="my-special-button-class"/> <class name="dark-button"/> </style> </object> ]]></programlisting> </example> </para> </refsect2>