1. 19 May, 2018 1 commit
  2. 18 May, 2018 2 commits
  3. 17 May, 2018 3 commits
    • Alvin Wong's avatar
      Make QQuickWidget accept touch events on recent Qt versions · b1d67ddc
      Alvin Wong authored
      This fixes some issues operating the touch docker and other QML parts
      with touchscreen when using Qt LTS later than 5.9.3. See
      Differential Revision: https://phabricator.kde.org/D12762
    • Emmet O'Neill's avatar
      Refactor: Unified Color Picker Code & Removed Some Duplication · af5acee0
      Emmet O'Neill authored
      This patch is part of task T8708, focused on further improving Krita's color picker.
      >As of right now, Krita effectively has two near-duplicate paths when it comes to color picking code: the code for the dedicated Color Selector Tool (P) exists mainly in "kis_tool_colorpicker", while the code for the ctrl-key activated color picker that you can pull up while other tools are active [as well as the scratchpad's picker] exists mainly in "kis_tool_utils".
      This patch addresses this issue by, as much as possible without some much bigger changes, unifying all of the core color picking functionality within the `KisToolUtils` namespace's `pickColor` function.
      Essentially all of the duplicate code was removed from `KisToolColorPicker::pickColor`, which now calls into the same `KisToolUtils::pickColor` function that's used elsewhere creating a single place in the code where things like sampling radius and color picker blending are implemented. As a result, any change to the code in `KisToolUtils::pickColor` will now affect all of Krita's color pickers (the dedicated tool [P], the ctrl-activated picker, and the scratchpad picker) in a uniform and predictable way.
      While this patch does solve the most of the code-duplication issue that existed in Krita's color pickers, there are still a few ways in which the dedicated tool and the ctrl-picker behave inconsistently. In my view, more extensive refactoring can be done in the future to create more uniform and predictable behavior across the various pickers, resulting in more color picking code being moved into `KisToolUtils::pickColor` from elsewhere. For now though, I wanted to focus on code-reuse improvements that don't have any user-facing design implications.
      Also, some minor code-style cleanup was done here and there.
      Test Plan:
      Test the various color pickers (dedicated tool, ctrl-picker, scratch pad) for *mostly predictable and equivalent behavior.
      *Certain aspects of the dedicated/ctrl picker can't be unified without some bigger changes, such as 'sample from merged/active only'.
      Reviewers: #krita, #krita_abyss, rempt, dkazakov
      Reviewed By: #krita, #krita_abyss, dkazakov
      Subscribers: #krita_abyss, #krita
      Tags: #krita_abyss
      Differential Revision: https://phabricator.kde.org/D12941
    • Emmet O'Neill's avatar
      Animation Timeline Docker: Insert Keyframes with Timing. · 7c639729
      Emmet O'Neill authored
      This patch adds timing functionality to the Animation Timeline Docker's "Insert N Keyframes" menu actions. Out of necessity, it also replaces the create-on-demand QInputDialog with a new TimelineInsertKeyframesDialog that was designed as a drop-in replacement that allows for getting more than a single variable of user input (i.e. frame count and timing) and which could easy be given more functionality in the future.
      The motivation behind this patch was to improve the "Insert N Keyframes Right/Left" action workflow by giving the animator control of frame timing. Previously, those actions worked by adding a number of immediately adjacent frames based on the user's desired number of frames to insert.
      In animation, keyframes that are immediately adjacent to each other are described as being "on 1s", but other timings are also common - "on 2s", "on 3s", etc. - in which drawings are held for different amounts of time. Animations typically maintain a particular rhythm for a span of frames, but it's also very common for different parts of a single animation to switch timings.
      This patch improves upon existing functionality to facilitate animating on 1s, 2s, 3s, and others. Now, a Krita user can specify a timing of 2 to quickly and easily insert keyframes "on 2s", a timing of 3 to insert "on 3s", and so on, allowing even longer timings if desired.
      ( Pair-programmed on a sunny Portland Saturday with @eoinoneill, of course! =] )
      Test Plan:
      1. Right-click a position on the animation Timeline docker.
      2. Select "Keyframes > Insert N Keyframes Right" or "Keyframes > Insert N Keyframes Left".
      3. A new dialog windows should pop up, asking for a number of frames and a timing.
      4. Test different values as well as both the "Cancel" and "OK" buttons and check for predictable behavior in a variety of cases.
      Reviewers: #krita, #krita_abyss, dkazakov, rempt, scottpetrovic, Bollebib
      Subscribers: #krita_abyss, #krita, eoinoneill
      Tags: #krita_abyss
      Differential Revision: https://phabricator.kde.org/D12843
  4. 16 May, 2018 2 commits
  5. 15 May, 2018 6 commits
  6. 14 May, 2018 4 commits
  7. 12 May, 2018 4 commits
  8. 11 May, 2018 2 commits
  9. 10 May, 2018 6 commits
  10. 08 May, 2018 1 commit
  11. 07 May, 2018 3 commits
    • Jouni Pentikäinen's avatar
      Remove experimental code · ee5f1f6e
      Jouni Pentikäinen authored
      This commit removes the paging docker and quick layout chooser dropdown.
      These were merely proofs of concept, and never meant to go into master.
    • Boudewijn Rempt's avatar
      Rename foreGround/backGround to foreground/background · 21e8384d
      Boudewijn Rempt authored
      This is more consistent with the rest of Krita and is more correct.
      However, the colorSource and halftone filter haven't been changed
      since those used these strings to save and load config.
    • Boudewijn Rempt's avatar
      Add Document::setBackgroundColor API · 24f97f7d
      Boudewijn Rempt authored
      This can be used like this:
      from krita import Krita
      from PyQt5.QtGui import QColor
      kt = Krita.instance()
      doc = kt.activeDocument()
      test_color = QColor(128, 128, 128, 255)  # change as needed
      old_background = doc.backGroundColor()
      print("Old background: {}".format(old_background.getRgb()))
      new_background = doc.backGroundColor()
      print("New background {}".format(new_background.getRgb()))
      Patch by Jeroen Hoolmans, thanks!
      fferential Revision: https://phabricator.kde.org/D12729
  12. 06 May, 2018 3 commits
  13. 04 May, 2018 3 commits