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

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 get_events(&self) -> EventMask;
fn set_events(&self, events: EventMask);
unsafe fn destroy(&self);
fn hide_on_delete(&self) -> Inhibit; }

Required methods

fn drag_dest_set(
    &self,
    flags: DestDefaults,
    targets: &[TargetEntry],
    actions: DragAction
)

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 (Widget::drag-motion, Widget::drag-drop, ...). They all exist for convenience. When passing DestDefaults::All for instance it is sufficient to connect to the widget’s 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 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 Widget::drag-motion, and invokations of gtk_drag_finish in Widget::drag-data-received. Especially the later is dramatic, when your own 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 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:

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.

n_targets

the number of entries in targets

actions

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

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

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

n_targets

the number of items in targets

actions

the bitmask of possible actions for a drag from this widget

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

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

intersection

rectangle to store intersection of self and area

Returns

true if there was an intersection

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

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::StructureMask mask. GDK will enable this mask automatically for all new windows.

event

the gdk::EventAny which triggered this signal.

Returns

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

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

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::StructureMask mask. GDK will enable this mask automatically for all new windows.

event

the gdk::EventAny which triggered this signal

Returns

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

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

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.

gdk::FrameClock::get_frame_time should generally be used for timing continuous animations and gdk::FrameTimings::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 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

user_data

data to pass to callback

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 Widget::remove_tick_callback

fn add_events(&self, events: EventMask)

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

events

an event mask, see gdk::EventMask

fn get_events(&self) -> 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 Widget::set_events or Widget::add_events, and the event mask necessary to cater for every EventController created for the widget.

Returns

event mask for self

fn set_events(&self, events: EventMask)

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 Widget::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::get_has_window). To get events on those widgets, place them inside a EventBox and receive events on the event box.

events

event mask

unsafe fn destroy(&self)

Calls gtk_widget_destroy() on this widget.

Utility function; intended to be connected to the 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

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.

fn hide_on_delete(&self) -> Inhibit

Loading content...

Implementors

impl<O: IsA<Widget>> WidgetExtManual for O[src]

Loading content...