Page 1 of 1

Action logging wanted

Posted: 05 Jun 2006, 00:45
by AbteriX
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]

Posted: 05 Jun 2006, 09:51
by Jan Rysavy
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.

Re: Action logging wanted

Posted: 06 Jun 2006, 09:08
by KNUT
AbteriX wrote:I want to have an "action log"
Nice idea, but not a "must have" for me.

Posted: 06 Jun 2006, 20:52
by schroeder
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.
Yeah, I was actually wondering about an undo command. CAN you undo the last action?

And how would this action log help you to replace an undo feature?

schroeder

Re: Action logging wanted

Posted: 06 Jun 2006, 21:39
by SvA
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).

Posted: 06 Jun 2006, 22:18
by JohnFredC
schroeder wrote:CAN you undo the last action?
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).

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.

Posted: 07 Jun 2006, 01:10
by schroeder
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.
Sounds good. But I agree with SVA on leaving that stuff in the memory with the option to write it to a file eventually.

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. :wink:

schroeder

Posted: 07 Jun 2006, 09:28
by AbteriX
Thanks for the comments.


To keep our privacy:

[x] enable logging
( ) crop older entrys if log file is greater then [4096][kB]
(o) wipe log-file if Salamander go to be closed


---
Or have such an "enable logging"-switch directly in the copy dialog
for time-to-time access.

Posted: 07 Jun 2006, 12:39
by SvA
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.
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.
schroeder wrote:I guess the most challenging part is an 'interpreter' function to read the log and undo all the taken actions, right?
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 dont think anybody expects a undo history of the last 10 actions with a file manager.
Having the ability to undo your last action is certainly the most valuable, but undo the ones before that not less usefull...
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. :wink:
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).
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...
schroeder wrote:Naturally Salamander could never be expected to undo some other file manager's actions... (except under a journaling file system).
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.

Posted: 07 Jun 2006, 13:37
by JohnFredC
2SvA
I suggest, schoeder, that you read throug the wiki article your post (intended to) link to.
Actually that was I who put the bad link. I've corrected it. Also, that last quote you cited is mine.

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!

Posted: 07 Jun 2006, 23:24
by SvA
Oohhh, :oops: I beg your pardon for attributing the statement to the wrong person.