I see you've done quite extensive digging on the subject: 👏 That being, said, there are a few nitpicks and elephants-in-the-room after a cursory reading.

Further notes backing up the version upgrade:

Change was deployed in https://invent.kde.org/graphics/krita/-/commit/ca645e71a09e1ee81dc0f7ef153b00304af058de and reverted in https://invent.kde.org/graphics/krita/-/commit/fa671d407fd6d89c87c15c67d486e5dd1c7b0301.

@bcooksley because MSYS2 is a rolling release distribution, and IIRC from our IRC conversations, you and Dmitry weren't comfortable with the idea of not having a pinned version.

I approve of the move, it'll bring superb performance improvements for very little cost. It's also got a great suite of checks and sanitizers.

I need to check on ImageBuilder::createImageFromClipboardDelayed.

All instances of clip() now go through the consent flow, same as anyone calling getImageFrom<clipboard/metadata>.

Some stats:

Original version: this was the "consent flow".

I never answered this! It's pretty simple, my dislike of Jenkins is too much. I'd probably prefer to use Gitlab CI for that, though I'm not sure if sysadmin would want several 4GB Docker images being shuttled every now and then.

Unfortunately, marking this as wontfix. We've coded ourselves into a corner with the usage of readPathEntry, which has no equivalent at all in QSettings.

In T14865#263873, @dkazakov wrote:

Buffer Discarding

---

• not available in openGL ES at all
• extension for openGL: "GL_ARB_invalidate_subdata"

1. List of OpenGL features we use (WIP)

Well, it gives me 3.0 all the time on my laptop. Though I'm not sure where we tell it what version we want.

In T14865#263264, @alvinhochun wrote:

Do we really support OpenGL ES 2 at all? On Windows we require Direct3D 11 which is needed to get OpenGL ES 3 with ANGLE.

@dkazakov, what would happen if we went SQlite for the preferences handling? That would turn versioning into a plain SQL migration (which I'm not sure if @rempt has dealt with in the past, for the resources refactor).

Quick remark, I think this approach is a no-go for our code. Check usages of entryMap().

In T14815#262375, @dkazakov wrote:

1. Changing KisConfig or KisImageConfig requires almost full recompilation of Krita. I wanted to refactor KisConfig into a namespace, so each class could define its own class in this namespace in a local file to define "rules" for config loading/saving. We have a pattern like that in KisDomUtils. QDebug is also a good example. Right now people tend to use KConfigGroup-based ad-hoc code to avoid changing global KisConfig because of that.

re files: I see at least three files where we store preferences. It'd be nice to consolidate them:

Further comments after sleeping over it.

Further notes: QSettings does not support temporary/namespaced changes; the handling of synchronization, unlike KConfig, is completely private to Qt.

I'm running a potential refactor here and I'm seeing many instances of setting preferences against read-only instances of KisConfig. For instance,

In T863#27737, @woltherav wrote:

Okay, looking about there's a few places where we could want dithering to improve gradients, all of these should be optional:

1. Displayfilter, so that people have the feeling 16bit and higher is indeed as smooth as a babies butt.
2. Gradients, primarily for drawing 8bit gradients.
3. Converting from high bitdepths to 8bit
4. Brush masks... aparantly the brushmasks currently give odd banding artefacts: https://forum.kde.org/viewtopic.php?f=288&t=132097&p=354832#p354832 dithering could deal with this.
   
   
   

FTR, Cryptpad is self hosted, the instance i'm using is pads.c3w.at. If I recall correctly, the problem was on Russia's telecoms' side.

Additional stretch goals were:

The SeExpr documentation has been merged in 9bb62c8ea128d9c5a059438108a5c8492d10e3c6 (master branch) and a71ad098ba1c33708d60365edf66fb8219674644 (4.3).

The SeExpr documentation and tutorial is available as a MR: https://invent.kde.org/documentation/docs-krita-org/-/merge_requests/145 .

The SeExpr generator has been merged in e4dbb4d80c50e330a7f9807c2ac7fd611bc8d0ab (master branch) and 510f039cc676dfe69d44a5bc2d8144cf9a0874a4 (4.3).

Multithreaded KisGenerators (i.e. conversion to the strokes system) was proposed in https://invent.kde.org/graphics/krita/-/merge_requests/412. Please let me know if you want an appimage for testing.

In T13097#233972, @lsegovia wrote:

• Research multi-threaded renders: SeExpr provides a way to detect threadsafe expressions and share these among workers, and Agata's MR for Histogram is really instructive.
• Move SeExpr logging to a interceptable approach. I had in mind logfault, which allows for a Qt shim on the Krita side.
• Make SeExpr fully locale-proof. I added some hacks wherever sscanf and atof are used (they are sensitive to decimal point changes between locales), but I'd like to not deal with locales at all.

Infrastructure was added with https://invent.kde.org/graphics/krita/-/commit/2d564eec6b0a3503d7671c69c10d18f8901934b9?merge_request_iid=380
Finalized with https://invent.kde.org/graphics/krita/-/commit/4e6f75bab8dd3898d77520c2454229b8214dfcef?merge_request_iid=380

Hey everyone,