Bug 79370 - QListView Bug on KeyDown under special conditions
Summary: QListView Bug on KeyDown under special conditions
Status: RESOLVED WORKSFORME
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: 3.2.1
Platform: unspecified All
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
: 93140 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-04-10 12:07 UTC by usa
Modified: 2008-08-25 22:40 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
The testcase for described bug (4.00 KB, application/x-designer)
2004-11-05 16:05 UTC, Daniel Molkentin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description usa 2004-04-10 12:07:17 UTC
Version:           3.2.1 (using KDE 3.2.1, SuSE)
Compiler:          gcc version 3.3.1 (SuSE Linux)
OS:          Linux (i686) release 2.6.4

keyboard navigation in konquerors multi-column-view wiht a lot of bugs.

Example:
You have a column like this:

aaaaaaaaaaaaaaa...
bbb
ccccccccccccccc...

1st and 3rd name are shortened in the view because of the length (as it should be).

You have selected 1st file, it is focused. If you now press the down arrow you would expect that bbb (with shorter filename) gets the focus/is selected. But that doesn't happen. ccc.. gets the focus.
Comment 1 David Sibai 2004-05-16 16:37:30 UTC
Still there in 3.2.2, debian testing/unstable, kernel 2.6.6, gcc 3.3.3.
Same problem with icon view as well.

To reproduce (multicolumn and icon): 
 1. Create an empty folder, say ~/test 
 2. get into that folder, and create files with names a,b, and 
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa : 
 touch a b aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa   
 3. Make sure you're in multicolumn view. Press the up/down arrow keys, the file with the very long name is skipped every time. 
 4. Switch to icon view, set icon size so small (it won't work otherwise) press the left/right arrow keys: same problem
Comment 2 Ahmed Kamal 2004-07-11 11:27:36 UTC
This bug has been there since prolly kde2. It's killing me as I always use multicolumn view (with smallest icons), & I really like keyboard navigation (who doesn't). If any dev sees this, please please fix it.

Suse 9.0, Qt3.3, KDE3.2.3
Comment 3 Oded Arbel 2004-07-13 00:37:46 UTC
same problem here. its happens almost any time when there is a big difference in icon names' sizes. not only when a name is truncated but also in icon view where names are wrapped and it always happens in file open/save dialogs.

KDE 3.2.3, Mandrake 10 RPMs
Comment 4 Ahmed Kamal 2004-07-27 13:57:57 UTC
This bug is still irritating me, can anyone reading this please "vote" for bug to speed up its fixing? Kindly consider voting. I already voted for it
Comment 5 Daniel Kratzert 2004-08-26 15:00:12 UTC
The is also in kde-3.3.0, qt-3.3.3, gentoo
Comment 6 Unknown 2004-09-09 09:11:40 UTC
Confirming this bug for KDE 3.3.0 Debian unstable. And voting for it!

By the way: may I also inform you about an even older and also very nasty bug of multi-column view? See Bug #31898 "Dynamic column width in file manager mode" and vote for it! 
Comment 7 Mario Hein 2004-09-13 20:52:21 UTC
Addition to this bug: If the "end" of a large directory is reached, and I try to sroll once more, the next highlighted file is not the first one in the directory. Instead it highlights files somewhere in the middle of the actual directory. Don't know how KDE (Konquerror) chooses the file to be the first one.... i think it will ever be a mistery to me ;)

This bug isnt Konquerror-specific. Every Dialogue to chose a file in KDE has this bug!!!
Comment 8 Ahmed Kamal 2004-09-19 10:52:14 UTC
Can I please ask everyone watching this bug, to VOTE for it. This 
seriously needs to be fixed!

Mario Hein wrote:

