1. 20 Dec, 2015 1 commit
  2. 16 Dec, 2015 2 commits
  3. 14 Dec, 2015 1 commit
  4. 12 Dec, 2015 1 commit
    • Benjamin Otte's avatar
      cssnode: Change style-changed signal · 971a2774
      Benjamin Otte authored
      Instead of having old and new style, now have a GtkCssStyleChange opaque
      object that will compute the changes you are interested in for you.
      
      This simplifies change signal handlers quite a bit and avoids lots of
      repeated computation in every signal handler.
      971a2774
  5. 22 Nov, 2015 1 commit
  6. 03 Nov, 2015 4 commits
  7. 14 Sep, 2015 1 commit
    • Alexander Larsson's avatar
      gtk: Stop setting GDK_EXPOSURE_MASK on random widgets · d5f17549
      Alexander Larsson authored
      These days exposure happens only on the native windows (generally the
      toplevel window) and is propagated down recursively. The expose event
      is only useful for backwards compat, and in fact, for double buffered
      widgets we totally ignore the event (and non-double buffering breaks
      on wayland).
      
      So, by not setting the mask we avoid emitting these events and then
      later ignoring them.
      
      We still keep it on eventbox, fixed and layout as these are used
      in weird ways that want backwards compat.
      d5f17549
  8. 26 Jul, 2015 1 commit
  9. 01 Jul, 2015 1 commit
  10. 15 Jun, 2015 1 commit
    • Matthias Clasen's avatar
      Deal with events from wrong display · e367c4ba
      Matthias Clasen authored
      GtkInspector is opening a separate display connection, which makes
      it more likely that gtk_get_current_event() returns an event from
      the "wrong" display.
      e367c4ba
  11. 02 Jun, 2015 1 commit
  12. 03 Nov, 2014 1 commit
  13. 11 Oct, 2014 1 commit
  14. 10 Oct, 2014 1 commit
  15. 02 Oct, 2014 1 commit
  16. 25 Sep, 2014 1 commit
  17. 17 Jul, 2014 1 commit
  18. 12 Jun, 2014 1 commit
  19. 09 Jun, 2014 4 commits
  20. 17 May, 2014 1 commit
  21. 15 May, 2014 1 commit
    • Jasper St. Pierre's avatar
      wayland: Fix GtkMenuButton popups in a terrible, hacky way · 75ecdf50
      Jasper St. Pierre authored
      Since you can't take grabs on unmapped windows, GtkMenu takes a grab on
      the menu in a convoluted way: it first grabs another window, shows the
      menu window, and then transfers the grab over to the GtkMenu widget.
      
      For normal menubars, this is perfectly fine, as the first window it grabs
      is our toplevel, and that gets picked up in our transient path.  For
      GtkMenuButton or other spurious uses of gtk_menu_popup, it creates a new
      temporary input-only window which it takes the grab on, known as the "grab
      transfer window". Since this window isn't a transient-for of our new menu
      widget window, the grab isn't noticed when we go to show it, and thus the
      menu ends up as a new toplevel.
      
      Add a special hack to GtkMenu and the Wayland backend which lets us notice
      this "grab transfer window", and include it in our grab finding path.
      
      It's sort of terrible to have to hack up the widgets instead of just the
      backend, but the alternative would be an entirely new window type which is
      managed correctly by GDK. I don't want to write that.
      75ecdf50
  22. 01 May, 2014 2 commits
  23. 29 Mar, 2014 1 commit
  24. 06 Mar, 2014 1 commit
  25. 19 Feb, 2014 1 commit
  26. 09 Feb, 2014 1 commit
  27. 07 Feb, 2014 3 commits
  28. 05 Feb, 2014 1 commit
  29. 04 Feb, 2014 2 commits