GitLab

The messing with relative paths to the default folder meant that
the user never could be sure which path we were going to save to.

Rendering to GIF still fails, though, but I need more brain to
figure out why.

CCBUG:372572,372537

Waiting for the moment when Q_OS_OSX gets deprecated for Q_OS_MACOS...

It's not relevant for krita and was only used in the pdf export
code, which is now also simplified, because there was no reason
to have it split up into two functions.

Loading is no longer asynchronous (we don't download something
from a remote url anymore), so this flag doesn't make sense
anymore.

Qt 5.6 has fixed the bug for which this reverted commit was
a hacky fix; the hacky fix caused problems for kwin because
we first show, then position the main window.

BUG:371568

Revert "Fix wrong positioning of children/popup widgets"

This reverts commit ceff0e24.

Sometimes, if the dialog would open by default on a template
page, and you'd create an image from a template, the dialog
and pane would be deleted too early. We said, when creating
the slots, that deleteLater would be used to delete the dialog,
but we didn't do that... Now we do.

Sometimes, if the dialog would open by default on a template
page, and you'd create an image from a template, the dialog
and pane would be deleted too early. We said, when creating
the slots, that deleteLater would be used to delete the dialog,
but we didn't do that... Now we do.

This makes refactoring easier since the compiler detects renames.

The recent files list system deletes the QUrl object, so make
an explicit copy of it before passing it on to the rest of Krita.

It's also connected in KisViewManager

Fine for office suites, for Krita we need something a bit more
effective.

This wasn't used in Krita -- it was meant for flat xml files,
ODF directories or encrypted files.

Fixes T3351
BUG:365992

BUG:366102

D2237 Diff 5364 (corrected by dkazakov)

Render to Animation can now do everything this action did.

Summary:
Menus on top of fullscreen OpenGL windows were not visible.

There's a bunch of finger pointing with Qt saying Windows' OpenGL
implementation is broken. A workaround is added in Qt 5.6.
http://doc.qt.io/qt-5/windows-issues.html

Fullscreen on Windows will then add a 1px border around the window by
default. This can be worked around by patching Qt.
https://bugreports.qt.io/browse/QTBUG-41309

Reviewers: #krita:_next

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

Fixes the initialisation of the option widget docker/popup

BUG:364022

Summary:
Menus on top of fullscreen OpenGL windows were not visible.

There's a bunch of finger pointing with Qt saying Windows' OpenGL
implementation is broken. A workaround is added in Qt 5.6.
http://doc.qt.io/qt-5/windows-issues.html

Fullscreen on Windows will then add a 1px border around the window by
default. This can be worked around by patching Qt.
https://bugreports.qt.io/browse/QTBUG-41309

Reviewers: #krita:_next

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

Fixes the initialisation of the option widget docker/popup

BUG:364022

On Windows, Qt5 cannot draw menus if the window is full-screen
and there's an opengl widget active. Todo: make a small demo
applet and report the bug in Qt's bug tracker...

The Qt file dialog api confuses "filters" with selected file
type, making this trickier than needed.

Otherwise Qt's file dialog will, for some weird reason, automatically
select the first extension of the first entry in the filter combobox
for the file, making sure that you'd save any file as .exr.

When we set the canvas on all dockers _before_ the canvas is
visible, the opengl context is not yet current. If that's the
case, the lut docker will try to update the image textures, but
fail because there's no context.

1) Deny double entry into the saving process
2) Don't try to save if the user has closed the waiting
   progress dialog. Otherwise it may cause a crash.
3) Make the saving progress bar modal. Otherwise it hides behind
   Krita window and the user sees a locked-up canvas.

Fixes T2430
BUG:362675

In Qt 5.5.1 the "change screen" events do not arrive to the widgets
until they are shown on screen and fully initialized. Therefore, if
we initialize geometry of the main window too early, it will be assigned
with a wrong screen and all the child/popup widgets will start
appearing of a different monitor. In Qt 5.6.0 this problem is resolved,
and you can move the window as much as you like even before showing it.

Fixes T2482
BUG:362025