1. 18 May, 2018 6 commits
  2. 17 May, 2018 9 commits
    • Alvin Wong's avatar
      Merge branch 'alvin/D12710-tablet-tester' · e38339f1
      Alvin Wong authored
      Add tablet tester from Drawpile, with some changes.
      Differential Revision: https://phabricator.kde.org/D12710
    • Alvin Wong's avatar
      Improve logging of tablet proximity events · c0cf2856
      Alvin Wong authored
    • Alvin Wong's avatar
      Adapt and enable tablet tester · 512be25c
      Alvin Wong authored
    • Alvin Wong's avatar
      Replace tabs with spaces · fc43b0de
      Alvin Wong authored
    • Alvin Wong's avatar
      Add TabletTester code files from Drawpile · 39e15d60
      Alvin Wong authored
      The source files are not yet modified.
    • 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
    • Boudewijn Rempt's avatar
      Merge branch 'rempt/update-frameworks' · bef84207
      Boudewijn Rempt authored
    • 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
  3. 16 May, 2018 2 commits
  4. 15 May, 2018 8 commits
  5. 14 May, 2018 5 commits
  6. 12 May, 2018 6 commits
  7. 11 May, 2018 4 commits