This year I want to ship the first luapowered cross-platform desktop consumer app. To get there, a few essential tools and modules need to be finished first. Here's what I would like to get done this year towards that:
- bundle -- now that there are static libs for everything, making single-exe deployments is the next logical step, and a really necessary one for shipping consumer apps, which is after all what luapower is aiming for.
- nw - the ability to work with windows, draw on the window surface, and working with user input in a uniform way across platforms is foundational to any desktop app -- nw is a facade API for these core platform services - it sits on top of winapi on Windows and objc on Mac -- Linux is missing and that must be fixed before stabilizing this API. It will use cairo for 2D rendering and possibly opengl for 3D and 2D layering.
- cross-platform APIs for multi-threading and processes, including all portable forms of IPC; these are needed for robust sandboxing, batch processing, and working around the memory limitations of LuaJIT/Lua's GC on x64.
- a immediate-mode GUI library -- cplayer is the current prototype for that, but it currently only works on windows -- the plan is to port it to nw and finish it afterwards. It should be pixel-perfect (including text rendering), themeable, fast, and flicker free (no "web feel").
- an auto-update system that should be able to update a well-made app without the need to restart it (should also have a self-check and auto-revert mechanism in place).
- bundle is done
timepackages are done (processes and IPC will be next on that front)
threadpackage containing various hi-level threading primitives and patterns is done (has similar functionality to Python's thread module)
- work on nw for Linux (based on
XCBXlib) is in almost finished
Follow the dev log for a closer view of the progress.
Is cairoview intentionally nonfunctional right now? It looks like there was a point in the history of the nw repository where it did work, but it doesn't at the moment (there is no
window:cairoviewand manually creating it using
:getcairoview()as a backend view just tends to kill LuaJIT on most platforms).
Yes, and yes :) nw is in heavy development right now as you've probably seen from the news log. I'm working hard to finish the X11 backend. After that, and after strengthening the unit tests some more, I will release nw and cairo and gl views will work again, this time on all 3 platforms.
I didn't want to release nw without a Linux backend even though the Windows and OSX backends were pretty complete and functional at one point. The reason is that I was afraid that a Linux backend would impose additional restrictions on the final API (and of course I was right). All 3 windowing APIs are horrible but X11 just has a unique flair of absurdity and arbitrariness which slows things down more :)
On top of that I had a complete false start with XCB. Everywhere on the web including freedesktop.org suggests that people should be using XCB for new developments instead of Xlib, which is a complete lie, because XCB is incompatible with GLX so you can't have OpenGL with XCB alone. So I had to scrap some 2 weeks of work and start again with Xlib, which btw is better documented and a somewhat friendlier API. Just tossing it out there in case someone might be tempted to use XCB to get to OpenGL.
Thanks for your patience.
PS: How's luapower working out for you so far? Skip the good parts if you want, I need the bad.
Ah, alright. I'm greatly looking forward to being able to use Lua for writing proper desktop apps!
As for the bad, I really don't think I can think of that much. Luapower is a great project! :)
If anything, I was quite surprised initially by the recommended 'default' choice to be cloning all packages. That doesn't seem like it'd scale very well as the number of packages increases ;). I definitely see the beauty in a simple multigit-ish environment though.
Keeping all packages in the same root folder feels very messy but is understandable. I'm probably missing some details here, but wouldn't just it be possible to update the 'luajit' package to include "../../?/init.lua" in
package.pathby default and thus be able to keep packages in separate folders (with the usual
I'm sure there's many people who would like to contribute (me included), so perhaps consider raising issues for what's missing in existing packages, milestones for general things, adding notes for coding style standards, how you'd prefer to accept contributions and the like to existing packages.
Thanks for the feedback. Much appreciated.
It looks I have to review some choices here.
- you're right about the scaling problems with git. I'll have to write a download/unzip-based package manager as a faster alternative. I might have overestimated people's need for version control.
- I thought about keeping packages separated, it looks like I have to do it already and it doesn't have to be one way or the other, we can have both. The
init.luatrick can be an option, but it's somewhat unfriendly:
- all the tabs in your editor will be called init.lua :)
- even if in the long run I'll be the only weirdo to prefer the all-files-in-one-directory layout, I still want to keep that option because I will never convert :)
[The thing with git is that I wanted a package manager that also supports collaboration i.e. I wanted to have an answer to the question "I just fixed a bug in your package, what's the quickest path for me to push it to you?". Most (all?) package managers ignore this aspect completely, and thus support a dichotomy between producers and consumers. I know there are other factors to that dichotomy (social, cognitive) but at least let's eliminate the technical factor, anyway that was my thinking.]
Oh, and about contributing, you're totally right, I need to address all of those things you mentioned. After the nw release.
Update: coding style guide is up.
Update: I moved all my current TODOs into github issues https://github.com/issues?q=is%3Aissue+user%3Aluapower+is%3Aopen
still no detailed roadmap (it's coming, stay tuned).