1. 26 Feb, 2019 1 commit
  2. 24 Feb, 2019 2 commits
  3. 23 Feb, 2019 1 commit
  4. 22 Feb, 2019 1 commit
    • Debarshi Ray's avatar
      gegl, test-gegl: Split out the code to convert a GeglBuffer to a format · 54b89044
      Debarshi Ray authored
      This code is necessary whenever the validity of a floating point
      GeglBuffer has to be asserted because floating point colour component
      values are inherently not reproducible. Minor errors can creep in due
      to differences in computer architecture, varying Babl conversions or
      other changes in code. These errors don't indicate a bug and will
      cause spurious test failures. Therefore, it's better to convert such
      GeglBuffers into integer values before checksumming. eg., this is
      relevant when a buffer is zoomed by a GeglSampler because the result
      is floating point premultiplied alpha.
      Subsequent commits will add a new codec API for GeglBuffer similar to
      those for GdkPixbuf, which is going to offer on-the-fly zooming while
      decoding a bitstream. Therefore, this will be useful for testing those
      code paths.
  5. 21 Feb, 2019 2 commits
  6. 19 Feb, 2019 2 commits
  7. 17 Feb, 2019 1 commit
  8. 16 Feb, 2019 2 commits
  9. 07 Feb, 2019 2 commits
  10. 06 Feb, 2019 2 commits
  11. 05 Feb, 2019 4 commits
  12. 04 Feb, 2019 1 commit
  13. 03 Feb, 2019 1 commit
  14. 02 Feb, 2019 1 commit
    • Leesoo Ahn's avatar
      main-toolbar: Enable the gear menu only when the item is loaded · 354f925d
      Leesoo Ahn authored
      The "app.gear-menu" GAction is enabled and disabled from both
      photos_application_actions_update and the MainToolbar when the mode
      changes. This makes things unpredictable by relying on the order in
      which the callbacks are invoked. Currently the MainToolbar was
      winning and rendering parts of commit 031df27c ineffective.
      Instead, this should only be handled in one place -
      photos_application_actions_update. It's a lot more fine-grained and
      informed than the MainToolbar itself. eg., the MainToolbar only knows
      about the mode changing to PREVIEW, but doesn't know whether the item
      has finished loading.
      This code was added in commit 7e12154b, and the above rationale
      held true even then. However, back then, the item's loading state was
      not looked at. This is probably why the problem got overlooked.
  15. 01 Feb, 2019 1 commit
  16. 31 Jan, 2019 1 commit
  17. 28 Jan, 2019 2 commits
  18. 27 Jan, 2019 1 commit
  19. 25 Jan, 2019 2 commits
  20. 20 Jan, 2019 1 commit
  21. 19 Jan, 2019 1 commit
  22. 18 Jan, 2019 2 commits
  23. 17 Jan, 2019 1 commit
  24. 11 Jan, 2019 2 commits
  25. 05 Jan, 2019 1 commit
  26. 04 Jan, 2019 2 commits
    • Daniel Mustieles's avatar
      Updated Spanish translation · 31e6485e
      Daniel Mustieles authored
    • Debarshi Ray's avatar
      flatpak: Explicitly specify the LibRaw build options · b843015c
      Debarshi Ray authored
      Currently the build detects the presence of the necessary dependencies
      and automatically enables or disables the corresponding options. Unless
      someone is keeping a close eye on the build logs, a change in the
      manifest or the SDK might silently and unexpectedly change the build
      Ideally, the build would fail if a requested option can't be met, to
      draw attention to this unforeseen change.
      Unfortunately, the LibRaw build uses AC_MSG_WARN even for explicitly
      enabled build options. This means that a missing dependency won't fail
      the build even if the option was explicitly requested. While this is
      not ideal, at least listing the options makes it clear what the
      required outcome is. That way someone can manually check the logs from
      time to time and see if it's living up to the requirements.
      The set of build flags have been chosen to match the current reality of
      automatically selected options. Hence, there shouldn't be any
      user-visible change.