| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
|
| | | |
|
|\| | |
|
| |\| |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We'll end up calling Text.redraw_all anyway, which will clear starty and
much more besides.
We'll still conservatively continue clearing starty in a few places
where there's a possibility that Text.redraw_all may not be called. This
change is riskier than most.
|
|\| | |
|
| |\| |
|
| | | |
|
|\| | |
|
| |\| |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Just checking mouse.isDown works if the editor is the entirety of the
app, as is true in this fork. However, we often want to introduce other
widgets. We'd like tapping on them to not cause the selection to flash:
https://news.ycombinator.com/context?id=38404923&submission=38397715
The right architecture to enforce this is: have each layer of the UI
maintain its own state machine between mouse_press and mouse_release
events. And only check the state machine in the next level down rather
than lower layers or the bottommost layer of raw LÖVE.
|
|\| | |
|
| |\| |
|
| | | |
|
|\| | |
|
| |\| |
|
| | | |
|
|\| | |
|
| |\| |
|
| | |
| | |
| | |
| | |
| | |
| | | |
I'm not sure this can trigger everywhere (I've only been able to
exercise it in Lua Carousel), but it seems like a safety net worth
having against future modifications by anybody.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit doesn't guarantee we'll always catch it. But if this
invariant is violated, things can get quite difficult to debug. I found
in the Lua Carousel fork that all the xpcalls I keep around were
actively hindering my ability to notice this invariant being violated.
|
|\| | |
|
| |\| |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This came up when trying to integrate my apps with the vudu debugger
(https://github.com/deltadaedalus/vudu). In general, it's a subtle part
of LÖVE's semantics that you can modify event handlers any time and your
modifications will get picked up. Now my Freewheeling Apps will follow
this norm as well.
|
|\| | |
|
| |\| |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Each one should provide a message that will show up within LÖVE. Stop
relying on nearby prints to the terminal.
I also found some unnecessary ones.
There is some potential here for performance regressions: the format()
calls will trigger whether or not the assertion fails, and cause
allocations. So far Lua's GC seems good enough to manage the load even
with Moby Dick, even in some situations that caused issues in the past
like undo.
|
|\| | |
|
| |\| |
|
| | |
| | |
| | |
| | | |
We have an early exit for 'error' mode in this function.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In particular, I want to be able to switch to 'error' mode rather than
throw a real error() on test failures, because that's a little more
responsive and might be recoverable. (On some Android devices the font
is slightly different, and tests fail as a result.)
|
|\| | |
|
| |\| |
|
| | | |
|
| | | |
|
|\| | |
|
| |\| |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
before:
stack traceback:
[string "text.lua"]:9: in function 'draw'
[string "edit.lua"]:200: in function 'draw'
[string "run.lua"]:140: in function 'draw'
[string "main.lua"]:162: in function <[string "main.lua"]:155>
[C]: in function 'xpcall'
[string "app.lua"]:38: in function <[string "app.lua"]:20>
[C]: in function 'xpcall'
[love "boot.lua"]:370: in function <[love "boot.lua"]:337>
after:
stack traceback:
text.lua:9: in function 'draw'
edit.lua:200: in function 'draw'
run.lua:140: in function 'draw'
main.lua:162: in function <[string "main.lua"]:155>
[C]: in function 'xpcall'
app.lua:38: in function <[string "app.lua"]:20>
[C]: in function 'xpcall'
[love "boot.lua"]:370: in function <[love "boot.lua"]:337>
|
| | |
| | |
| | |
| | | |
Port of a fix "upstream": commit b38f172ceb in template-live-editor.
|
|\| | |
|
| |\| |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Thanks eril for the report and patch.
|
|\| | |
|
| |\| |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
Make it more obvious that the color passed in is just for the background.
The icon will do the rest.
r/g/b keys are more consistent with App.color().
|
|\| | |
|
| |\| |
|