1. 19 May, 2018 2 commits
  2. 18 May, 2018 7 commits
    • Emmet O'Neill's avatar
      Bug fix: Ctrl-activated color picker no longer glitches out when double clicking with a mouse. · 1d8c0c10
      Emmet O'Neill authored
      Currently a glitch exists where double clicking with a mouse while using the ctrl key-activated color picker causes the `KisAbstractInputAction::eventPos` and ``KisAbstractInputAction::eventPosF` functions to return an incorrect value, which then causes the ctrl-picker to return an undefined and unwanted color (usually black or white).
      This patch fixes this bug by simply adding the `QEvent::MouseButtonDblClick` case to both switch statements, returning the correct position info for the abstract input events.
      I believe this should close https://bugs.kde.org/show_bug.cgi?id=394396 . Although the user reported a crash associated with this bug, I was unable to reproduce any.
      I also threw in some tiny formatting/style changes while I was in those files.
      Test Plan:
      Using a mouse, select the Brush Tool, hold the Ctrl Key to pop up a color picker, and double click.
      Without this patch applied the picked color will often incorrectly be pure black or pure white, which seems to change depending on the zoom level.
      After this patch, double clicking should not create any unwanted or unpredictable behavior from the ctrl-picker.
      Reviewers: #krita, rempt, dkazakov
      Reviewed By: #krita, dkazakov
      Subscribers: #krita
      Tags: #krita
      Differential Revision: https://phabricator.kde.org/D12953
    • Halla Rempt's avatar
      Fix playhead positioning after adding/removing hold frames · c215d014
      Halla Rempt authored
      BUG: 393396
    • Halla Rempt's avatar
      Fix inconsistent frame numbering when calling FFMPEG · 10e9c86a
      Halla Rempt authored
      BUG: 389045
    • Dmitry Kazakov's avatar
      Comment-out some environment variables in the docker environment · 8b611ec1
      Dmitry Kazakov authored
      PYTHONPATH should not be set to python3-binaries in
      the environment when python2 is used often
    • Dmitry Kazakov's avatar
    • Halla Rempt's avatar
      If there translations in the build or src dir, install them · c8b8a016
      Halla Rempt authored
      Note: I have no idea whether the createtarball ruby script would
      still add this code at the end of the top-level CMakeLists.txt
      Second note: to fetch the translations, run cmake with the following
      cmake ../krita -DKDE_L10N_AUTO_TRANSLATIONS=ON -D... This will
      fetch the translations from subversion (so svn needs to be installed).
      If you build master, it will fetch the right translations.
      Not sure whether if you're on the stable branch, it will automatically
      know that that's the stable branch...
      You can also run "make fetch-translations" manually.
    • Halla Rempt's avatar
      Fix channel swizzling problem on OSX (BGRA vs RGBA on 32Fbits) · 893e22d1
      Halla Rempt authored
      OSX supports core profile only, so it doesn't report any extensions
      for floating point texture formats. We should just use it directly if
      openGL version is higher than 3.0, when floating point textures became
      core profile.
  3. 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
    • Halla Rempt's avatar
      Merge branch 'rempt/update-frameworks' · bef84207
      Halla 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
  4. 16 May, 2018 2 commits
  5. 15 May, 2018 8 commits
  6. 14 May, 2018 5 commits
  7. 12 May, 2018 6 commits
  8. 11 May, 2018 1 commit