nativefs doesn't work on iOS since LÖVE v11.5, so I should stop using it
at least on forks for mobile devices.
I still use it in a couple of cases:
* on a file DELETE request from the driver
* when trying to write modifications from the driver to the original
location
Current design choices:
* Unstashing doesn't delete the file. You have to bump down to the
scratch screen for that.
* Can't unstash if the file already has local modifications. Decide
whether to revert or stash them.
I'm scaling down my ambitions. Stashed files can't have notes attached.
I think that encourages a higher scale of development on such apps than
is currently justified, given you're liable to lose all your work if you
upgrade LÖVE.
New plan: just name stashed files with a numeric suffix.
The remaining open question is now around unstash. Should unstash copy
or move?
We can create them and see them on the file dialogs, but not yet load
them back.
I want stashed files to remember the original filename. I think that
implies the ability to add a note to them. But I don't yet know how to
represent the note on disk.
And this creates cascading questions, like should editing a stash file
continue to modify it or create a new version? How to create a new
version? Should unstash copy or move?
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.
Kartik K. Agaram