-
Notifications
You must be signed in to change notification settings - Fork 29
ShoesImplementations.md
There are many different Shoes implementations that various groups have written over the years. Scarpe is ours.
You can find some of them listed in our README, such as _why's original Shoes, plus later versions like Shoes3 and Shoes4 with very similar -- but slightly different -- APIs.
See README for many of them.
There's a fun old pattern of naming experimental Shoes versions by colour:
- Red Shoes (Original Codebase)
- White Shoes - modularisation project from Blue Shoes to support various backend GUIs
- Blue Shoes (Shoes on QT)
- Green Shoes (Pure Ruby Shoes using GTK2 and Cairo)
- Orange Shoes (Apps “Compile” to HTML5 Canvas JS)
- Purple Shoes (SWT-based Shoes)
- Brown Shoes -- apparently this was the basis of Shoes4? So my guess is Shoes-on-swt
- Black Shoes - Shoes in CoffeeScript and the browser
There's a Shoes-based presentation library:
- Wingtips by PragTob, here's an example Shoes presentation
And various other Shoes implementations over time:
- Shoes-Atom - JS backends using Opal
- Shoes-qt - Qt-based, like Blue Shoes, for Shoes4 and Shoes-Core
You'll occasionally see references to Raisins (Shoes 2.0), Policeman (3.1) and Federales (3.2). These are a roughly-continuous codebase from when _why started, and separate from the codebase change of Shoes4.
The Raisins/Policeman/Federales codebase is sometimes referred to as "Red Shoes."
Shoes4 has a similar overall architecture to Scarpe - it separates the Shoes API from the display implementation (in their case it's SWT.) While it doesn't look easy to just drop Scarpe's implementation into Shoes4, there's a lot we could learn from what properties and styles they allow where and so on.
It would absolutely be worth a systematic attempt to get a list of what drawables and methods can be called where by reading Shoes4's Shoes-Core.
While reading any of the Shoes implementations could get us some of that, Shoes-Core is interesting in how similar its basic idea is to what we're doing. I assume we could learn a lot.
The Shoes4 Git history starts by adding the files from Brown Shoes to some from White Shoes, but doesn't go back to the original _why code of (e.g.) Shoes3.
While Scarpe's core portable Shoes DSL mostly communicates via signals and properties with its backend, Shoes4 takes the much more standard approach of creating a GUI backend object and calling methods on it.
Most small apps will basically run on whatever Shoes implementation you want. Shoes apps tend to be simple, small, and not too picky about exactly where each pixel goes. That's perfect for using a portable UI language.
Some Shoes apps use less-common features, or features whose API changed from (e.g.) Shoes Classic to Shoes4. Those apps will only be compatible with some Shoes implementations and not others.
Portability is a deep topic. Not only the Shoes implementation matters, but also whether the app uses gems, local-machine libraries, command-line utilities or OS-specific or Ruby-specific features that may not be available on all platforms. There have been Shoes implementations on many OSes, several different Rubies, and for many years. There's also a difference between running a Shoes app ("hey, it works for me!") and packaging a Shoes app ("yeah, but we need to make sure everybody who runs the final version has a copy of caffeinate they can run!")
If your Shoes app cares a lot about exactly where each part shows up on screen, that will probably change the portability story too. Green Shoes, for instance, needs explicit widths, and its automatic widths don't necessarily match Classic Shoes. Scarpe uses HTML formatting for Webview, which changes a lot of rules about what shows up where. We're working on it -- but even if we get to match other Shoes versions pretty closely, that kind of thing varies between other implementations too, not just Scarpe.