Ticket #266 (WontFix)Tue Feb 01 23:36:45 UTC 2011
File selection not maintained when adjust-clicking on File->Rename
| Reported by: | Trevor Johnson (329) | Severity: | Minor |
| Part: | RISC OS: Module | Release: | |
| Milestone: | Status | WontFix |
Details by Trevor Johnson (329):
I hope that the resolution of this would be less complicated than the ‘set type’ fix.
From the File->Rename menu, rename the file and adjust-click. The menu then shows File’’, with the desirable situation being obvious.
This adjust-clicking for filenames may not occur frequently, but an example is when dealing with an untyped file from another OS and with an extension (where not handled by MIMEMap).
Changelog:
Modified by Sprow (202) Tue, November 12 2013 - 08:03:18 GMT
- Status changed from Open to WontFix
Looked into this, yes it is a similar nature to the ‘set type’ fix where the menu is reopened for the adjust click before the next Wimp_Poll.
In the rename case it’s more complicated as the dirviewer (the internal structure holding the file names) marks the single file as selected so the menu is built with that name. When the rename happened an upcall is recorded saying that the rename happened and marks that window as dirty, setting the poll word. On the next Wimp_Poll the pollword is collected and the directory recached, at which point the Filer tries to copy over any previous selections to the new dirviewer from the old based on name – except of course the name has changed.
That’s not too much of a headache, because at the point of renaming the old copy of the dirviewer can be updated with the new filename (a bit of a hassle as they’re kept packed together in an RMA block which would then need resizing and reinserting into the linked list of dirviewers).
As a rough prototype I dealt with the case where renaming ended up with a shorter filename so I didn’t need to bother doing an RMA block resize (much simpler!), but that immediately illustrated why this request is a bad thing.
When you make the filename shorter the top level ‘Filer’ menu changes width, but the other two (File & Name) don’t move, which looks very odd. I imagine in the rename-to-longer-name case the top level ‘Filer’ menu would get wider and be underneath the other two. While it could be possible to manually fiddle the place where the top level menu appears that would either make it jump around, or the File and Name boxes would need to move – potentially so they’re no longer under the mouse, causing them to close.
There was also a minor technical challenge that the Filer users OS_CLI but the rename function doesn’t get back any error status, so a failed rename in this simple prototype would leave the menu out of sync with the disc.
Note that the filer does keep the selection open when no rename occurs. That seems reasonable, and it probably makes more sense that, having selected a file, when you rename the file the selection is no longer valid so is cancelled. The other operations that retain the selection (eg. Access, Stamp) don’t affect the selection. Delete and rename do, so it’s reasonable that the selection is dropped in these cases.
