uliwitness / stacksmith Goto Github PK

You can only click a small area in the middle, even if the button is bigger. Will have to find out what to override to fix that. dd

Full-blown menu objects with a script for the entire menu, each item, and icon, title, shortcut.

Like HyperCard's "set the textStyle of character 1 to 5 of cd fld 1 to bold".

Best approach is probably to make the optimizer notice when a property expression references a chunk (in Simplify()) and in that case make sure it's turned into a chunk reference, not a constant chunk. Furthermore, LEOValue needs to be extended to have a call that sets a property with a range, and an instruction needs to be added that calls that method. Then we close down the range (as usual with nested chunks) and then call that on the final value. Then buttons and fields need to implement their contents as object reference values (not just a string) so we can send a "change property X with range Y to value Z" method to the actual object.

Worries: What if a field or its substring contains an associative array? If that has a textStyle key? I guess we'll finally have to introduce a "contents" property, and use that to explicitly state when we want the text as text, and not an editable range of the field? A bit too techie though...

Right now you can close a project's last stack and the project stays loaded. You have no way to re-open a stack, as the message box looks at the frontmost stack window. You have to quit to unload the project.

Right now, parts recreate their views when the style changes. Problem is, when you're in a mouseDragged handler or so, the NSButton goes away while it is still tracking the mouse, and we crash. Either find a way to recreate the views without that crash, or failing that, at least follow HyperCard's rule of "whatever the user does, don't crash" and lock the "style" property while tracking.

But really, mouse-over indicators and stuff like that should be able to change button styles.

The move to using WILDPartPresenter subclasses to create the actual Cocoa views needed to display a part on the screen probably broke the Find command.

When the "edit background" menu item is chosen, make the card layer slide off as if it was a transparent piece of plastic containing the card-specific parts that gets pulled away towards the camera. This way, users get a better intuitive understanding of what is going on. Do a reverse of this effect when coming back to edit the card again.

While we're at it, we could also implement this effect as a visual effect, or even a whole group of effects (scroll card layer away to the side, scroll in new card layer, but leave background parts stationary).

This would probably be an early form of the Project Canvas (#12) that shows all stacks at least, so you can open one, and see what stacks a project contains.

For some reason, moving a button or field via drag & drop shows the image at a few pixels off from the location the button really ends up at.

Only new media are saved. Since NSDocument creates a new folder for us to write to, we lose the old media.

Have to be able to paste movies or movie files, control playback position, speed, pause etc. They must correctly be embedded in the document or reference external files. Must be able to set natural or skewed size, show controls (system-standard or if those are too ugly something like QuickTime X which users consider system standard).

Text source code is so 80ies. HyperCard already had "Link to..." and later "Button Tasks", SuperCard had "ClickScript".

We do not want a code generator. Instead, we want the next generation of syntax coloring: When people write script text, we don't just color it, we turn each token or group of tokens into UI elements, Automator-style. Users can simply select valid parameters from a popup menu in the spot where the parameter would be etc. But users can still type in their scripts, and they get saved as plain text HyperTalk scripts for better version control.

In addition, like Scratch or Automator, there will be a library of commands that you can just drag onto the script editor's canvas, so users that don't want to type don't have to, and new users can just drag together operations. There should also be a caret and type-selection, and maybe even auto-completion, so you can use the keyboard to select an item from the library and insert it in the right spot on the canvas.

Even cooler would be if the editor canvas took advantage of the entire 2D space. Every function and every command in it has a location on the canvas (specified in some sort of grid units though, so the editor can move surrounding stuff a bit when a function becomes wider?). The user can now visually arrange everything as it makes sense, connect stuff, create new function and command handlers by "grouping" commands (specifying the parameters as inputs and outputs, Prograph-style).

Furthermore, the graphical debugger could show several functions at once on the same canvas, so you see what is executing concurrently.

Decide whether that means you can't "go" there at all, or whether that just affects the arrow keys and menu items that a user might use. Maybe have "next card including invisibles" construct, and don't ever go there by default?

Syntax coloring should generate Scratch-like capsules for each fully recognized command, and pop up matching command capsules as you type. Same for expressions in command parameters etc. There should also be a "trough" on the side containing all available commands/functions, sorted into topics.

The idea is that it can be used like a regular text editor, but that the auto-completed text can also be used with the mouse to assemble code. That way beginners don't need to look up or remember command names, parameter labels etc.

like "number of cards", "number of card buttons" etc. Keep in mind not to break stuff like

put "foo" into buttons
answer number of card buttons

which should probably parse as 'number of card "foo"' ? Or maybe we should notice cases like that and tell the user about the ambiguity right away?

Ideally it would be in a more generic form, something between the old Link To palette (standalone and modeless so it can be used from scripts to e.g. select text and link to a card, or to create a button that points to another card), button Tasks and Scratch's code editor. So that a scripter can expose any command and its parameters to her users.

Currently the UI ends up in a weird in-between state where the 'Edit' button widget in the title bar has the wrong highlight.

Like in HyperCard, for chunks of a value, and for objects. With expressions or just a property as the 'by' clause. Also make it possible to sort parts.

These are objects that only show while editing, like in OMO, and can be set to periodically send messages, started and stopped.

Something about the ones in OMO irks me, though. Definitely don't want to replicate the list of messages that way. Maybe stick to one message and time interval in human-readable seconds for now. At the least a timer should be able to loop once it's sent all its messages. Don't do the global timerExpired message at all.

• Variant of autoSelect text fields
• show/hide column headers and set their title properties
• lockText vs. editable
• Column styles like "checkbox", "icon" etc.
• styled text
• switching between column- and column-less mode (esp. updating bg fields with card-specific contents in a lossless way)
• syntax "column C of row R of fld F"

When you 'go' to a card, we run closeCard etc. handlers, then openCard. We also pause the script while we load the new card. In the future, other commands besides 'go' might use the pausing mechanism. So we must make sure that an openCard handler that is paused gets resumed first, not the handler that executed the 'go' command that triggered it.

A way to specify a list of menus that will be shown whenever a given window is frontmost. Should be available as per-project default and as per-stack setting. Also needs a mode that shows Stacksmith's menus in addition to these menus, and allows editing the stack's menus easily.

When moving parts. Make sure the algorithms for this are in the cross-platform code. Only actual drawing of guidelines is platform-specific.

Queries should ideally be specified as something between LINQ and the search command's syntax. Make it so users don't have to escape query values etc., not unlike prepared statements in SQL. Maybe even throw in SQL support while we're at it.

This has to be done in a way that it'll work for both native objects of the platform and our objects. Ideally, we'd later be able to also let scripters temporarily disable undo or control undo grouping.

Functions for encrypting a string in a secure way. I.e. give a string and a password, turn into gibberish/turn back. Maybe use LibreSSL for that?

Should this be a style of combo box fields? Probably not.

We have ULIMelodyQueue for this already. All we need is syntax and an instruction that grabs the sound file and hands the melody notes string off to ULIMelodyQueue to parse and play. Also the 'the sound' property to indicate a sound is done, and sound channels.

SuperCompiler (where the parser for Forge came from) used to have a feature where you could write MacOS CoreFoundation function calls and Objective C method calls into your Hammer (HyperTalk/SuperTalk) scripts, and thus call system API directly. This got broken with the move from generating C++ source code that is compiled into an XCMD to generating Leonie byte-code.

Make this work again by adding byte-code instructions to Leonie that call native functions and methods, and by fixing the parser to generate the right data types/translate whatever the user passed in. That way, we do not need XCMDs anymore. Even better, with the Stacksmith Canvas, a user could create a plain "NSFileManager" object and write wrappers around NSFileManager methods in there, and then anyone could use it like an XCMD, without having to worry about the memory management or weird ObjC syntax that the creator of this object had to.

This may have repercussions on how we implement the "start using" command. We want real XCMDs and objects like this one 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).

