Undocumented

Undocumented

The button-press-event signal will be emitted when a button (typically from a mouse) is pressed.

To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_BUTTON_PRESS_MASK mask.

This signal will be sent to the grab widget if there is one.

The button-release-event signal will be emitted when a button (typically from a mouse) is released.

To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_BUTTON_RELEASE_MASK mask.

This signal will be sent to the grab widget if there is one.

Determines whether an accelerator that activates the signal identified by signal_id can currently be activated. This signal is present to allow applications and derived widgets to override the default GtkWidget handling for determining whether an accelerator can be activated.

Undocumented

The child-notify signal is emitted for each child property that has changed on an object. The signal’s detail holds the property name.

The composited-changed signal is emitted when the composited status of widgets screen changes. See gdk_screen_is_composited().

composited-changed is deprecated: Use GdkScreen::composited-changed instead.

The configure-event signal will be emitted when the size, position or stacking of the widget‘s window has changed.

To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_STRUCTURE_MASK mask. GDK will enable this mask automatically for all new windows.

Emitted when a redirected window belonging to widget gets drawn into. The region/area members of the event shows what area of the redirected drawable was drawn into.

The delete-event signal is emitted if a user requests that a toplevel window is closed. The default handler for this signal destroys the window. Connecting gtk_widget_hide_on_delete() to this signal will cause the window to be hidden instead, so that it can later be shown again without reconstructing it.

Signals that all holders of a reference to the widget should release the reference that they hold. May result in finalization of the widget if all references are released.

This signal is not suitable for saving widget state.

The destroy-event signal is emitted when a GdkWindow is destroyed. You rarely get this signal, because most widgets disconnect themselves from their window before they destroy it, so no widget owns the window at destroy time.

To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_STRUCTURE_MASK mask. GDK will enable this mask automatically for all new windows.

The direction-changed signal is emitted when the text direction of a widget changes.

The places sidebar emits this signal when it needs to ask the application to pop up a menu to ask the user for which drag action to perform.

When the user starts a drag-and-drop operation and the sidebar needs to ask the application for which drag action to perform, then the sidebar will emit this signal.

The application can evaluate the context for customary actions, or it can check the type of the files indicated by source_file_list against the possible actions for the destination dest_file.

The drag action to use must be the return value of the signal handler.

The drag-begin signal is emitted on the drag source when a drag is started. A typical reason to connect to this signal is to set up a custom drag icon with e.g. gtk_drag_source_set_icon_pixbuf().

Note that some widgets set up a drag icon in the default handler of this signal, so you may have to use g_signal_connect_after() to override what the default handler did.

The drag-data-delete signal is emitted on the drag source when a drag with the action GDK_ACTION_MOVE is successfully completed. The signal handler is responsible for deleting the data that has been dropped. What “delete” means depends on the context of the drag operation.

The drag-data-get signal is emitted on the drag source when the drop site requests the data which is dragged. It is the responsibility of the signal handler to fill data with the data in the format which is indicated by info. See gtk_selection_data_set() and gtk_selection_data_set_text().

The drag-data-received signal is emitted on the drop site when the dragged data has been received. If the data was received in order to determine whether the drop will be accepted, the handler is expected to call gdk_drag_status() and not finish the drag. If the data was received in response to a GtkWidget::drag-drop signal (and this is the last target to be received), the handler for this signal is expected to process the received data and then call gtk_drag_finish(), setting the success parameter depending on whether the data was processed successfully.

Applications must create some means to determine why the signal was emitted and therefore whether to call gdk_drag_status() or gtk_drag_finish().

The handler may inspect the selected action with gdk_drag_context_get_selected_action() before calling gtk_drag_finish(), e.g. to implement GDK_ACTION_ASK as shown in the following example: (C Language Example):

