1. 08 Jul, 2014 3 commits
  2. 07 Jul, 2014 2 commits
  3. 18 May, 2014 1 commit
  4. 17 May, 2014 1 commit
  5. 05 May, 2014 1 commit
  6. 04 May, 2014 1 commit
  7. 02 May, 2014 1 commit
  8. 09 Apr, 2014 1 commit
  9. 07 Apr, 2014 3 commits
  10. 06 Apr, 2014 1 commit
  11. 31 Mar, 2014 1 commit
    • Jasper St. Pierre's avatar
      Kill meta_ui_add_event_func / remove_event_func · afce4482
      Jasper St. Pierre authored
      The reason we don't simply use gdk_window_add_filter directly is
      because of some twisted idea that any GDK symbol being used from
      core/ is a layer violation. While we certainly want to keep any
      serious GDK code out of ui/, event handling is quite important
      to have in core/, so simply use a GDK event filter directly.
      afce4482
  12. 13 Mar, 2014 1 commit
    • Carlos Garnacho's avatar
      core: Add minimal handling of touch events · 991c85f6
      Carlos Garnacho authored
      Currently touch events are ignored in the core event handler,
      and hence dealt with within GDK. If those touch events were
      emulating pointer events, GDK would attempt to convert back
      those events to pointer events as the frame GdkWindow doesn't
      have the GDK_TOUCH_MASK set.
      
      This results in XI_TouchBegin events being initially processed
      by GDK, converted to button events, and triggering a grab op
      that subverts touch events into pointer events, so the touch
      is never ever seen again by GDK. This leaves GDK in an
      inconsistent internal state wrt pointer grabs, so future
      pointer-emulating touches will refer to the same window forever.
      
      Fix this by handling touch events minimally, just enough to
      convert XI_TouchBegin to GDK_BUTTON_PRESS within mutter, so GDK
      is bypassed for every touch event just like it is for pointer
      events. This, and the XIGrabDevice() that keeps coercing pointer
      events when the grab operation starts, are enough to fix window
      drag and drop on touch devices.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=723552
      991c85f6
  13. 05 Mar, 2014 2 commits
    • Owen W. Taylor's avatar
      Fix handling of dynamic updates to colors/font/etc. · 365af537
      Owen W. Taylor authored
      Since the introduction of frame sync in GTK+, updates to titlebar font and
      colors haven't been working because GTK+ counts on the frame clock to
      do style updates, and the frame clock doesn't run for an unmapped
      GdkWindow. (It's possible that GtkStyleContext changes subsequent to
      the introduction of the frame clock were also needed to fully break
      things.)
      
      We actually need to map the MetaFrames GdkWindow and let the
      compositor code send out the frame sync messages in order to pick up
      style changes.
      
      Hopefully no bad side effects will occur from this - we make the window
      override-redirect, 1x1, and outside the bounds of the screen.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=725751
      365af537
    • Owen W. Taylor's avatar
      Fix handling of dynamic updates to colors/font/etc. · 4a8f7aa8
      Owen W. Taylor authored
      Since the introduction of frame sync in GTK+, updates to titlebar font and
      colors haven't been working because GTK+ counts on the frame clock to
      do style updates, and the frame clock doesn't run for an unmapped
      GdkWindow. (It's possible that GtkStyleContext changes subsequent to
      the introduction of the frame clock were also needed to fully break
      things.)
      
      We actually need to map the MetaFrames GdkWindow and let the
      compositor code send out the frame sync messages in order to pick up
      style changes.
      
      Hopefully no bad side effects will occur from this - we make the window
      override-redirect, 1x1, and outside the bounds of the screen.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=725751
      4a8f7aa8
  14. 13 Jan, 2014 1 commit
  15. 12 Jan, 2014 1 commit
  16. 20 Aug, 2013 1 commit
  17. 19 Aug, 2013 1 commit
  18. 13 Aug, 2013 2 commits
  19. 17 Apr, 2013 1 commit
    • Simon McVittie's avatar
      Let the UI layer (via the core) construct the frame mask · c2a9ccb7
      Simon McVittie authored
      This essentially just moves install_corners() from the compositor, through
      the core, into the UI layer where it arguably should have been anyway,
      leaving behind stub functions which call through the various layers. This
      removes the compositor's special knowledge of how rounded corners work,
      replacing it with "ask the UI for an alpha mask".
      
      The computation of border widths and heights changes a bit, because the
      width and height used in install_corners() are the
      meta_window_get_outer_rect() (which includes the visible borders but not
      the invisible ones), whereas the more readily-available rectangle is the
      MetaFrame.rect (which includes both). Computing the same width and height
      as meta_window_get_outer_rect() involves compensating for the invisible
      borders, but the UI layer is the authority on those anyway, so it seems
      clearer to have it do the calculations from scratch.
      
      Bug: https://bugzilla.gnome.org/show_bug.cgi?id=697758
      
      Signed-off-by: Simon McVittie's avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: Jasper St. Pierre's avatarJasper St. Pierre <jstpierre@mecheye.net>
      c2a9ccb7
  20. 29 Mar, 2013 1 commit
  21. 07 Feb, 2013 1 commit
  22. 03 Jan, 2013 1 commit
  23. 23 Dec, 2012 1 commit
  24. 17 Dec, 2012 1 commit
  25. 13 Dec, 2012 2 commits
  26. 12 Nov, 2012 1 commit
  27. 15 Oct, 2012 1 commit
  28. 14 May, 2012 1 commit
  29. 28 Oct, 2011 1 commit
  30. 24 Aug, 2011 1 commit
  31. 09 Aug, 2011 2 commits