view object

[monte]

A number of people have requested group scaling and I'm wondering if the feature could be resolved in the simplest way by having a view object that was a placeholder for drawing a stack. That would allow us to embed multiple stacks in a single window and potentially allow us to mess with the scaling factor of regions of the window independently of each other.

A view object would have relatively few properties: rect, stack, scale, scroll and perhaps a mask. We would then interact with the stack as we normally do.

I'm not sure what would happen if there were multiple instances? Perhaps the new instance would take the stack from the old view/window so there's only ever one.

One of the nice things this might enable would be a single window IDE but there are lots of others.

[FourthWorld]

This would be especially useful if we could have tool modes limited to specific stacks. In SuperCard the tool is a stack property, and my RQCC request #623 to provide tool modes for groups could be satisfied with a viewer object just as easily as with a group, perhaps even easier if scaling comes along for the ride.

Just this morning I came across a thread in these forums form someone who wanted to make a painting stack in which the canvas and the controls were in a single window.

Some means of limiting the scope of tool modes is loooooooooooooooooooooooooooooooooong overdue.

[monte]

Although it's not really as good as what you want what if the view honoured the cantModify of the stack it was viewing independently of the cantModify of the stack it was on? So the parent stack has the cantModify true and view stack has the cantModify false. Then you can use the pointer tool.

[FourthWorld]

That sounds like a decent starting point; I'll take what I can get.

Will you have the pull request submitted for v6.5?

[monte]

Lol... there's probably a few things to work out first... like what to do about window related syntax if the stack is currently visible in a view... There's also the possibility that RunRev might prefer to overload group rather than add a new control type.

[LCMark]

You mean like http://quality.runrev.com/show_bug.cgi?id=2786?

A stack view has long been something we've discussed... With the work @runrevian has been doing on the fullscreen modes, we're almost at the point where a stack will be an object that is hosted in a view, in much the same way as a control is hosted in a group. So this will make the addition of a stack view object much easier to achieve.

As @monte says it would solve the scaling canvas problem at the moment - there aren't any unpleasant co-ordinate transform interactions to deal with since the fullscreen mode has already demonstrated scripts work quite happily assuming things are points (logical pixels) rather than actual pixels.

In regards to group tool modes - this is probably a tad easier to get to than a stackview... Although, of course, nowhere near as powerful

[LCMark]

Although it's not really as good as what you want what if the view honoured the cantModify of the stack it was viewing independently of the cantModify of the stack it was on? So the parent stack has the cantModify true and view stack has the cantModify false. Then you can use the pointer tool.

Since the idea is a stack view, I think having the stack containing the stackview and the stack in the view being completely independent is the way to go so this would work... Additionally you could add a stack level tool property which would go the rest of the way.

[FourthWorld]

In regards to group tool modes - this is probably a tad easier to get to than a stackview... Although, of course, nowhere near as powerful

I'll take what I can get. If tool modes could be optionally limited to groups (e.g., "set the tool of group MyGroup to pointer") that would make it possible for us to craft single-window layout environments MUCH more easily than with the workarounds we have to employ to attempt that today (in most cases even the best workarounds require expert scripting and are often still never quite right).

Today's example:
http://forums.runrev.com/viewtopic.php?f=9&t=17735

If instead of optionally limiting tool modes to groups we were to do that for stacks as part of this proposed View control, either way we'd still need some form of non-global tool mode.

So unless there's a conflict with support both stacks and groups as the tool mode scope, I'd love to see the quicker path taken to get this for groups now, and leave the stack implementation for later as part of the proposed View.

[monte]

I'm sure there's also a discussion in RQQC somewhere with some comments from me about this kind of idea... I've wanted something like this for quite a while but I was reminded after seeing the stackview.cpp filename appear in one of the commits on the graphics branch. I'm wondering if this might help us to present stacks as modals and popovers on mobile too or perhaps we just need to enable the modal command and a go stack as popover?

There's some other things to consider like the message and inheritance paths. Is the view the stack's parent in the massage path so messages would go stack -> view -> [groups 0..n] -> card -> [background] -> stack etc ? ... all a bit topsy turvy. Then there's stuff like background. If the stack and it's card has no background color/pattern set is it therefore virtually transparent in the view sitting on the card of another stack?

[LCMark]

@monte: In terms of modal / popover stuff, then yes a split between stack and view would make those things cleaner and easier to implement (as the stack wouldn't have to be concerned about what it was in, just events and display); however, it wouldn't potentially be too hard to get that working before that.

I've always thought of the 'stack view' object feature as basically just being about displaying a stack within another window, rather than interacting directly with the surroundings - so from this point of view, the messages paths should probably not interact directly. Indeed, it would probably work better to add syntax so that the script in the hosted stack could talk / know about its container - i.e. send messages to it etc.

I think it would be quite neat if you could turn off opaque for card / stack of the hosted stack and have it blend with the host - indeed, the ink and opacity (and effects!) of the stackview object would come into play here.

[monte]

What about stuff like setting the rect of the stack or view? It would be nice if the view could have scrollbars so setting the rect of the stack wouldn't change the rect of the view. The stack might need to get a message when the view is resized though and resizeStack wouldn't work because you might not want to resize to the size of the view. Unless resizeStack were sent only if the rect of the stack is smaller than the rect of the view...

Other than where and how to draw the stack what other window related stuff needs to change? The stack would still have all it's window related properties which would be used whenever it's opened in a window.

[LCMark]

I think the rect of the stack and rect of the view should be independent. The rect of the stack determines the content size of the view, where as the rect of the view determines the viewport.

The fullscreen modes work in the stackview case - resize would mean rect of view should match rect of stack (resizeStack when the view is resized, attempt to resize stack wouldn't work as its constrained by the view - just like on mobile), and the others would scale the stack appropriately (taking into account the stacks size, which would be changeable). Additionally, a scrolling option could be added, providing for the ability to have a stack embedded in a viewport as a scrolling canvas.

Indeed, the scrolling mode works just as well when considering a stack's embedding in a window as much as it does in a stackview.

In terms of window stuff, then its probably best just to think of the window related properties as being 'pass throughs' to the view - so when a stack is hosted (whether in a stackview or window) it would communicate the window properties to the host, the window would happily oblige, whereas the stackview would ignore them.