1. 24 Mar, 2015 1 commit
    • Benjamin Otte's avatar
      cssnode: Clear widget path more aggressively · fdc620cd
      Benjamin Otte authored
      When recomputing CSS, we need a correct widget path in the fallback mode
      where we're still using widget paths.
      So we need to invalidate it everytime it actually changes, and not just
      when emitting the style-updated signal.
      
      Fixes css-match-regions reftest.
      fdc620cd
  2. 18 Mar, 2015 2 commits
  3. 05 Mar, 2015 1 commit
  4. 02 Mar, 2015 1 commit
    • Carlos Garnacho's avatar
      gtkwindow: Move window dragging to a standalone drag gesture · 13e22e20
      Carlos Garnacho authored
      The gesture is hooked to the capture phase, so it works for buttons in
      header bars and whatnot. In order to be friendly to the widget it is
      capturing events from, an ugly hack is in place to avoid capturing
      events when the target widget has a gesture that would consume motion
      events.
      13e22e20
  5. 11 Dec, 2014 1 commit
  6. 09 Dec, 2014 1 commit
    • Carlos Soriano's avatar
      gtkwindow: Use actions from focused widget to activate accel · 235837ad
      Carlos Soriano authored
      Currently we only take into account the window GActionGroup for
      activating the accels.
      
      However, the application could have some custom GActionGroup in the
      chain of focused widgets that could want to activate some action if
      some accel is activated while that widget is focused.
      
      To allow applications to set accels on widgets that use custom
      GActionGroups, simply use the muxer of the focused widget, which
      already contains the actions of the parents.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=740682
      235837ad
  7. 29 Oct, 2014 1 commit
  8. 24 Oct, 2014 1 commit
  9. 20 Aug, 2014 1 commit
  10. 27 May, 2014 1 commit
  11. 24 May, 2014 3 commits
  12. 23 May, 2014 2 commits
  13. 15 May, 2014 1 commit
  14. 03 Jul, 2013 1 commit
  15. 13 May, 2013 1 commit
    • Allison Karlitskaya's avatar
      action stuff: stop abusing GLib's namespace · 6c49cd0e
      Allison Karlitskaya authored
      Rename our internal GActionMuxer, GActionObserver and GActionObservable
      classes and interfaces to have names in our own namespace.
      
      These classes were originally intended for GIO but turned out to be too
      special-purpose to be useful there, so we never made them public API but
      have just been copying them around (without bothering to properly rename
      them).  Now that other people will be copying them out of Gtk, it's even
      more important to prevent this namespace abuse from spreading further.
      6c49cd0e
  16. 11 May, 2013 2 commits
  17. 07 May, 2013 1 commit
    • Alexander Larsson's avatar
      Only handle exposes on native window, propagate to children via draw() · d22fd722
      Alexander Larsson authored
      We now consider non-native windows non-opaque, which means any invalid
      area in a subwindow will also be invalid all the way up to the nearest
      native windows. We take advantage of this by ignoring all expose events
      on non-native windows (which typically means just the toplevel) and instead
      propagating down the draw() calls to children directly via
      gtk_container_propagate_draw.
      
      This is nice as it means we always draw widgets the same way, and it
      will let us do some interesting ways in the future.
      
      We also clean up the GtkWidget opacity handling as we can now always
      rely on the draing happening via cairo.
      
      We can't really just draw by walking down the widget hierarchy, as
      this doesn't get the clipping right (so e.g. widgets doing cairo_paint
      may draw outside the expected gdkwindow subarea) nor does it let
      us paint window backgrounds.
      
      So, we now do multiple draws for each widget, once for each GdkWindow,
      although we still do it on the same base cairo_t that we get for the
      toplevel native window. The difference is only the clipping, the rendering
      order, and which other widgets we propagate into.
      
      We also collect all the windows of a widget so we can expose them inside
      the same opacity group if needed.
      
      NOTE: This change neuters gtk_widget_set_double_buffered for
      widgets without native windows. Its impossible to disable
      the double buffering in this model.
      d22fd722
  18. 01 May, 2013 1 commit
  19. 23 Apr, 2013 2 commits
    • Alexander Larsson's avatar
      Handle non-baseline supporting subclasses overriding baseline supporting classes · 316d4504
      Alexander Larsson authored
      If a subclass (say a child of GtkButton) overrides the non-baseline
      size request methods we need to call these, rather than the new
      get_height_and_baseline_for_width method.
      
      In order to handle this we make the default for this method to be
      NULL, and instead check at runtime which method to call. If any
      non-baseline vfunc has changed in a class but the baseline one
      hasn't, then we can't use the baseline one.
      316d4504
    • Alexander Larsson's avatar
      Initial support for baselines · 852cbb62
      Alexander Larsson authored
      This modifies the size machinery in order to allow baseline support.
      
      We add a new widget vfunc get_preferred_height_and_baseline_for_width
      which queries the normal height_for_width (or non-for-width if width
      is -1) and additionally returns optional (-1 means "no baseline")
      baselines for the minimal and natural heights.
      
      We also add a new gtk_widget_size_allocate_with_baseline() which
      baseline-aware containers can use to allocate children with a specific
      baseline, either one inherited from the parent, or one introduced due
      to requested baseline alignment in the container
      itself. size_allocate_with_baseline() works just like a normal size
      allocation, except the baseline gets recorded so that the child can
      access it via gtk_widget_get_allocated_baseline() when it aligns
      itself.
      
      There are also adjust_baseline_request/allocation similar to the
      allocation adjustment, and we extend the size request cache to also
      store the baselines.
      852cbb62
  20. 22 Apr, 2013 1 commit
  21. 14 Nov, 2012 4 commits
  22. 04 Nov, 2012 4 commits
  23. 20 Aug, 2012 1 commit
    • Lars Uebernickel's avatar
      GtkWidget: Add gtk_widget_insert_action_group() · d30d5645
      Lars Uebernickel authored
      This allows adding a GActionGroup with a given name at an arbitrary
      point in the widget tree.
      
      This patch also adds an internal _get_action_muxer() API.  Calling this
      will create a GActionMuxer associated with the widget.  The parent of
      the muxer will be the muxer of the widget's conceptual parent.  For
      non-menus, that is the normal parent.  For menus, it is the attach
      widget.
      
      In this way, we end up with a hierarchy of GActionMuxer that largely
      reflects the hierarchy of GtkWidget, but only in places that the action
      context has been requested.  These muxers are the ones on which the
      inserted actions groups are installed.
      
      A following patch will add a user of this API.
      d30d5645
  24. 17 Apr, 2012 4 commits
  25. 01 Mar, 2012 1 commit
    • Carlos Garcia Campos's avatar
      gtk: Add a way to do event capture · 9f4bfff1
      Carlos Garcia Campos authored
      This patch adds a capture phase to GTK+'s event propagation
      model. Events are first propagated from the toplevel (or the
      grab widget, if a grab is in place) down to the target widget
       and then back up. The second phase is using the existing
      ::event signal, the new capture phase is using a private
      API instead of a public signal for now.
      
      This mechanism can be used in many places where we currently
      have to prevent child widgets from getting events by putting
      an input-only window over them. It will also be used to implement
      kinetic scrolling in subsequent patches.
      
      http://bugzilla.gnome.org/show_bug.cgi?id=641836
      
      We automatically request more motion events in behalf of
      the original widget if it listens to motion hints. So
      the capturing widget doesn't need to handle such
      implementation details.
      
      We are not making event capture part of the public API for 3.4,
      which is why there is no ::captured-event signal.
      9f4bfff1