Merge lp:~simon-kersey/bzr-explorer/add-bzrexec-tool into lp:bzr-explorer

Hi Simon,

This all looks ok to me. FWIW, your suggested test fails for me gumbling about ...

'QBzrRunDialog' object has no attribute 'init_button_status'.

That doesn't look like it's your fault though.

Before I merge this, I'd like slightly more detail on your plans. For example, are you planning to make "bzr-exec" a new kind inside tool_dialogs.py? Or a checkbox that only becomes active when the "Bazaar Command" kind is selected? If the latter, maybe we ought to model it that way inside the XML as well?

> Hi Simon,
>
> This all looks ok to me. FWIW, your suggested test fails for me gumbling about
> ...
>
> 'QBzrRunDialog' object has no attribute 'init_button_status'.
>
> That doesn't look like it's your fault though.

Mine is working with the following environment:

Bazaar (bzr) 2.1.0rc1
  Python interpreter: C:\Program Files\Bazaar\python25.dll 2.5.4
  Python standard library: C:\Program Files\Bazaar\lib\library.zip
  Platform: Windows-XP-5.1.2600-SP3
  bzrlib: C:\Program Files\Bazaar\lib\library.zip\bzrlib
  Bazaar configuration: C:\Documents and Settings\simon.kersey\Application Data\bazaar\2.0
  Bazaar log file: C:\SJK\Bazaar\log\.bzr.log

With the following plugins:

bzrtools 2.1.0b1
    Various useful commands for working with bzr.

explorer 1.1.0dev
    Version Control for Human Beings.

fastimport 0.9.0dev
    FastImport Plugin

launchpad 2.1.0rc1
    Launchpad.net integration plugin for Bazaar.

netrc_credential_store 2.1.0rc1
    Use ~/.netrc as a credential store for authentication.conf.

qbzr 0.18.0
    QBzr - Qt-based frontend for Bazaar

rebase 0.5.5
    Rebase support.

trunk 0.1.0dev
    Commands and Hooks to support Reserved Edit of files in Bazaar.

upload 1.0.0dev
    Upload a working tree, incrementally.

xmloutput 0.8.5
    This plugin provides xml output for status, log, annotate, missing, info,

>
> Before I merge this, I'd like slightly more detail on your plans. For example,
> are you planning to make "bzr-exec" a new kind inside tool_dialogs.py? Or a
> checkbox that only becomes active when the "Bazaar Command" kind is selected?
> If the latter, maybe we ought to model it that way inside the XML as well?

I hadn't given much thought to the UI. I was initially going to put this feature and support for %(selected)s in just through editing the tools.xml file. Then once that was working OK, look at UI support.

I suppose I would probably just add it as a different command type in tool_dialogs.py in the end.

The reason I wouldn't expose it on the UI initially is that it really only makes sense once you can select items on which to run the tool.

With regard to support for selecting items I was going use the fact that the tool action contained %(selected)s to determine whether it should be displayed or not. If it contained %(selected)s then it would only be shown if the working tree browser was shown. Then when you run the tool anything that was selected in the working tree would replace %(selected)s. (This goes back to a branch I submitted some months ago about toolbars and stuff)

The next part of my grand plan is to add tools to the working tree right-click menu. You outlined some thoughts you had on this. From that I sort of inferred the following as a way forward and would be interested in knowing what you thought.

Add a new file type, ContextMenus.xml.

Have separate <folder> elements within this file relate to particular UI features that might support a context menu, e.g. working_tree. Within the UI feature folder specify folders of tools that apply to items displayed in the UI feature. It's at this point that it starts to get complicated when you consider the working tree. The working tree displays...

OK. I'm happy with this patch so I'm merging it.

Can you email the qbzr mailing list please about supporting right click menus in Explorer's WT browser? I think that conversation is best held there (vs on this merge request).