- You probably should do the different projects as tabs on the bottom instead of full-height side buttons, especially on Android where the horizontal space is sparse, and make the text editor full-screen.
- The other UI elements OTOH are way too small on android.
- The BG/FG sliders can be interacted with even while invisible.
- On Android, sliding space left/right which moves text normally, doesn't work.
- If you don't run the abbreviations snippet, subsequent examples fail.
- When you touch to move text cursor position, for a frame, a selection flashes
- Automatic indentation and highlighting Lua keywords at least would be cool to have.
- In the sweep trails example, set T to less, otherwise it looks like it's lagging.
This part is brilliant, the user can modify the app itself while it's running.
> Lua Carousel is a "freewheeling" app that you can read and modify the source code for as it runs. The app contains all its source code.
It feels similar to a self-hosting language that's written in itself. I love the idea of giving the user the power to modify not only their own programs as they run, but the editor and runtime environment. ..Ah, the readme of the Git repo goes into more detail how it works.
Love2D is amazing. This is cool, but you can just use whatever text editor or IDE you want and dynamically load and replace functions every second or two. Then you can type in a lua development environment and have the love2D window be separate instead of text in your way, which works well in the age of high resolution and multiple monitors.
If you catch errors you can just print the error in the Love2D window. With this structure/technique you can make games in real time while they are running, because you don't have to clear your global state to sub in a different draw function / input handling function etc.
The origin story for this project is my collaborator exclusively uses an iPad and wanted to program with LÖVE. He tried a bunch of tools for this, and found various sharp edges in integrating a workflow out of multiple apps while dealing with iOS limitations.
The 10% I disagree on is a use case that all modern environments ignore that I think is very important: helping outsiders make changes to the programs they use. Open source projects have a way of gradually diverging the development experience from the user experience. The best way I've found to avoid this slippery slope is a very hard line: developing at least small changes should require exactly the software needed to run the app, and nothing else. In this case, that's LÖVE. The design constraint I bring to this project is: it's built in LÖVE and so I know LÖVE is installed on the system. How can I make changes to this project using just LÖVE and nothing else? My current best answer is https://git.sr.ht/~akkartik/driver.love which lets you make changes to this app and other apps I've built as they're running.
(Unfortunately my design constraint is currently only satisfied on desktop devices. iOS considers LÖVE to be the first-class app and won't let two copies of a first-class app run simultaneously. So you're stuck making changes to your app on a computer and then transferring it to your mobile device somehow.)
Look great! I've done something similar with exactly the same approach of fully reevaluating Love functions, which allows changing the app behavior on the fly: http://notebook.kulchenko.com/zerobrane/live-coding-with-lov.... This is only running on a desktop (as it's controlled from the ZeroBrane Studio IDE running on the same machine) and allows both changing the source code and using virtual sliders on any numbers in the script to drag left/right to affect the behavior.
It was very interesting to work on that and to see the behavior of the script changing in real time. I've seen some of the users creating simple applications in a matter of minutes using this approach; here is one that was done at about the same time as the Love demo (although it's using Gideros SDK): https://notebook.kulchenko.com/zerobrane/gideros-live-coding...
Re: Decker, I these "continuing the legacy of Hypercard" tools didn't also continue with the aesthetics of Mac System 6. At that point just use MiniVMac. Why not embrace 32 bit color and high resolution?
> Why not embrace 32 bit color and high resolution?
It's a deliberate design decision, which hearkens back to an era when computing was simple. I appreciate it.
> At that point just use MiniVMac.
Decker has many modern improvements though:
> It retains the simplicity and ease of learning that HyperCard provided, while adding many subtle and overt quality-of-life improvements, like deep undo history, support for scroll wheels and touchscreens, more modern keyboard navigation, and bulk editing operations.
I personally like that it can output standalone HTML documents, uses a VCS friendly format, and its language can be used from the CLI.
It seems like a great project, in the same vein as Lua, LÖVE, Carousel, PICO-8, etc. In an era of complex, bloated, slow, opaque, and often hostile software, these projects are a breath of fresh air.
Well, there is Cardstock, which is a Hypercard-like in progress written in Python (and which uses Python as its language rather than a Hypertalk-like). It seems a bit more modern in that it isn't going for the 1980s Mac aesthetic.
Because I don't care for what those things do to programming environments.
If you take more than a superficial look at Decker, you might find it is capable of quite a bit more than HyperCard in an emulated Mac Plus. If you want it to look different, the project is free, open source, and permissively licensed; do as you please.
When you first run it, it shows a few example screens. Some of the later ones demonstrate how you hook into draw, update, events, etc. Basically you can't define love.draw, etc., but rather car.draw, car.update, etc., and Carousel will call those for you inside love.draw, etc.
(Just merged your PR into wigwam.directory haha thanks!)
For those who don't know, Kartik's "freewheeling" apps are incredible.
Very much fits in the spirit of Uxn and other small ecosystem projects.
I recommend watching his short lecture and following along with the slides:
[1] https://archive.org/details/freewheeling
[2] http://akkartik.name/freewheeling/
He totally sold me on the viability of Lua, LOVE, and small apps for making better software.
He also has a lovely VM called mu that's worth checking out:
[3] https://github.com/akkartik/mu