An intuitive software erector kit targeted at people new to programming, but with enough potential to stay useful once they've learned, inspired by HyperCard.
Each Stacksmith file should be a canvas. You drag objects out on that. By default, that is a single stack, which in turn contains other objects (cards, parts, backgrounds). Media also go on this canvas, kind of like resources used to, just without all that legacy fork stuff that no user understands. If we ever do XCMDs/XFCNs/XRTNs, those will, too.
The canvas is like a drawing app, or a XIB file: You put stuff on the canvas. Some of it is visible (everything that is inside a stack).
Objects on the canvas that would usually be visible can be hidden. I.e. you can have a second stack on your canvas, but it is hidden. You can (ab)use this stack as a database, then have the other stack use the data in there, but provide a different view. You don't need databases or arrays anymore, you just create hidden stacks.
There are invisible objects. A "plain object" (kinda like NSObject to which you can add your script and user properties, but it's pretty useless on its own), timers (like in OMO). They have name, ID, can be placed anywhere in the hierarchy (e.g. on a card in a stack) but they don't draw anything (except some sort of placeholder when you're editing so you can find & edit them).
You can "group" objects on the canvas (e.g. to create an array, or just so your canvas isn't so messy). And they are persistent, just like stacks or buttons.
This solves lots of problems:
Databases
Arrays
Custom objects/classes, including custom controls, which could just be grouped vector graphics and buttons and fields on the canvas that then get "aliased" to cards or backgrounds as a whole.
Editing/managing resources like media or externals
Distinguish run and edit mode (if you see the graph paper of the canvas, you're in "edit")
Multiple stacks in one file. We don't even need a "main" stack, we just show all stacks that aren't hidden.
This may have repercussions on how we implement the "start using" command. We want real XCMDs and objects containing scripts on the root of the canvas to be available to people who "start using" our stack. Maybe just slap on a property "share with users of this stack" ? (I don't like that name, open for suggestions).
Each Stacksmith file should be a canvas. You drag objects out on that. By default, that is a single stack, which in turn contains other objects (cards, parts, backgrounds). Media also go on this canvas, kind of like resources used to, just without all that legacy fork stuff that no user understands. If we ever do XCMDs/XFCNs/XRTNs, those will, too.
The canvas is like a drawing app, or a XIB file: You put stuff on the canvas. Some of it is visible (everything that is inside a stack).
Objects on the canvas that would usually be visible can be hidden. I.e. you can have a second stack on your canvas, but it is hidden. You can (ab)use this stack as a database, then have the other stack use the data in there, but provide a different view. You don't need databases or arrays anymore, you just create hidden stacks.
There are invisible objects. A "plain object" (kinda like NSObject to which you can add your script and user properties, but it's pretty useless on its own), timers (like in OMO). They have name, ID, can be placed anywhere in the hierarchy (e.g. on a card in a stack) but they don't draw anything (except some sort of placeholder when you're editing so you can find & edit them).
You can "group" objects on the canvas (e.g. to create an array, or just so your canvas isn't so messy). And they are persistent, just like stacks or buttons.
This solves lots of problems:
This may have repercussions on how we implement the "start using" command. We want real XCMDs and objects containing scripts on the root of the canvas to be available to people who "start using" our stack. Maybe just slap on a property "share with users of this stack" ? (I don't like that name, open for suggestions).