bzr-explorer-dev team mailing list archive

[Ian Clatworthy <ian.clatworthy@xxxxxxxxxxxxx>]

Simon Kersey wrote:
> 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.

This bit is now available in rev 395.

>> 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.

Appending is working but replacement isn't yet supported.

> So toolbars and their tools will be handled via a completely separate .xml 
>  file to toolbox tools. How will plugins affect these toolbars?

They can append to them if they wish. Replacement is coming later. See
below.

>  Will there be a toolbar.xml file in the plugins explorer subdirectory?

Optionally, yes.

>  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.

That's the plan, yes. I'm thinking of adding an attribute to a
ToolFolder called "existing" with values of "append" or "replace".
Suggestions about alternative names welcome.

BTW, this is a small (10-15 minute) change code-wise to
toolbar_builders.py. (The bigger issue is getting the naming of the
attribute right. :-) )

> 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)

Take a look at rev 395 and give it a try. I think it works pretty
nicely, partly because one can define toolsets that get reused across
multiple toolbars. There are also 2 magic toolsets called prefix and
suffix that you can extend to put actions onto every toolbar.

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

My feeling here is that we ought to define another Extension Type called
either Popups, ContextMenus or simply Menus. Folder names would indicate
whether items are appropriate for working tree items (in the WT browser
or even the status report) or locations within a repository browser. The
latter currently have no context menus and I find that annoying.

For example, folder titles (in menus.xml) might be:

* kind:branch - add these to the context menu for branches
* status:unversioned - add these actions to items in the status report
  and WT browser popups
* File - add these items to the File menu (above Quit).
 [post 1.0 feature]

> 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

> 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.

+1 on all of this.

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

Perhaps. I'm really unhappy with the rendering and placement of the
toolbox currently. I'm leaning towards making it a tree and rendering it
below the WT browser. That will fix some of the issues you mention and
make the impact of hat switching more visible. It doesn't rule out
having a toolbar linked to the WT browser though. I suspect we still
want that.

Ian C.