1. 16 May, 2019 1 commit
    • Dmitry Kazakov's avatar
      Fix logic of the stroke lifetime in QMic · 57686d84
      Dmitry Kazakov authored
      We shouldn't try to end the same stroke multiple times. The patch
      also makes sure KisProcessingApplicator is owned by a scoped pointer
      instead of manual handling.
      
      BUG:407520
      57686d84
  2. 16 Apr, 2019 1 commit
  3. 12 Oct, 2018 4 commits
  4. 27 Sep, 2018 1 commit
  5. 14 Aug, 2018 1 commit
    • Dmitry Kazakov's avatar
      Make unit tests' names consistent · 46c27f94
      Dmitry Kazakov authored
      TEST_NAME parameter should state **only** the actual name
      of the test without any prefixes. NAME_PREFIX should state \
      the prefix. And, no, we cannot shortcut the thing and concatenate
      the name and the prefix in TEST_NAME, because it will break actual
      tests' binary file names.
      46c27f94
  6. 08 Aug, 2018 1 commit
  7. 05 Aug, 2018 1 commit
  8. 24 Jul, 2018 1 commit
  9. 10 Jul, 2018 1 commit
  10. 05 Jun, 2018 1 commit
  11. 30 May, 2018 1 commit
    • Boudewijn Rempt's avatar
      Fix typo · eb3afe6d
      Boudewijn Rempt authored
      (cherry picked from commit 5333bbf910d0bac66bf5364864d93abe6de6b224)
      eb3afe6d
  12. 14 Mar, 2018 2 commits
  13. 07 Mar, 2018 1 commit
  14. 28 Feb, 2018 1 commit
  15. 09 Jan, 2018 1 commit
  16. 27 Nov, 2017 1 commit
  17. 28 Oct, 2017 1 commit
  18. 19 Sep, 2017 1 commit
    • Boudewijn Rempt's avatar
      Remove the configuration for gmic-qt · 2a80805d
      Boudewijn Rempt authored
      There are now two ways of finding gmic-qt: have the executable
      built with the same Qt and other libraries as krita next to the
      krita executable (should work for both our builds as well as for
      distributions that package both krita and gmic-qt), or locate
      a folder that starts with gmic next to the krita executable. The
      folder can contain the version of gmic-qt that is build by gmic.eu.
      
      For a next iteration, I am considering also looking into
      QStandardPaths::AppDataLocation or QStandardPaths::AppLocalDataLocation
      to find a gmic-qt plugin folder, but for the current release, this
      should work.
      
      CCMAIL:kimageshop@kde.org
      2a80805d
  19. 13 Sep, 2017 1 commit
  20. 01 Sep, 2017 1 commit
  21. 26 Aug, 2017 1 commit
  22. 24 Aug, 2017 1 commit
  23. 18 Aug, 2017 1 commit
    • Pino Toscano's avatar
      typo fixes · 35b1cfd9
      Pino Toscano authored
      - "avaialble" -> "available"
      - "grabed" -> "grabbed"
      - "miliseconds" -> "milliseconds"
      - "postion" -> "position"
      - "sturctures" -> "structures"
      - "tranformation" -> "transformation"
      - "unknow" -> "unknown"
      35b1cfd9
  24. 15 Aug, 2017 2 commits
  25. 12 Aug, 2017 2 commits
  26. 10 Aug, 2017 2 commits
    • Nicholas LaPointe's avatar
      Fix panning in gmic-qt when using it with a non-RGBA image · 27813472
      Nicholas LaPointe authored
      The position of the source rectangle was not used when converting an image, so attempting to pan in the preview didn't work.
      Additionally, this fixes an issue where applying a G'MIC filter to a selection of a non-RGBA layer would not work (this is also present in old plug-in).
      
      Differential Revision: https://phabricator.kde.org/D7226
      27813472
    • Nicholas LaPointe's avatar
      Scale channel values by 255.0 when sending a non-RGBA image to G'MIC · 26e32b7e
      Nicholas LaPointe authored
      A different code path is taken depending on whether or not the image data to be sent to G'MIC is in the RGBA space.
      In the RGBA case, the channel values are scaled to range between 0.0 and 255.0
      In the non-RGBA case, the values were not being similarly scaled before this commit.
      (In both cases, the image is converted to use 32-bit float RGBA before any scaling is applied.)
      
      This is different from how the old plug-in worked:
      Old plug-in
          convertToGmicImageFast() on RGBA image fills gmicImage._data with values between 0.0 and 1.0
          convertToGmicImage() on non-RGBA image fills gmicImage._data with values between 0.0 and 1.0
      
      New plug-in, after commit
          convertToGmicImageFast() on RGBA image fills gmicImage->_data with values between 0.0 and 255.0
          convertToGmicImage() on non-RGBA image fills gmicImage->_data with values between 0.0 and 255.0
      
      New plug-in, before commit
          convertToGmicImageFast() on RGBA image fills gmicImage->_data with values between 0.0 and 255.0
          convertToGmicImage() on non-RGBA image fills gmicImage->_data with values between 0.0 and 1.0
      
      BUG: 382396
      Differential Revision: https://phabricator.kde.org/D7225
      26e32b7e
  27. 30 Jul, 2017 1 commit
  28. 27 Jul, 2017 1 commit
  29. 21 Jul, 2017 2 commits
  30. 16 Jul, 2017 1 commit
  31. 13 Jul, 2017 2 commits
    • Nicholas LaPointe's avatar
      Fix calculations of source rectangle and selection dimensions when sending data to G'MIC · f80c0940
      Nicholas LaPointe authored
      When there was no selection, the old plug-in would read and write pixels within the rectangle (0,0 canvasWidth x canvasHeight).
      The new plug-in was still set up to do this, except it would send the rectangle (0,0 layerWidth x layerHeight) to G'MIC.
      
      When there was a selection in the old plug-in, it would read and write within the selection rectangle.
      The new plug-in would read using (0,0 layerWidth x layerHeight), then write inside the selection rectangle.
      
      This commit should reinstate the old behavior.
      
      BUG:381732
      Differential Revision: https://phabricator.kde.org/D6431
      f80c0940
    • Nicholas LaPointe's avatar
      Initialze gmic_qt_get_cropped_images handler's cropRect to a unit square · b609a2a9
      Nicholas LaPointe authored
      prepareCroppedImages() expects normalized coordinates to define the area of an image which will be sent to G'MIC.
      These coordinates are normally retrieved from the message passed from G'MIC to Krita, but in the case of an error, the dimensions of the image were used instead.
      Since the image dimensions are not normalized, this was incorrect.
      
      This commit causes a unit square to be used when G'MIC didn't send valid coordinates, thus using the full area of the canvas or selection.
      b609a2a9