Bazaar Explorer

Code review comment for lp:~simon-kersey/bzr-explorer/add-bzrexec-tool

add-bzrexec-tool
Merge into trunk

Revision history for this message

Simon Kersey (simon-kersey) wrote on 2010-04-01:

> 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 different types of things (files, directories, links) which can have different states (added, modified, deleted etc.). In an ideal world you would probably want to support being able to specify a tool to add to the right click menu of any modified file. So potentially something like:

which could support multiple types or states with a delimited list, e.g. '... types="file,dir"...'.

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

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 different types of things (files, directories, links) which can have different states (added, modified, deleted etc.).  In an ideal world you would probably want to support being able to specify a tool to add to the right click menu of any modified file.  So potentially something like:

which could support multiple types or states with a delimited list, e.g. '... types="file,dir"...'.

« Back to merge proposal