GitLab

Summary:
I did some tests and it seems Linux is not affected by this bug.
For Nvidia it seems to break with driver 375.63+. (tested 368.81 - 378.49)
For AMD I couldn't find a driver it would run correctly. (tested 13.251, 15.200)
For Intel, this is my main computer running linux and I would rather not mess with its configurations too much..
Unfortunately I don't have a mac so I couldn't do any testing for it.

I suspect the bug to be driver related and tried to debug wglgetProcAddress or rather the ICD implementation DrvGetProcAddress (nvoglv64.dll) once I ruled out invalid context, the possibility of wglMakeCurrent grabbing the wrong context, init failure, ... It is rather strange that only glLogicOp and none of the sync functions seem to be affected.
First I came to a different conclusion so some material I gathered as proof become worthless but for some trivia, here some disassembly (https://gist.github.com/Joefish/c300ebac0cb579334838927d8cad26ba)

The patch uses QOpenGLFunctions_3_0 to obtain an object pointer to supported GL functions instead of GLES2 compatible QOpenGLFunction + extension loading.
According to Steam, Krita needs "Modern (since 2009) graphics / Intel HD" so GL3.2 sounds like a reasonable target, even for macs (in my opinion). It would also give a clear support target (instead of GLES2 + extensions), make many checks obsolete and in this case also circumvent a bug by just getting an offset table to the desired function subset. I think to remember than QPainter depends on deprecated GL functions and that's why 3.2core can't be set by default but Nimmy's opengl branch he already uses GL3.2Core (Core probably for compatiblity with OSX) like commit dd32d5e4
So, according to KisOpenGL::setDefaultFormat 3.0 is fine and once the way is free for 3.2 we can bump it up.

Test Plan:
* Krita built with patch applied on Linux/Windows
* Open an image and see if the brush outline is XOR'd accordingly

Reviewers: Nim, dkazakov

Reviewed By: Nim, dkazakov

Subscribers: dkazakov

Differential Revision: https://phabricator.kde.org/D4506

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

make setting up the environmental variables a step before running cmake. The order was causing a bit of confusion.

Summary: The issue was that when the current document title
was changed (by using Document Information dialog for example),
its name shown in the files tab remained the same, without
being updated. I searched for the method which should update
the document name and called it.

BUG:374389

Reviewers: #krita, dkazakov
Differential Revision: https://phabricator.kde.org/D4462

Summary: The issue was that when the current document title was changed (by using Document Information dialog for example), its name shown in the files tab remained the same, without being updated. I searched for the method which should update the document name and called it.

Reviewers: #krita

Subscribers: dkazakov, woltherav

Tags: #krita

Differential Revision: https://phabricator.kde.org/D4462

Summary: use PgDn, PgUp as shortcuts to move through the invisible layers inside a group.

Test Plan: Checked by building it.

Reviewers: rempt, dkazakov

Subscribers: dkazakov, Bollebib, woltherav, #krita

Tags: #krita

Differential Revision: https://phabricator.kde.org/D4373

This reverts commit 9dba353e.

It's not possible to read our config file before the application
is constructed and also not possible to set the application
flag after the application is constructed.

Now users can set the maximum brush size to 10,000. The default is
still 1,000 -- and trust me, a 10,000 pixel diameter brush is
slow and takes a huge amount of memory.

BUG:334123
CCMAIL:kimageshop@kde.org

CCMAIL:Edgar At BrashMonkey <lucid@brashmonkey.com>

'glob' option is not available on Windows in normal ffmpeg builds.
Therefore, we should use '-start_number' instead.

Fixes T5228

This doesn't work currently because the gradient is stored in a
problematic way in the filter config:

With an absolute path, which makes the file non-portable

Could not find gradient "C:/Users/GC/AppData/Roaming/krita/gradients/kC5644.svg"

With a plain name

Could not find gradient "skin1"

Or apparently without any name, I guess for the autogenerated gradients

Could not find gradient "C:/Users/GC/AppData/Roaming/krita/gradients\\.svg"

To fix this properly, we will need to sit down and fix the resource system.

icon for preset switcher shortcut

Thanks to deevad for the proposal and icon idea, I only made a few changes to improve them.

After the option was removed in a46bc0f0, Krita would segfault at startup for me. This patch fixes that and removes other references to PACKAGERS_BUILD.

Differential Revision: https://phabricator.kde.org/D4327

This takes more time, but should guarantee that all projections are correct.

It is supremely important NOT to use i18n before the application
is created.  If i18n is called too early, like when creating a static
KoID, the translation system is initialized before we've had a chance
to add the path to the translations to the XDG_DATA_DIRS variable. Then
the translation system only sees the globally available translations,
and Krita stays untranslated.

Always use ki18n when initializing a static object with a translation.

CCMAIL:kimageshop@kde.org

Since it's static, it accesses KConfigGroup before the application
is created, which accesses the application object, which is not
possible.

The direct effects were a warning & that the config value didn't get
read.

Fixes: T3500
Differential Revision: https://phabricator.kde.org/D4022

This complicates builds, is less compatible with Eigen3 and doesn't
give a noticable performance improvement if turned off.

The default folder for save as is taken from the path of the image.

Experimental: this might break the size of the filter dialog

Editing bundles now seems to work; it will overwrite an existing
bundle, though, not save a new one. Creating new bundles now
also adds the bundle to the resource manager.