Scenario: every once in a while I try to paste on my phone (in the
overflow menu) and fat finger and tap 'clear' next to it instead.
I could try adding space between the buttons in the overflow menu, but
that creates cascading issues of how it should look. Swapping these two
buttons is a hacky way to ensure that buttons that mutate the buffer
are never side by side.
I originally made this change to keep the next/prev buttons from
overwriting the search bar. But now the dropdown menu up top gets
overwritten by the scrollbars! You can only see it if the window width
is just right, as happens on my phone.
I could fix this perfectly, but at the cost of some code complexity.
Just take that slight visual ugliness for now, it doesn't seem to impede
anything.
scenario:
* run Carousel on a computer
* press ctrl+f
Before this commit, the search dialog that came up was occluded by the
output editor's scrollbar.
The reason is tooltips for buttons that lie along the left or bottom
edge of the app window. Since adding tooltips I noticed that the tooltip
on the 'next' button (which lies all down the right margin of the
window) would continue to be visible after the mouse moves off the
window. It turns out that LÖVE doesn't disable the mouse position
somehow after it goes off screen. It just remains at 0 or width-1 or
height-1.
Why was I not seeing the same issue with the 'previous' button? Kinda by
happy accident. The checks in button.lua were comparing using < and >,
not <= or >=. And the x coordinate when the mouse goes off window is 0.
So the quick solution is to remove one px of clickable area from the
bottom and right. It doesn't seem too hacky; the icon switches to
resizing the window anyway when you're _right_ at the border.
I'm also focusing now on the fact that pixel values in LÖVE go from 0 to
width-1 in spite of Lua's 1-based indexing in most places.
Hopefully this is easy to remember from left to right:
- run is F1
- stop is F2
- hide/show is F3
- save is F4
- load is F5
There are also tooltips to introduce these shortcuts to newcomers.
Most of the shortcuts are only enabled when code is visible. In keeping
with existing conventions for mouse events, we leave most event handlers
for the script when code is hidden. The only exception is 'F3' to show
code. So if you want to use a shortcut 'k' when code is hidden, you have
to instead use 'F3 k F3'.
This is all tentative and open to change. But I'll probably grow more
reluctant to change the shortcuts in a few weeks or months.
scenario:
- create a long wrapping line
- tap past end of first screen line
Before this commit the cursor would be positioned not quite at the end
of the screen line but one character before. In effect there was no way
to position cursor at end of a wrapping line.
I'm not sure how this bug has lasted so long. It was introduced in
commit 8d3adfa36 back in June 2022, which was itself billed as a bugfix
for "clicking past end of screen line". But when I go back to it this
bug exists even back then. How did I miss it?! I wrote a test back then
-- and the test was wrong, has always been wrong.
Kartik K. Agaram