>------- You are receiving this mail because: -------
>You are a voter for the bug, or are watching someone who is.
>        
>http://bugs.kde.org/show_bug.cgi?id=79370        
>
>
>
>
>------- Additional Comments From MHein03 web de  2004-09-13 20:52 -------
>Addition to this bug: If the "end" of a large directory is reached, and I
try to sroll once more, the next highlighted file is not the first one in
the directory. Instead it highlights files somewhere in the middle of the
actual directory. Don't know how KDE (Konquerror) chooses the file to be the
first one.... i think it will ever be a mistery to me ;)
>
>This bug isnt Konquerror-specific. Every Dialogue to chose a file in KDE
has this bug!!!
>
>  
>

Comment 9 Ahmed Kamal 2004-09-21 13:16:46 UTC
Confirmed on Suse9.0 Kde 3.3.0.
Comment 10 Daniel Molkentin 2004-11-05 16:02:34 UTC
This is in fact a bug of QIconView, which Sebastian Kratzert and I just successfully reproduced. I will attach a testcase.

The problematic code is in "QIconView::keyPressEvent( QKeyEvent *e )":

    case Key_Down: {
	d->currInputString = QString::null;
	QIconViewItem *item;
	selectCurrent = FALSE;
	Direction dir = DirDown;

	QRect r( d->currentItem->x(), 0, d->currentItem->width(), contentsHeight() );
	item = findItem( dir, d->currentItem->rect().center(), r );

	// finding the closest item below and to the right
	while ( !item && r.x() < contentsWidth() ) {
	    r.moveBy( r.width() , 0 );
	    item = findItem( dir, QPoint( r.center().x(), 0 ), r );
	}

The problem arises occurs if you have one long item in the current "column" and a very short one at the end. The width of this one will be added. Now, if there is an item with a long text in this "column", the new offset will not find the first item in the next column, but the first item in the current column which is long enough to match.

The whole strategy looks both fragile and greedy, but I have no idea how to work around that without breaking something :(

On the other hand, this renders applications like konqerors multicolumn view useless for people that use keyboard navigation.

Any idea from the Trolls maybe?
Comment 11 Daniel Molkentin 2004-11-05 16:05:38 UTC
Created attachment 8181 [details]
The testcase for described bug

Just run it with designer in preview mode or use {k,q}uiviewer.
Comment 12 qt-bugs 2004-11-08 15:14:21 UTC
On Friday, 05. Nov 2004 16:02 Daniel Molkentin wrote:
> ------- You are receiving this mail because: ------- You are on the CC
> list for the bug, or are watching someone who is.
>
> http://bugs.kde.org/show_bug.cgi?id=79370 molkentin kde org changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |qt-bugs trolltech com
>          OS/Version|Linux                       |All
>             Summary|keyboard navigation in      |QListView Bug on
>             KeyDown
>                    |konquerors multi-column-view|under special
>                    conditions
>                    |buggy                       |
>
> ------- Additional Comments From molkentin kde org 2004-11-05 16:02
> ------- This is in fact a bug of QIconView, which Sebastian Kratzert
> and I just successfully reproduced. I will attach a testcase.
>
> The problematic code is in "QIconView::keyPressEvent( QKeyEvent *e )":
>
>     case Key_Down: {
> d->currInputString = QString::null; QIconViewItem *item; selectCurrent
> = FALSE; Direction dir = DirDown;
>
> QRect r( d->currentItem->x(), 0, d->currentItem->width(),
> contentsHeight() ); item = findItem( dir,
> d->currentItem->rect().center(), r );
>
> // finding the closest item below and to the right while ( !item &&
> r.x() < contentsWidth() ) {
> 	    r.moveBy( r.width() , 0 );
> 	    item = findItem( dir, QPoint( r.center().x(), 0 ), r );
> }
>
> The problem arises occurs if you have one long item in the current
> "column" and a very short one at the end. The width of this one will
> be added. Now, if there is an item with a long text in this "column",
> the new offset will not find the first item in the next column, but
> the first item in the current column which is long enough to match.
>
> The whole strategy looks both fragile and greedy, but I have no idea
> how to work around that without breaking something :(
>
> On the other hand, this renders applications like konqerors
> multicolumn view useless for people that use keyboard navigation.
>
> Any idea from the Trolls maybe?
>

Hi

I am afraid the only way to fix this is to reimplement all the
keyHandling yourself.

We will resolve this in 4.0 but until then I don't see any other
options.

Sorry for any inconvenience caused.

best regards

Anders Bakken
--
Trolltech AS, Waldemar Thranes gate 98, NO-0175 Oslo, Norway

Comment 13 Maksim Orlovich 2004-11-15 22:30:53 UTC
*** Bug 93140 has been marked as a duplicate of this bug. ***
Comment 14 Alex Radu 2005-01-18 03:34:09 UTC
Well, at least it will be fixed sometime.... ;) 

I hope Qt 4 will have better KDE integration and focus.
Comment 15 S. Burmeister 2005-02-27 20:02:24 UTC
What I get when trying to chose a wallpaper from the wallpaper-dir is that when I move down mit the cursor key, in the first column it jumps back from the last to the fourth item and in the 2nd, 3rd... column from the last of n to the fourth of n+1.
Comment 16 Ahmed Kamal 2005-02-28 09:36:31 UTC
Don't tell me this wont get fixed in kde3.4 either! This is the longest 
standing bug I have ever seen.

BR

S.Burmeister wrote:
>------- You are receiving this mail because: -------
>You are a voter for the bug, or are watching someone who is.
>         
>http://bugs.kde.org/show_bug.cgi?id=79370         
>sven.burmeister gmx net changed:
>
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>                 CC|                            |sven.burmeister gmx net
>
>
>
>------- Additional Comments From sven.burmeister gmx net  2005-02-27 20:02 -------
>What I get when trying to chose a wallpaper from the wallpaper-dir is that when I move down mit the cursor key, in the first column it jumps back from the last to the fourth item and in the 2nd, 3rd... column from the last of n to the fourth of n+1.
>
>  

Comment 17 Thiago Macieira 2005-02-28 11:22:31 UTC
Ahmed: it has been said: it will be fixed for Qt4, not before. Which means KDE 3.4 isn't fixed.

Sorry for the inconvenience, but some design decisions aren't easily reversed. But maybe we could fix this with another qt-copy patch?
Comment 18 Mohd Asif Ali Rizwaan 2005-10-06 13:31:09 UTC
and unfortunately multicolumn bug is still not fixed in KDE 3.5 beta 1!
Perhaps the Developers do not use Multicolumn View for their day-to-day task, that's why it is not fixed for such a long time, IMO.

Comment 19 qt-bugs 2005-10-07 09:52:41 UTC
Hi David,

On Thursday, 06. Oct 2005 20:03 David Faure wrote:
[bugs.kde.org quoted mail]


No need to reply to this email, I just wanted to thank you for removing
us form the list. The person who added us in the first place may have
thought that it was a good idea, but for us it can be rather annoying.

Again, thank you very much, and have a great day!


Kind regards,

Stian Thomassen

--
Trolltech AS, Waldemar Thranes gate 98, NO-0175 Oslo, Norway

======================================================================
You're invited to Trolltech Developer Days 2005!
Meet Trolltech developers, executives and partners, hear in-depth
seminars on Trolltech technology and network with hundreds of
your peers at the 2005 Trolltech Developer Days!
Register online today at http://www.trolltech.com/devdays2005
======================================================================
Comment 20 Andrew Wang 2008-05-05 02:44:40 UTC
This is still present in Konqueror 3.5.9, but it appears fixed in 4.0.3
Comment 21 Jaime Torres 2008-07-17 19:05:17 UTC
May be this bug is related to http://bugs.kde.org/show_bug.cgi?id=56574 (or vice versa).
Comment 22 Björn Ruberg 2008-08-23 11:20:45 UTC
As this obviously wontfix in KDE 3 with Qt3 and is fixed in KDE 4 with Qt4 why not close this bug?
Comment 23 David Faure 2008-08-25 22:40:03 UTC
Good to hear it's fixed in Qt4; closing.