Thanks for adding qrun to Bazaar Explorer (revno 315)

[Ian Clatworthy]

Maritza Mendez wrote:
> 
> This is a very nice addition. 

It is. With a little more love, it could be a quantum leap forward,
bringing in the richness of dozens of plugins to the GUI. Here's what
I'm thinking:

1. Tweak the qrun UI.

2. Add configurable toolbars to Explorer that can call into it. e.g.
   right click on the toolbar presents a list of toolbars and you'd
   pick the one you want (or add one).

The goal is something like "I want to use a pipeline now. Switch to the
pipeline toolbar." Ditto loom, scmproj, rebase, builddeb, etc. Under the
covers, the various toolbar actions would just call into qrun to do most
of the work.

Here's my thoughts on tweaking qrun:

1. Turn the combo box holding the list of commands into something that
   allows easier finding of commands. "bzr help commands | wc -l" gives
   240 for me which is way too many entries for a flat list. I'm
   thinking something like ...

   Category:       Commands:      [ ] Show hidden commands
   +------------+  +-------------------------------------------------+
   Core            cmd-1    cmd-5
   plugin-a        cmd-2    cmd-6
   plugin-b        cmd-3
   plugin-c        cmd-4
   +------------+  +-------------------------------------------------+

   core is still 60+ which is a bit big so sub-categories may make sense
   there, e.g. Basic, Administration, Miscellaneous. When run from
   Explorer or qbzr-eclipse say, that would be quite useful because the
   Basic commands already have custom dialogs: it's the others (e.g.
   break-lock) which users will be looking for. Down the track,
   we can add logical categories, e.g. "Favorites", "Aliases".

2. Like "Insert Directory..." and "Insert Filenames...", add
   "Insert Options..." and "Insert Global Options..." buttons to help
   build up the parameter list. The first would use the metadata in the
   command object to build a basic form with checkboxes for boolean
   options, combo-boxes for registry options, text fields for string
   options, etc. The second would present a custom dialog that made it
   easy to turn on the various debug options (e.g. -Derror), profiling,
   etc.

3. Add a Reset button that reset the form so users could do that instead
   of having to Close and re-start qrun. See bug
   https://bugs.edge.launchpad.net/qbzr/+bug/486373 (raised by you).

Does that sound useful? If so, any volunteers to help with the various
pieces? They sound relatively independent.

Also, if this gains some momentum, I wonder what changes to bzr's
command infrastructure would help. Maybe we want to mark selected
commands as "interactive = True" and mask those out by default? Maybe we
also want to mark commands that assume fixed font output so that
"columns" within the output appear correct in qrun's display?

Nothing beats a well-designed dialog optimised for a task. OTOH,
investing a little into a generic solution like qrun could pay a large
dividend by providing a "good enough GUI" experience across 95% of our
ecosystem (thanks to bzrlib's well-designed Command+Option framework).

Thoughts?

Ian C.