[KDE Usability] Review Request 123658: If double-click is on empty area, then invoke back.

[Thomas Pfeiffer]

> On May 6, 2015, 8:17 p.m., andreas kainz wrote:
> > Hi I made a bug report about this behavior because it is the only missing feature in dolphin. and my bug report was a duplicate. so also other users want this feature.
> > 
> > I know it from qttabbar an qt extension for the windows explorer (file manager). feel free to test it there.
> > 
> > why I think it was a realy good feature:
> > - because you can navigate with the mouse in the main window without using buttons or the keyboard
> > - it's fast
> > 
> > I never had problems with qttabbar that I change the folder when I would select an file but maybe you can offer this feature only in areas where there are realy no folders/files. most of the time you have less files in an folder that it would be no problem to click in an empty area.
> > 
> > please add this feature. at least optional with an setting.
> 
> Martin Klapetek wrote:
>     Fwiw, should this feature get in, it also must get into the file dialogs (KFileDialog) so that those are consistent.
> 
> Frank Reininghaus wrote:
>     I agree with Martin - file manager and file dialog should aim to provide similar functionality and similar workflows to the user.
>     
>     I strongly object the idea to add a setting for this. New settings make the settings dialog harder to use and the code harder to maintain. Therefore, we must ask ourselves if there would be a good reason for disabling the feature. Ideally, users who do not want to use the feature would simply not double-click on the empty area, and if the feature did not have any other effects, then it simply would not matter to them if the feature exists or not - no setting needed :-)
>     
>     As far as I can see, the only valid reason for allowing the user to disable the feature is to work around the "double click on a folder" bug that Ashish mentioned. But adding a setting is never the right way to work around bugs. The correct solution is to fix the bug.

I fully agree with Frank: A setting only makes sense if a feature is preferable to have for some, but preferable to not have for others. Since double-clicking on an empty space doesn't do anything normally, those who do not use this new feature should not feel any drawbacks.

If it turns out to happen oftent hat people accidentally double-click on an empty area when in fact they wanted to click a file or folder, then we have to make the hit areas for files and folders bigger, instead of adding an option for this feature, because regardless of whether someone uses the feature or not, accidentally triggering it is never good.


- Thomas


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


On May 6, 2015, 7:41 p.m., Ashish Bansal wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123658/
> -----------------------------------------------------------
> 
> (Updated May 6, 2015, 7:41 p.m.)
> 
> 
> Review request for Dolphin, KDE Usability and Emmanuel Pescosta.
> 
> 
> Bugs: 307505
>     https://bugs.kde.org/show_bug.cgi?id=307505
> 
> 
> Repository: dolphin
> 
> 
> Description
> -------
> 
> If mouse double click is done on the empty area, then invoke the go back to previous directory in the history.
> 
> 
> Diffs
> -----
> 
>   src/kitemviews/kitemlistcontroller.h b8a93ed 
>   src/kitemviews/kitemlistcontroller.cpp 1c86ff0 
>   src/views/dolphinview.cpp d302358 
> 
> Diff: https://git.reviewboard.kde.org/r/123658/diff/
> 
> 
> Testing
> -------
> 
> Doesn't works sometimes.
> 
> 
> Thanks,
> 
> Ashish Bansal
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20150510/e6fc2ca9/attachment.htm>
-------------- next part --------------
_______________________________________________
kde-usability mailing list
kde-usability at kde.org
https://mail.kde.org/mailman/listinfo/kde-usability