Improving dt's UI

[Vlad Skvortsov]

David Wolever wrote:
> (sorry about the delayed reply -- I've been offline the last couple days)

Nevermind, I can be out of the project for *weeks* and everyone still 
tolerates me! ;-)

>> I've applied the patch and tried that out just now. While I found it 
>> quite convenient actually, that reminded me of why we went the menu 
>> direction in the first place. The version set (e.g. available 
>> versions for an issue) depends on the category. Several categories 
>> can each have its own version set (and it can be quite long).
> Yea, I couldn't think of a good way of solving that.
> I don't know how people in general use it, but I've found that (with 
> issue tracking in general) I rarely use more than one or two 
> categories, so the hope was that it was "probably better than nothing".

I was thinking about this issue the other day and here is what I have in 
mind (we need to flesh it out, of course).

What if we modify dt to support templates? Well, actually templates for 
templates as you'll see in a moment :-)

When 'dt new' is invoked with an extra argument, that argument is 
treated as a template name. The templates are just files somewhere in 
'issues/etc/dt/templates', so 'dt new fe' will make 'dt' use 
'issues/etc/dt/templates/fe'. The template might look like:

===
Category: product/frontend
Due-in: $(VERSIONS_FUTURE)
Reported-for: $(VERSIONS_CURRENT)
...
===

So dt would go ahead and process the template and use the result as a 
template for the editor (hence 'templates for templates'). Thus there 
are no menus and the editor pops up immediately. Once the editor is 
finished, we check the headers for consistency and if there are 
problems, we tell exactly what they are and either offer some reasonable 
defaults or let the user go back to the editor.

This is of course almost the same as accepting category name as a 
command line argument to 'dt new', but provides additional flexibility 
at (seemingly) very small cost.

How does that sound?


[skipped]
> So, if I had my way, these commands would be added:
> - close: accepts --fixed, --invalid or --dropped (but defaults to 
> --fixed)
> - ed: edit a ticket, including all the headers and the body
> - sh: open a shell which DT commands can be executed from.
> For example:
> $ dt sh
> > ls
> 1 open Fix the widget
> 2 closed Link foo to bar
> > new
> ... create a new ticket ...
> > close 1
> ... go through the steps of closing ...
> Where each of the commands is identical to running `dt $cmd` from the 
> shell.
> (I'd like this because my poor mac takes a second or two to start up, 
> and it's really frustrating when I've got to run two or three commands 
> in sequence).
>
> So that is the list of things that I would find useful.
>
> What do you think? 

You know what, I've thought about the shell idea and I like it a lot. I 
also assume that you are long for e.g. the 'close' command just because 
working with current dt's command line arguments is ugly. I mean, this 
is ok for scripts but for interactive work it's not as convenient.

With the shell we might improve the UI significantly without adding a 
bunch of new commands. Also (what I'm missing a lot) we'd be able to use 
readline and autocompletion and stuff; basically there are more 
possibilities because we keep the context between commands.

So, the question is, assuming we have a 'dt shell' command with 
easy-to-use commands, autocompletion, etc, would you still need these 
commands you mention ('close', 'reopen', etc)?

-- 
Vlad Skvortsov, vss at 73rus.com, http://vss.73rus.com