{"thread":{"id":"977","subject":"Re: qgit-0.6","startedAt":"2005-06-19T19:54:45Z","lastAt":"2005-06-19T19:54:45Z","messageCount":1,"participants":["Marco Costalba"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"5048","messageId":"20050619195446.4183.qmail@web26302.mail.ukl.yahoo.com","threadId":"977","inReplyTo":null,"subject":"Re: qgit-0.6","fromName":"Marco Costalba","fromEmail":"mcostalba@yahoo.it","sentAt":"2005-06-19T19:54:45Z","receivedAt":"2005-06-19T19:54:45Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"Ingo Molnar wrote:\n\nthanks for your feedback\n>\n>works fine here and is nice and fast, but there are a few minor visual \n>glitches:\n>\n>- annotated file contents are not properly aligned over each other. E.g.  \n>  check commit 7875b50d1a9928e683299b283bfe94778b6c344e in the current \n>  git repository, and select read-tree.c and view it annotated - the \n>  lines start right after the author field ends, not in any aligned way.\n>\n\nYes, it depends on variable spaced font, If you note the number of characters of the header of\neach line is always the same and is calculated for each file (the gray color part has always a\nfixed number of chars). I have already switched to a fixed font (courier) in my tree,\nplus others little things like truncation if exceeds a maximum lenght with \nfirst name collpasing (Marco Costalba -> M. Costalba).\n\n\n>- the tree visualization is hard to follow - gitk's output is much \n>  nicer. As an example of nice rendering check out the octopus merge \n>  around commit 211232bae64bcc60bbf5d1b5e5b2344c22ed767e. One glance at \n>  the gitk output shows what happened - qgit's output is in essence \n>  unreadable.\n>\n\nYou are definitely right! The problem is graph is not drawed! I precalculate at startup all\nthe diffrents pixmaps and put in a vector, drawing a graph is just correct indexing\nthe vector for each lane and do some bitblt. This is because QT has good pixmaps handling in\nQListView ( the main log list) but not line drawings capapility and because this way is very fast.\nBut in any case I definitely have to find something better. Suggestions are welcomed :-).\n\n>and a few requests for enhancements if you dont mind:\n>\nmore then welcomed.\n\n> - in annotated mode, it would be nice to select a particular line \n>   and then double-click would jump to the commit that added that line.  \n>   This would nicely round up annotation support.\n>\n\nOk, I'll add this. By the way, now you can select the corresponding commit in the \nhistory list above file content (it's the one with the same number) and the\n main view will update. \nI can make the selection: 'line content number -> line history number' automatic and that\nshould be enough.\n\n\n> - plaintext search capability in every window. E.g. in the annotated\n>   file window i often would like to search for some code, or to jump to\n>   a given line.\n\nOk. I'll add this.\n\n\nMarco\n\n\n\n\t\t\n__________________________________ \nDiscover Yahoo! \nStay in touch with email, IM, photo sharing and more. Check it out! \nhttp://discover.yahoo.com/stayintouch.html\n"}]}