On Sun, Oct 28, 2007 at 11:13:43PM +0000, Paul Mackerras wrote: > Pierre Habouzit writes: > > > As you seem to be the guy to ask for, I've a couple of requests wrt > > gitk. > > > > * the diff window is quite bad with merge commits, the colorization is > > rather poor, and the last version you just merged isn't especially > > better. > > That's not a request, that's a grizzle. :) What would you like it to > look like? I believe that git show/diff has it right: lines with a + should be in the "added" color, and lines with a '-' in the "removed" one. gitk only take the first "column" of +/- into account or sth I find awkward at best, and I often go to the console to see a merge commit because of that. > > * the 'sha1' input field is a major pain in the UI: the cut&paste > > interaction is very poor. I don't know why, but it's often very very > > hard to really copy the sha id, probably because it's selected by > > default. > > It's selected so that the contents are in the cut buffer and you can > paste them in an xterm with middle-button. Possibly I need to check > that control-C (or command-C under macos) is properly bound to copy. Well, doing ^C doesn't always copy it (probably a glitch wrt which input has the focus), and it certainly doesn't synchronize with the cut buffer for me. And it doesn't work for anyone at work either. I use ion with the KDE clipboard manager (klipper -- because I never managed to find a clipboard manager that is as good yet, not depending upon KDE), and at work most people use KDE, with the same klipper. Maybe it's a bad interaction, I should try to use it under gnome or so to see if it is. > > * the fact that it remembers the position where it was in the WM when > > it was closed is really annoying. the WM is supposed to place the > > window. With at least ion3 and xinerama it often shows up on the > > wrong screen. Remembering the window size though is fine. > > That came in with some changes that make gitk start up correctly under > windows. I could see about making it set the window position only > under windows. That'd be really great. > > * still wrt the layout, the focus is quite cumbersome. Gitk would be > > really really really nice to be used only from the keyboard, but > > because of a very unclear focus policy, it really isn't for me. > > Maybe it's just me, and I know this may not be 100% helpful, but I > > never know which part of gitk will receive my keys (history part, > > diff part, tree, ...). > > What focus policy would you like? Well, what would make sense (to _me_ at least) would be some shortcuts to move to the history panel (say e.g. using F1), or to the diff view (using e.g. F2), or in the file list (say F3). That would hilight with a black 1px line (like it does for other inputs fields) to say that this is the primary window part that takes the keyboard inputs atm. And when doing that, if you press 'down' or 'up' it would scroll the adequate panel. It's really confusing that the keyboard (or hjkl) right now always make the history change. This way you can make the difference between the keyboard shortcuts that apply to the focused part of the window (up/down, pgup/pgdown are IMHO of that kind), and the one that the user (or the default gitk) has associated to a specific part, no matter if it has the focus. E.g. J/K (or for emacsish people ^N/^P) could always move the history, that would make sense. Cheers, -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpLBqd6N1eUx.pgp
Description: PGP signature
