GitLab

Summary:
I'm not sure whether this has any material impact.

http://blog.qt.io/blog/2007/08/09/qt-invaded-by-aliens-the-end-of-all-flicker/

Reviewers: rempt, #krita:_next

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

Summary:
- Port shortcut scheme file search to KoResourcePaths
  Also prettify the shortcut scheme options

- Update comments+indentation in KisShortcutsEditor

- Restore changeShortcutScheme()

- Move shortcut schemes work from XMLGUI to KisActionRegistry.

- Define behavior of custom shortcuts vs. shortcut schemes
  kritashortcutsrc now contains only custom shortcuts. Shortcut schemes
  files are loaded separately and go in share/krita/shortcuts/

- Add empty (for now) directory for shortcut schemes
  This directory is where the shortcut editor will look for scheme files.

Reviewers: #krita:_next

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

kritashortcutsrc now contains only custom shortcuts. Shortcut schemes
files are loaded separately and go in share/krita/shortcuts/

Move shortcut schemes work from XMLGUI to KisActionRegistry.

Also prettify the shortcut scheme options

The strategy so far: first, attempt to use our own handler. If that
fails, send the event through the QPA subsystem. This means tablet
events get constructed and rejected twice, but it doesn't seem harmful.

This will make it easier to track the deltas.

Low level APIs are just the worst, urgh

After we get a tablet event, we'll ignore five mouse events. Easy!

Basically, merging Qt's qwindowstabletsupport.h into Krita.

I have only tested this with a modified version of Qt. I comment out
 the following line in QWindowsContext::QWindowsContext():

// d->m_tabletSupport.reset(QWindowsTabletSupport::create());

this is found at line 347 of qwindowcontext.cpp in my local copy.

The reasoning behind that change is as follows. Qt creates a hidden
dummy window to receive tablet events. I do not want to worry about
conflicting tablet contexts, so I disabled Qt's extra window.

Enable GUI sync event compressor by default

There was only one toolbox implementation left, so no need for a
registry. This also removes the nextStep signal, so it doesn't need
to be QObject anymore (that wasn't used since 2008 either).

Maybe we should set it once and for all in main.cc...

Summary:
This prevents accidental creation of multiple images when creating the image is slower than clicking (i can easily get five images open by clicking fast). for some reason, opening multiple images like this also causes an assertion to fire:

ASSERT (krita): "m_dummiesMap.contains(node)" in file /home/timo/kde4/src/krita/krita/ui/flake/kis_node_dummies_graph.cpp, line 187

With this patch it's no longer possible to create multiple new files "in parallel"

Reviewers: rempt, abrahams

Reviewed By: abrahams

Subscribers: rempt

Projects: #krita:_next

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

Summary:
In the availability widget for instant preview, the tooltip doesn't actually show items as a list. when there's multiple items, the words aren't even separated by spaces.

this patch turns the limiters or blockers into a bulleted list.

Reviewers: #krita:_next, abrahams

Reviewed By: #krita:_next, abrahams

Subscribers: abrahams, rempt

Projects: #krita:_next

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

We need to know the name of an icon to switch between light and dark,
but iconName is only filled if the icon is loaded from a theme. Which
we don't do, because we load the icons from a qrc file. And there's
no setIconName, for whatever reason. So, use the cachekey to keep track
of the mapping.

It is, technically, but if g1.0 is saved without a profile, all
other applications will be confused.

Sometimes these become user-facing so it is better to clean them first.

no need to have external code access the API

hide the number input for onion skinning. I do not think we need that much control and it makes the UI a bit cluttered.