I tried out the fallback patch and my Japanese UI continues to work fine.

In T2333#31099, @rempt wrote:

Hm, I just made beta builds, and there even more is untranslated, apparently because some translations do not have a context. I'm experimenting a bit now.

Hi Boud: changing the call to i18nc context "action" seems to fix the problem.

I wrote a patch for each of the bugs, the first one should probably have gone on differential, but I seem to be able to save and load primary/alternate shortcuts now.

Okay, I found one problem in the action manager code, which meant we were using some untranslated strings for certain menu items. Now "Save Incremental &Version" will display properly in the menu.

That is very bizarre. I'll look into it.

A full mingw environment install includes a Windows port of gdb, I remember using it with success when I attempted mingw builds a while back. I have not tried using Breakpad.

No problem! ?

The error with saving when custom shortcuts are set to empty should be fixed in rKRITA55bbe2312368.

Hi Dmitry, thank you for reviewing this. I completely overlooked that the events have different pressure. Of course dropping the first event is incorrect here, the correct starting pressure should be 71%.

OK, I can get a mingw build going if necessary.

See rKRITA5bd8323f83f1

OK, creating new schemes seems to be fixed, and the crash from pressing "cancel" should be gone.

This breaks MSVC 2015. Three sorts of template errors:

I don't think Mac support should block this. And I wouldn't expect Qt 5.6 on Linux to cause any problems since we implement our own input handler anyway.

Works well with Windows (Qt 5.6) and a tablet. Cage transform is very usable.

Yes, it's just a few lines that are going to disturb things, like reporting when a target window or target widget changes, since those things happen during strokes. I'll comment those out for now.

Hi Boud: the intent of dbgTablet is to have a debugging area which is enabled by default, since dbgTablet is only called after pressing ctrl+shift+T. But with this change, we don't get clean tablet logs anymore. We could create another debug area like dbgTabletLog which is enabled by default.

Seems this is just one of many problems with using Qt's High DPI settings.

Reopening with a new list of problems:

Taken care of by rKRITAb55d79bb7dcf8a8fe08ec55aef9c7e0e4120e94d

Luckily this spooky stuff seems to have been resolved in Qt 5.6.

Unless I am mistaken we have to implement something like this in our own code. QCursor looks up the DPI of the screen first, then returns the appropriate cursor.
https://codereview.qt-project.org/#/c/141437/3/src/plugins/platforms/windows/qwindowscursor.cpp

Gonna call this resolved. Doing conflict checking between KisShortcutsConfiguration and XMLGUI shortcuts would involve slapping together a nasty mess just for a small benefit, I don't plan to do it myself. Those two shortcut systems need to be merged together someday anyway.

Thank goodness!

In T1244#24557, @kamathraghavendra wrote:

@abrahams here the problem is duplicate letters, i 'll check once again for unique letters. the mnemonics for trim to selections for example is 'e' where as it is same for resize image too. so there is a conflict.

In D1174#22463, @rempt wrote:

I'm fine with that limitation, and it would be really good to have those two bugs fixed!

Thank you for fixing these leaks! ?

+1 for starting from first principles. I'm game to code up whatever you guys decide is best, even if it's complex.

I think these two bugs are the same, and that D1174 is a reasonable workaround.
https://bugs.kde.org/show_bug.cgi?id=359561
https://bugs.kde.org/show_bug.cgi?id=349422

I think this is caused by a bug in the Wintab driver or at the very least a hideously ugly corner case. It seems wTInfo may return the wrong logical button map if Krita is not in focus but the tablet is used in Krita's window. The strange part is that wtInfo will then continue to send this bad button map even after you focus Krita and do another query after entering proximity.

Landed this together with D1151.

The only case that is removed is when hotspotX is set to -1, which is supposed to indicate the center is bitmap.width / 2. But Qt does that already if you pass hotspotX = -1 through straight into the QCursor constructor, so there wasn't really a point to doing that as far as I could tell.

Hi Boud, you're right there was a simpler way to write this that makes caching nicer.

Rewrite in a simpler way with QHash

I hope this patch is acceptable as a "bug fix, not an additional feature." The intention is that this cache will handle DPI switching logic for cursors in a central place.

Add Qt bug report in commit message

Remove some accidentally commited comment lines

Hi all,

Hi @kamathraghavendra - it's not easy to add new mnemonics for copy/paste layer because the layer menu is already full. Currently there are already two that try to claim 'C' and two that claim 'M', so there are way too many mnemonics in that menu already. Maybe it would be better to remove some of the lesser used mnemonics, or add more sub-menus. I would prefer some user input before changing the UI like that.

Running Manage Resources -> Open Resource Directory works like it should on Windows. I think this is good to go, unless @rempt expects something on OSX to be different.

I am able to replicate Bug 359561 in Windows, hopefully it will be easy to solve.

After D1121 lands I do not intend to do any more significant refactoring before Krita 3.0 is released. The only big task remaining on my agenda is to restore checking for shortcut conflicts, which should be relatively straightforward.

Hi @dimitril, if you make these cleanups to the patch I can test it on Windows. It looks correct, I would be very surprised if there were any problems.

It seems there's just one appropriate icon that has to be reused for "Shortcuts," "Performance" and "Canvas Input Settings." It would be nice to find a different icon for one of these.

Hi @kamathraghavendra, I came to this task and made some fixes to the system, but could you provide a little more information about the problems with restoring shortcuts and the mnemonic system?

KoZoomTool does look like a dusty old bit of code... hard coding ctrl key support in D1115 seems to do the trick for me.