- User Since
- Jun 19 2016, 12:39 PM (139 w, 4 d)
Sat, Feb 16
Mon, Feb 11
Mon, Feb 4
Sun, Feb 3
Wed, Jan 23
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-v220.127.116.11-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.
Sep 23 2018
Sep 19 2018
This post  describes a way of building OpenSSL with mingw(-w64).
Sep 10 2018
Jul 21 2018
Jul 6 2018
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.?
Jun 14 2018
I think you probably should specify KFormat::JEDECBinaryDialect.
Jun 9 2018
Jun 8 2018
Jun 7 2018
May 31 2018
May 27 2018
May 23 2018
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.
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.
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.
May 22 2018
May 21 2018
May 20 2018
May 19 2018
May 18 2018
May 17 2018
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.
May 15 2018
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.
May 12 2018
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?
May 9 2018
May 8 2018
That is interesting. Is it the same output in Drawpile? Because it should be now that Drawpile borrows the tablet code from Krita.
May 5 2018
I should also add that this is not a replacement of the tablet log since it bypasses KisInputManager completely.
Apr 18 2018
Seems good to me
Apr 16 2018
Apr 15 2018
- Now automatically selects WinInk if there exists a WinInk pen device.
- Changed the prompts.
Apr 14 2018
Apr 13 2018
Apr 11 2018
Apr 6 2018
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.
Apr 4 2018
Apr 3 2018
Mar 29 2018
Mar 28 2018
Mar 25 2018
@dkazakov should check this.
Mar 20 2018
Haven't tested but looks fine to me.
Though there are some minor issues with the code formatting: