scarpe-team / scarpe

Scarpe - shoes but running on webview

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Multiple Shoes Apps per Process

noahgibbs opened this issue · comments

We currently don't allow multiple Shoes apps per process.

Shoes Classic has a single display server (it doesn't call it that) that runs your Shoes apps. Usually one single one that runs all your Shoes apps.

But also, the Shoes API is designed around the idea that window == app. If you have a Shoes app with a top window and it spawns three more windows, it treats that as four apps. They each get an entry in the APPS array. Each one has a parent method that points to the app (window) that created them.

Also, things like the Shoes Splash App make a lot more sense if you're not going to accidentally launch five of them by double-clicking an app icon five times when your computer is sluggish. And the Shoes Console is assumed to be shared among all your Shoes apps, which is the only reason that having a Shoes console viewer app even makes any sense -- otherwise there would never be anything in there to view.

When we decide to support that, we're going to need to get better about keeping app pointers in widgets somewhere (or just in the doc root?). The current thing where we do Shoes::App.instance in a bunch of places isn't going to cut it.

We could load everything into a single Ruby process, and then exe/scarpe will need to send it some kind of a "load an app" message to load in the new one. Or we could have multiple Ruby processes talk to a single app server. Either way. We'll need some RPC in either case to have a new process show up and start talking to existing ones.

For multiple Shoes apps, we're going to need to make some changes in Lacci. Right now we do things like "Shoes::App.instance" in several places -- and that only makes sense if there's only one instance. If there can be more than one Shoes app, we'll need to be more careful about which one to use.

Also we'll need some kind of pointer from particular drawables to their app, either directly or indirectly. So maybe a DocumentRoot would know what Shoes::App it was part of? Something like that.