1. 06 Jun, 2016 1 commit
  2. 25 Feb, 2016 1 commit
  3. 20 Jan, 2016 2 commits
  4. 29 Dec, 2015 4 commits
    • Cosimo Cecchi's avatar
      viewport: don't render a background over the bin window · 09835b4c
      Cosimo Cecchi authored
      GtkViewport currently tries to draw a background over the bin window.
      The feature is a bit broken at the moment, as it does not take into
      account padding that might have been set on the GtkViewport, but in
      general it does not seem very useful, and goes somewhat against the CSS
      box model where every widget/gadget is responsible to draw its own
      background. For a fix, we could either have the viewport gain a "bin"
      gadget, or we could stop drawing the background.
      
      As it isn't clear that there are any users of this feature, stop drawing
      the background; a client can achieve the same effect by drawing the
      background on the widget inside the viewport itself.
      09835b4c
    • Cosimo Cecchi's avatar
      viewport: port to use a gadget · 5daede51
      Cosimo Cecchi authored
      This will get us margin support, among other things, and simplifies the
      code.
      5daede51
    • Cosimo Cecchi's avatar
      viewport: trivial code cleanup · 71d7b10d
      Cosimo Cecchi authored
      71d7b10d
    • Cosimo Cecchi's avatar
      viewport: use gtk_container_class_handle_border_width() · a37129fd
      Cosimo Cecchi authored
      No need to do this manually.
      a37129fd
  5. 22 Nov, 2015 1 commit
  6. 14 Nov, 2015 1 commit
  7. 29 Oct, 2015 1 commit
  8. 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
  9. 13 Sep, 2015 1 commit
  10. 01 Jul, 2015 1 commit
  11. 13 Oct, 2014 1 commit
  12. 03 Oct, 2014 1 commit
  13. 27 Jun, 2014 1 commit
  14. 10 Jun, 2014 1 commit
  15. 09 Jun, 2014 2 commits
  16. 06 May, 2014 1 commit
  17. 01 May, 2014 4 commits
  18. 09 Apr, 2014 1 commit
  19. 19 Feb, 2014 1 commit
  20. 07 Feb, 2014 1 commit
  21. 09 Jul, 2013 1 commit
  22. 07 May, 2013 1 commit
    • Alexander Larsson's avatar
      Make GtkViewport use GtkPixelCache · 2df27ce7
      Alexander Larsson authored
      Since gdk_window_move() no longer uses XCopyArea all scrolling
      now re-renders everything in the window. To get performance
      back we use a GtkPixelCache to store already drawn children,
      and we when we expose the viewport we just blit the
      offscreen to the right place.
      2df27ce7
  23. 04 May, 2013 1 commit
  24. 19 Feb, 2013 1 commit
  25. 07 Feb, 2013 1 commit
    • Alexander Larsson's avatar
      Add gtk_widget_(un)register_window · 3d4cd4db
      Alexander Larsson authored
      This replaces the previously hardcoded calls to gdk_window_set_user_data,
      and also lets us track which windows are a part of a widget. Old code
      should continue working as is, but new features that require the
      windows may not work perfectly.
      
      We need this for the transparent widget support to work, as we need
      to specially mark the windows of child widgets.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=687842
      3d4cd4db
  26. 02 Feb, 2013 1 commit
  27. 12 Dec, 2012 1 commit
    • Alexander Larsson's avatar
      Use GTK_RESIZE_PARENT resize_mode for GtkViewport · 0cb714fe
      Alexander Larsson authored
      We used to use GTK_RESIZE_QUEUE, but that is problematic for e.g
      a GtkScrolledWindow with NEVER scroll policies, as size changes
      in ancestors will never get propagated to the scrolled window, causing
      it to not have the correct size.
      
      This is a slight performance hit, but in practice its not bound to be
      problematic. In typical UIs there is only a single "large" GtkScrolledWindow
      visible at a time, so a size requeust propagating out of such a window
      will only hit the smaller amount of widgetry outside the scrolled window,
      and additionally all such widgets will have their size request caches
      still valid.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=690099
      0cb714fe
  28. 02 Jul, 2012 1 commit
  29. 05 Apr, 2012 1 commit
  30. 03 Mar, 2012 1 commit
  31. 01 Mar, 2012 2 commits