Trait gtk::prelude::WidgetExtManual[−][src]

pub trait WidgetExtManual: 'static {
    fn drag_dest_set(
        &self, 
        flags: DestDefaults, 
        targets: &[TargetEntry], 
        actions: DragAction
    );

    fn drag_source_set(
        &self, 
        start_button_mask: ModifierType, 
        targets: &[TargetEntry], 
        actions: DragAction
    );

    fn intersect(
        &self, 
        area: &Rectangle, 
        intersection: Option<&mut Rectangle>
    ) -> bool;

    fn connect_map_event<F: Fn(&Self, &Event) -> Inhibit + 'static>(
        &self, 
        f: F
    ) -> SignalHandlerId;

    fn connect_unmap_event<F: Fn(&Self, &Event) -> Inhibit + 'static>(
        &self, 
        f: F
    ) -> SignalHandlerId;

    fn add_tick_callback<P: Fn(&Self, &FrameClock) -> Continue + 'static>(
        &self, 
        callback: P
    ) -> TickCallbackId;

    fn add_events(&self, events: EventMask);

    fn events(&self) -> EventMask;

    fn set_events(&self, events: EventMask);

    unsafe fn destroy(&self);

    fn hide_on_delete(&self) -> Inhibit;
}

Required methods

Sets a widget as a potential drop destination, and adds default behaviors.

The default behaviors listed in flags have an effect similar to installing default handlers for the widget’s drag-and-drop signals (signal::Widget::drag-motion, signal::Widget::drag-drop, …). They all exist for convenience. When passing DestDefaults::ALL for instance it is sufficient to connect to the widget’s signal::Widget::drag-data-received signal to get primitive, but consistent drag-and-drop support.

Things become more complicated when you try to preview the dragged data, as described in the documentation for signal::Widget::drag-motion. The default behaviors described by flags make some assumptions, that can conflict with your own signal handlers. For instance DestDefaults::DROP causes invokations of gdk_drag_status() in the context of signal::Widget::drag-motion, and invokations of gtk_drag_finish() in signal::Widget::drag-data-received. Especially the later is dramatic, when your own signal::Widget::drag-motion handler calls WidgetExt::drag_get_data() to inspect the dragged data.

There’s no way to set a default action here, you can use the signal::Widget::drag-motion callback for that. Here’s an example which selects the action to use depending on whether the control key is pressed or not:

⚠️ The following code is in C ⚠️

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

  gdk_window_get_pointer (gtk_widget_get_window (widget),
                          NULL, NULL, &mask);
  if (mask & GDK_CONTROL_MASK)
    gdk_drag_status (context, GDK_ACTION_COPY, time);
  else
    gdk_drag_status (context, GDK_ACTION_MOVE, time);
}

flags

which types of default drag behavior to use

targets

a pointer to an array of GtkTargetEntrys indicating the drop types that this self will accept, or None. Later you can access the list with WidgetExt::drag_dest_get_target_list() and WidgetExt::drag_dest_find_target().

actions

a bitmask of possible actions for a drop onto this self.

Sets up a widget so that GTK+ will start a drag operation when the user clicks and drags on the widget. The widget must have a window.

start_button_mask

the bitmask of buttons that can start the drag

targets

the table of targets that the drag will support, may be None

actions

the bitmask of possible actions for a drag from this widget

Computes the intersection of a self’s area and area, storing the intersection in intersection, and returns true if there was an intersection. intersection may be None if you’re only interested in whether there was an intersection.

area

a rectangle

Returns

true if there was an intersection

intersection

rectangle to store intersection of self and area

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 gdk::Window associated to the widget needs to enable the gdk::EventMask::STRUCTURE_MASK mask. GDK will enable this mask automatically for all new windows.

event

the GdkEventAny which triggered this signal.

Returns

true to stop other handlers from being invoked for the event. false to propagate the event further.

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 gdk::Window associated to the widget needs to enable the gdk::EventMask::STRUCTURE_MASK mask. GDK will enable this mask automatically for all new windows.

event

the GdkEventAny which triggered this signal

Returns

true to stop other handlers from being invoked for the event. false to propagate the event further.

Queues an animation frame update and adds a callback to be called before each frame. Until the tick callback is removed, it will be called frequently (usually at the frame rate of the output device or as quickly as the application can be repainted, whichever is slower). For this reason, is most suitable for handling graphics that change every frame or every few frames. The tick callback does not automatically imply a relayout or repaint. If you want a repaint or relayout, and aren’t changing widget properties that would trigger that (for example, changing the text of a Label), then you will have to call WidgetExt::queue_resize() or WidgetExt::queue_draw_area() yourself.

FrameClock::frame_time() should generally be used for timing continuous animations and gdk_frame_timings_get_predicted_presentation_time() if you are trying to display isolated frames at particular times.

This is a more convenient alternative to connecting directly to the signal::gdk::FrameClock::update signal of gdk::FrameClock, since you don’t have to worry about when a gdk::FrameClock is assigned to a widget.

callback

function to call for updating animations

notify

function to call to free user_data when the callback is removed.

Returns

an id for the connection of this callback. Remove the callback by passing it to gtk_widget_remove_tick_callback()

Adds the events in the bitfield events to the event mask for self. See WidgetExtManual::set_events() and the [input handling overview][event-masks] for details.

events

an event mask, see gdk::EventMask

Returns the event mask (see gdk::EventMask) for the widget. These are the events that the widget will receive.

Note: Internally, the widget event mask will be the logical OR of the event mask set through WidgetExtManual::set_events() or WidgetExtManual::add_events(), and the event mask necessary to cater for every EventController created for the widget.

Returns

event mask for self

Sets the event mask (see gdk::EventMask) for a widget. The event mask determines which events a widget will receive. Keep in mind that different widgets have different default event masks, and by changing the event mask you may disrupt a widget’s functionality, so be careful. This function must be called while a widget is unrealized. Consider WidgetExtManual::add_events() for widgets that are already realized, or if you want to preserve the existing event mask. This function can’t be used with widgets that have no window. (See WidgetExt::has_window()). To get events on those widgets, place them inside a EventBox and receive events on the event box.

events

event mask

Calls gtk_widget_destroy() on this widget.

Safety

This will not necessarily entirely remove the widget from existence but you must NOT query the widget’s state subsequently. Do not call this yourself unless you really mean to. Destroys a widget.

When a widget is destroyed all references it holds on other objects will be released:

  • if the widget is inside a container, it will be removed from its parent
  • if the widget is a container, all its children will be destroyed, recursively
  • if the widget is a top level, it will be removed from the list of top level widgets that GTK+ maintains internally

It’s expected that all references held on the widget will also be released; you should connect to the signal::Widget::destroy signal if you hold a reference to self and you wish to remove it when this function is called. It is not necessary to do so if you are implementing a Container, as you’ll be able to use the GtkContainerClass.remove() virtual function for that.

It’s important to notice that gtk_widget_destroy() will only cause the self to be finalized if no additional references, acquired using g_object_ref(), are held on it. In case additional references are in place, the self will be in an “inert” state after calling this function; self will still point to valid memory, allowing you to release the references you hold, but you may not query the widget’s own state.

You should typically call this function on top level widgets, and rarely on child widgets.

See also: ContainerExt::remove()

Utility function; intended to be connected to the signal::Widget::delete-event signal on a Window. The function calls WidgetExt::hide() on its argument, then returns true. If connected to ::delete-event, the result is that clicking the close button for a window (on the window frame, top right corner usually) will hide but not destroy the window. By default, GTK+ destroys windows when ::delete-event is received.

Returns

true

Implementors