Eric J. Smith wrote:
>>- The commit dialog already has enough buttons. More buttons would just
>>clutter the dialog and make it too complicated. If a button, then where?
> I think both of these options should just be on the right-click context menu
> for the log message textbox. Then you could get rid of the big fat "Paste
> Changed Filenames" button. I would do something like add a "Insert" menu
> item on the bottom of the context menu and then have sub-items in that menu
> for "Changed Files" and "Issue Numbers".
Are you suggesting to change the commit dialog even without having this
feature? Moving the "changed files" button into a context menu item?
>>- The available bug ID's should be fetched automaticaly without any user
>>intervention. Then, they should show up like the autocompletion while
>>the user is typing --> a special char has to be defined to trigger it.
>>How define that trigger char? Separate property? Regex?
> To me having the numbers in the auto-complete list would be fairly useless
> because you either know the issue number and you just type the 3 or 4 digit
> number in or you don't know it in which case you want to look it up. How
> useful is it that you auto-complete a cryptic number for me? Unless of
> course you could do something like VS.NET does and show a tooltip to the
> right of the auto-complete list item that shows a short description of that
> issue number.
It wouldn't be completely like an autocompletion! It would show (in the
same way the autocompletion works) e.g. "Issue #123 : the program
crashes when you start it!", but then when you select that entry in the
autocompletion, only "Issue #123" or just "123" would be inserted into
the edit box.
> What if instead of allowing us to pass in the SVN username, you just allowed
> us the ability to pass in the current windows username? That information is
> pretty easy to get from the windows API. I would think this would just be a
> variable that would be available to use in the issue API query string if we
> wanted to use it.
VERY bad idea. That would also mean that you'd have to choose the same
username in the issue tracker as your login name is. That's something
you should never do! Your login name should _never_, _ever_ be something
you pick for other things, especially not if the issue tracker is
located somewhere on the internet.
> I think the issue API should allow for specifying a search term and then in
> the find issue dialog I could type something like "post-commit" and it would
> show me all the issues with that keyword in it. That would make finding
> unknown issue numbers much easier and it would take away a lot of the pain
> of not being able to filter by user.
> Also, in the find issue dialog I think it would be critically important to
> show a short description of each issue.
That would make the "fetching automatically" part impossible. And then,
what's the difference in firing up the browser and specify the search
We're talking here about making things easier and most of all _faster_
for the user. If the user has to enter several things before the list of
issues is available, then it won't be faster than with a webbrowser.
>>- Issue trackers usually require the user to login first. This requires
>>authentication (user interaction). Since the list should be fetched
>>automatically, this would interrupt the user while (s)he is typing the
>>log message --> not very UI friendly! Better ideas?
> I think you can skip the authentication. Either we don't care about auth
> for showing a read only list of issue numbers and we just write API's that
> don't require auth or we are out of luck and we can't use the feature. :-)
What about using Subversion in a company? There the issue tracker
definitely will require a login - so they all can't use that feature.
And if so many people can't use a feature, it's not worth the amount of
work needed to implement it.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Feb 21 20:15:40 2005