1. 19 Jan, 2016 13 commits
    • Carlos Garnacho's avatar
      gtkdnd: Optionally use gdk_drag_context_manage_dnd() · e4f5e31b
      Carlos Garnacho authored
      When this is in use, there's essentially a bunch of dead code here.
      When all backends are ported, we'll be able to remove grab/cursor
      management plus a bunch of source-side event handlers.
      e4f5e31b
    • Carlos Garnacho's avatar
      x11: Implement gdk_drag_context_manage_dnd() · bfee45e6
      Carlos Garnacho authored
      This includes managing input events and source-side DND events,
      as well as setting the appropriate cursor and emitting the signals
      that are expected in this mode of operation.
      bfee45e6
    • Carlos Garnacho's avatar
      gdk: Add gdk_drag_get_cursor() · ed5da43a
      Carlos Garnacho authored
      This function (most similar to gtk_drag_get_cursor() helps figure out
      the right cursor that applies to a given action. To be used by the
      various backends.
      ed5da43a
    • Carlos Garnacho's avatar
      gdk: Run DnD internal handlers before the main event handler · f6b8fb5a
      Carlos Garnacho authored
      We'll be stealing those to GTK+, if the GdkDragContext manages
      the DnD operation.
      f6b8fb5a
    • Carlos Garnacho's avatar
      gdk: Allow internal management of source-side DnD · edc4374a
      Carlos Garnacho authored
      We've traditionally left GTK+ to handle the input side of things,
      letting GDK only manage the windowing-specific messaging. This
      way of splitting responsibilities is not compatible however with
      some backends, we must fold then input management at the DnD stage
      into GDK (and backends) domain.
      
      The gdk_drag_context_manage_dnd() call is meant to be the entry
      point for this mode of operation, if the drag and drop operation
      becomes managed, the caller (i.e. gtkdnd.c) doesn't need to perform
      grabs, nor manage input events itself.
      
      As a consequence of this, different aspects now belong to the
      backend GdkDragContext implementation:
      - Because the caller doesn't see keyboard events anymore,
        keyboard navigation must be managed in GDK, so is the decision
        of the current action based on modifiers/button pressed.
      - Because the caller won't see input events in general, the lifetime
        of the drag and drop operation is now communicated through the
        ::drop-performed, ::dnd-finished and ::cancel events
      - Because the caller doesn't participate anymore on the action
        being chosen, the pointer cursor must be set by the backend.
        The caller is rather notified of the final action through the
        ::action signal.
      
      The caller is still responsible of dealing with the corresponding
      GdkSelection, ensuring its ownership and communicating the supported
      mimetypes.
      edc4374a
    • Benjamin Otte's avatar
      widget: Call gdk_window_mark_paint_from_clip() again · a50baba1
      Benjamin Otte authored
      The proper window to call it is the event window, as the call itself
      ignores non-native windows anyway.
      a50baba1
    • Marek Černocký's avatar
      Fixed typo childen->children · f64bb38a
      Marek Černocký authored
      f64bb38a
    • Matthias Clasen's avatar
      gtk-demo: Add a progress bar to foreigndrawing · 3fea7f29
      Matthias Clasen authored
      This is another commonly requested widget.
      3fea7f29
    • Benjamin Otte's avatar
      container: Properly reorder no-window children · 409760ba
      Benjamin Otte authored
      ... that are setup with gtk_widget_set_parent_window().
      
      Fixes scrollbars not being drawn in GtkScrolledWindow.
      409760ba
    • Benjamin Otte's avatar
      widget: Add forgotten push_group code · ab5dbfd1
      Benjamin Otte authored
      ... and remove the also forgotten void function that lingered around
      with it.
      
      Fixes opacity=0 parts like inactive spinners or sort indicators in
      treeview headers being drawn since last commit.
      
      Oops.
      ab5dbfd1
    • Benjamin Otte's avatar
      widget: Redo drawing code · 580ea227
      Benjamin Otte authored
      Previously, we had a special cae to draw subwindows of widgets.
      
      This is not necessary as conformant widgets should be able to properly
      render themselves when all windows need to be painted.
      From now on assume that is the case.
      
      We therefore paint nonnative GDK windows "inline" by just returning TRUE
      for gtk_cairo_should_draw_window() for those windows.
      
      This speeds up hilighting different rows in the listbox gtk-demo example
      tremendously (by a factor of 10 or more) as the previous code was
      O(<number of non-window subwidgets> *
      <number of subwindows>) which in the listbox example were ~15,000 and
      ~2,000 respectively.
      580ea227
    • Benjamin Otte's avatar
      actionbar: Don't forall() widgets twice · 402cecf9
      Benjamin Otte authored
      When using forall(), only list the revealer, which lists the box
      containing all the children. When using foreach(), bypass revealer and
      box and list all children added to the box.
      402cecf9
    • Matthias Clasen's avatar
      Updates · 575dfb40
      Matthias Clasen authored
      575dfb40
  2. 18 Jan, 2016 27 commits