Just a reminder since it's easy to forget it exists: Holding ctrl+alt+shift when Krita is starting up will ask the user if they wish to clear Krita's settings file. This feature was originally implemented to help reset a config file that causes Krita to crash. The function responsible for this is KisApplication::askClearConfig() and KisApplication::clearConfig(). The caveat is that the functions have to be called before the config has been loaded.

In D18708#405077, @rbreu wrote:

I've already added a flake8 config and instructions to run it, and my plan was to squash the flake8 warnings bit by bit and have a bit of an eye on the code, and bring up any issues worth discussing as I find them, such as right now the line lengths (and keep notes for documenting the stuff).

Krita doesn't have any formal style guides yet. I added T6588 to address this, although it's not likely to get much further unless we sit down and figure out what's important and what works for Krita.

Committed: https://phabricator.kde.org/R37:08968e7b66ea49ef21ebfee96aaf3b5eb38b3deb

Looking at the code base, there are two steps that should be taken before any radical change occurs:

I've added the necessary build scripts for building a designer plugin collection, including plugins for KisColorSpaceSelector and KisGradientSlider. You can toggle building of the plugin collection with

Note that I've only tested this under Linux (Ubuntu 17.10). There are quite a few gotchas for Windows, which requires that the plugin is compiled under similar conditions as Qt Designer itself. See https://doc.qt.io/qtcreator/adding-plugins.html#matching-build-keys

I wrote an initial implementation for two widgets as a test.

This has already been pushed in 80af6093bad5847fe3681e4715f7ab8b683b2a6a (2017-08-04)

In T6588#121427, @brendanbd wrote:

There should be guidelines about where scripts ought to persist their data.

Good point. Do you have any actual use-cases in mind?

In D7878#147005, @bcooksley wrote:

The usage of try/except blocks in this case is deliberate and intentional to ensure that any errors in a given entry don't break the script entirely but just cause that entry to fail.

In D7441#140672, @alvinhochun wrote:

Fixed the incorrect localPos calculation.

New build: https://drive.google.com/open?id=0B1i7Q5Isuy2JeTJpczNvRHV4MlE

I tested this on my Surface Pro 2 (Wacom) to see if there were any regressions. For me it looks like the Win8+ "Pointer Input Message" produces jitter compared to the wintab version. I've attached an image of two reasonably straight lines, drawn in two instances of the 4.0-prealpha_winink build. The first one with the Win8+ Pointer Input Message support enabled, the second without. I merged the images to show the difference (top: "winink", bottom: "wintab"):

I ran autopep8.py on the entire code base as an experiment, and there is one set of PEP8 rules which I'm a bit torn about: The spacing after commas and operators. If it's followed, then

You may wish to backport the following commits from master. They should all merge cleanly in the following order:

• Added importConfiguration helper functions to KisConfig that mimics exportConfiguration, but with a different tag
• Remember endianness for import and export heightmap dialog separately, per mime type
• Use KisSequentialConstIterator when exporting data

In D6460#122056, @dkazakov wrote:

The patch looks fine. Though I'd suggest two small fixes to make UIX more obvious:

1. When importing and exporting set endianness to the default endianness of the currently running system. Or at least save the last used value and reuse it next time. Right now the UIX is not very smooth:
   1. User saves .r16 map in big-endian mode
   2. User opens the file, the dialog suggests him that the file is little-endian (not nice, but okay)
   3. User opens the same file again, and the dialog suggests him that the file is little-endian again (already not okay, can make people furious :) )

Updated screenshot of import dialog:

• Removed references of PC and Mac from the UI.
• Added standard file diff unit tests (disabled because the function is broken?)

In D6460#121238, @rempt wrote:

Can the endianness still really be described by PC vs Mac? Mac have been x86 for ages now.

Screenshot of the new import dialog: