Page 1 of 3

Layers protocol…

Posted: Thu Apr 21, 2011 9:02 pm
by Randall Lee Reetz
How many layers does LiveCode allow per view? In the SuperCard universe, there are only two physical layers (where interface objects and graphics can appear). It would be much much much more wonderful if one could dynamically build and assign and order layers via script. Replace the fixed card and background structure with layers which would exist independent of view, port, or window.

I create projects that morph dynamically in response to user activity and data flow. Doing so in fixed card/background structure leads to lots and lots of frustrating hacks to keep the order of objects as they should be (labels and indicators in proper stack order with the objects to which they refer, node connection lines properly woven above and behind other objects, etc., etc.).

assign layer "myControls" over layer "myObjects" in window 3
assign graphic "French People" over object "Belgian People" in layer "myObjects"
remove layer "myControls" from window 3

The use of the properties hide and show (visible and invisible) would work here as well.

hide [show] layer "myControls" in [of] window 3
set the visible of layer "myControls" in [of] window 3 to true [false]

How about using the key words "promote" and "demote" to move objects and layers already assigned above and below their current strata respectively?

demote layer "myControls" in window 3
promote object "Belgian People" in layer "myObjects"

And may I suggest the new layer and object ordering commands; "order", "reverse", and
"promote/demote":

set the order of the objects in layer "myObjects" to "atom,molecule,cell,organ,animal" [to myObjectOrderList]
reverse the order of the objects in layer "myObjects"
promote the order of the objects in layer "myObjects"
demote the order of the objects in layer "myObjects"

I can even imagine a default "object" layer associated with each object. This would be similar to "grouping" of objects but would be behaviorally and or conditionally dynamic. One could edit the script of an object's group independent of any script associated with an object. Objects would thus have four sets of scripts. 1. Object Prototype (or "class") script (true of all instances of that object regardless of its cloned instantiation). 1.1 Object Prototype Group script (also true of all instances but effecting the behavior of objects grouped with that object), 2. Object Instance Script (context-dependent script only activated when an object is instantiated in an environment that satisfies user-defined conditional parameters), and, 2.1. Object Instance Group script.

The proposed object and layer strata protocol would bring true object orientation (OO) to xTalk environments for the first time. Modern hardware is more than powerful enough to offset any performance overhead introduced. Remember that the original card/background HyperCard solution was necessitated by 7mghz CPU's (today's platforms, including phones and pads, are literally millions of times more powerful!).

The default object strata could be set at 2 layers and these layers could still be referred to by the traditional key words "card" and "background" based upon their subjective ordering (background under card). But the new functionality could be called in situations that require more flexibility and ontological specificity.

Randall Lee Reetz

Re: Layers protocol…

Posted: Thu Apr 21, 2011 9:43 pm
by dunbarx
Hi.

In reading your post I am not sure if everything you ask is already natively supported, or whether I am missing the whole point entirely.

Does "window 3" mean a stack window? You must be aware, that on a quick reading of the post, all you ask for is plainly and long standingly available. It starts, with me,at least, possibly on what you mean by "layers". Since you seem familiar with HC, SC and LC, I assume I am missing your idea.

Craig Newman

Re: Layers protocol…

Posted: Thu Apr 21, 2011 9:54 pm
by Randall Lee Reetz
So I repeat my question:

How many layers does LiveCode provide? In SuperCard and HyperCard there are only two layers in which objects can be displayed at one time in one window or stack. How many layers can one display simultaneously in a single window or view or port in LiveCode?

Randall Lee Reetz

Re: Layers protocol…

Posted: Thu Apr 21, 2011 9:56 pm
by Randall Lee Reetz
Also, as a side note, this forum is not functional in Apple's Safari browser. Logging in doesn't work.

Randall Lee Reetz

Re: Layers protocol…

Posted: Fri Apr 22, 2011 12:43 am
by dunbarx
I am using Safari. No problems.

So you mean the card layer and the background layer in HC/SC. But these were objects with specific functional attributes, and did not really affect the ability to overlay, hide or show, or in any other way help or hinder the display of window objects. Would fifty different background layers have made a difference in creating an application?

LC has only one layer. Groups and certain properities do the work of what was the background "layer" in HC. So there is only one kind of field, for example, and its owners determine its functionality.

One layer is going to sound to you, I know, like a lack of breadth. Can you tell me what your intent is? Perhaps give a simple example? I cannot imagine any scenario that cannot easily and natively be managed in LC regardless of the number of objects, or the way they might be viewed.

Craig Newman

Re: Layers protocol…

Posted: Fri Apr 22, 2011 1:10 am
by BvG
There is no background in LiveCode, and therefore there are no layers. However, you can have as many groups as you want, and those replicate the layer idea, very nicely. For example objects in one group cant have another object in between them, so if you group stuff, it always will be on it's own layer, so to say. And if you edit one group you can't edit anything outside of it, if you use the start editing /stop editing button in the button bar.

Note that in liveCode, the "layer" is a specific property, which denotes the order from front to back of all objects, as well as the tab-order of them. it can be found on the "size & position" part of the inspector.

Re: Layers protocol…

Posted: Fri Apr 22, 2011 1:39 am
by Randall Lee Reetz
OK, so no card/background layers, just a card layer. Got it. This would lead me to think that the "group" structure would be well supported and richly and intuitively editable both within the IDE and through script via commands and properties during runtime. Within the IDE, are the order of a group's component objects visualized in as they are ordered? Can their order be manipulated through drag and drop there in the IDE? Do the scripts of individual objects receive messages before or after their group's script is parsed for handlers? Through script can the objects and properties of objects within a group be manipulated at runtime? Order, visibility, script, position, size, insert into group, delete from group, etc.? Can whole groups be cloned from one window (stack) to another and inserted into a specific layer order within that stack? Are there any restrictions to the kind or type of objects that can exist within a group or restrictions to the behavior or user interaction allowed for objects once they are part of a group? Can grouped objects exist outside of a stack or card? Can multiple cards be displayed at the same time (in one stack or window)? Can visual effects like ink or opacity and event transparency be applied and changed in real time to an entire group? Is it possible to split text field contents between several groups but composed and displayed within the same widget? Can groups have custom properties and are the values of these properties conserved when the groups are cloned or copied and pasted from one stack to another?

Thanks ahead of time for informative responses,

Randall Lee Reetz

Re: Layers protocol…

Posted: Fri Apr 22, 2011 7:15 am
by dunbarx
Yes, yes, yes, yes, yes, no, yes, yes...

Seriously, almost all of what you ask for is natively supported. You cannot have more than one card in a window. That is similar to HC. Of course you can have multiple stacks (windows) open all over the place.

You are asking exactly what a new user with an xTalk background might. You are just asking all at once. I think you can work all this out, and since you have experience, it will only take a few weeks to learn the differences, all of them startling enhancements, from HC and SC.

Keep asking, but play hard at the same time. You must remember what it took to learn HC, and how nice it was when you did. This is 100 times better, and bigger, so get cracking.

Craig Newman

Re: Layers protocol…

Posted: Fri Apr 22, 2011 6:12 pm
by Randall Lee Reetz
I would really prefer to have each of my questions answered individually. I don't need encouragement. I need information. I don't have trouble with changes, with adjustments, with learning. I have trouble with dead ends, with "playing" long and hard only to find that I can't do what I want to do with this particular "toy". This is why I am asking these questions up front.

Randall Lee Reetz

Re: Layers protocol…

Posted: Fri Apr 22, 2011 6:29 pm
by Randall Lee Reetz
1. Within the IDE, are the order of a group's component objects visualized in as they are ordered?
2. Can their order be manipulated through drag and drop there in the IDE?
3. Do the scripts of individual objects receive messages before or after their group's script is parsed for handlers?
4. Through script can the objects and properties of objects within a group be manipulated at runtime (order, visibility, script, position, size, insert into group, delete from group, etc.)?
5. Can whole groups be cloned from one window (stack) to another and inserted into a specific layer order within that stack?
6. Are there any restrictions to the kind or type of objects that can exist within a group or restrictions to the behavior or user interaction allowed for objects once they are part of a group?
7. Can grouped objects exist outside of a stack or card?
8. Can multiple cards be displayed at the same time (in one stack or window)?
9. Can visual effects like ink or opacity and mouse-event-transparency be applied and changed in real time to an entire group?
10. Is it possible to split text field contents between several groups but composed and displayed within the same widget?
11. Can groups have custom properties and are the values of these properties conserved when the groups are cloned or copied and pasted from one stack to another?

Re: Layers protocol…

Posted: Fri Apr 22, 2011 6:44 pm
by BvG
Ok we get it, you are lazy, but fortunately for you we aren't! :D
Within the IDE, are the order of a group's component objects visualized in as they are ordered?
No, the layer is a number property that you can see in the inspector, as I said. Visual wouldn't really make much sense, because it'd be very complicated to do. So basically, a knowledgeable liveCode user could make one, but you can't do that, as you're too lazy.
Can their order be manipulated through drag and drop there in the IDE?
Again, as there is no sense in a visual representation, this does not work. You can set the layer number via script or the inspector, and you could therefore make your own visual interface, if you are so desperately needing it.
Do the scripts of individual objects receive messages before or after their group's script is parsed for handlers?
You have not read the documentation yet. Telling you to do that obviously is bound to fail. Unfortunately for you, understanding the message path is one of the very few things one definitely has to understand for more complex projects to work. So if you are unable to understand how messages are passed trough the hierarchy, and unwilling to look it up, all you will find out here is that the group comes later in the message path.
Through script can the objects and properties of objects within a group be manipulated at runtime? Order, visibility, script, position, size, insert into group, delete from group, etc.?
Yes all properties are available all the time. unless you use "edit group", at which point only objects within the currently edited group are available. See, now this could be tested by entering "set the foregroundColor of field 1 of group 1 to blue" into the message box. But you didn't. And now you're angry. Was it worth that?
Can whole groups be cloned from one window (stack) to another and inserted into a specific layer order within that stack
If you'd have looked up the copy command and the clone command, you'd know. Fortunately for people who do not read (like you), everyone also just can have try it out, and find that the answer is yes on the copy part. For the layer part, you'd need to add another command after the copy one (set the layer to <number>), a complexity in scripting that is probably beyond your comprehension :)
Are there any restrictions to the kind or type of objects that can exist within a group or restrictions to the behavior or user interaction allowed for objects once they are part of a group?
No, that'd be silly wouldn't it? Well actually, you can't drag them out of the group in edit mode i guess... That is a kind of restriction?
Can grouped objects exist outside of a stack or card?
Nothing exists outside a stack or a card, it's not possible to live in the void. However, you can set the location to negative numbers, so you can hide shit offscreen. Or you can use the hide command, or the disable command, depending on your needs.
Can multiple cards be displayed at the same time (in one stack or window)?
No, this is a feature request which exists since before RunRev. One could probably fake it tho, by using several stacks with no decorations?
Can visual effects like ink or opacity and event transparency be applied and changed in real time to an entire group?
set the opacity of group "try stuff before you ask" to true --always works!
Is it possible to split text field contents between several groups but composed and displayed within the same widget?
Yes, and it's very hard. Mostly because there's no built in way to do it, no matter if there is a group or not. But it's possible to do it with your own code, by using the formathedHeight of the fields. I think this is not only a valid question, but also a valid feature request.
Can groups have custom properties and are the values of these properties conserved when the groups are cloned or copied and pasted from one stack to another?
All objects, and all cards, and all stacks can have custom properties, and all properties, custom or not are always copied with them when using the copy command, or copy paste within the IDE (for your own standalone, you need to make custom copy/paste code, or imitate (steal) the one from the IDE). Why don't you try it out? select some random object, hit cmd-c and then cmd-v and bask in the duplicity of your object.

As you won't believe a word I said, you'll now have to test every of your question yourself anyway. So this was a waste of my time, thank you very much for that. :|

Re: Layers protocol…

Posted: Fri Apr 22, 2011 10:12 pm
by Randall Lee Reetz
Don't ever ask questions of a question forum. Sad.

Re: Layers protocol…

Posted: Fri Apr 22, 2011 10:13 pm
by mwieder
Diving in against my better judgement...

I think BvG is wrong about a couple of things here (snarkiness aside):
Within the IDE, are the order of a group's component objects visualized in as they are ordered?
Yes I believe this is true in and out of groups. Higher layer numbers obscure lower layer numbers.
Can grouped objects exist outside of a stack or card?
No and yes. You can have unplaced groups in a stack, which are not part of any card. These weird me out, though, because there's no easy way to deal with them in the IDE.

It *is* possible to rearrange the order of group visibility on a card, but it takes much time for the groups to relayer and I wouldn't advise it unless there's no alternative.

Re: Layers protocol…

Posted: Fri Apr 22, 2011 10:21 pm
by Randall Lee Reetz
Craig,

You wrote that you are using Safari and are not having trouble logging in to the RunRev Forums. I am on:

Model Name: MacBook Pro
Model Identifier: MacBookPro6,1
Processor Name: Intel Core i7
Processor Speed: 2.66 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache (per core): 256 KB
L3 Cache: 4 MB
Memory: 4 GB
Processor Interconnect Speed: 4.8 GT/s
Boot ROM Version: MBP61.0057.B0C
SMC Version (system): 1.57f16

And running: Safari, Version 5.0.5 (6533.21.1)

After logging in, Safari reopens the forum loggin page. Endless loop. And yes I have cleared the cookies, etc.

Any suggestions? I can use firefox but prefer safari.

Randall

Re: Layers protocol…

Posted: Fri Apr 22, 2011 10:22 pm
by FourthWorld
Randall Lee Reetz wrote:Also, as a side note, this forum is not functional in Apple's Safari browser. Logging in doesn't work.
I'm logged in using Safari right now. Do you have cookies disabled for this site?