Review Request: Mouse wheel interaction with breadcrumb-style address bar
Todd
toddrme2178 at gmail.com
Mon Dec 7 16:35:52 GMT 2009
> On 2009-12-06 13:29:11, Peter Penz wrote:
> > Thanks Todd for the patch. I think the "iterate through directories"-feature with the mouse-wheel is very useful. I'm unsure regarding the "go-up" feature. I'd consider this as contra productive: assuming your mouse is focused above the viewport and you scroll left/right; a minor moving of the mouse upwards to the URL navigator will result in (most probably unintended) going up some directories... So IMO this part of the feature should be skipped.
> >
> > I'm not 100 % happy that currently there is quite a lot of code needed for this kind of feature (but this is not your fault). The code overlaps a lot with the "show the subdirectories as list" feature. For KDE 4.5 I've planned to do some cleanups in the KUrlNavigator & Co (the current code is still quite 1:1 to an early KDE 4.0 version that has been ported from early days of Dolphin code). One minor detail is that KUrlNavigatorButton won't have any dependency anymore to KUrlNavigator (this cyclic dependency is not nice and makes it unclear which class is responsible for what task).
> >
> > So I'd suggest that we "park" this feature until I did some internal refactoring for the KUrlNavigator classes. I'd be open to port your patch then to the refactored code. Would this be OK for you?
>
> Todd wrote:
> For the go up, it seems pretty useful to me (much easier than an "up" button), but I could change it so you have to be over a folder to do it rather than anywhere on the address bar.
>
> It is fine for me to wait, but I should point out this is only one of several features I was planning on implementing for the breadcrumb bar. I was also planning on implementing middle click to open as tabs, changing which 100 folders are shown if there are too many directories, and optional recursive navigation. Should I go ahead and implement these so you can take them into account when doing the refactoring, or should I wait until the refactoring is done?
>
> Peter Penz wrote:
> Regarding the go-up: What I don't like in the approach is that "scroll-left" and "scroll-right" trigger the same action: "go-up". This does not feel natural to me... It is also not obvious how to undo this action if it is triggered per accident. Wouldn't it make more sense to implement a "go-forward"/"go-backward" in history with the horizontal scroll wheel?
>
> Regarding the other features: Please wait until the refactoring has been done. Also please contact me in advance before investigating too much time and work into a feature, so that we can discuss whether this feature should go in at all.
> - middle click to open tabs: I agree, this would be fine.
> - which 100 folders are shown: Please let's discuss this outside the scope of this review. I'm interested how you want to solve this, but it requires quite some discussions I think...
> - optional recursive navigation: I don't think this needs to be optional, just having it is good. But it requires quite some work, as drag & drop and middle-click must be implemented too in this case ("all or nothing" ;-))
>
> I've added all your suggested features as note to my KUrlNavigator-refactoring issue, so that I make the integration of those things as easy as possible. Should I contact you as soon as I've finished the refactoring?
Sure, let me know when it is done and we can talk more.
- Todd
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2330/#review3383
-----------------------------------------------------------
On 2009-12-06 08:11:18, Todd wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2330/
> -----------------------------------------------------------
>
> (Updated 2009-12-06 08:11:18)
>
>
> Review request for Dolphin and kdelibs.
>
>
> Summary
> -------
>
> This patch allows mouse wheel interaction with the breadcrumb (not editable) address bar used in programs like Dolphin. Currently this version of the address bar does not have any mouse wheel interaction, so this patch does not interfere with existing functionality.
>
> There are two different interactions supported:
>
> First, when the vertical mouse wheel (any normal mouse wheel) is used on one of the folders, it moves through the folders in the same level in alphabetical order. So say you have a folder in your Home directory named "test", with 5 sub-folders, folder1, folder2, folder3, folder4, and folder5. You are currently in folder3. If you put your mouse over the folder3 entry in the address bar and rotate your mouse wheel down by one notch, you will switch to folder4. If you rotate your mouse wheel up by one notch, you will move to folder2. Move down and up by 2 (or more, in this case) notches moves you to folder5 and folder1, respectively. While in any of these folders, using your mouse wheel on the "test" folder entry will cycle through the other subfolders in your Home directory (since those folders are at the same level as test). When you reach the first or last folder in the directory further mouse wheel activity in that direction does nothing.
>
> The second functionality is provided when doing a horizontal scroll (generally alt+wheel) anywhere on the breadcrumb-style address bar. In this case, rotating the wheel by one notch in either direction moves you up one directory. In other words, holding alt and rotating the mouse wheel by one notch is equivalent to hitting the "Up" toolbar button once.
>
> This patch does not change the mouse wheel behavior of the traditional text-based (editable) address bar.
>
> I know this won't make it in before 4.5.
>
>
> Diffs
> -----
>
> /trunk/KDE/kdelibs/kfile/kurlnavigator.h 1058639
> /trunk/KDE/kdelibs/kfile/kurlnavigator.cpp 1058639
> /trunk/KDE/kdelibs/kfile/kurlnavigatorbutton.cpp 1058639
> /trunk/KDE/kdelibs/kfile/kurlnavigatorbutton_p.h 1058639
>
> Diff: http://reviewboard.kde.org/r/2330/diff
>
>
> Testing
> -------
>
>
> Thanks,
>
> Todd
>
>
More information about the kde-core-devel
mailing list