Multiple stacks and windows

Main points

Adding a stack to a window indirectly breaks the system.

For example try add stack to first window of current stack (which on bootstrap will add a stack to the toolbox window).

The following happens:

a stack is added to the window. The model, with the proper window owner, and view are created and you can see it in the DOM.
instead of being added as a subpart to window, the new stack replaces the old, i.e. window.subparts has only one stack
any references to the first stack, which is still there in the DOM breaks the system.
and of course any reference such as second stack of first window... also throws an error

So this begs the question, some of which is related to #206:

what is window and what is it for?

is it just an agglomeration/arrangement of various parts? then that is really the job of an area

is it just something that gives a nice way to drag things around without a halo, then all that doesn't warrant all the underlying structure and we could imagine adding mouse-movement to area without the halo if desired

is it a view on a single stack only? if so we should make sure that this adding more stacks is not permitted and define exactly what we mean by "window on a stack" Right now the toolbox window is not really a view on some other stack in the system, since that stack only lives in window. Furthermore we should add some functionality to window like add stack id [ID] to window which would be a view of said stack within the window (this is actually how i imaged building the navigator at first)

is it a view on multiple stacks? if so we need to have the notion of current stack there as well. This would require changing the grammar so that current stack is not a terminal specifier. Then we'd need to decide what current stack specifies in the context of a window, i.e. is it the current stack of the window or the current stack of the world, the latter implying that we always need explicit references in window contexts.

but the main question is: what is window for and when would you would to add one to a stack?

but don't windows live subordinate to stacks? i guess i'm just confused. if windows are hierarchically under stacks, then what does it mean to add a stack to that window? i thought you only "add" stacks to a world.

a stack can accept a window a card can accept a window

a window can only accept a stack

ie it's a window on that stack. In theory imagine you want to to view another stack without actually loosing your current view and going there, you could open a window on it. Maybe something is going on there, maybe some things you want to copy over, or someone is doing something in a collaborative manner. For example, you can imagine navigator being made up of windows on stacks in some manner. BUT we never sort out what's what, hence the issue (the bug is really there b/c we never properly defined what window is)

with that said window is one of the most common parts in our stacks at the moment, although we all need to make more stacks in general

Since I made the first pass of window and lobbied for its inclusion I should describe what I was thinking (and discuss, perhaps, why it is no longer appropriate).

At the time we needed some draggable, modal way of dealing with Parts that would be visually above / independent from the given Card or Stack context, but still programmable within it. This was actually one of the shortcomings of Hypercard, which only had one window -- the main display. There were a couple of very popular XCMD extensions for Hypercard that implemented the ability to script OS-like windows with buttons etc, but you had to pay for those, install them, and learn the special extension commands. So part of what I was imagining is that we shouldn't have that as an afterthought but include it upfront. People know what windows are and will probably want to use them for dynamic menus, etc.

Having Windows use Stacks as their primary subpart was also my idea. I was thinking someone might want to create a dynamic window that cycles through different subviews. Also at the time it was unclear which sections of our system would have the responsibility for managing parts. Stacks seemed like the best entrypoint but that is no longer the case.

We have Area now. Whether we can currently implement Window-like things using composition is an open question, but I think we should try. If we can implement "windows" using Area composition then it is both a testament to the malleability and usability of our system, as well as a way to reduce the number of "primitive parts" in SimpleTalk. I think it's worth trying out.

However, that leaves open another question. Should Area be allowed to contain Stacks as subparts? And, if so, when Stack is a subpart should we force it to be the only subpart? To be honest I'm not sure. But I can give you an example of why this is a "blurry" decision. The other day you might recall I made an example of an Area that had two image subparts -- one was a hand drawn arrow and the other was the same arrow with a shadow. I was demonstrating mousedown events on it, hiding the plain arrow and showing the shadowed one when the mouse is down in the Area. It worked fine, and was scriptable, but isn't it a little clumsy? After all, we have a structure in place for cycling through visual fields of Parts and that is the stack of cards. I am not sure which one makes more sense.

The main problem is the one we have now when it comes to specifying Parts in the language. Though there is only ever (and always) one "current stack" (ie, the Stack being viewed in the main Browser window), there can be multiple "current cards" (if we allow nested Stacks). This makes the context evaluation problematic in the language, as we are discovering. If I have a button in a card of a stack of a window, and I use the phrase "current card" in its script, what part am I talking about exactly -- the current card of the window stack or the current card of the whole System (ie, the current card of the single current stack)? If we assume locality -- ie the first option -- what methods could I use to actually address the overall current card? My vote is that one should know the locality when scripting, and that to get the latter object one would say current card of current stack. We could even eventually have helper tools in script editors that make this clear as a form of feedback. But for the moment this seems to be causing more confusion than anything else.

If we want to keep things simple for a v1, it probably makes sense to:

Remove Window entirely and try to use Area composition to get the same functionality;
Disallow Stacks as subparts of Area and make only simple "windows" for the time being

If we decide it would be better to allow Stacks inside of Areas, or that we want Windows back because it's more efficient for eventing/styling or whatever, then we can easily come back to it.

here is my take on this:

Areas should not be "complex" parts, they should be collections of basic parts laid out in a specified way, i.e. what you would expect an "area" in a view to be.

I still like the idea of a window, but i think a window should really be a view on a stack not something in between an area (organize parts) and a stack like thing. And what i mean by this is that window should be a view on a real existing stack on the system with a part property like view which is a stack id (or an object specifier which is interpreted to a stack id). And maybe it should have a private command like tell window to view [stack obj specifier]. This means the following:

we allow multiple views per model
then everything that happens in the target stack and the view of it in a window has the same results
all the object references for said stack are exactly the same, so current card in a window -> stack means the current card of said stack
with one exception to the rule, current stack is a terminal specifier ALWAYS referring to the current stack in the view. And using current stack inside a window will reference objects on the current stack, and will generally be considered bad practice. Basically using current stack anywhere should be used only if you plan on having something happen on the current stack outside of that stack.
only one stack per window, otherwise madness...

This means simpler grammar, simpler semantics. We just take our current delegation model and case out one terminal specifier "current stack" and everything else should go up the context chain as is.

Lets take the toolbox example:

I would make a toolbox stack in the world.

Then I would put a window on my current stack to view the toolbox stack

add window "Toolbox" to this stack  -- note the "this" instead of our usual "current"
tell window "Toolbox" of this stack to view stack "Toolbox"

The Toolbox stack then can have many cards with different buttons, areas, whatever which you can cycle through in the window "Toolbox" So you could have this +1 depth organization for any menu, on top of organizing any card on the menu as you wish (card for adding, card for property setting which you can combine with the target halo in quick ways, and of course card to get you to all the menu cards)

after some deliberation, I think that the current implementation of window should really become more like a movable area (with a header), not the stack container it is now, and the ideas of viewing or browsing other stacks as a completely different part - a browser...

Yes this introduces parts which we can potentially make with something more basic. For example, I could make a movable area by adding a command which will catch add to world like

on add partName
     if partName is "window"
     then
           -- create a window out of area
           -- field (for the title bar), and on
           -- mouseEnter, mouseLeave handlers
    else
         -- send along to system
         add partName
end add

(or something in that spirit). But I could also make something like that for a button, by combing areas and fields.

In short, we'll always have this balance between minimal parts and minimal semantics, and with button, window, browser I think semantics are strong enough to win the argument.

UnitedLexCorp / SimpleTalk

Multiple stacks and windows #207

Main points