more about the standard File Manager API

[Fred Drake]

On 10/22/06, Marcos <bugshideout at yahoo.com> wrote:
> 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.

Ok, I think I understand better what you're trying to do.

> I expect to veto the operation, also to add new opens
...
> To extend an operation, one must reimplement it. I can't see any other way...
...
> - This is the same as adding addicional operations

My understanding now is that there are two core bits:

- disable specific operation (making them unavailable), and

- add new operations.  New operations may be similar to old
operations, but adding new constraints if appropriate, or they may
really be new.

> > 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 extension API is straightforward, yes.  I don't think the
extension API is actually an issue, just an implementation detail.

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

Right.  My point is that really implementing the kind of thing you're
describing in such a way that it works properly even for CLI users
working with the conventional tools is a hard thing, *because* it
needs to work for everything.  I think that's why we don't really
think about using that sort of thing on Unix-type systems.

On Windows, the little bits of code that extend the context menus for
Windows Explorer and the like are called "Shell Extensions", and with
good reason: the only thing that's really being extended is the shell
used to access files and directories directly.  We can do that on
Unix/Linux as well, but we have more shells to deal with.  Some of
them will allow high levels of integration (I expect the KDE and Gnome
shell components will fall into this category), and others will not
(cp, rm, etc.).

So while there are people that will only use the GUI shell for their
desktop environment to access files and directories, we see a lot more
mixed-mode usage on Unix than we see on Windows.  Making an extension
work well in such an environment is difficult.  Years ago, Sun used a
message bus system called ToolTalk to integrate their IDE with the
command line tools, but you had to run special versions of the command
line tools that included integration code.  Presumably free desktop
tools would use dbus for integration instead.

What it comes down to is that if you effectively want to intercept
certain basic operations, you really need to cover a lot of bases.  If
you're only looking to offer additional operations, that's a lot
easier.

> The application that I am currently writting is a good example where the context menu would be
> usefull: http://treesize.sf.net

I can see where a new operation would be convenient.

> About changing the filesystem to add more operations, that would break to
> many standards...

Don't know about the standards involved, but it just doesn't seem
realistic.  Building such a filesystem isn't so hard (well, not really
harder than anything else at that level), but it doesn't seem like a
really good way to go about things.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Every sin is the result of a collaboration." --Lucius Annaeus Seneca