bzr-explorer-dev team mailing list archive

[Ian Clatworthy <ian.clatworthy@xxxxxxxxxxxxx>]

Simon Kersey wrote:

> Has any thought been given as to how to integrate command line plugins
> with Bzr-Explorer?

Yes. As luck would have it, I sat down and designed an extension
architecture for explorer last week while on some annual leave.

It would be *great* if you wanted to help me put it together.

> My thoughts were the following:

> (1)    Bzr-Explorer needs a way to allow the user to edit and produce
> customised toolbars.

I'm open to the idea of custom toolbars and custom entries in the main
menu. However, I'd like to get some other things going first, partly
because having a standard main menu and a fixed set of toolbar layouts
makes support a bit easier.

My initial target for plugins is adding things to the toolbox and to the
context menus in the working tree browser. I agree that the toolbox
layout is crappy. It should be a panel under the WT browser and the
tools should be displayed differently. I'll try and fix that in coming days.

> (2)    Bzr-Explorer needs a way to allow the selected items in the
> working tree widget to be passed to the user defined tools when they are
> run.

Agreed.

> I have attempted a quick hack where I changed the toolbox code to
> produce top level toolbars as well and changed the code that runs the
> tools to use the qrun --execute option and to get the selected item(s)
> from the treewidget to pass as the ‘%selecteds’ command placeholder.
> This seems to work quite well.  I have also had a look at adding
> functionality to qbzr treewidget to support adding items to the
> right-click menu.

Cool.

> My main problem is that I need some overall guidance on the structure of
> incorporating these ideas – if people think they are worthwhile.

> Do I create some additional xml entities for tools.xml to allow tools to
> be added to the toolbox; toolbars and/or treewidget right click menu?
> 
> Or should these be in separate files, e.g. toolbartools.xml;
> rightclicktools.xml?

> With regard to plugins extending Bzr-Explorer should a plugin define an
> Explorer directory which contained tools.xml and some icons and have
> Bzr-Explorer search through the plugins for tools.xml files?

Here's the plan. Where possible, I want plugins to extend Explorer by
putting xml and txt files in a directory called "explorer". On startup,
explorer will search for these folders. In some cases, explicitly
registering Python code will require calls to Explorer APIs (e.g. custom
workspace initialisation routines). Needing to call APIs should be the
exception though.

Note that explorer already have a "profile path" that it uses internally
for building its UI. Right now, there are 3 places searched on that path:

* plugins.explorer.lib.std_profile
* ~/.bazaar/explorer
* the selected "hat" if any.

The explorer directories provided by plugins will simply appear 3rd on
that list.

Right now, explorer supports 2 types of extension points:

* tools
* bookmarks

I intend to expand that to cover:

* alerts - icons that appear in the status bar when certain conditions
  are met
* welcome extensions (add new sections, actions or help)
* topics (linked to from welcome help say)
* reports - tabs that appear on the repository view (ala Recent History)
  or the Status view or both
* preferences (that tools, alerts, reports, etc. can use).

All of these will be defined by xml files except for help topics which
will be ReST.

Returning to tools in particular, I want to use just the one file -
tools.xml - with predefined folder names for context menus (and
ultimately toolbars):

* ItemContextMenu will hold the entries for right-click in the
  WT browser
* LocationContextMenu will hold the entries for right-click in
  the repository browser (later)

When building the toolbox, folders with names ending in ContextMenu will
be skipped. Also, toolbox building should be smarter so plugins can put
entries into existing folders (like Register Project On) rather than
create a second folder with the same name.

The "Add Tool" dialog will get additional fields as follows:

1. Destination: a combo will entries:
   * Toolbox
   * Item Context Menu

2. If the latter is selected, a group box will appear ...

[ ] Only enable tools for some items types
    [ ] Changed             [ ] Added
    [ ] Unchanged           [ ] Deleted
    [ ] Ignored             [ ] Conflicts

The selections in the group box (like Changed) are only enabled if the
top level checkbox for the group box is enabled. Make sense?

Within the xml file, these checkboxes get mapped to an attribute called
conditions, a space separated list of keywords. That data is then used
to decide whether a given action is shown (or enabled?) for a given type
of item.

If all of that sounds ok by you, let's work together on making it
happen. I'll make the changes for searching for the explorer directory
and a nicer toolbox. Perhaps you could work on getting the item context
menus going and the enhanced Add Tool dialog? Once that's done, we can
discuss custom toolbars.

Sound OK?

Ian C.