void
drag_data_received (GtkWidget          *widget,
                    GdkDragContext     *context,
                    gint                x,
                    gint                y,
                    GtkSelectionData   *data,
                    guint               info,
                    guint               time)
{
  if ((data->length >= 0) && (data->format == 8))
    {
      GdkDragAction action;

      // handle data here

      action = gdk_drag_context_get_selected_action (context);
      if (action == GDK_ACTION_ASK)
        {
          GtkWidget *dialog;
          gint response;

          dialog = gtk_message_dialog_new (NULL,
                                           GTK_DIALOG_MODAL |
                                           GTK_DIALOG_DESTROY_WITH_PARENT,
                                           GTK_MESSAGE_INFO,
                                           GTK_BUTTONS_YES_NO,
                                           "Move the data ?\n");
          response = gtk_dialog_run (GTK_DIALOG (dialog));
          gtk_widget_destroy (dialog);

          if (response == GTK_RESPONSE_YES)
            action = GDK_ACTION_MOVE;
          else
            action = GDK_ACTION_COPY;
         }

      gtk_drag_finish (context, TRUE, action == GDK_ACTION_MOVE, time);
    }
  else
    gtk_drag_finish (context, FALSE, FALSE, time);
 }

The drag-drop signal is emitted on the drop site when the user drops the data onto the widget. The signal handler must determine whether the cursor position is in a drop zone or not. If it is not in a drop zone, it returns false and no further processing is necessary. Otherwise, the handler returns true. In this case, the handler must ensure that gtk_drag_finish() is called to let the source know that the drop is done. The call to gtk_drag_finish() can be done either directly or in a GtkWidget::drag-data-received handler which gets triggered by calling gtk_drag_get_data() to receive the data for one or more of the supported targets.

The drag-end signal is emitted on the drag source when a drag is finished. A typical reason to connect to this signal is to undo things done in GtkWidget::drag-begin.

The drag-failed signal is emitted on the drag source when a drag has failed. The signal handler may hook custom code to handle a failed DnD operation based on the type of error, it returns true is the failure has been already handled (not showing the default “drag operation failed” animation), otherwise it returns false.

The drag-leave signal is emitted on the drop site when the cursor leaves the widget. A typical reason to connect to this signal is to undo things done in GtkWidget::drag-motion, e.g. undo highlighting with gtk_drag_unhighlight().

Likewise, the GtkWidget::drag-leave signal is also emitted before the drag-drop signal, for instance to allow cleaning up of a preview item created in the GtkWidget::drag-motion signal handler.

The drag-motion signal is emitted on the drop site when the user moves the cursor over the widget during a drag. The signal handler must determine whether the cursor position is in a drop zone or not. If it is not in a drop zone, it returns false and no further processing is necessary. Otherwise, the handler returns true. In this case, the handler is responsible for providing the necessary information for displaying feedback to the user, by calling gdk_drag_status().

If the decision whether the drop will be accepted or rejected can’t be made based solely on the cursor position and the type of the data, the handler may inspect the dragged data by calling gtk_drag_get_data() and defer the gdk_drag_status() call to the GtkWidget::drag-data-received handler. Note that you must pass GTK_DEST_DEFAULT_DROP, GTK_DEST_DEFAULT_MOTION or GTK_DEST_DEFAULT_ALL to gtk_drag_dest_set() when using the drag-motion signal that way.

Also note that there is no drag-enter signal. The drag receiver has to keep track of whether he has received any drag-motion signals since the last GtkWidget::drag-leave and if not, treat the drag-motion signal as an “enter” signal. Upon an “enter”, the handler will typically highlight the drop site with gtk_drag_highlight(). (C Language Example):

static void
drag_motion (GtkWidget      *widget,
             GdkDragContext *context,
             gint            x,
             gint            y,
             guint           time)
{
  GdkAtom target;

  PrivateData *private_data = GET_PRIVATE_DATA (widget);

  if (!private_data->drag_highlight)
   {
     private_data->drag_highlight = 1;
     gtk_drag_highlight (widget);
   }

  target = gtk_drag_dest_find_target (widget, context, NULL);
  if (target == GDK_NONE)
    gdk_drag_status (context, 0, time);
  else
   {
     private_data->pending_status
        = gdk_drag_context_get_suggested_action (context);
     gtk_drag_get_data (widget, context, target, time);
   }

  return TRUE;
}

