https://bugs.kde.org/show_bug.cgi?id=497326
Bug ID: 497326
Summary: Manual Operations on Listboxes (With or Without the
Physical Files)
Classification: Applications
Product: krusader
Version: unspecified
Platform: Other
OS: All
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: general
Assignee: krusader-bugs-n...@kde.org
Reporter: adalbert.hans...@gmx.de
CC: krusader-bugs-n...@kde.org
Target Milestone: ---
This whishlist entry relates to #468505: Search results can be saved in a list
box (VFS). This can be the starting point for a further, more refined search.
Sometimes you will also find items among the results that you want to exclude
manually from further searches. Or you may want to widen the repeated search by
adding other files or directories to the listbox.
There are situations in which you want to manually delete entries from a list
box (VFS), but not the physical files to which they refer.
I therefore suggest to introduce operations for list boxes that only affect
them, rather than the physical files to which the entries refer.
Currently you can delete entire listboxes without deleting the physical files
they contain (you have to locate an active panel at virt:///). Currently,
within a listbox you can only delete entries and the associated files at the
same time. This looks a bit inconsistent and since deletion is destructive, the
user interface should be improved with this regard. It is currently even
possible to copy or move files into a listbox using drag&drop. The physical
storage point of objects moved to a list box is a mystery to me. They vanished
from where I moved them to the list box. The listbox shows the m after the
movement. You can also move them back from there so that they appear again
(physically) in the original place – but I don't know where they were
(physically) in between. The moving function should be described properly – or
this function should not be offered in the context menu of a drag&drop
operation and Ctl-x should not be offered from it.
Currently, you CANNOT delete files or selected groups from a list box without
this also affecting the physical files. However, this would be useful for
repeated and refined searches. That's why I would like to see a delete
operation within a list box that only affects its entries, but not the
associated physical files. The add operation already exists, see above.
I suggest to modify the delete operation (e.g. with the Delete key or via the
context menu) so that it normally only affects the entries of the list box. In
addition, a stronger and therefore more destructive version should be offered,
which also affects the associated physical files. As a shortcut, perhaps by
simultaneously pressing Delete and Shift, Control or another key that is usual
for such “reinforced” actions, in the context menu of a group of selected
objects in a list box by means of a separate option, “delete physical file(s)”.
It is a question of taste whether you always ask after the physical variants
whether a physical deletion of the selected x elements is really desired,
whether you only make such a security query if the selection concerns >1
objects (or non-empty directories), etc., or whether you do not ask such
security queries. However, I would prefer the middle variant: As soon as more
than one object is selected for deletion, especially if there is also a
non-empty directory among it.
The listbox (VFS) is physically represented by the file
~/.local/share/krusader/virtualfilesystem.db. This file also keeps track in
MetaInfo_/= on how the objects int he listbox got there. Currently it does not
register any manual operations on the list box. Of course one could keep track
on such things there too, which files or directories were added or deleted
manually. Perhaps a simplified "+ manual operations on VFS" would suffice. I
don't know the purpose for the additional entires in the listbox file. Perhaps
they were implemented in preparation of further enhancements. Depending on that
one should decide on how much manual operations (additions or deletions) from a
VFS shall be documented in it. Also one has to think about "move to" or "cut
from" a listbox: What do they actually do. If it can't be explained easily, it
probably would be better to not offer"move to" and "cut from", but only "copy"
and "paste".
--
You are receiving this mail because:
You are watching all bug changes.
