Bug 313017 - Still loading passive notification appears for files in the background after they have finished loading
Summary: Still loading passive notification appears for files in the background after ...
Status: RESOLVED DUPLICATE of bug 323092
Alias: None
Product: kate
Classification: Applications
Component: part (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR minor
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-10 13:55 UTC by Nikola Kovacs
Modified: 2013-08-27 18:49 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 4.10.1


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nikola Kovacs 2013-01-10 13:55:48 UTC
If I have a bunch of files open over sftp. When I hit reload all, eventually the still loading passive notification appears. This notification disappears for the currently active file, but when I switch to another one, it appears, and only disappears after I've switched to a third file and back to the second one.

This doesn't happen with every file, only files that take longer to load and trigger the notification.

Reproducible: Always

Steps to Reproduce:
1. Open a lot of files over sftp to cause the still loading notification to appear (I'm not sure if it'll happen with local files)
2. Hit File->reload all
3. Switch to another file (if the notification is not there, keep switching until you find a file that took longer to load and triggered the notification)
Actual Results:  
The still loading notification appears

Expected Results:  
The still loading notification should not appear (if the file has finished loading)

Kate 3.9.97
Kde 4.9.97
Comment 1 Nikola Kovacs 2013-01-16 07:57:44 UTC
Also, when using split views, the notification gives them a minimum width, preventing them from being resized.
Comment 2 Christoph Feck 2013-01-23 00:19:29 UTC
For the resizing issue, please see bug 313521.
Comment 3 Dominik Haumann 2013-02-17 22:13:21 UTC
Git commit e4659ad77653189f4f5e9c8525c46e03961ffad8 by Dominik Haumann.
Committed on 17/02/2013 at 23:12.
Pushed by dhaumann into branch 'master'.

remove loading message prior to posting new one
FIXED-IN: 4.10.1

M  +1    -0    part/document/katedocument.cpp

http://commits.kde.org/kate/e4659ad77653189f4f5e9c8525c46e03961ffad8
Comment 4 Dominik Haumann 2013-02-17 22:13:50 UTC
Git commit a028c142e2fb216a69cb45b72c5d772b5e98715d by Dominik Haumann.
Committed on 17/02/2013 at 23:12.
Pushed by dhaumann into branch 'KDE/4.10'.

remove loading message prior to posting new one
FIXED-IN: 4.10.1

M  +1    -0    part/document/katedocument.cpp

http://commits.kde.org/kate/a028c142e2fb216a69cb45b72c5d772b5e98715d
Comment 5 Nikola Kovacs 2013-03-08 08:43:07 UTC
This is stil happening in Kate 3.10.1
Comment 6 Christoph Feck 2013-04-23 22:37:30 UTC
Nikola, please reopen the bug if the issue is not fixed. Maybe you might need to clarify the steps needed to reproduce.
Comment 7 Nikola Kovacs 2013-04-23 22:40:51 UTC
The steps I described in the description will reproduce the issue, always.
Comment 8 Nikola Kovacs 2013-05-07 07:27:32 UTC
I figured it out, it doesn't always happen. I have a kate session with 4 different files visible on start (ui is split into 4 views). If I load the session, the messages appear and after the files are loaded, there are no stuck messages. Then if I hid reload all, it still works perfectly. But if I switch to a file that was not visible before, and then hit reload all, the message will appear for all five files now (the four that were originally visible, plus the new one I switched to), and it will be stuck in the background for the one file that was visible before, but now isn't. If I switch back to that file (make it visible again), the message will be there, and will only disappear if I switch away and back. As I continue to use kate, I switch to different files, and it seems that after a file has been displayed once, its state changes forever, and the message can get stuck on it.
Comment 9 Dominik Haumann 2013-08-27 18:49:28 UTC

*** This bug has been marked as a duplicate of bug 323092 ***