static void
drag_data_received (GtkWidget        *widget,
                    GdkDragContext   *context,
                    gint              x,
                    gint              y,
                    GtkSelectionData *selection_data,
                    guint             info,
                    guint             time)
{
  PrivateData *private_data = GET_PRIVATE_DATA (widget);

  if (private_data->suggested_action)
   {
     private_data->suggested_action = 0;

     // We are getting this data due to a request in drag_motion,
     // rather than due to a request in drag_drop, so we are just
     // supposed to call gdk_drag_status(), not actually paste in
     // the data.

     str = gtk_selection_data_get_text (selection_data);
     if (!data_is_acceptable (str))
       gdk_drag_status (context, 0, time);
     else
       gdk_drag_status (context,
                        private_data->suggested_action,
                        time);
   }
  else
   {
     // accept the drop
   }
}

The places sidebar emits this signal when the user completes a drag-and-drop operation and one of the sidebar’s items is the destination. This item is in the dest_file, and the source_file_list has the list of files that are dropped into it and which should be copied/moved/etc. based on the specified action.

This signal is emitted when a widget is supposed to render itself. The widget‘s top left corner must be painted at the origin of the passed in context and be sized to the values returned by gtk_widget_get_allocated_width() and gtk_widget_get_allocated_height().

Signal handlers connected to this signal can modify the cairo context passed as cr in any way they like and don’t need to restore it. The signal emission takes care of calling cairo_save() before and cairo_restore() after invoking the handler.

The signal handler will get a cr with a clip region already set to the widget’s dirty region, i.e. to the area that needs repainting. Complicated widgets that want to avoid redrawing themselves completely can get the full extents of the clip region with gdk_cairo_get_clip_rectangle(), or they can get a finer-grained representation of the dirty region with cairo_copy_clip_rectangle_list().

The edge-overshot signal is emitted whenever user initiated scrolling makes the scrolled window firmly surpass (i.e. with some edge resistance) the lower or upper limits defined by the adjustment in that orientation.

A similar behavior without edge resistance is provided by the GtkScrolledWindow::edge-reached signal.

Note: The pos argument is LTR/RTL aware, so callers should be aware too if intending to provide behavior on horizontal edges.

The edge-reached signal is emitted whenever user-initiated scrolling makes the scrolled window exactly reach the lower or upper limits defined by the adjustment in that orientation.

A similar behavior with edge resistance is provided by the GtkScrolledWindow::edge-overshot signal.

Note: The pos argument is LTR/RTL aware, so callers should be aware too if intending to provide behavior on horizontal edges.

The enter-notify-event will be emitted when the pointer enters the widget‘s window.

To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_ENTER_NOTIFY_MASK mask.

This signal will be sent to the grab widget if there is one.

The GTK+ main loop will emit three signals for each GDK event delivered to a widget: one generic event signal, another, more specific, signal that matches the type of event delivered (e.g. GtkWidget::key-press-event) and finally a generic GtkWidget::event-after signal.

After the emission of the GtkWidget::event signal and (optionally) the second more specific signal, event-after will be emitted regardless of the previous two signals handlers return values.

Undocumented

The focus-in-event signal will be emitted when the keyboard focus enters the widget‘s window.

To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_FOCUS_CHANGE_MASK mask.

The focus-out-event signal will be emitted when the keyboard focus leaves the widget‘s window.

To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_FOCUS_CHANGE_MASK mask.

Emitted when a pointer or keyboard grab on a window belonging to widget gets broken.

On X11, this happens when the grab window becomes unviewable (i.e. it or one of its ancestors is unmapped), or if the same application grabs the pointer or keyboard again.

Undocumented

The grab-notify signal is emitted when a widget becomes shadowed by a GTK+ grab (not a pointer or keyboard grab) on another widget, or when it becomes unshadowed due to a grab being removed.

A widget is shadowed by a gtk_grab_add() when the topmost grab widget in the grab stack of its window group is not its ancestor.

The hide signal is emitted when widget is hidden, for example with gtk_widget_hide().

