Renaming in the pop-up dialog in its current status has the following advantages / disadvantages: + you can see the old filename in the main window while typing the new name + you won't accidentally start the renaming (I've observed many people do and curse about it) - the dialog window is too small and inconvenient for longer filenames - it's an ugly pop-up, in-place renaming looks more elegant (but that's a matter of taste) Possible solutions: * Make the dialog window larger / scale appropriately * Rename in-place and show old filename in status bar while renaming. However, in-place renaming might suffer from the same size issues as the dialog window. Enter the bulk renamer: There is no way to invoke the bulk renamer for single files. Why is this bad? Why would one want to do that? Imagine you just renamed a lot of files, then want to perform the same operation on a single file you forgot or on a lot of single files in different folders. It's impossible right now, isn't it? Solution: Provide override key, like <Shift>-<F2>, or shift-clicking on the context menu entry, as with the delete function (bypass trash).
Created attachment 3766 Patch to fix the rename dialog width. This should auto-resize the rename dialog to 10*(filename length), and then restrict it to some sane limits.
Created attachment 3772 Similar solution to fix the dialog width. Thanks for your patch, I tried it but had to adapt it a bit: * Your solution does not account for the icon size and spacing, so I've added 80 pixel to the calculation. * Unfortunately, multiplying the filename length does not take into account the font size. My first idea was to get the font from the widget style and calculate the string length in pixel using gdk_string_width. However, this did not work, as the length was always the same though I changed the font size in xfce-settings. So your solution still works best, but I had to increase the multiplicator from 10 to 12 to be effective. This provides extra space for renaming files to longer names. * Instead of using the whole screen estate, my patch restricts the dialog width to the parent window size, which should still be enough for most filenames. In the rare cases where it does not, one will have to scroll. But this way, the dialog stays well within the thunar window.
> * Your solution does not account for the icon size and spacing, so I've added > 80 pixel to the calculation. Fine with me, this is more correct than just choosing a magic number that works. > * Unfortunately, multiplying the filename length does not take into account the > font size. My first idea was to get the font from the widget style and > calculate the string length in pixel using gdk_string_width. However, this did > not work, as the length was always the same though I changed the font size in > xfce-settings. So your solution still works best, but I had to increase the > multiplicator from 10 to 12 to be effective. This provides extra space for > renaming files to longer names. No problem here. Too small is annoying, but too big is harmless or even helpful. > * Instead of using the whole screen estate, my patch restricts the dialog width > to the parent window size, which should still be enough for most filenames. In > the rare cases where it does not, one will have to scroll. But this way, the > dialog stays well within the thunar window. Is there a good reason to keep the dialog within the thunar window? I recently had to rename about 100 presentations (my motivation for patching) that regularly overflowed my default thunar window.
> Is there a good reason to keep the dialog within the thunar window? > I recently had to rename about 100 presentations (my motivation for > patching) that regularly overflowed my default thunar window. Accidentally, I stumbled over this again and saw that I forgot to answer your question. Actually it's just a matter of taste. I don't know how your thunar window is, but its size on my computer is a bit more than half of the screen. Usually I don't have to deal with such long filenames that they would exceed the size of the main window. If that were the case, there would still be the possibility to go fullscreen (maximize window), or use the bulk renamer to quickly reduce the length of the filenames. I'd say: Different needs, different preferences ;-) Nevertheless, the default behaviour definitely sucks. Unfortunately, till now there have not been any comments from the devs, so I guess they don't care about this. Thanks for your ideas and your patch, I've been using it happily for quite a while now.
Created attachment 4003 Enable forcing the bulk renamer using the shift key. About the bulk renamer: I've patched thunar-standard-view.c to open the bulk renamer when holding the shift key down while pressing the shortcut. This works as intended, but introduces some more hardcoded behaviour, and I don't like hardcoded behaviour very much. Yet, it solves the issue for me. Pieces of this patch were shamelessly cobbled together from other parts of thunar.
Created attachment 4502 Renamer screenshot Ping. This is by far the stupidest bug I have to deal with on a day-to-day basis.
Fixed resizing in 57d6461.
Applied Shift rename with some modification in c08072e.
Tested both commits successfully, they work fine. Thanks!