Bug 237553 - Broken keyboard behaviour with group mode.
Summary: Broken keyboard behaviour with group mode.
Status: REOPENED
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: kdeui (show other bugs)
Version: 4.4
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Rafael Fernández López
URL:
Keywords:
: 243389 262060 275269 275536 291410 329003 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-05-13 23:25 UTC by Alejandro Nova
Modified: 2013-12-19 16:32 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alejandro Nova 2010-05-13 23:25:10 UTC
Version:            (using KDE 4.4.3)
OS:                Linux
Installed from:    Fedora RPMs

When I enable the group mode in Dolphin folder view, I can't scroll, using my keyboard, to the bottom or to the top of the file list. The cursor gets stuck somewhere. Where does it get stuck depends on a) the number of files and b) the number of generated groups.

The expected behaviour, of course, is that I can scroll up and down with my keyboard arrows.
Comment 1 Alejandro Nova 2010-06-23 16:36:58 UTC
Still present, KDE 4.5 beta 2.
Comment 2 Christoph Feck 2010-07-02 00:10:59 UTC
*** Bug 243389 has been marked as a duplicate of this bug. ***
Comment 3 Christoph Feck 2011-01-04 15:51:00 UTC
*** Bug 262060 has been marked as a duplicate of this bug. ***
Comment 4 Rafael Fernández López 2011-01-04 16:27:27 UTC
Indeed, it is a feature, you can only navigate to a lower level if there is an item in the current column, same with top.

If you can draw a horizontal or vertical line from the item you are currently to the target one and they are one next to another, you should be able to navigate, otherwise you should not.

  ^
< o >
  v

Assuming "o" is your current item, you can only navigate in those four directions and assuming there is an item next to the current one.

And you may ask ? Why a feature ? In a previous version, KCategorizedView allowed to jump big heights, and by nature, there can be a really big height between elements on this view, what makes an accidental key press on arrow up or down a huge offset on the view, losing what you were navigating by mistake.

Being more restrictive made the view less error prone.

Please, if you consider this is answered I'd be happy to close this bug report.
Comment 5 S. Burmeister 2011-01-04 16:46:37 UTC
(In reply to comment #4)
> And you may ask ? Why a feature ? In a previous version, KCategorizedView
> allowed to jump big heights, and by nature, there can be a really big height
> between elements on this view, what makes an accidental key press on arrow up
> or down a huge offset on the view, losing what you were navigating by mistake.
> 
> Being more restrictive made the view less error prone.

I consider this a bug. The reason is simple. You claim that because of big heights jumping up/down is wrong.

IMHO that argument is wrong because up/down should not jump big heights but simply jump to the next row. If there is no item in the same column of the next row it has to jump to the last item in the next row.

No big heights to jump and a lot less keystrokes! Just think about the following scenario.

item 1 - 2 - 3 - 4 - 5 - 6
item 1
item 1 - 2 - 3 - 4

Now you are at row one item six and want to navigate to item four row three. That's 10 keystrokes. With this bug fixed it would be two.

Two because a proper fix would keep the "item 6" in mind and jump to the "sixth or last" item in the next row until the user presses left/right.

So this bug is still lvalid for KDE 4.6 RC1.
Comment 6 Todd 2011-01-04 17:36:16 UTC
Text editors have this same problem.  Lines of text can be very different.  They handle this by remembering what column they were in and going back when they can.

So in this scenario:

1 2 3 4 5 6 7 8 9
1 2
1
1 2 3
1 2 3 4 5 6

Let's say we were at 5 in the first row.  You press down once, you go to 2 in the second row.  You press down again, you get to 1 in the third row.  You press down again, you go to three in the fourth row.  You press down again, you are now at 5 in the fifth row.  Press left twice, you are at three in the fifth row.  Up once, 3 in the fourth row.  Up once, 1 in the third row.  Up once, 2 in the second row, up once, 3 in the first row.

This seems pretty standard for text editors, I think it would work well for categorized view as well.
Comment 7 Peter Penz 2011-01-04 17:39:26 UTC
I agree with Sven and Todd here and think having the same scrollbehavior like in text-editors would improve the situation a lot.
Comment 8 Rafael Fernández López 2011-01-04 18:01:14 UTC
Absolutely correct.
Comment 9 Alejandro Nova 2011-03-25 21:01:41 UTC
This is about two separate issues, closely related.

1. The "big heights" versus "notepad" behavior. I agree with "notepad" behavior. That's what I find in Windows Explorer, Nautilus, and in almost anything.
2. A separate bug. Sometimes, EVEN IF I AM SCROLLING IN COLUMN 1, cursor gets stuck, and I can't scroll anymore. This is evident if you have a folder with lots of groups. That's clearly a bug, even if I accept Rafael's theory.
Comment 10 Christoph Feck 2011-06-10 00:25:27 UTC
*** Bug 275269 has been marked as a duplicate of this bug. ***
Comment 11 Christoph Feck 2011-06-13 20:21:07 UTC
*** Bug 275536 has been marked as a duplicate of this bug. ***
Comment 12 Alejandro Nova 2011-11-21 13:29:04 UTC
Squashed with Dolphin 2. Thank you all!

FIXED IN KDE 4.8 BETA 1.
Comment 13 Christoph Feck 2011-11-21 23:07:23 UTC
Dolphin is fixed because it no longer uses the KCategorizedView. That doesn't mean the bug in KCategorizedView (kedlibs) is fixed. Reopening.
Comment 14 Christoph Feck 2012-02-10 18:45:03 UTC
*** Bug 291410 has been marked as a duplicate of this bug. ***
Comment 15 Kevin Funk 2013-12-11 09:10:40 UTC
Bump. This issue is still valid in KDE 4.11.3. Can't scroll via keyboard, which makes system settings unusable without mouse. Any takers?
Comment 16 Christoph Feck 2013-12-19 16:32:56 UTC
*** Bug 329003 has been marked as a duplicate of this bug. ***