Improving dt's UI

[Vlad Skvortsov]

David Wolever wrote:
>> ...so, am I understanding you correctly that you'd like to skip the 
>> version selection menu altogether if there is only one version in the 
>> "present" set? What if there are more than one? I'm talking about the 
>> current dt UI (not about that you are proposing below).
> I would like to skip as much interaction as possible, while still 
> ensuring that all the required fields (category, version, etc) still 
> exist.
> Now that I've got a patch, just take a look at that and see how it 
> does the defaults and such :)

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

The other minor annoyance was that, with that many categories and 
versions as we have, my lines all got wrapped in an editor and it took 
me more time to choose what I needed (dWdWdW...) than it would with the 
menu.

We could put all possible versions to the issue template, but it seems 
to defeat the purpose of simplifying the UI. ;-)


>> I would prefer to keep the number of commands to minimum, especially 
>> if there are ways to achieve the desired result using the existing 
>> ones. By the way, if your preference is to have a separate command 
>> for each logical action, this can be achieved by shell aliases.

[skipped]

> 0) Shell aliases don't work everywhere (eg, when I use `:!...` from 
> Vim, aliases don't work)
> 1) They aren't standard -- when I go to my friend's machine, he 
> doesn't have my aliases, so he either has to type a lot more (using 
> the internal commands) or duplicate my aliases.
> 2) It's not very standard to require long commands for common 
> actions.  For example, adding, moving, removing and copying are all 
> separate commands in svn -- it doesn't use something like `svn shell 
> --command=mv` (the exception, of course, is `propset`, but it's got 
> `propedit` too, so it's not TOO bad)

The points you are making are valid and I agree the aliases approach has 
drawbacks you mention. Ok, so what actions would you propose to promote 
to commands? Let's discuss that on case-by-case basis. :-)

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