Bug 402625

Created attachment 117159 [details]
Comment-1 additional notes

The observation by the bug OP is just one of a general range of problems that krita has when asked/forced to open a file that it does not have input support for.

To avoid a long comment box here, I've made a text file that notes my observations and attached it.

Note: The existence (or not) of a suitable ffmpeg installation would not be significant because ffmpeg is only used for the output/creation of a video file during Rendering of an animation.

> The observation by the bug OP is just one of a general range of problems
> that krita has when asked/forced to open a file that it does not have input
> support for.


The problem isn't that Krita can't support the files. The problem is that the dialog box saying that keeps coming back shortly after I hit OK.

Also, I think I made a slight mistake on my version of Windows. I think it's 1809, not 1803.

(In reply to Tristan Y. from comment #3)

> The problem isn't that Krita can't support the files. The problem is that
> the dialog box saying that keeps coming back shortly after I hit OK.

Actually, never mind this, sorry

Tristan: Um, doesn't this happen then? 

Ahab: long comments are fine in bugzilla.

(In reply to Boudewijn Rempt from comment #5)
> Tristan: Um, doesn't this happen then? 
> 
> Ahab: long comments are fine in bugzilla.

It does happen but I'm just saying stuff I thought you already knew so that why I said never mind, sorry for any confusion over that

How did you load the file in. The File > New dialog won't even let me pick an unsupported file. 

The only way I could figure out how to load any file was to drag it on the canvas from the desktop. I used another video format, MKV, but the error only shows up once.

Scott: My attached notes in Comment 1 describe several ways to get krita to try to open a file that it deoesn't support. I'm sorry for making them obscure - I won't do that again.

Setting this confirmed.

Git commit 52ee93a924365b5af795a913b038303a7f8ea46a by Agata Cacko.
Committed on 11/03/2019 at 18:18.
Pushed by tymond into branch 'master'.

Fix loading wrong file format (progress bar + recent docs)

Summary:
Before this patch, when you forced Krita to load file in
unknown format, it showed uncancelled progress bar and
showed the file in Recent Documents.
It happened when you dragged and dropped file to the
welcome screen or import animation frames or use Open->File
or Open -> Recent Files.
Progress bars were visible only when some image was opened.
This commit cancels progress bars and make sure unloadable
files are not added to Recent Documents.

Test Plan:
1. Create an unloadable file. Can be "touch a".
2. Load it using one of the ways mentioned above
3. After loading, there is an error message. Click ok.
4. If you used Import Animation Frames, look at the bottom
of Krita window.
- before: progress bar still "loading"
- now: no progress bar visible
5. If you used other option, create a new file or open
something else, and you'll see the same effect.
6. Look at Recent Documents.
- before: unloadable file added to list
- now: no unloadable file added to list
(beside the ones that were aleady there after testing)

Reviewers: #krita, rempt

Reviewed By: #krita, rempt

Tags: #krita

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

M  +14   -7    libs/ui/KisDocument.cpp

https://commits.kde.org/krita/52ee93a924365b5af795a913b038303a7f8ea46a

I've just tried the 4.2.0-pre-alpha (git 3805574) appimage and noted the following situation where a continuous loading progress bar is shown, can not be cancelled, reappears after Close then New/Open(valid file) and then can only be got rid of by a Quit and restart of krita:-

File -> Import animation frames, Add Images then select an animated .gif file or a .kra file, from the list of displayed files of the type 'All supported formats'.

If you try to force the importing from a .mp4, .mkv etc file then an appropriate error message is shown with no bad consequences.


Also, if you try to Open an animated .gif file, you get a single paint layer which has a colour distorted version of one of the frames of that animated .gif and the file appears in the Recent Documents list. This may be a separate issue from the main purpose of this commit.

The attempted Opening of various other types of non-supported files seems to have been fixed.
I have not tested the Windows version because it's not ready yet.

Git commit 06fbeb808625da5eabe8cafa64cb6159f9e37a7a by Agata Cacko.
Committed on 19/03/2019 at 20:06.
Pushed by tymond into branch 'master'.

Fix infinite progress bar on import animation frames

Before this patch, when you tried to import one picture
using Import Animation Frames feature, there was an infinite
progress bar that was not possible to get rid of.
This commit fixes that behaviour (progress bar fills itself
and disappear when the image is loaded).

Tests:
- import one .png file
- import one .gif file
- import one .kra file
- import multiple .png files

M  +2    -2    libs/ui/kis_animation_importer.cpp

https://commits.kde.org/krita/06fbeb808625da5eabe8cafa64cb6159f9e37a7a

The bug report is closed now because:

- there were three issues, all fixed:
  (a) adding unloadable files to Recent Documents
  (b) loading unloadable file by Import Animation Frames created infinite progress bar
  (c) loading one file using Import Animation Frames created infinite progress bar (no change in behaviour depending on whether it was .kra, .gif or .png file)
All of them are fixes now.

- whether .gif or .kra files should be loaded as animation frames, is down for discussion. Note: you can export image sequence as .kra or .gif files. Makes sense to be able to import it as well.

- animated .gif file is loaded the same way (aka looks "corrupted") when loaded using File -> Open as it is loaded using Import Animation Frames. I think it is because it is opened with the assumption of not being animated. When you open the same file in Gimp and hide some layers, the image looks "corrupted" as well. So I think it just shows the first frame instead of merging all of it to get a nice picture. It is a different issue anyway and should be in a different bug report, possibly as a feature request, not a bug.