The hierarchy-changed signal is emitted when the anchored state of a widget changes. A widget is “anchored” when its toplevel ancestor is a GtkWindow. This signal is emitted when a widget changes from un-anchored to anchored or vice-versa.

The key-press-event signal is emitted when a key is pressed. The signal emission will reoccur at the key-repeat rate when the key is kept pressed.

To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_KEY_PRESS_MASK mask.

This signal will be sent to the grab widget if there is one.

The key-release-event signal is emitted when a key is released.

To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_KEY_RELEASE_MASK mask.

This signal will be sent to the grab widget if there is one.

Gets emitted if keyboard navigation fails. See gtk_widget_keynav_failed() for details.

The leave-notify-event will be emitted when the pointer leaves the widget‘s window.

To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_LEAVE_NOTIFY_MASK mask.

This signal will be sent to the grab widget if there is one.

The map signal is emitted when widget is going to be mapped, that is when the widget is visible (which is controlled with gtk_widget_set_visible()) and all its parents up to the toplevel widget are also visible. Once the map has occurred, GtkWidget::map-event will be emitted.

The map signal can be used to determine whether a widget will be drawn, for instance it can resume an animation that was stopped during the emission of GtkWidget::unmap.

The map-event signal will be emitted when the widget‘s window is mapped. A window is mapped when it becomes visible on the screen.

To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_STRUCTURE_MASK mask. GDK will enable this mask automatically for all new windows.

The default handler for this signal activates widget if group_cycling is false, or just makes widget grab focus if group_cycling is true.

The motion-notify-event signal is emitted when the pointer moves over the widget’s GdkWindow.

To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_POINTER_MOTION_MASK mask.

This signal will be sent to the grab widget if there is one.

The places sidebar emits this signal when it starts a new operation because the user clicked on some location that needs mounting. In this way the application using the GtkPlacesSidebar can track the progress of the operation and, for example, show a notification.

Undocumented

The move-focus-out signal is a keybinding signal which gets emitted when focus is moved away from the scrolled window by a keybinding. The GtkWidget::move-focus signal is emitted with direction_type on this scrolled window’s toplevel parent in the container hierarchy. The default bindings for this signal are Ctrl + Tab to move forward and Ctrl + Shift + Tab to move backward.

The notify signal is emitted on an object when one of its properties has its value set through g_object_set_property(), g_object_set(), et al.

Note that getting this signal doesn’t itself guarantee that the value of the property has actually changed. When it is emitted is determined by the derived GObject class. If the implementor did not create the property with G_PARAM_EXPLICIT_NOTIFY, then any call to g_object_set_property() results in notify being emitted, even if the new value is the same as the old. If they did pass G_PARAM_EXPLICIT_NOTIFY, then this signal is emitted only when they explicitly call g_object_notify() or g_object_notify_by_pspec(), and common practice is to do that only when the value has actually changed.

This signal is typically used to obtain change notification for a single property, by specifying the property name as a detail in the g_signal_connect() call, like this:

(C Language Example):

g_signal_connect (text_view->buffer, "notify::paste-target-list",
                  G_CALLBACK (gtk_text_view_target_list_notify),
                  text_view)

It is important to note that you must use canonical parameter names as detail strings for the notify signal.

The places sidebar emits this signal when the user selects a location in it. The calling application should display the contents of that location; for example, a file manager should show a list of files in the specified location.

The parent-set signal is emitted when a new parent has been set on a widget.

The places sidebar emits this signal when the user invokes a contextual popup on one of its items. In the signal handler, the application may add extra items to the menu as appropriate. For example, a file manager may want to add a “Properties” command to the menu.

It is not necessary to store the selected_item for each menu item; during their callbacks, the application can use gtk_places_sidebar_get_location() to get the file to which the item refers.

The selected_item argument may be nil in case the selection refers to a volume. In this case, selected_volume will be non-nil. In this case, the calling application will have to g_object_ref() the selected_volume and keep it around to use it in the callback.

The container and all its contents are destroyed after the user dismisses the popup. The popup is re-created (and thus, this signal is emitted) every time the user activates the contextual menu.

