git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[BUG gitk] strange scrolling behaviour if history canvas not completely filled

From
Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date
Mar 27, 2013, 13:35 UTC
Message-ID
<20130327133529.GA10464@pengutronix.de>
Hello,
(running gitk from Debian's gitk 1:1.8.2~rc3-1 package)

if only a few commits are shown in gitk such that the history canvas is too big, i.e. there is place for more commits to be shown, the scroll bar on the right hand side correctly is greyed out. Still I can scroll using the mouse moving the oldest shown to the bottom of the canvas (sometimes even half a line further). Not sure this qualifies as bug already.

But when having scrolled down selecting commits with the mouse doesn't work as expected anymore: If I click on the topmost commit, not that one is selected but the one that would appear at the mouse tip if the history were not scrolled down.

Best regards Uwe

PS: I'm not subscribed, so please Cc: me on replies.
-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Message 1 of 1 in “[BUG gitk] strange scrolling behaviour if history canvas not completely filled”
  1. Uwe Kleine-KönigMar 27, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.