Introduce my self
A. Yerenkow
My name Alexander I'm java programmer, pretty good :)
I want somehow participate in mucommander dev, and looking into
plugins architecture.
So, I here describe my thoughts about plugins, and will wait for
comments :)
1. Plugin is java-class, which implements certain Interface.
2. plugin can on register stage:
- add MenuItem to main menu, or to any menu;
- add MenuItem to context menu, and make it conditional-based (for
example - some additional action only for extension *.foo)
- add Item to root Folders;
- add additional toolbar (I'm not sure yet what for :D )
of course all this additional actions can have shortcuts;
further, we need plugin features similar to total commander:
- packer plugin - allow transparent work with specific archive
types;
- lister plugin - like F3 on image - we see image, not binary
content;
- file system plugin - similar to packer, but target object could
be not file.
- file info plugin (like id3 tags, like width&height of video, etc)
- syntax highlighting plugin (in future maybe some feature like
intellisense, at least for special words)
and one more, I'm lack of toolbar like in TC - to which any file can
be drag-n-dropped and created icon-link to it.
As you may know, selected files and current directory in both panels
can be translated to this program as parameters - so there is a lot of
space for creation useful things.
And last, my thought about what is key features which isn't there yet
in mucommander:
- customizable toolbar
- packer plugin
- categories in bookmarks; I have to work to up to ten FTP, and I want
to have about 5-10 bookmarked directory. This looks not accurate :)
And what about to web-masters, they could have much, much more stored
fpt connections, maybe something else.
- synchronize dirs and file diff; however, one man is working on it;
- find files and list it to panel;
- background processing (copy/move/delete, etc...)
- fast lister, I mean really fast, which didn't copy whole file to
mem, and allow immediately view of many Gb file :)
and many more :)
Waiting for comment about plugin interface, I could start making some
POC;
Maxence Bernard
Thanks for taking the time to lay out your thoughts. Your offer to
participate in the development of muCommander is very much appreciated !
Here are my comments on the different points you raised. At this
point, we can just keep throwing ideas and discussing them ; we'll
come up with a proper plan to move forward later on.
> 1. Plugin is java-class, which implements certain Interface.
Agreed. This interface could be as simple as having only two methods :
init() and deinit() .
> 2. plugin can on register stage:
> - add MenuItem to main menu, or to any menu;
> - add MenuItem to context menu, and make it conditional-based (for
> example - some additional action only for extension *.foo)
> - add Item to root Folders;
> - add additional toolbar (I'm not sure yet what for :D )
> of course all this additional actions can have shortcuts;
By default, if we don't try to shield the muCommander classes away
from plugins using a separate classloader, a plugin will be able to
access all public classes/methods. That includes menu item
registration, toolbar customization, filesystem registration, etc...
Letting plugins access the whole muCommander API is IMO the easiest
and most flexible thing to do, even though that means plugins will be
able to do all sorts of non-recommended things that could break the
app. To limit the extent of that, we should as much as possible hide
(package protect) classes/methods that we don't want plugins to use,
and on the contrary provide guidelines to the APIs that are safe and
recommended to use.
> further, we need plugin features similar to total commander:
I agree with all of the different types you listed, though from an
implementation perspective they could all just be implementations of
the same Plugin interface ; they would just call different APIs on
registration, depending on the type of functionality they provide.
Note that for the most part, muCommander core APIs are already
pluggable, i.e. they support dynamic extension with registeration/
unregistration methods. Here are examples corresponding to the
particular examples you listed :
>
> - packer plugin - allow transparent work with specific archive
> types;
Archive format implementations can be registered dynamically in the
FileFactory class.
>
> - lister plugin - like F3 on image - we see image, not binary
> content;
Viewers / editors can be registered dynamically in ViewerRegistrar and
EditorRegistrar.
> - file system plugin - similar to packer, but target object could
> be not file.
Same as for archive format implementations, these are registered in
FileFactory.
> - file info plugin (like id3 tags, like width&height of video, etc)
This concept does not exist yet in muCommander : there is no unified
way to retrieve metadata from files.
> - syntax highlighting plugin (in future maybe some feature like
> intellisense, at least for special words)
The current com.mucommander.ui.autocomplete package supports dynamic
registration of 'services'.
Actions (see MucoAction class) are another core concept of muCommander
you may be interested in. They extend the notion of a Swing action and
allow new functionalities to be registered and associated with a
particular keyboard shortcut.
I'm sure we'll find some limitations and flaws in those APIs along the
way, but I think we already have some solid foundations that can be
leveraged by plugins.
I'll send another email shortly with some ideas that we had when
Nicolas and I toyed with the idea of adding plugins. To be
continued... :)
Cheers,
Maxence