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.
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
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
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
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
The is also in kde-3.3.0, qt-3.3.3, gentoo
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!
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!!!
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!!! > > >
Confirmed on Suse9.0 Kde 3.3.0.
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?
Created attachment 8181 [details] The testcase for described bug Just run it with designer in preview mode or use {k,q}uiviewer.
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
*** Bug 93140 has been marked as a duplicate of this bug. ***
Well, at least it will be fixed sometime.... ;) I hope Qt 4 will have better KDE integration and focus.
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.
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. > >
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?
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.
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 ======================================================================
This is still present in Konqueror 3.5.9, but it appears fixed in 4.0.3
May be this bug is related to http://bugs.kde.org/show_bug.cgi?id=56574 (or vice versa).
As this obviously wontfix in KDE 3 with Qt3 and is fixed in KDE 4 with Qt4 why not close this bug?
Good to hear it's fixed in Qt4; closing.