| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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().
|
|
|
|
|
|
|
|
|
|
|
| |
To do this I need some support for multiple versions. And I need an
'error' mode to go with existing 'run' and 'source' modes
(`Current_app`). Most errors will automatically transition to 'source'
editor mode, but some errors aren't really actionable in the editor. For
those we'll use 'error' mode.
The app doesn't yet work with LÖVE v12. There are some unit tests failing
because of differences in font rendering.
|
|
|
|
| |
This time it really does work with pensieve.love
|
|
|
|
|
| |
Annoying dangers of testing in one fork and committing upstream
(where it isn't used yet).
|
|
|
|
|
|
|
|
| |
These are like versions in nativefs, but only support absolute paths.
I want to be thoughtful about the precise location at each call-site.
It's a little ugly that app.lua now has a dependency on file.lua. Or
source_file.lua for the source editor.
|
| |
|
| |
|
|
|
|
|
|
| |
If we're already in source editor we'll quit as before.
It's ugly that app.lua now knows about run.lua. But it's a start.
|
|
|
|
| |
It doesn't work on Android, and it's not much work to avoid.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to physfs and nativefs.lua
nativefs still introduces some inconsistencies with love.filesystem with
relative paths:
* love.fs.read: reads from save dir if it exists, falls back to source dir if not
* nativefs.read: reads from save dir if it exists, falls back to source dir if not ✓
* love.fs.write: always writes to save dir
* nativefs.write: always writes to source dir (since no restrictions)
* love.fs.newFile followed by file:open('r'): reads from save dir if it exists, source dir if not
* nativefs.newFile followed by file:open('r'): always reads from working dir
* love.fs.newFile followed by file:open('w'): always writes to save dir
* nativefs.newFile followed by file:open('w'): always writes to working dir
So avoid using relative paths with App primitives.
|
| |
|
|
|
|
|
|
| |
I was so sure my comments were clear when I wrote this a year ago. They
were shit. So, most probably, is the current iteration. Feedback
appreciated.
|
|
|
|
| |
The old name was confusing, as its description showed.
|
| |
|
|
|
|
|
| |
We had this problem because our test fakes were out of sync with reality.
And just in the source app.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Now we render lines one screen line at a time rather than one word at a
time.
I can't port the source side just yet; I need to fix hyperlinks first..
|
| |
|
|
|
|
| |
Is it just my imagination, or does the app feel lighter and more fluffy?
|
|
|
|
|
| |
In the process I discovered the horrible fact that Text.x allocates a new Text.
And it gets called (just once, thank goodness) on every single frame.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've been misunderstanding what Text objects are. They can render a lot
of text with a given line height, word wrap, colors in various places.
And I've been creating one for every word :facepalm:
Unwinding this will take some time. This is just a first baby step for
ad hoc text objects. Turns out I don't need to convert to Text to get
something's rendered width, just the Font can do that.
Thanks to the LÖVE Discord for educating me:
https://discord.com/channels/329400828920070144/330089431379869708/1091535487333826580
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
I want the words to be easy to read, and to use a consistent tense.
update and focus seem more timeless; let's make everything like those.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
scenario: open app from .love file, press ctrl+e
Before this change the source file showed up empty.
|
|
|
|
|
| |
integrated from pong.love via text.love:
https://merveilles.town/@akkartik/108933336531898243
|
|
|
|
| |
Now missing files will result in similar behavior: nil file handles.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
The test harness now also mimics real usage more precisely.
|
|
|
|
|
|
|
|
| |
It might reduce wear and tear on disk, and losing 3 seconds of data
doesn't feel catastrophic (short of a C-z rampage).
Thanks to the love2d.org community for the suggestion:
https://love2d.org/forums/viewtopic.php?f=14&t=93173
|
| |
|