1. The plugin will be split into components instead of one big interface.
2. There are three interfaces that I see so far. A tool interface(for new tools), a Menu interface(for adding new menus to the menu bar), and a MenuItem interface(for adding menuitems to already constructed menus).
3. The Menu interface will have a single method:
public JMenu getJMenu();
4. The MenuItem interface will have a single method as well:
public Map
The Map will be mapping JMenuItems with AvailableMenus.
5. The Tool interface is the next thing to be considered.
to be continued...
2 comments:
You can probably start defining these as genuine Java interfaces and commit them to the repository.
A note on naming: you should probably append "-PlugIn" to each name. To wit:
public interface MenuPlugIn {
public JMenu[] getMenus();
}
Additional naming tips:
1. Don't include the "J" in method names; the "J" is a Swing prefix and we don't really need to bind Swing to the method names.
2. Notice how I changed the menu method to returning multiple menus instead of just one. Just a thought; it is possible for a plugin to supply multiple menus.
3. The notion of "available menus" probably needs additional detail; I figure actually trying to write the interface will help shake that down.
4. ToolPlugin will probably behave a lot like MenuPlugIn, except that you'll be returning some list of tools. If not already available, you'll probably need to add a way to present tool visuals such as an icon, tooltip (no pun intended), etc.
OK, I think that's what I've got so far...
Action items based on our 4/5/2007 discussion:
- Map a captured gesture from the gesture tool into an Jig drawable (contact Dave Hoffman if necessary)
- Envision the interaction between the trainer and tool; i.e., if a user trains a new gesture: (a) how does the user map that to a new Jig shape? (b) does the trained shape become available immediately, or does it need to be saved first? etc.
Post a Comment