* [BUG gitk] strange scrolling behaviour if history canvas not completely filled
@ 2013-03-27 13:35 Uwe Kleine-König
0 siblings, 0 replies; only message in thread
From: Uwe Kleine-König @ 2013-03-27 13:35 UTC (permalink / raw)
To: git
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/ |
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2013-03-27 13:36 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-27 13:35 [BUG gitk] strange scrolling behaviour if history canvas not completely filled Uwe Kleine-König
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).