Age | Commit message (Collapse) | Author |
|
Wow. This is pretty old.
|
|
|
|
|
|
Closes #100.
|
|
|
|
|
|
|
|
This reverts commit 1a5d29ec
|
|
|
|
|
|
|
|
|
|
|
|
This means that mouse events are propagated upwards the widget tree
until they are processed or the root panel is reached.
Code duplication in mouse handling was reduced by moving all logic
into a new MouseInputHandler helper class. (I'd obviously have them
directly in the screen classes if there was only one.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.3.4 was a broken build.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Changed the MatrixStack translation to direct GL translation
via RenderSystem. I've already fixed this bug in the 4.0 branch
by using MatrixStacks for texture rendering, but that won't work here.
|
|
|
|
|
|
Apparently having a client-only-typed field referenced in a lambda body
can be dangerous, so I moved the packet registration to the client
init class.
|
|
|
|
|
|
|
|
Use the movable area (ie. scroll bar length minus
handle length) instead of just the scroll bar length.
This makes it so the handle actually feels like it's sticking
to the cursor while scrolling.
|
|
|
|
:tiny_potato:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|