Closed bertsky closed 2 years ago
Yes, sry, I did not test with touch pad – you're right!
Some sensible upper and lower boundaries might be prudent anyway.
It's really strange. This works, but after zooming out too much, you cannot ever zoom back in. (Fortunately that's not true in reverse.) It's totally unclear why the layout/context does never get updated at that point. Maybe just a Gtk bug.
I fiddled with another API option, get_pango_context()
instead of get_style_context()
, and that does work in a way, and does not suffer from that problem (of snapping into a low resolution). But it only applies to the line numbers, not the actual text content. (Therefore I left this commented.)
But the upper and lower boundary should prevent the crash, and the mouse wheel sensitivity should be honoured now.
218eadf fixes #32
Ok, now it works! The problem was that font.get_size()
did not return the exact size it got via font.set_size()
, but an int rounded to the next Pango.SCALE
tick. The resulting size was too small trigger the next tick for small sizes.
Ok, now it works! The problem was that
font.get_size()
did not return the exact size it got viafont.set_size()
, but an int rounded to the nextPango.SCALE
tick. The resulting size was too small to trigger the next tick for small sizes.
Wow. That drove me crazy. Should have thought about that possibility!
Thanks for the PR! I tried it and found 2 problems: 1) Zooming with a touchpad is much too fast this way, maybe it would be better to respect
delta_y
(for a mouse wheel tickdelta_y
is +/-1 for a touchpad scroll event it is something around +/-0.01)2) I run into a GTK related crash if I zoom in too much. I'll look into it.