I think simply appointing a fundraising director or cultivating a more active fundraising arm may go a long way. It would also create a more reasonable 2-year goal.

The plugin architecture looks a bit magical at first, I was certainly surprised myself the first time I saw it. So here's my understanding having gone through this before.

Correct i18n for the floating message should be something like i18n("Current preset changed to: %1\n", preset->name())

In D6522#122848, @alvinhochun wrote:

In D6522#122808, @abrahams wrote:

If the goal is to prevent heap allocation, wouldn't it be easier to simply get rid of the PIMPL idiom for this class entirely and move the contents of KisPaintInformation::Private out into KisPaintInformation?

I believe the original intention was to keep binary compatibility whenever the internal data fields are changed. Though it also increases the recompilation speed by a lot. But tbh how often are these fields changed?
I'm not sure if binary compatibility is really needed. I don't think there are any third-party plugins for Krita written in C++, are there? And we are moving to Python scripting anyway.

I went through a quick proofread and edit of this manual page. I think it looks good and could be considered a complete first edition.

If the goal is to prevent heap allocation, wouldn't it be easier to simply get rid of the PIMPL idiom for this class entirely and move the contents of KisPaintInformation::Private out into KisPaintInformation?

Fixed by 9be24287419794ed1fd1a44195bbc88382df9bb5 ?

Is this closed by a1863a8?

The macro system has been removed in favor of python scripting right?

It seems strange that getStabilizedPaintInfo would be some sort of choke point. If that's really the case, I wonder if it would be worth pushing the implementation of getStabilizedPaintInfo into KisPaintInformation using a function with signature like
KisPaintInformation::mixQueue(QQueue<KisPaintInformation> queue, bool stabilizeSensors).

Instead of doing multiple string comparisons every redraw, why not make an enum for the different shaders?

Hi Dmitry - yes I believe this was pushed but the revision was not closed. I'll take care of that.

When I began working on the eraser I realized this really REALLY needed to be done. Awesome.

Apparently this has been resolved.

The bug seems to have been resolved at some point. Maybe good to remind users to restart Krita after changing their Wintab driver settings.

Well, krita 3.0 has been released, so hopefully the release-blocking regressions are gone!

No big deal, just was away for the holiday weekend in the US and would have pushed a little while earlier!

Is this acceptable?

Okay, now the tool doesn't just ignore shift then click.

Fix Shift+Click for move tool.

Fix typos and restore some comments

Nevermind, I like how you wrote it Scott

Add Qt patch for fullscreen without 1px border, write path with forward slash, bump Qt version

I noticed we've been adding patches to the Krita repository. I'm not sure how to test such changes since I'm still using Emerge but I could upload the patch to Phabricator here.

https://docs.krita.org/Shortcuts

This seems fixed for me now.

Closed by rKRITAc7621d2d80c8

This has never been implemented. Right click events are not registered at all. Implementing this would either require asking Microsoft to update its drivers or switching from Wintab to the Windows Ink API.

Can I land this right now and replace it in the settings window some other time?

I'll look into this tomorrow.

The Qt and Wintab resolutions always match on my machines, which I suppose is a good thing.

I didn't realize this was still causing problems. D1602

The tablet screen mapping menu was removed. It should really be possible for our code to always do the right thing. Qt5 puts in a lot of additional support for carefully handling DPI scaling. I believe restoring the dialog will not be difficult but I would want users to report it to us if they find it's necessary to use it.

Bug 362743 actually brings up another issue, which is that tool-specific shortcuts like "convert to path" might duplicate global shortcuts but we should be OK with that happening. The current behavior is not majorly broken as long as nobody is reassigning these tool-specific shortcuts.

For the untranslated animation strings, it looks like there are a number of untranslated user-facing strings in plugins\dockers\animation\, under addAction() setToolTip() and maybe others.

Bug 361578 is fixed by rKRITA37389d5353ec
Bug 362341 is fixed by rKRITA932bcb70669e

Hi Dmitry: yes, I was replicating this bug on my Surface Pro 3, but my custom builds have been broken for a while, so I can't replicate it on my machine reliably anymore. It would be good if you took this over.

Why did this require converting to a pointer? Couldn't this have been done by simply adding m_timer(this) to the initializer list?