Version: (using KDE KDE 3.4.0) Installed from: Gentoo Packages OS: Linux While renaming a file with konqueror in MultiColumn View at the bottom of the window with a large filename, causes the rename preview field to leave the visible area of the window. This also happens in Icon View. My wishes: For MultiColumn View is to use a rename preview field like in Tree View, but with multiple line support like the file are shown in MultiColumn View. For Icon View to ensure the rename preview field to stays in the window. It's just a detail, not a big deal, but KDE has reached a level of quality were such things now getting important ;-)
Hi! Please, would you like to try the new KDE SC 4.3.4 or KDE SC 4.4 beta 1 and check this specific issue? Many thanks.
Since KDE4 renaming in konqueror works with a separate window, therefore the initial bug is gone. Now the MultiColumn View in konqueror is broken.
@phorsyon: you can enable inline renaming from dolphin/konqueror settings.
OK, finally i got arround to test this. I remeber a text scrolling feature, while renaming long filenames in inline mode with KDE 4.4.0, but now in KDE 4.4.2 this has gone again so the bug remains. Also i noticed that it's not possible to select files with long filenames directly using the keyboard. The file just gets underlined, meaning the keyboard cursor is on it, pressing space then actually selects the file. Next thing to mention: MultiColumn View. I don't now if anybody ever tested it since KDE4 has arrived, but what you get by selecting it in Konqueror/Dolphin/FileOpenDialog is a single tiny column, a scrollbar up-down instead of left-right and a huge empty field right next to it. It's a regression to KDE3. Sorry for the delay.
Created attachment 51564 [details] Screenshots to illustrate the issue I attached 3 Screenshots showing a Use Case example where Joe User wants rename a file in konqueror from $VERYLONG.aaa to $VERYLONG.bbb 1. Joe selects the file $VERYLONG. Everything is fine. 2. Joe presses F2 to rename $VERYLONG. A $MARK_COLOR box appears around the filename which is marked to signalize Joe he can just start typing in the new filename. Little does he know that the cut of this box on the right side already foretells the frustration he's gonna encounter in a about a moment. 3a. Joe wants to edit the fileextension and knows about the End-Key to jump to a lines end. So he presses <End>, but to his deep disapointment the part of the filename he wants to edit stays out of sight. So he starts his $DE project focussing on renaming files with very long names. 3b. Joe wants to edit the fileextension, but does not know about the End-Key, so he holds down the Left-Arrow-Key to reach the lines end, but to his deep disapointment the part of the filename he wants to edit stays out of sight. While facing he's helplessness right, Joe User gets really angry, cursing around, smashing his keyboard against his monitor and so on. Then he starts ranting on the internet about $OS. I hope this is enough info. If you need more information just ask. ;-)
I forget to mention that screenshots where taken from a KDE 4.5.1 (Gentoo ebuilds) installation.
Thanks Phorsyon, only one last question: I imagine you can reproduce the bug even with dolphin right?
That's correct, FiNeX. Dolphin shows the exact same behaviour, I just checked it.
Thanks :-)
Cannot reproduce on today's trunk. In all three view modes, long names get split into multiple lines and you can hit Up/Down keys to "scroll" through long names.
Okey, making the file names even longer, it still happens in Column View mode that the text edit is longer than the view. But as far as I know, Column View mode does not use the Categorized kdelibs view classes, right? Peter?
> Column View mode does not use the Categorized kdelibs view classes, right? Peter? Right. I've not tried to reproduce the issue yet but I've reassigned it to Dolphin.
*** This bug has been marked as a duplicate of bug 290747 ***