Before 3.18, the container always was a GtkMenu, and you were expected to add your items as GtkMenuItems. Since 3.18, the popup may be implemented as a GtkPopover, in which case container will be something else, e.g. a GtkBox, to which you may add GtkModelButtons or other widgets, such as GtkEntries, GtkSpinButtons, etc. If your application can deal with this situation, you can set GtkPlacesSidebar::populate-all to true to request that this signal is emitted for populating popovers as well.

This signal gets emitted whenever a widget should pop up a context menu. This usually happens through the standard key binding mechanism; by pressing a certain key while a widget is focused, the user can cause the widget to pop up a menu. For example, the GtkEntry widget creates a menu with clipboard commands. See the Popup Menu Migration Checklist for an example of how to use this signal.

The property-notify-event signal will be emitted when a property on the widget‘s window has been changed or deleted.

To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_PROPERTY_CHANGE_MASK mask.

To receive this signal the GdkWindow associated to the widget needs to enable the GDK_PROXIMITY_IN_MASK mask.

This signal will be sent to the grab widget if there is one.

To receive this signal the GdkWindow associated to the widget needs to enable the GDK_PROXIMITY_OUT_MASK mask.

This signal will be sent to the grab widget if there is one.

Emitted when GtkWidget:has-tooltip is true and the hover timeout has expired with the cursor hovering “above” widget; or emitted when widget got focus in keyboard mode.

Using the given coordinates, the signal handler should determine whether a tooltip should be shown for widget. If this is the case true should be returned, false otherwise. Note that if keyboard_mode is true, the values of x and y are undefined and should not be used.

The signal handler is free to manipulate tooltip with the therefore destined function calls.

The realize signal is emitted when widget is associated with a GdkWindow, which means that gtk_widget_realize() has been called or the widget has been mapped (that is, it is going to be drawn).

Undocumented

The screen-changed signal gets emitted when the screen of a widget has changed.

The scroll-child signal is a keybinding signal which gets emitted when a keybinding that scrolls is pressed. The horizontal or vertical adjustment is updated which triggers a signal that the scrolled window’s child may listen to and scroll itself.

The scroll-event signal is emitted when a button in the 4 to 7 range is pressed. Wheel mice are usually configured to generate button press events for buttons 4 and 5 when the wheel is turned.

To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_SCROLL_MASK mask.

This signal will be sent to the grab widget if there is one.

The selection-clear-event signal will be emitted when the the widget‘s window has lost ownership of a selection.

Undocumented

Undocumented

Undocumented

The selection-request-event signal will be emitted when another client requests ownership of the selection owned by the widget‘s window.

Undocumented

The show signal is emitted when widget is shown, for example with gtk_widget_show().

The places sidebar emits this signal when it needs the calling application to present an way to connect directly to a network server. For example, the application may bring up a dialog box asking for a URL like “sftp://ftp.example.com”. It is up to the application to create the corresponding mount by using, for example, g_file_mount_enclosing_volume().

show-connect-to-server is deprecated: use the #GtkPlacesSidebar::show-other-locations signal to connect to network servers.

The places sidebar emits this signal when it needs the calling application to present an way to directly enter a location. For example, the application may bring up a dialog box asking for a URL like “http://http.example.com”.

The places sidebar emits this signal when it needs the calling application to present an error message. Most of these messages refer to mounting or unmounting media, for example, when a drive cannot be started for some reason.

Undocumented

The places sidebar emits this signal when it needs the calling application to present a way to show other locations e.g. drives and network access points. For example, the application may bring up a page showing persistent volumes and discovered network addresses.

show-other-locations is deprecated: use the #GtkPlacesSidebar::show-other-locations-with-flags which includes the open flags in order to allow the user to specify to open in a new tab or window, in a similar way than #GtkPlacesSidebar::open-location

The places sidebar emits this signal when it needs the calling application to present a way to show other locations e.g. drives and network access points. For example, the application may bring up a page showing persistent volumes and discovered network addresses.

