| Summary: | Broken keyboard behaviour with group mode. | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | Alejandro Nova <alejandronova> |
| Component: | kdeui | Assignee: | Rafael Fernández López <ereslibre> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | CC: | amic, cfeck, denis.prost, dev+kde, kaabud-kde, kde.uat, kfunk, peter.penz19, skierpage, sven.burmeister, toddrme2178 |
| Priority: | HI | ||
| Version: | 4.4 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Alejandro Nova
2010-05-13 23:25:10 UTC
Still present, KDE 4.5 beta 2. *** Bug 243389 has been marked as a duplicate of this bug. *** *** Bug 262060 has been marked as a duplicate of this bug. *** 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. (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. 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. I agree with Sven and Todd here and think having the same scrollbehavior like in text-editors would improve the situation a lot. Absolutely correct. 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. *** Bug 275269 has been marked as a duplicate of this bug. *** *** Bug 275536 has been marked as a duplicate of this bug. *** Squashed with Dolphin 2. Thank you all! FIXED IN KDE 4.8 BETA 1. Dolphin is fixed because it no longer uses the KCategorizedView. That doesn't mean the bug in KCategorizedView (kedlibs) is fixed. Reopening. *** Bug 291410 has been marked as a duplicate of this bug. *** 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? *** Bug 329003 has been marked as a duplicate of this bug. *** Hi, kdelibs (version 4 and earlier) is no longer maintained since a few years. KDE Frameworks 5 or 6 might already have resolved this bug. If not, please re-open against the matching framework if feasible or against the application that shows the issue. We then can still dispatch it to the right Bugzilla product or component. Greetings Christoph Cullmann |