1. 08 Feb, 2019 1 commit
  2. 05 Feb, 2019 1 commit
  3. 03 Feb, 2019 1 commit
  4. 31 Jan, 2019 1 commit
  5. 30 Jan, 2019 2 commits
  6. 28 Jan, 2019 1 commit
  7. 26 Jan, 2019 1 commit
  8. 25 Jan, 2019 1 commit
  9. 22 Jan, 2019 1 commit
  10. 21 Jan, 2019 2 commits
  11. 20 Jan, 2019 2 commits
  12. 17 Jan, 2019 2 commits
  13. 16 Jan, 2019 1 commit
    • Jakub Steiner's avatar
      icon: make app icon more legible · e99ed854
      Jakub Steiner authored
      - the app icon relies on a dark background
        or having the icon-drophadow class for light backgrounds.
        Slight shading has been added to make it less invisible on light
        backgrounds. It's still reliant on bg help, but at least it's
        not completely invisible.
      e99ed854
  14. 15 Jan, 2019 1 commit
  15. 14 Jan, 2019 3 commits
  16. 11 Jan, 2019 1 commit
  17. 08 Jan, 2019 3 commits
  18. 29 Dec, 2018 1 commit
  19. 28 Dec, 2018 1 commit
  20. 26 Dec, 2018 1 commit
  21. 25 Dec, 2018 1 commit
  22. 23 Dec, 2018 1 commit
  23. 19 Dec, 2018 3 commits
  24. 18 Dec, 2018 2 commits
  25. 17 Dec, 2018 1 commit
    • Felipe Borges's avatar
      app-window: Don't quit on Ctrl+Q while on Display page · 533d2398
      Felipe Borges authored
      In Gtk the key event handling is top-down in the widget hierarchy.
      Therefore the AppWindow object would handle Ctrl+Q before any
      widget under it. This is unwanted because most of the time while
      on Display mode, users are actually intenting to use the Ctrl+Q
      shortcut against the guest, not the host. This would close the
      Boxes window and suspend the currently running VMs (very
      annoying).
      
      Since we can't guarantee whether the guest properly handled the
      key press event as desired, lets just not handle it all in Display
      mode/view.
      
      Related #244
      533d2398
  26. 14 Dec, 2018 3 commits
  27. 13 Dec, 2018 1 commit
    • Felipe Borges's avatar
      list-view: Allow ListView to shrink · e04c71a6
      Felipe Borges authored
      We were forcing a constant width for ListView rows in order to limit
      the maximium width of the content. This prevented the main Boxes
      window from being resized to values smaller than that.
      
      Now we store a max-content-width value in the ListView and whenever
      the allocated width for the main window is smaller than that, we
      just let the listbox fill the available space.
      
      This is somewhat a responsive behavior for width allocation that
      should cover small screen devices or tiling displays.
      
      Hopefully Gtk4 will introduce a max-width CSS property that would
      ease the implementation of these use cases. Alternatively, Gtk4
      might have a constraint layout machinery that would obsolete this
      issue.
      
      Fixes #76
      e04c71a6