The places sidebar emits this signal when it needs the calling application to present a way to show the starred files. In GNOME, starred files are implemented by setting the nao:predefined-tag-favorite tag in the tracker database.

Undocumented

The state-changed signal is emitted when the widget state changes. See gtk_widget_get_state().

state-changed is deprecated: Use #GtkWidget::state-flags-changed instead.

The state-flags-changed signal is emitted when the widget state changes, see gtk_widget_get_state_flags().

The style-set signal is emitted when a new style has been set on a widget. Note that style-modifying functions like gtk_widget_modify_base() also cause this signal to be emitted.

Note that this signal is emitted for changes to the deprecated GtkStyle. To track changes to the GtkStyleContext associated with a widget, use the GtkWidget::style-updated signal.

style-set is deprecated: Use the #GtkWidget::style-updated signal

The style-updated signal is a convenience signal that is emitted when the GtkStyleContext::changed signal is emitted on the widget‘s associated GtkStyleContext as returned by gtk_widget_get_style_context().

Note that style-modifying functions like gtk_widget_override_color() also cause this signal to be emitted.

Undocumented

The unmap signal is emitted when widget is going to be unmapped, which means that either it or any of its parents up to the toplevel widget have been set as hidden.

As unmap indicates that a widget will not be shown any longer, it can be used to, for example, stop an animation on the widget.

The unmap-event signal will be emitted when the widget‘s window is unmapped. A window is unmapped when it becomes invisible on the screen.

To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_STRUCTURE_MASK mask. GDK will enable this mask automatically for all new windows.

The places sidebar emits this signal when it starts a new operation because the user for example ejected some drive or unmounted a mount. In this way the application using the GtkPlacesSidebar can track the progress of the operation and, for example, show a notification.

The unrealize signal is emitted when the GdkWindow associated with widget is destroyed, which means that gtk_widget_unrealize() has been called or the widget has been unmapped (that is, it is going to be hidden).

The visibility-notify-event will be emitted when the widget‘s window is obscured or unobscured.

To receive this signal the GdkWindow associated to the widget needs to enable the GDK_VISIBILITY_NOTIFY_MASK mask.

visibility-notify-event is deprecated: Modern composited windowing systems with pervasive transparency make it impossible to track the visibility of a window reliably, so this signal can not be guaranteed to provide useful information.

The window-state-event will be emitted when the state of the toplevel window associated to the widget changes.

To receive this signal the GdkWindow associated to the widget needs to enable the GDK_STRUCTURE_MASK mask. GDK will enable this mask automatically for all new windows.

Undocumented

Undocumented

Undocumented

Undocumented

Undocumented

Undocumented

Whether the widget is double buffered.

double-buffered is deprecated: Widgets should not use this property.

Undocumented

Whether to expand in both directions. Setting this sets both GtkWidget:hexpand and GtkWidget:vexpand

Whether the widget should grab focus when it is clicked with the mouse.

This property is only relevant for widgets that can take focus.

Before 3.20, several widgets (GtkButton, GtkFileChooserButton, GtkComboBox) implemented this property individually.

Undocumented

How to distribute horizontal space if widget gets extra space, see GtkAlign

Undocumented

Undocumented

Enables or disables the emission of GtkWidget::query-tooltip on widget. A value of true indicates that widget can have a tooltip, in this case the widget will be queried using GtkWidget::query-tooltip to determine whether it will provide a tooltip or not.

Note that setting this property to true for the first time will change the event masks of the GdkWindows of this widget to include leave-notify and motion-notify events. This cannot and will not be undone when the property is set to false again.

Undocumented

Whether to expand horizontally. See gtk_widget_set_hexpand().

Whether to use the GtkWidget:hexpand property. See gtk_widget_get_hexpand_set().

Undocumented

Undocumented

Whether kinetic scrolling is enabled or not. Kinetic scrolling only applies to devices with source GDK_SOURCE_TOUCHSCREEN.

Undocumented

Undocumented

Sets all four sides’ margin at once. If read, returns max margin on any side.

Margin on bottom side of widget.

