more about the standard File Manager API

[Marcos]

Hello again, Kevin
Hello Fred
 
Am I talking about embedding the desktop's filemanager ?
Good question! I never saw the problem at this point of view.

My initial objective was just to add ( and modify and extend ) the context menu from the default
file manager for files and folders in my application. The files and folder representation was
being done by myself, althought the icons come from the user's window manager.

Since the context menu will be extended, I don't think one can call it embedding.



> Are you talking about embedding the desktop's filemanager?
> 
> If this is about file dialogs, we are working on that.
> 
> Cheers,
> Kevin
> 



--- Fred Drake <fdrake at gmail.com> schrieb:

> On 10/22/06, Marcos <bugshideout at yahoo.com> wrote:
> > A generic File Manager API is another missing standard.
> >
> > It would be nice if, just like in MSWindows, one could implement in any application basic file
> > functions like "delete, rename, propreties".
> 
> What's interesting about these operations?  I expect some/all of the following:
> 
> - veto the operation

I expect to veto the operation, also to add new opens

> 
> - extend the operation to perform additional changes
To extend an operation, one must reimplement it. I can't see any other way...



> 
> - provide additional file properties that are only associated with
> specific applications (version control, backup applications, whatever)
 
- This is the same as adding addicional operations

> 
> This suggests that any application used to manage files might need to
> ensure participation of extensions.

The way to implement this would be easy....

the default File Manager API just have to return, for each line of the context menu:

a) type of the operation (fixed)
b) name of the operation (which might vary according to the user's locale)
c) a pointer of the function which performs the operation
d) some extra stuff I've forgotten 

> 
> I don't know about you, but I still do most of my file management from
> a command line, though I use Gnome and an occaissional KDE
> application.  Unless "rm", "cp", "ln" and the rest of  the tools I
> happen to use play nice with these things, I don't see how the
> situation is improved.  That suggests to me that extending a file
> manager isn't what's needed; we need to be able to plug bits into the
> filesystem implementation to allow real operations to be extended.

I also use the terminal as my filemanager and I don't think anything could beat the command line.
But not all users think like that. Some prefer a GUI, others simple can't use a CLI.
The application that I am currently writting is a good example where the context menu would be
usefull: http://treesize.sf.net

About changing the filesystem to add more operations, that would break to many standards...
Although it would be nice if every filesystem was marked as local or remote. With this single
filesystem wide bit, applications could deal with data in a much more precise way.


Marcos


> 
> I think that could be interesting, though difficult to do effectively.
>  It's also less useful from the application perspective, because that
> ties application functionality to the specific filesystem selected,
> defeating portability.
> 
> So, interesting, but not particularly feasible.  Perhaps I don't
> understand what use case you're trying to address?
> 
> 
>   -Fred