Review Request 129061: Don't hide not yet shown messagewidgets

Emmanuel Pescosta emmanuelpescosta099 at gmail.com
Sun Oct 2 20:54:01 BST 2016



> On Sept. 28, 2016, 4:17 p.m., Fabian Vogt wrote:
> > AFAICS this approach is not correct. If directory loading takes longer than the message animation, it gets hidden for no reason.
> 
> Emmanuel Pescosta wrote:
>     I think that we should not automatically hide error messages when the directory loading has been completed, at least not with the current error message handling. I don't know why and when this audo-hiding code was added.
>     
>     IMHO hiding error messages only makes sense if we know what kind of error message we hide. But this isn't possible with `KMessageWidget` ATM as far as I know. This would require additional information for each error message (e.g. an enum value like `DirectoryLoadingFailed`, `PastingFailed`, ...) which can then be used for hiding the error message e.g. when reload (call hide with `DirectoryLoadingFailed` and if a message of this type is shown it will be hidden) or another paste action (call hide with `PastingFailed` and if a message of this type is shown it will be hidden) succeeded.
> 
> Elvis Angelaccio wrote:
>     Well I guess it was added in order to "clean" the view upon pressing F5 (which imho is a good feature, I think I used it more than once).
>     
>     What about using a boolean flag to store whether the message widget has been shown? KMessageWidget has a showAnimationFinished signal which should do the trick.
> 
> Fabian Vogt wrote:
>     > Well I guess it was added in order to "clean" the view upon pressing F5 (which imho is a good feature, I think I used it more than once).
>     
>     In this case I would say the correct fix is to only hide messages when pressing F5 and not when the refresh was triggered by KDirNotify.
> 
> Elvis Angelaccio wrote:
>     Yeah we could that. It probably requires a boolean in DolphinViewContainer and a signal "reloadTriggered" in DolphinView, to keep track of the trigger event. Emmanuel? Do you prefer this way or the "enum-based message hiding" that you were talking about?

> Do you prefer this way or the "enum-based message hiding" that you were talking about?

No it was just an idea for "context sensitive" message hiding ;)

The easiest solution would be to add a `reload` method to `DolphinViewContainer`. This method should invoke `view()->reload()` and hide the message widget of the container. We can then use this method in `DolphinMainWindow::reloadView()`. 

What do you think?


- Emmanuel


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129061/#review99631
-----------------------------------------------------------


On Sept. 28, 2016, 4:14 p.m., Elvis Angelaccio wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129061/
> -----------------------------------------------------------
> 
> (Updated Sept. 28, 2016, 4:14 p.m.)
> 
> 
> Review request for Dolphin.
> 
> 
> Bugs: 357651
>     https://bugs.kde.org/show_bug.cgi?id=357651
> 
> 
> Repository: dolphin
> 
> 
> Description
> -------
> 
> Bug #357651 results in a messagewidget that gets hidden before it's even shown. Since we already have a slot connected to the `directoryLoadingCompleted()` signal, we can use to it to check whether the message widget has finished the animated show (instead of connecting this signal to `KMessageWidget::hide`).
> 
> 
> Diffs
> -----
> 
>   src/dolphinviewcontainer.cpp 1c43fc9 
> 
> Diff: https://git.reviewboard.kde.org/r/129061/diff/
> 
> 
> Testing
> -------
> 
> The messagewidget from bug #357651 is now visible. Refreshing the view still hides a visible messagewidget.
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20161002/fa3aae69/attachment.htm>


More information about the kfm-devel mailing list