[Bzr-explorer-dev] Integrating Plugins with Bzr-Explorer

[Simon Kersey]

Hi,

I've had a chance to think about your comments

Ian Clatworthy wrote:

> Firstly though, here's an update on my thinking re custom toolbars ...
>
> I want to have different toolbars for different location kinds, e.g. the
> actions for a repository will be different to those to a branch,
> bound-branch or checkout. For example, 'switch' might be on the toolbar
> shown for checkouts while multi-pull might be on the toolbar for
> repositories.
>
> I want users to be able to tag locations with a "logical kind" as well.
> For example, you might want to say this is a "review branch",
> "pipeline", "packaging branch" or (bzr-builder) "recipe". A new dialog
> will be added (File --> Properties) that shows the name and kind of a
> location and lets you set/unset the logical kind. (BTW, logical kinds
> will have icons that are displayed in place of the actual kind's one on
> tabs, etc.)
>
> Behind the scenes, the toolbar for each kind will be defined in a folder
> of that name inside toolbars.xml. Users and plugins will be able to add
> their items or replace the standard toolbars. They will also be able to
> add toolbars for logical kinds, e.g. the toolbar for a "review-branch"
> may have actions like Pull, Merge and Revert but it won't have a Commit
> action.
>

So toolbars and their tools will be handled via a completely separate .xml 
 file to toolbox tools. How will plugins affect these toolbars?
 Will there be a toolbar.xml file in the plugins explorer subdirectory?  If the 
 plugin is going to replace the existing toolbar will there be some sort of
 flag in the <folder> definition to indicate that it is to replace rather than
 append to the existing folder.

The only slight pain that I can see is the plethora of toolbars that may 
 need to be defined.  If you create a plugin that wants to add a toolbar tool
 that is always visible you will need to add it to a lot of toolbars. Either that
 or there will have to be a sort of toolbar hierarchy:
 (a) Common/Standard (always visible)
 (b) Location kind based (visible based on location kind though you
      might want to customise the standard toolbar to remove stuff...)
 (c) Logical type based (visible based on logical type of location)
	[possibly if have logical it supersedes location kind?]
 (d) User defined ? (my customised set of tools on my toolbar 
      - always visible for me)

I probably prefer the idea of defining a toolset and then saying how
 it should be displayed (menu, toolbar, toolbox ...) and under
 what conditions it should be shown (location kind/logical type)
 - rather than defining many different toolbars with different names where
 the names indicate when they should be shown

Will this also be the case for right-click menu options on the tree browser?



> > http://code.launchpad.net/~simon-kersey/bzr-explorer/update-tool-defs
>
> > (2)    <tool … applies=”toolbox toolbar menu wt_menu” /> -  to specify
> > to which GUI items a tool can be added
> > 
> > (3)    <folder … add-to=”toolbox toolbar menu wt_menu”> - to specify to
> > which GUI items a toolset should be added
>
> Given my comments above, please remove toolbar from the list of
> supported values.
>
> I'd also like to hear some feedback on how useful it is to have tools
> that only appear in the Tools menu or Toolbox but not both. Currently,
> it's a "feature" that there's one set of tools and 2 ways (Tools menu or
> Toolbox panel) for launching them. *If* we decide it's better to keep
> the 2 in sync, then we're down to menu vs wt_menu. In that case, I
> wonder whether those should be multiple exclusive, i.e. this tool is
> either item-selection-dependent or it isn't?
>
> > (4)    <folder … linked=”wt”> - to specify that the toolset was linked
> > to the working tree (so would only be visible when it was visible)
>
> This sounds interesting. I'm curious as to how you're using this to
> improve the UI experience! If you get a moment, could you outline an
> example folder of WT actions you've defined?
>

Well - a long time ago now - I wrote a plugin to support reserved edit.
 It had commands like red-lock and red-unlock which require a file/folder 
 to be selected for locking/unlocking.  When locked a file is available for
 edit otherwise it is not.

So to make it easier for the hard of command-lining I created a toolbox
folder with the commands as tools. I tried this out but found various
 issues:
- Couldn't select file in working tree
- Command not run immediately
- Toolbox behind working tree so button not visible
- Toolbox docking didn't allow sensible arrangement so that
  working tree and toolbox tools could be visible

This was where my drive to improve the toolbox/toolbar things came
from. Basically the best solution I found was to have a right docked
toolbar that was only visible when the working tree was enabled. [OK
the ideal solution would be to add them to the right click menu of
the working tree browser but that looked a little too difficult.]

The reason why the toolbar visibility is linked to the working tree being
 visible and enabled was that the tools (red-lock; red-unlock) only
 made sense if the user could select files or directories on which
 to run them.

This is how the working tree dependency was designed to be used.

Basically you could define tools that would take a selected item and
 perform an operation on it and only have them visible when the
 working tree was enabled for the user to select from.

The principle behind it being don't show the user commands that are
 not valid in the current context.

> Was --execute added as a generic q* feature or is it only
> supported for some commands?

I only added it to qrun as this was how toolbox tools were
 executed. In principle it could be added to the other commands.

Interestingly you could then have different tool behaviour on the Tools
 menu to the toolbox/toolbars.  Tools on the menu could provide 
 you with the dialog (i.e. without the --execute) and tools in the toolbox/
 toolbar would just execute with a (hopefully sensible) default set
 of arguments. 

I should have some time later this week to take out support for toolbars 
 from the parsing of the tools.xml. I'll try and get a merge proposal done 
 then.

PS I quite liked the right docked toolbar - could the toolbox be done in
 a similar fashion?


The information transmitted is intended only for the person
or entity to which it is addressed and may contain
confidential and/or privileged material. If you are not the
addressee, any disclosure, reproduction, copying,
distribution, or other dissemination or use of this
communication is strictly prohibited. If you have received
this transmission in error please notify the sender
immediately and then delete this email.

Any representations or commitments expressed in this email
are subject to contract.

This message has been scanned for viruses and dangerous
content. However, it is essential that the recipient also
checks this message using commercially available mail
scanning and anti-virus software. IPL Information Processing
Limited accepts no liability for any loss or damage resulting
from any virus or other dangerous content in this message.

IPL Information Processing Limited is registered in England
and Wales under company registration number 1418818.
Registration took place at Cardiff on 10 May 1979. IPL
Information Processing Limited's registered office and
normal place of business is Eveleigh House, Grove Street,
Bath, BA1 5LR, United Kingdom. IPL is also registered for
Value Added Tax (VAT) under registration number GB 601 2931 83.