This property adds margin outside of the widget’s normal size request, the margin will be added in addition to the size from gtk_widget_set_size_request() for example.

Margin on end of widget, horizontally. This property supports left-to-right and right-to-left text directions.

This property adds margin outside of the widget’s normal size request, the margin will be added in addition to the size from gtk_widget_set_size_request() for example.

Margin on left side of widget.

This property adds margin outside of the widget’s normal size request, the margin will be added in addition to the size from gtk_widget_set_size_request() for example.

margin-left is deprecated: Use #GtkWidget:margin-start instead.

Margin on right side of widget.

This property adds margin outside of the widget’s normal size request, the margin will be added in addition to the size from gtk_widget_set_size_request() for example.

margin-right is deprecated: Use #GtkWidget:margin-end instead.

Margin on start of widget, horizontally. This property supports left-to-right and right-to-left text directions.

This property adds margin outside of the widget’s normal size request, the margin will be added in addition to the size from gtk_widget_set_size_request() for example.

Margin on top side of widget.

This property adds margin outside of the widget’s normal size request, the margin will be added in addition to the size from gtk_widget_set_size_request() for example.

The maximum content height of scrolled_window, or -1 if not set.

The maximum content width of scrolled_window, or -1 if not set.

The minimum content height of scrolled_window, or -1 if not set.

The minimum content width of scrolled_window, or -1 if not set.

Undocumented

Undocumented

The requested opacity of the widget. See gtk_widget_set_opacity() for more details about window opacity.

Before 3.8 this was only available in GtkWindow

Undocumented

Whether overlay scrolling is enabled or not. If it is, the scrollbars are only added as traditional widgets when a mouse is present. Otherwise, they are overlayed on top of the content, as narrow indicators.

Note that overlay scrolling can also be globally disabled, with the GtkSettings::gtk-overlay-scrolling setting.

Undocumented

If :populate-all is true, the GtkPlacesSidebar::populate-popup signal is also emitted for popovers.

Whether the natural height of the child should be calculated and propagated through the scrolled window’s requested natural height.

This is useful in cases where an attempt should be made to allocate exactly enough space for the natural size of the child.

Whether the natural width of the child should be calculated and propagated through the scrolled window’s requested natural width.

This is useful in cases where an attempt should be made to allocate exactly enough space for the natural size of the child.

Undocumented

Undocumented

The scale factor of the widget. See gtk_widget_get_scale_factor() for more details about widget scaling.

Undocumented

Undocumented

Undocumented

Undocumented

Undocumented

Undocumented

Undocumented

Undocumented

Undocumented

The style of the widget, which contains information about how it will look (colors, etc).

style is deprecated: Use #GtkStyleContext instead

Sets the text of tooltip to be the given string, which is marked up with the Pango text markup language. Also see gtk_tooltip_set_markup().

This is a convenience property which will take care of getting the tooltip shown if the given string is not nil: GtkWidget:has-tooltip will automatically be set to true and there will be taken care of GtkWidget::query-tooltip in the default signal handler.

Note that if both GtkWidget:tooltip-text and GtkWidget:tooltip-markup are set, the last one wins.

Sets the text of tooltip to be the given string.

Also see gtk_tooltip_set_text().

This is a convenience property which will take care of getting the tooltip shown if the given string is not nil: GtkWidget:has-tooltip will automatically be set to true and there will be taken care of GtkWidget::query-tooltip in the default signal handler.

Note that if both GtkWidget:tooltip-text and GtkWidget:tooltip-markup are set, the last one wins.

Undocumented

How to distribute vertical space if widget gets extra space, see GtkAlign

Whether to expand vertically. See gtk_widget_set_vexpand().

Whether to use the GtkWidget:vexpand property. See gtk_widget_get_vexpand_set().

Undocumented

Undocumented

Undocumented

The widget’s window if it is realized, nil otherwise.

Undocumented

Whether “window-placement” should be used to determine the location of the contents with respect to the scrollbars.

window-placement-set is deprecated: This value is ignored and

GtkScrolledWindow:window-placement value is always honored.