I want to have an "action log",
i mean a text csv file where i can
see what i/Sala have done.
e.g.
if i copy a lot of files
and be asked something from Sala
and i choose e.g. "Skip All"
and go away till the action is done
it would be nice to know
WHAT files are skipped in the mean time.
i like to have smtg like:
[x] enable logging
( ) crop older entrys if log file is greater then [4096][kB]
Action logging wanted
Action logging wanted
AbteriX
-
- ALTAP Staff
- Posts: 5231
- Joined: 08 Dec 2005, 06:34
- Location: Novy Bor, Czech Republic
- Contact:
Re: Action logging wanted
Nice idea, but not a "must have" for me.AbteriX wrote:I want to have an "action log"
Kind regards, KNUT
_____________________________________________
Satisfied Servant Salamander User from Version 1.5 till now
_____________________________________________
Satisfied Servant Salamander User from Version 1.5 till now
Yeah, I was actually wondering about an undo command. CAN you undo the last action?Jan Rysavy wrote:YES, this is definitely possible to implement into Servant Salamander and it could be good replacement for frequently required Undo command, which is almost impossible to do. I mean log for ALL actions, including plugins operations, (unintenional) drag & drop, etc.
And how would this action log help you to replace an undo feature?
schroeder
Re: Action logging wanted
From what AbteriX wrote in the beginning, I assume he's talking about a persistent log file, which keeps logging all actions.
I would not want to use this.
On the other hand, in casees such as he names in his example, where Salamander takes default actions without asking me explicitely each time, it was very good to get a protocol of what Salamander has done. This should be stored in memory only, but with an option to export to a file to serve as a 'todo-list' or as a base for some batch processing.
(I often work on customer's computers and want to keep my footprint as small as possible, and moreover this would rise issues of privacy also.)
I don't think, a protocol of all actions could reasonably easy serve as a replacement for an undo command (from a programmer/developer's point of view).
I would not want to use this.
On the other hand, in casees such as he names in his example, where Salamander takes default actions without asking me explicitely each time, it was very good to get a protocol of what Salamander has done. This should be stored in memory only, but with an option to export to a file to serve as a 'todo-list' or as a base for some batch processing.
(I often work on customer's computers and want to keep my footprint as small as possible, and moreover this would rise issues of privacy also.)
I don't think, a protocol of all actions could reasonably easy serve as a replacement for an undo command (from a programmer/developer's point of view).
Of course you can. Indeed, you could conceivably undo ANY Salamander action (not just the last), as long as all of the parameters of the action have been recorded, and still exist or can be recreated. Naturally Salamander could never be expected to undo some other file manager's actions... (except under a journaling file system).schroeder wrote:CAN you undo the last action?
An action log is actually the first step in implementing an undo function. The log would keep all of the necessary info about the action. Selections, old names, new names, from folder, to folder, etc.
DOpus (a competitor to Salamander) maintains such a log and offers a limited undo function that works OK as far as it goes. Its undo list shows the following columns: Action, Name, Path, Destination, New Name. From these columns you might correctly conclude that not all actions possible in DOpus are recorded to the undo list. Copy, move, rename, new folder actions ARE recorded and "undoable", but the action of changing a file's attributes (for instance) is not recorded to the undo the list.
Designing a comprehensive undo function for any tool is challenging. However, if you consider that other products do offer extensive undo functionality (consider Photoshop, or Excel), it's obviously possible.
Last edited by JohnFredC on 07 Jun 2006, 13:18, edited 1 time in total.
Mouse-centric, Registered
Sounds good. But I agree with SVA on leaving that stuff in the memory with the option to write it to a file eventually.JohnFredC wrote: An action log is actually the first step in implementing an undo function. The log would keep all of the necessary info about the action. Selections, old names, new names, from folder, to folder, etc.
I guess the most challenging part is an 'interpreter' function to read the log and undo all the taken actions, right? That would definitely be a good thing to have. I dont think anybody expects a undo history of the last 10 actions with a file manager. But still...this free Windows Paint substitute Paint.NET (open source BTW) keeps an unlimited history of all actions and lets you undo them step by step if you want. If this bunch of students can develop that...you can too guys.
schroeder
Well, kind of. I would certainly organise my log differently depending on whether I want to document actions, redo actions (in forward or reverse order) or implement a true undo.JohnFredC wrote: An action log is actually the first step in implementing an undo function. The log would keep all of the necessary info about the action. Selections, old names, new names, from folder, to folder, etc.
See above. When you write a log for documentation and then want to act on it, you are right, but your undo capabilities will be rather limited.schroeder wrote:I guess the most challenging part is an 'interpreter' function to read the log and undo all the taken actions, right?
Having the ability to undo your last action is certainly the most valuable, but undo the ones before that not less usefull...schroeder wrote:I dont think anybody expects a undo history of the last 10 actions with a file manager.
Many file system operations are destructive. To be able to undo an action, you need to record the (meta-)data as it was before, which might be large in size and might be counterproductive for what you want to achieve (e.g. gain free space by deleting files).schroeder wrote:But still...this free Windows Paint substitute Paint.NET (open source BTW) keeps an unlimited history of all actions and lets you undo them step by step if you want. If this bunch of students can develop that...you can too guys.
To come back to your example quoted above, an imaging application can keep it's original data and add your operations with all their parameters to an internal log. It can then just replay all you've done up to the last point you keep after undo is done. (The application can of course store other data to speed things up or calculate inverse functions to undo in the literal sense). Anyway, only this application accesses the file while you are working with.
On a file system, keeping the initial state is impossible. Furthermore, on a file system, the file manager is not the only application accessing it...
A journal in a journaling file system is there to keep the file system consistent. I am not aware of any implementation of a file system that would provide functionality to let the user undo their operations that affected the file system. I suggest, schoeder, that you read throug the wiki article your post (intended to) link to.schroeder wrote:Naturally Salamander could never be expected to undo some other file manager's actions... (except under a journaling file system).
2SvA
There are a variety of file systems linked to by that wiki article, some of which could potentially offer undo as a core function. Naturally, destructive actions typically can't be undone. However, please see the link to the log-structured file system article.
None of this will ever be applicable to Salamander, though!
Actually that was I who put the bad link. I've corrected it. Also, that last quote you cited is mine.I suggest, schoeder, that you read throug the wiki article your post (intended to) link to.
There are a variety of file systems linked to by that wiki article, some of which could potentially offer undo as a core function. Naturally, destructive actions typically can't be undone. However, please see the link to the log-structured file system article.
None of this will ever be applicable to Salamander, though!
Mouse-centric, Registered