This is a prototype for how we might extend the ribbon from PyXLL extensions.

There's a bit of a hacky workaround with the config right now, because PyXLL parses it prior to loading extensions and then doesn't reexamine the ConfigParser object.

We have to specify two files, a default_ribbon and the normal ribbon. The default_ribbon is really just the old ribbon file and serves as a starting point. Then the extensions all submit their fragments to be included and they are combined by the extension loading code. Finally, we write out the new complete to ribbon xml to whatever file ribbon is set to, since PyXLL is hardcoded to load that.

It's not beautiful, but it works nicely.

This PR doesn't handle layout whatsoever. We have no control over the order in which extensions are loaded and there's no effort here to try to order the fragments smartly. If they extension submits a new tab it just goes at the end of list. If the extension submits an tab that matches an existing tab, the groups just get appended to that tab. If one knows the names of all the fragments, one can ask for them to be combined in a particular order, but there's no easy way to know right now.

The API might be nicer if we extract the element ids as the name rather than make the extension pass it in, which can be error prone. I'm not sure about this yet.

@tonyroberts this is the initial version of the package. I'll add a sphinx doc directory asap.

Can you review?

We need to add a license. I would suggest BSD.

I have pyxll installed, how to I start using your objectcache.

Is there any complete tutorial to show me how to import the module etc,

I would appreciate it if you could help.

Thanks

Charles

When printing multiindexes in pandas, values are replaced with '' if the previous index was the same at the same level, except for the innermost index. The pandastypes code does the same, apart from it doesn't skip the innermost level.

This PR simply bumps the version to prepare for a new release of pyxll-utils.

The major version bump is needed because the new feature to contribute ribbon fragments (contributed in #7) is backwards incompatible.

With the addition of the extension loading machinery, we are in a good position to allow PyXLL extensions to be easily deployed and discovered with no manual editing of config files.

What's missing from this is a way to contribute to the ribbon. One can imagine the plugin loading code might also receive an xml fragment from each plugin.

I don't know what the ribbon manipulating code looks like right now, but in the worse case scenario, we could write these ribbon fragments out into a single file and then load it the way we already do. The best case would be something like responding to ribbon update events from the plugins and handling it dynamically.