2006-01-18: Added a new Goal, "powerfull commandlines", and removed what was mentioned about that in Ideas.
2006-01-21: Added the "Design?", "Guidelines?" and "Definitions?" sections. Added a two new Goals, batch commands and commandline return values.
The menu that shows up when you right-click on things has several names: right-click menu, shortcut menu, and context menu. This is my latest shell extension that involves around this particular menu. Promptly begun around the 1-year anniversary of ThumbView. A context menu screenshot:
The name comes from the idea that the shell extension itself is just a menu that mediates between a file and a command. Mediator is also a GOF pattern.
MediatorMenu is created to make context menu adding easy as pi. It is designed for easy manipulation of files in Windows Explorer by calling a predefined command line, passing information such as the filename, directory, etc. Such a command could be the image compress command line argument I used in last context menu articles (i.e. convert.exe %L" -quality 85% "%L" where %L is the filepath, given by Windows). The commands themselves are static, but by design it is possible to have dynamic parts by letting the receiver application allow the user to modify/extend the command before executing it. For an example, think of JPEG compression; a static command would be "Compress to 85%", such as the command line above, while a dynamic command would be "Compress image" that calls a Windows application where you can set the compression level and then compress.
I already described how one might do this without coding in my previous articles, but that method comes with a few constraints:
- Repetetive and error prone to duplicate one command for various filetypes
- No submenus
- No icons
- Static commands
The first constraint could probably be fixed with the use of .BAT files. The last constraint still remains, but, as noted, it is possible to fix that at the called application end; such as dialog boxes.
This idea comes from my converter utility idea This2That, where you can easily convert one file type to another by just right-clicking on it. Such as bmp -> png, 3ds -> md3, wav -> ogg, etc. Now, I hate reinventing the wheel, and I'm cured from Not Invented Here (NIH) , so I always based the idea on using other Open Source libraries for the actual conversion. The question was if it should connect to these libraries through DLL or something else. The answer is now clear; it will connect to commandline tools. This2That will be built with MediatorMenu!
I have some goals that I want MediatorMenu to achieve:
- Easily add/remove/edit new context menu items.
- Natural look in Windows.
- Optional icon for each menu item.
- Easily share created menus with others.
- Handle single files, multiple files, and folders (both base with and without subfolders).
- Ampersand in context menu items (verbs), allowing for keyboard selection.
- Support for normal application launch and Dynamic Data Exchange (DDE).
- The actual menu is defined by a XML file.
- Support for multiple languages.
- Powerfull commandlines. Additional information about the archive(s) clicked on, such as directory path and system variables (%PATH%, etc), through variables in the XML commandline.
- Batch commands. Several ways to operate on several files at once. Call the command once for each file, like image converting, call the command once and pas all files as parameters, as with tarballs, or other ways.
- Command return values. Capture the return value from comandlines, this should allow for querying and other advanced features to alter the menu behaviour.
I have some more ideas for MediatorMenu.
- An editor for the menu (XML) editing, guaranteeing that the XML is always well formed and scheme conformant.
- Easy distribution, Any Dummy(TM) will be able to add context menu items that will help their development team to be more efficient, but unless there's a shiny "Distribute" button not Any Dummy(TM) will be able to distribute it. The action should create an installer with the selected menu items.
- Extensions such as simple dialog boxes for dynamic commands. This2That could be viewed as an extension, but is actually more a distributed version (see item above). The idea is to please Python and other users that do funky stuff to their files which isn't really replicable in static commands, the simplest solution would be to open an dialog for the file where the coder can do the Python-magic but a more suitable solution should be created by an actual funky python programmer. The MediatorMenu project website could hold a package of "official" extensions and/or distributions.
Because of perceived usefulness , not everybody will agree with me. But I think right-clicking on a file and doing something with it without having to open an application is eXtremely convenient! There are several grunt operations that are just tedious, right-clicking allows you to execute that operation anywhere you see the file; browse dialogs, windows explorer, desktop, etc.
Ranked from easy to hard:
- Making coffee, including roasting the beans.
- Clicking on one file.
- Clicking on a folder or on several files, that are all of the same filetype.
- Do this recursively for all subfolders and files.
- Clicking on a folder or on several files, that include different types of files.
- Do this recursively for all subfolders and files.
With Microsoft's Component Object Model (COM)  you can hook up a context menu handler shell extension handler into windows that allows you to dynamically create menus inside the context menu. Normally COM's are created in C++ with the use of Microsoft's Active Template Library (ATL) . But my experiences with in when I created ThumbView formed the opinion that I don't want to use it unless I really have to. Although a new tendency is growing, using C# with COM. I would use this if it wasn't for the fact that many people are still resisting to install .NET, and I feel that MediatorMenu isn't a strong enough product to convince these people to install it. I'll just bite the bullet and do it in good-ol C++.
COM DLL's have an entry point, a function called when the DLL is loaded. And Windows caches DLL's so it won't be unloaded until some time after the last reference to it released it. This allows us to parse the XML on load and keep a fast lookup table in memory during the DLL's load-lifetime, everytime the menu is created all that's done is some lookup to create the menu.
To design the actual context menu and decide what and how it should mediate the commands I'll be using the eXtended Markup Language (XML) . XML Scheme will be used for validation, although how this validation is going to occur is not yet defined; it might be done using Internet Explorer or a standalone application, or it might even be done by MediatorMenu itself if a suitable XML library is found. But then again, validation could be safe if the XML file isn't manually edited but created through a UI. I was going to post about the XML structure, but I'm still evaluating several features such as Master filetypes and Master commands. I'm going to post it when I get a bit closer to actually implement the XML part.
MediatorMenu has been broken down into modules.
- FileMediator: A common base for MediatorMenu and another project; FileWatcher. More on that one later. ;)
- MediatorMenu Context Menu: The actual context menu shell extension. "the thing you see when you right-click on a file"
- MediatorMenu XML Menu Structure: The XML based configuration file for specifying the later generated context menu.
- MediatorMenu Editor: A wysiwyg editor that hides the XML Menu Structure by a easy to use graphical editor. Note: I'm going to use .NET 2.0.
This is going to be a open source project hosted on SourceForge. I'll contact them when I have a working beta out. But there is also another point to bring up; the idea is that it should be easy to share your created menu. The ideal would be other applications using MM for their context menu needs. Most often code created context menus can be replaced by simple commandlines.
This is a pretty advanced topic and discussing with DrunkenCoder brought us to two ideas. Basicly, it came down to two options.
- Either the application uses MM like a framework, a installed service, so that there is MM installed on the client computer that the application uses. Like .NET or DirectX.
- The other option is to have a MM with each application. Like commonly done with SDL.
There are alot of hidden problems in both approaches, I'll cover them in more detail at a later date. Problems like GUIDs, registration, what files MM consists of, etc.
"With great power comes great responsability." There will be a list of guidelines people using MM to create context menus should follow. I'll be adding to this list.
- Use as few items on the main context menu as possible, try to group your actions in submenus. Filling the users context menu with alot of options directly is just evil.
Random implementation ideas.
To support batch commands we simply use the Command pattern and pass a list of all selected files to the execute command, even if it's just one file.
There are several names for the different parts in context menus.
- Context Menu: the menu that shows up when you right-click on files.
- Menu Item: each clickable menu entry in a context menu.
- Sub Menu: a menu inside another menu.
 Not Invented Here (NIH) Wikipedia
 Perceived usefulness (PU) - This was defined by Fred Davis as "the degree to which a person believes that using a particular system would enhance his or her job performance". Wikipedia.
 COM Objects and Interfaces. MSDN
 Active Template Library (ATL) Reference. MSDN
 eXtended Markup Language (XML). Google