@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.

With cases like this it's usually preferred to do feature detection instead of checking for specific versions.

Krita lacks options to rotate the canvas

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-v4.1.3.1-239-ge64348e693, so here's my observations/findings:

In T2299#162926, @davidedmundson wrote:

I'm not sure that it really happens this way.

Feel free to check.

This fixes one of the two issues that will make it less blurry https://phabricator.kde.org/P263

In T2299#162907, @dkazakov wrote:

Hi, @davidedmundson!

I have just tried to reproduce the problem again, and I do still reproduce it with Qt 5.9.1. I will try to search for exact lines in Qt's code, but I'm not sure I will manage to finish it today. Steps to reproduce:

1. Set GUI scaling in windows to 150-200%
2. Start Krita
3. Go to Settings->General->Enable HiDPI support (it basically activates GUI scaling). Without this option, openGL canvas behaves exactly like you explain, that is, renders inRestart hardware pixels. But after activating this option, scaling starts.
4. Restart Krita
5. Create 500x200 image
6. Activate "Use same aspect as pixels" box at the bottom-right corner of the window
7. Press '1' to set 100% zoom
8. BUG: See that the image has actually size of 1000x400 physical pixels. And Krita does not pass any extra scaling to openGL. It paints just in logical pixels.

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!

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.

In D15585#328376, @rempt wrote:

In D15585#328367, @alvinhochun wrote:

This post [1] describes a way of building OpenSSL with mingw(-w64).

That's rather different from what's in the openssl readme itself :-(

This post [1] describes a way of building OpenSSL with mingw(-w64).

In T9256#159693, @rempt wrote:

Angle

• The version of Angle that is packaged with Qt only supports OpenGL ES 2, which does not support 16 or 32 bits floating point textures: when using Angle, Krita's support for HDR images is already broken.

RE point 1: The toolbox's minimum size should be one tool button wide, does it mean some people want to reduce its size to smaller than one tool button? Or is it that they somehow want all the (perhaps only often used) tool buttons to be visible at once? Or that they want to hide the toolbox and make it a pop-up when pressing on a toolbar button, like the brush editor and etc.?

I think you probably should specify KFormat::JEDECBinaryDialect.

In T8803#144305, @scottpetrovic wrote:

1. it should not be mentioned in the installer. It should just be included

I get it that you probably don't want to confuse users, but would showing an option really be a huge issue? At this rate it would seem that the Windows build should even just have the ffmpeg path selection box hidden and the path hard-coded.

In T8803#143757, @rempt wrote:

Ben noted on irc that we should use a stripped down version like suse does -- but I'm not sure whether that's an option.

I don't see it in the backlog, it's overflown :( What does stripped down mean here? Custom build with limited features enabled?

Ideally we'd bundle it.

Yep.

I'm not sure about giving people an opt-out is all that useful.

Well, it does take a bit more space, I don't know if people would start complaining about that 8) Also not every users would need to render animations.

We should note that we include ffmpeg in the license text in the installer.

If you feel like doing it, can you make a copy of the license rtf and add the text there?

I would prefer to have it downloaded like any 3rdparty component

About 5, I'm not sure what would be best...

If files.kde.org doesn't mind 40MB extra of traffic with every deps build done, then it's simpler if you just just throw the original zeranoe build 4.0 packages up there, and I'll add the ExternalProject in CMake to fetch them. Would probably also make future updates easier.

Improved the logging of proximity events.

This patch to Qt isn't needed anymore now that D12762 "fixed" the issue.

Added run-time version check for Qt 5.9.x where x > 3 and Qt 5.10.1 or above.

Looks good to me now. I haven't tested it but I believe the remaining changes shouldn't specifically affect the Windows build.

Maybe you can find a way to make it work on Windows using a user-specified Python 2.7 install and self-built SIP/PyQt, but it must use separate code paths that is switched by an ifdef.

I would suggest just not allow Python 2.7 to be used with Windows/MinGW because the whole Python setup for the Windows build is pretty much tied to the embedded Python 3.6 package.
Do note that the Python setup for the Windows build is pretty specific and even requires a certain version range of Python to be installed on the build host to build properly.
Unless you also modify ext_python, ext_sip, ext_pyqt, the Python plugin code and the packaging scripts to be able to produce a package with Python 2.7 embedded into it, it's basically not usable.

Should I make improvements based on this specific code from Drawpile, or revive the old tablet tester that @rempt mentioned, or better write a new tablet tester to suit Krita's needs?

In D12762#259664, @anthonyfieroni wrote:

You can make a runtime check for version

static const bool shouldSetAcceptTouchEvents = QVersionNumber::fromString(qVersion()) > QVersionNumber(5, 9, 3);
if (shouldSetAcceptTouchEvents) {
    quickWidget->setAttribute(Qt::WA_AcceptTouchEvents);
}

That is interesting. Is it the same output in Drawpile? Because it should be now that Drawpile borrows the tablet code from Krita.

I should also add that this is not a replacement of the tablet log since it bypasses KisInputManager completely.

Seems good to me

• Now automatically selects WinInk if there exists a WinInk pen device.
• Changed the prompts.

It would be a bit tricky to detect N-Trig digitizers, but it should technically be doable. However, I would be reluctant to implement a special override for N-Trig digitizers. Some users might still want to install and use a Wacom tablet.

In D11905#239218, @rempt wrote:

Hm... I'm wondering, can we not just load the winink code silently if we don't find a wintab driver?

@dkazakov should check this.

Haven't tested but looks fine to me.
Though there are some minor issues with the code formatting:

Hi @scottpetrovic, does this fix https://bugs.kde.org/show_bug.cgi?id=362659 and can the commit 61a84e2c008939cb1989f648320e53b5d91760bd? be reverted?