Currently it's always true, it seems.

So we can show a stack pretty much pixel-identical to how it used to look originally. I'm aware that the fonts may not be pixel-identical, but get as close as we can.

This could be used for implementing the recent items window, or a game map, and could just be a special mode of the Stacksmith canvas (#12) if you explicitly show it while not in "Edit" mode. Allow themeing it a bit, and don't just hide objects that would be invisible anyway (like plain objects, XCMDs etc.) but also allow filtering the display (e.g. only ones that have a "firstLevelMap" user property set or so).

So opening an old stack will look a bit better. This could be done by simply creating a second, higher-depth version of an icon and applying a few smoothing filters to it.

Maybe we should have a special property for the text being edited, different from the items (or the other way round). Otherwise the field edits items that should be fixed (if we update prefix matches and make them the selectedLine), or grows boundlessly (if we append a new line each time).

Command that allows you to use e.g. a bezier path draw graphic's points to animate the movement of another part. 'move me along the points of grc "bounce route"' for example.

At the least, these should be parts that implement lines, ovals, rectangles, pictures, polygons and bezier paths. A "group" object would also be desirable (and maybe you could even clip to a draw graphic in the group?).

If we want to go crazy, we can optimize these so they're more efficient for the typical case of a non-changing static decorational graphic, by e.g. grouping graphics in a sequence into the same layer, not supporting autoHighlight and other button-like properties, maybe even not supporting a script (or just optimizing the ones without a script differently than interactive ones with a script).

Needs to be end-user suitable and needs to be possible to handle menu items in a palette, intercept keypresses etc.

Make the window look like a stack of cards, maybe even show each card behind the current one. Have little twist and skew effects at the edges, so it looks like the paper is bent a bit.

This is an important part of any HyperCard, you need to be able to copy example buttons and use them wherever you want.

Add little bubbles (like the "is this Bill Atkinson" popups in iPhoto) that display next to objects that receive messages and let you implement a handler for that message in the object at the click of a little arrow button (think the iTunes "show this in store" arrows). Extend the existing message watcher infrastructure (and maybe get rid of that boring window).

This may have to be a "recording" mode like AppleScript had it, as otherwise it could be annoying.

Right now we just grab them, but have no UI.

Should be like "popup" (and probably be called the same), just editable. Work out how to handle custom choices ... replace first line? Last line? Append a line? What about auto-completion? What if I want to allow a current value that is not part of auto-completion?

For appointments and calendars. Make looking stuff up similar to the database access support, something like LINQ and the sort command(?).

That way we can display the snapshot right away before we load the movie itself and be more responsive. Right now scripters would have to make the player transparent and put a picture behind it to get this effect.

Currently they give mouseUp even when tracking ends outside.

Whatever I can think of to fill out HTML templates. But a general

"foo" with X replaced by Y

or similar syntax would be great. Also HTML entity encoding/decoding and URL encoding. Maybe do base64 for e-mails while we're at it.

Make it possible to allocate the gInstructions array by passing in a second array to append to it. This will reallocate the whole buffer, placing built-in instructions at the start, the new ones after that. This way, we can better separate built-in instructions from platform- or host-specific ones.

A command that pops up the given menu from the stack at the given position (usually the mouseLoc). Alternately, a way to set up popup buttons invisible and somehow put one in a table cell.

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).

Make sure "rectangle" etc. button styles draw correctly, sometimes something is off regarding clipping and sometimes even color.