- User Since
- Jun 19 2016, 12:39 PM (148 w, 1 d)
Sat, Apr 20
Fri, Apr 19
Thu, Apr 18
Updated patch for master
Upload the correct patch
Wed, Apr 17
The question is: should we change the default behaviour to RoundPreferFloor instead of trying to keep the old behaviour by using Round? I feel like RoundPreferFloor would be more useful to users who doesn't want to enable fractional scaling (but that will probably be the minority if we can enable fractional scaling by default).
Tue, Apr 16
Mon, Apr 15
Sun, Apr 14
Moved some code from the converter to the canvas.
Sat, Apr 13
Fri, Apr 12
Wed, Apr 10
Tue, Apr 9
Mon, Apr 8
Sat, Apr 6
Fri, Apr 5
- Starting to convert more stuff to use device pixel
- Beginning to differentiate between device pixel and logical pixels
Thu, Apr 4
Tue, Apr 2
Add comments and updated 3rdparty/README.md
Mon, Apr 1
Sun, Mar 31
Thu, Mar 28
Wed, Mar 27
Tue, Mar 26
That bug should be fixed with R37:331beffd5332.
After last night's test, I can say this is not the fix to the pyqt situation on Windows.
Mar 16 2019
Mar 14 2019
I see that you've already committed this but unfortunately it is just broken on Windows. Running config definitely isn't how one would be able to build openssl on Windows.
I agree you should make a separate define for use with OpenGL-ES-only environments. OpenGL ES is not limited to Android after all.
- Should I still remove Chocolatey, if it's very similar to Homebrew on Mac?
Mar 7 2019
Though having the CMakeLists.txt doesn't mean they really support CMake build and probably nobody knows what would happen if you try to use it with the mingw-w64 native toolchain...
Both libraries seems to contain a CMakeLists.txt file. If they do support CMake there is no reason to not prefer it over using the autotools build.
Feb 16 2019
Feb 11 2019
Feb 4 2019
Feb 3 2019
Jan 23 2019
Jan 21 2019
A few things:
Dec 13 2018
Oct 17 2018
@dkazakov I see that you've changed the code to use devicePixelRatioF. I can see that the canvas now attempts to render at 100% device pixel size.
Oct 14 2018
With cases like this it's usually preferred to do feature detection instead of checking for specific versions.
Oct 11 2018
Krita lacks options to rotate the canvas
Oct 10 2018
One more issue: The fix seems to have used the integer version of devicePixelRatio somewhere instead of the floating point devicePixelRatioF. This is from my observation forcing a 1.5x scaling on Windows. I haven't checked the code. Even though Qt now rounds the scale factor to nearest integer on Windows, we should assume that real fractional scaling support will be added in the future. In fact the then-in-progress task https://bugreports.qt.io/browse/QTBUG-53022 is exactly for this. (It might even be already supported on KDE, but I can't confirm.) So please fix it to use the floating point devicePixelRatio.
@dkazakov Thanks for the partial fix. I've done some testing on Windows with krita-nightly-x64-v18.104.22.168-239-ge64348e693, so here's my observations/findings:
Oct 5 2018
Oct 4 2018
Sep 27 2018
Actually, only right-click press itself is for opening context menus
and some context-sensitive actions. I don't think right-click drag is
used for anything, or is it? Using right-click drag for scrolling is
not so implausible.
Ok. I was thinking that context menus often pop up on mouse down,
which would interfere with the scrolling. And since right-click release events
often trigger menu selections (does that happen on Windows too?
I can't remember off the top of my head) it might be prone to accidents.
Of course, all that stuff could be worked around and there's no harm in testing it!
Sep 26 2018
Alvin, is your issue that the middle mouse button is used by default? Because there are other scroll methods available already in the existing code(finger scroll and mouseclick scroll). I've been using the latter on my system.
This is a bit of a misunderstanding, I think.
Scroll bars are still enabled by default, as they probably should be.
It's merely that the checkbox says "Hide Scrollbars" now, and that users have to opt into hiding them.
It's purely a semantic change, the users opts into "hiding" the scrollbars instead of opting out of "showing" them.
This patch takes the concept of Kinetic Scrolling and applies it uniformly across Krita's user interface, where applicable. To do so, we've created a new KisKineticScrolling namespace that encompasses most of the behavior of kinetic scrolling in a single place, which allows for adding consistent kinetic scrolling behavior to any UI element with just a few function calls. Using the new namespace we were able to easily add kinetic scrolling to all of Krita's scrollable user interface elements including dockers, the toolbox, the brush preset selector, palettes, animation timeline, etc. Because all of these elements share the same code path, they all use the same user-configured settings. The namespace also has a couple of utility functions, including a cursor updater to unify the visual feedback.