This project is read-only.

Proposed New Design Approach for Menus/Toolbar/Ribbon

Mar 7, 2011 at 7:23 PM

Hi everyone,

In order to increase interoperability of plugins written for various DotSpatial based applications, Jiri and I would like to simplify and redesign the approach for menus/toolbars/ribbons as follows:

  1. Create a new generic interface for these things. We like the name "IHeaderControls" or "IHeaderControl" or something like that.
  2. Modify the AppManager so that a developer identifies the selected HeaderControl to use 
  3. Remove the Ribbon control from the main DS assemblies and build it into a separate assembly that implements the IHeaderConttrol interface
  4. Remove the DS Toolbar and build it into a separate assembly that implements the IHeaderControl interface.

Now a developer could use either header control (menu or standard) or could even develop their own header control (such as the Chrome style that basically does everything through one button), and the result is that every plugin can add stuff to any style of header control without re-compiling the plugins with specific ways of handling different headers. 

The interface for the header control would be something like this:

List of Items with standard Add, Remove, etc. on the list

a specific Item would have the following properites:

  • Name
  • Text
  • Picture
  • SmallPicture
  • Tooltip
  • StylePreference (MenuStyle, ButtonStyle, RibbonStyle)
  • ParentItem

StylePreference is just a "preference" that is an enumeration of some standard styles. The user could specify a style preference and that would just give some clues to the HeaderControl developers on how to best handle that item. This way if I'm developing a Ribbon header control, I could put some items in menus and some in buttons, etc. Or if I make up a new header control, I can decide how best to display stuff based on this preference.

We would really appreciate any feedback on this redesign idea since it would be fairly substantial.

- Dan and Jiri

Mar 8, 2011 at 6:59 PM

This sounds like a good idea to me. I have been uncomfortable with exposing actual widgets in the API because that makes it quite hard to change to new widgets in the future and it means that if I make a custom application that hosts DotSpatial plugins, then my application needs to use exactly the ribbon/toolbar/menu combination expected by each plugin. MW4 did a pretty good job of this, allowing MW4 to update to new .Net menu and toolbar controls when new ones became available in .Net without disturbing any plugins.

It sounds like this proposal is on the way toward working out how to use just a menu bar, or both a menu bar and toolbar, or a ribbon and let the plugin get its preference when possible or at least give it a control that works even if the plugin asked for something we don't have.

I picture the interface for a control including an event for when the control is activated.

I also picture the main application promising to automatically remove the control from the interface when the plugin that added it is unloaded.