1. 02 Dec, 2018 1 commit
  2. 11 Sep, 2018 1 commit
  3. 14 Jul, 2018 1 commit
  4. 11 Jul, 2018 1 commit
  5. 24 Jun, 2018 1 commit
  6. 17 Jun, 2018 2 commits
  7. 15 Jun, 2018 2 commits
  8. 31 May, 2018 1 commit
  9. 30 May, 2018 2 commits
  10. 28 May, 2018 1 commit
  11. 20 May, 2018 7 commits
  12. 15 May, 2018 5 commits
    • Jehan's avatar
      plug-ins: properly free rectScreens after allocating it. · 9fb1c286
      Jehan authored
      Also avoid global variables when possible. We can just use the data
      variable of EnumDisplayMonitors() which will be passed on to the
      callback. This is not perfect yet since rectScreensCount is still
      global, but let's go for it for now.
    • Jehan's avatar
      plug-ins: fixing various compilation warnings. · e357e711
      Jehan authored
      Mostly warnings about wrong types for some function parameters.
      There is still a single warning remaining about ignoring the #pragma
      macro, but I am not sure what to do about this warning. Apparently it is
      something specifically for use with Visual Studio. We don't need this,
      but since the contributor uses it, let's keep it.
    • Jehan's avatar
      plug-ins: put the initial foreground window back after a screenshot. · 382d6c8a
      Jehan authored
      This was lost in commit 966843564d. It's not a big deal since this code
      path would only happen when the capture using magnification API fails,
      yet we may as well make it perfect.
      Also taking the opportunity to change the return type to gboolean for
      the various capture functions (though it is technically the same,
      semantically we were returning success boolean).
      And removing a comment which had been duplicated and left at a the wrong
    • Jehan's avatar
      plug-ins: properly load user32.dll for SetProcessDPIAware(). · a0b28589
      Jehan authored
      Using similar code as other parts of Win32 code.
      I hope I am not doing anything wrong. At least now it builds!
    • Gil Eliyahu's avatar
      Plug-ins: fix screenshot bugs in windows. · ae93b6db
      Gil Eliyahu authored
      This fixes bugs 793722 and 796121.
      In particular it fixes:
      - Single-window screenshot when partly off-screen or covered by another
      - Screenshots when display scaling is not 100%.
  13. 15 Apr, 2018 1 commit
  14. 03 Mar, 2018 1 commit
  15. 24 Feb, 2018 1 commit
    • Simon Mueller's avatar
      Bug 789728 - Screenshot whole screen (Windows 10) only grabs screen... · 65379814
      Simon Mueller authored
      ... from first monitor
      While researching the cause for the missing window contents (bug
      793722), I noticed that the full screen capture mode was also not
      working as expected. No matter how many monitors were connected, it only
      ever captured the contents of the main monitor. This patch adjusts the
      source rectangle for the BitBlt copy operation so that multiple monitors
      are captured correctly.
  16. 23 Feb, 2018 1 commit
    • Simon Mueller's avatar
      Bug 793722 - Capture screenshot of single window fails if... · 14236761
      Simon Mueller authored
      ... thewindow is IE 11.
      The screenshot plugin for windows had a problem when capturing
      applications that use hardware rendering acceleration (e.g.
      Chromium-based Apps, IE11). Those applications seem to render their
      content to a device context (DC) that is different from the one that can
      be retrieved via GetDCEx(hWnd). So a screenshot that simply copies the
      main window DC will be incomplete (see bug attachment) or just plain
      This patch removes the code that uses GetDCEx for single window
      screenshots and always uses the display device context instead. This
      makes sure that all window contents are actually visible in the
      screenshot. With this change, we now have to set the source coordinates
      in the call to BitBlt() to the window's coordinates to exclude
      everything that isn't the window from the screenshot when doing a single
      window screenshot.
      Review comment by Jehan: as Simon notes in bug 793722, there is a
      regression though, which is that this new code cannot capture any part
      of a window which is not in any screen. This is still an improvement
      because at least for what is on screen, we always get exactly the same
      as what is displayed. This is especially true since hardware-accelerated
      applications are more and more common. So let's push this first commit
      and hope for further improvements.
  17. 13 Jan, 2018 1 commit
  18. 16 Dec, 2017 2 commits
    • Jehan's avatar
      plug-ins: add a SCREENSHOT_CAN_SHOOT_WINDOW capability. · 80490a2c
      Jehan authored
      And add the relevant option for when such capability is absent. Right
      now it is absent only from the new Freedesktop API.
    • Jehan's avatar
      plug-ins: implementation of the Freedesktop portal for screenshot. · 53a03b38
      Jehan authored
      I am told by the GNOME/Flatpak people that this is what we will
      ultimately need to implement. Basically this portal is supposed to work
      everywhere, in sandboxes (Flatpak, hopefully Snap too?), but also out
      of sandboxes, i.e. in GNOME and KDE, whether Wayland or X11. So that
      should be the unique API we will have to implement in the end, and every
      desktop environment/sandbox will need to implement this API (which is
      Apparently it is not part of default GNOME yet, but has to be installed
      separately (on Fedora, package is xdg-desktop-portal-gtk for GNOME and
      xdg-desktop-portal-kde for KDE).
      Now there are currently many shortcomings, and in particular, the
      screenshot API has apparently no advanced features (at all!). No window
      snap, no rectangular selection, no delaying, no choice on including
      cursor or decoration, nothing! Apparently this is normal that the API
      presents no feature, because "the API itself is not meant to specify the
      details how the screenshot is obtained. Instead the portal will present
      the user a dialog to take a screenshot, and that screenshot will be
      given back to the sandboxed app".
      This is acceptable behavior, except that currently, the dialog has none
      of the basic features so this is a very bad regression. This is why I
      test the freedesktop API last, which basically means it will likely
      never be actually used. That's on purpose. At least, the code is in and
      will be easy to improve later. Of course, when the Freedesktop portal
      for screenshot will finally be featureful, it is meant to be tested
      See: https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Screenshot.xml
  19. 10 Dec, 2017 6 commits
  20. 09 Dec, 2017 2 commits
    • Jehan's avatar
      plug-ins: fix a bunch of coding style. · bf13c13e
      Jehan authored
      The screenshot-win32.c file was absolutely not following our coding
      style. A lot of things are still wrong (like camelCase functions), but
      at least I fixed a bunch of indentations, space between function and
      arguments, alignments, curly brackets at start of lines, etc.
    • Jehan's avatar
      Bug 791352 - Screenshot delay is broken for region shots in GNOME. · 614bcf6d
      Jehan authored
      Delay should indeed happen before root and window screenshots, but must
      happen in-between region selection and region screenshot.
      One can notice that the logics is different for Windows screenshot in
      X11. The reason is that X11 window screenshot has an additional window
      selection step (and therefore delay must happen in between selection and
      actual screenshot). Window screenshot in Wayland doesn't have this step
      and simply screenshots whatever is the currently active Window.