Review Request: Proposal to add a 'lock toggle button' to filter bar to prevent clearing of filter when navigating to a different folder

Stuart Citrin ctrn3e8 at gmail.com
Sat Nov 24 01:29:01 GMT 2012


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107392/#review22451
-----------------------------------------------------------


1. coding standards compliance:
    For the next patch file I submit, I will make coding standards corrections and clean up the slop.

2. Issue of  "I'm wondering if the 'lock' button has the potential to confuse users....." etc.:

    First...disclaimer: I do not claim  to be a usability (or HCI) expert...I  write code(occasionally) and that makes me one of the worst to have an objective viewpoint...but I will state the following.  There are probably people out there who have no idea what "that filter bar thing" is supposed to do.  I can think of certain family members and know that they would never, without being shown and explained, understand how to use it.  My assumption is, if someone understands and is able to use the filter  bar, they will figure out what that little lock button is for.   Having said that, tool-tip text  is provided and is currently set to "Keep Filter When Changing Folders". Therefore, (beating this to death), if someone hovers their mouse over the button, they will see the said explanation, and then know what it's for.  (Of course, they need to know enough to actually hover the mouse over the button ).

I, personally, do not think the filter text should ever be persistent between visibility cycles of the filter bar.  If the filter bar is ever hidden,  then the text should be cleared. If the user hides the filter bar or kills the application, the assumption should be that they are done using  that particular filter.  Otherwise, they are always forced to clear the previous filter text when restoring the filter bar.   For the case where they want to restore previous text, they can always put it on the clipboard, or on  Parcellite or Klipper and then retrieve it.  Yes, I understand, under some circumstances, it would be useful to toggle a particular filter on and off, but this would be an outlier case. Converting the edit control in the filter bar to a dropdown combobox which stores, for example, the last five filters used may be one idea to cover this use case.  However, for the latter, I think it starts to be maybe a little too much of a modification.  When I wrote the patch, I really tried to keep it relatively unobtrusive in terms of changing the user experience and in terms of modifying the actual code.


3. "This also fixes a current bug in dolphin where one is unable to toggle"...and  https://bugs.kde.org/show_bug.cgi?id=215138:

The change I made (which actually was to revert the code to the way it had been), re-enables the toggle behavior of the"show filter"  button on the application toolbar. The stated bug complains about the non-persistence of the filter bar state when re-launching the application.

This is a little confusing.  First of all,  the stated bug refers to the fact that there is non-persistence of the visibility state of the filter bar when closing and restarting Dolphin.  This has probably always been the case.  The visibility of the bar on startup is configured  (I just discovered) by Settings->ConfigureDolphin->Startup->ShowFilterBar(checkbox) and is independent of the visibility state when the application had last been closed.

The change I made was to restore the toggle behavior of the "Show Filter Bar" toggle button on the application tool bar.  Previous (as in 2010 and probably some time before and thereafter) to cycle through showing or hiding the filter bar, one could click this button repeatedly.  You could also toggle the visibility by the default short cut key of Ctl-I....which still works for show, but not for hide in the current released version.  Somewhere the behavior was changed from 'toggle' to just 'show'.   Thus in its current form, to cycle through showing/hiding the filter bar (with mouse) one clicks on the tool bar button(top of application) to show the filter bar and then clicks on the red 'X' next to the filter bar(bottom of application) to hide it.  There is no keyboard shortcut (which I know of ) which is capable of hiding the filter bar.

It is not clear to me why the behavior was changed to the current behavior.  Perhaps someone felt the word 'Show' on the toggle button was confusing, when the button action  would alternate between 'Show' and 'Hide".  Admittingly, this really is a separate issue from locking the text,  and I should have not messed with it.  On the next patch I submit, I will revert it to how it is in the current git master....unless a consensus is reached to put it back as a toggle.




- Stuart Citrin


On Nov. 20, 2012, 5:16 a.m., Stuart Citrin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107392/
> -----------------------------------------------------------
> 
> (Updated Nov. 20, 2012, 5:16 a.m.)
> 
> 
> Review request for Dolphin.
> 
> 
> Description
> -------
> 
> I wrote a quick add-on for the Dolphin filter bar.   It is a button which prevents the filter text from clearing when navigating to a different folder. 
> 
> Why this might be needed:
> 
> This is an attempt to resolve the following usability conflict: 
> 
> If one navigates to a different folder, the filter is automatically cleared since one does not want a situation where someone forgets a filter is applied and then doesn't understand why all the files within a folder are not appearing.(current behavior) 
> versus: 
> A user might want to keep a filter while navigating an arbitrary set of folders, but is unable to, since the filter is automatically cleared upon navigation 
> 
> The implementation to try to resolve this conflict is as follows: 
> 
> 1. A lock filter toggle button is added to the right side of the filter bar. 
> 2. If the lock filter button is clicked(on), then if the user navigates away from the current folder, the filter is not cleared. If the lock filter button is released(off), then the text is cleared on navigation...which is the current behavior. 
> 3. A configurable shortcut is added to toggle the lock filter button, with the default being Ctrl-Shift-I (since the default shortcut for hiding and showing the filter bar is Ctrl-I.) 
> 4. If the user toggles the lock filter button to released (off), then the text in the filter also clears. The assumption here is that if the user no longer wants the text to be locked, he probably also wants to clear the text.
>  5. When the filter bar is hidden, then the lock filter button is released. The next time the filter bar is shown, the lock filter button will be in the released(off) position and the filter text will have been cleared. 
> 6. At application startup, the lock filter button is always off, and the filter bar text cleared. 
> 
> This also fixes a current bug in dolphin where one is unable to toggle the visibility of the filter bar using the tool bar filter button, or by using the assigned hot key.
> 
> Note... I think it is 'patch -p2' from the "dolphin" directory (above src directory ) to apply the patch
> 
> 
> Diffs
> -----
> 
>   dolphin/src/dolphinmainwindow.h 7da5801 
>   dolphin/src/dolphinmainwindow.cpp 11e03d0 
>   dolphin/src/dolphinviewcontainer.h 0300273 
>   dolphin/src/dolphinviewcontainer.cpp 6e99437 
>   dolphin/src/filterbar/filterbar.h 9546c63 
>   dolphin/src/filterbar/filterbar.cpp f3076f0 
> 
> Diff: http://git.reviewboard.kde.org/r/107392/diff/
> 
> 
> Testing
> -------
> 
> Went through all paths in dolphin.  Tested: 1. Navigate to different folder. Text should clear only when text not locked
> 2.Ctl-I shortcut to toggle visiblility of filterbar
> 3.Text clears when filterbar hidden and then shown
> 4. Lock button locks and unlocks text
> 5. Shift-Ctl-I shortcut to toggle lock status of text.  Lock button updates appropriately
> 6. Status (with non-perisistence from previous instance) of lock button when starting application..i.e. lock status is off on startup
> 7. Change keyboard shortcuts...works appropriately
> 8. F3 and split view..tabs..etc.. should still work appropriately
> 9. Monkey tested...cannot get it to crash
> etc....
> 
> 
> Thanks,
> 
> Stuart Citrin
> 
>

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


More information about the kfm-devel mailing list