Version: (using KDE KDE 3.1.2) Installed from: Debian testing/unstable Packages Compiler: gcc3.2 OS: Linux I just checked out the new Gnome 2, and the file manager there has a really useful feature. when you choose to rename the file, it automatically pre-select the filename, leaving out the extension, so all you have to do, is press F2, type the new name, and (i.e.) .png is kept at the back. of course, if you should feel the need to change the ezxtension, all you have to do then, is mark the remainder or press delete a couple of times. I found this feature immensely useful, saving lots of mousemovement and time, as I do a lot of renameing, for instance renaming ogg files to my preferred format :)
Created attachment 4580 [details] Current behavior
Created attachment 4581 [details] ( Hopefully ) future behavior
exactly! that's how it should act.
Very intelligent idea the GNOMEers had there... should be done in Konqueror too!
Don't know if Nautilus does it, but double extensions like .tar.bz2 should also be left out. This feature is very handy, I wonder why this has not been invented years before. Other systems warn before changing the extension, but simply not marking it seems to be a real innovation(TM).
Created attachment 6808 [details] Proposed patch This patch works well. Unfortunately it only works on the lists views. The icon views need a little more work.
*** Bug 87410 has been marked as a duplicate of this bug. ***
Did work on this patch continue? Maybe it can make it in KDE 3.4 then?
I have listed this wish in the KDE 3.4 feature plan so every working patch can enter until February. Read, an icon view patch is still welcome. :-)
Committed listview patch.
Created attachment 8877 [details] Possible beginning for iconview support I've attached a patch that someone could probably use as a starting point for getting this working for the iconview as well. The problem being that QIconView and QIconViewItem very much handle renaming by themselves, giving the application programmer no input as to how that happens. I've tried redoing the rename() implementation based on the source code of QIconViewItem::rename(). It sort of works as long as you hit enter to save the results instead of clicking outside of the text box, which doesn't work. Other things that don't work: 1) The file doesn't actually get renamed. This shouldn't be hard to do however. 2) The width and height don't adjust as you type at this point since the nifty QTextEdit::document() call is apparently internal to the library. It could probably be worked around with one of the various Qt calls to pack text into a rectangle. 3) The code style needs to be merged to match the surrounding code. I probably won't have time to work more on this so I wanted to put it up so it can be picked up by someone else.
Thanks for that. I'll see what I can do.
Created attachment 9013 [details] Example screenshot Seems the logic to select the filename is to grab everything from the first 'period' on the left to the beginning of the word. Would be better to grab the first 'period' from the right and select to the beginning of the word... example: this.is.a.test.html current will select 'this', would be best to select this.is.a.test Some file extensions are more than 1 period.. such as .tar.gz/bz, would be nice to at least check for these common cases along with the above suggestion.
Honestly, how common are such complete.stupid.filenames?
There is something like: .ps.gz .tar.bz2 Picture-14.1.2004.jpg as germans write the date, not really stupid. So on the one hand double extensions are not only .jpg.exe and on the other hand there are sensible ways of using the dot in filenames. My suggestion: Check from right to left and use whitelists of known extensions.
Just noticed that it bites with archive-version.numbers files. Do you have a patch? :-)
Let me make my suggestion clearer: - The last extension will never be marked. - Every known extension before the last will not be marked, scanning from right to left until we find an unknown extension - We get known extensions from KDE, so everyone can add his own extensions that will be recognized from then on. In all exceptional cases: bad luck, but still better than in KDE 3.3. Did I oversee something? BTW: What does nautilus do in these complicated cases?
I noticed today that renaming files in icon view by clicking the name (should be default behavior IMO, it's expected from all other platforms) selects a lot of whitespace to the left and right of the actual file name. It would be nice to select only the text that exists (along with the above modifications). Not sure if this is systemic (I'm using KDE 3.3.1)
*** Bug 98118 has been marked as a duplicate of this bug. ***
CVS commit by binner: Enhance renaming preselection: use mime type database, else search from right CCBUG: 58749 M +12 -4 konq_listview.cc 1.223 --- kdebase/konqueror/listview/konq_listview.cc #1.222:1.223 @@ -34,4 +34,5 @@ #include <kprotocolinfo.h> #include <klineedit.h> +#include <kmimetype.h> #include <qapplication.h> @@ -164,8 +165,15 @@ void ListViewBrowserExtension::rename() KLineEdit* le = m_listView->listViewWidget()->renameLineEdit(); if ( le ) { - QString txt = le->text(); - int firstDot = txt.find('.'); - if( firstDot > 0 ) - le->setSelection(0, firstDot); + const QString txt = le->text(); + QString pattern; + KMimeType::diagnoseFileName( txt, pattern ); + if (!pattern.isEmpty() && pattern.at(0)=='*' && pattern.find('*',1)==-1) + le->setSelection(0, txt.length()-pattern.stripWhiteSpace().length()+1); + else + { + int lastDot = txt.findRev('.'); + if (lastDot > 0) + le->setSelection(0, lastDot); + } } }
Was this included in KDE 3.4 final? It doesn't seem to be present in KDE 3.4.0. I distinctly remember seeing it working once, maybe it was in one of the 3.4 release candidates, but now it's gone. :(
Ah, I see that it works fine in List View, which is probably what I remember seeing. Would be nice if it worked in Icon View too.
*** Bug 132401 has been marked as a duplicate of this bug. ***
Confirmed KDE 3.5.5 / Kubuntu 6.10. File extension is included when renaming under: MultiColumn, Icon. File extension is not included under: Tree, Info List, Detailed List.
just a ping to remind about this feature which will make konqueror acting in a consistant way in all view
This would be nice feature if would work on all view styles. And if this could get work with http://www.kde-look.org/content/show.php/Selection+Eyecandy?content=52738 idea it could be awsome.
Fixed in KDE 4.