Layers protocol…

Anything beyond the basics in using the LiveCode language. Share your handlers, functions and magic here.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

Randall Lee Reetz
Posts: 28
Joined: Fri Sep 07, 2007 2:04 am
Contact:

Re: Layers protocol…

Post by Randall Lee Reetz » Fri Apr 22, 2011 11:40 pm

Hey Richard,

I am accepting cookies "Only from sites I visit" (Safari/Preferences/Security/Accept Cookies/).

All other settings are set to true.

Are you running on a similar platform? (OS X 10.6.7)

Randall
What matters is what matters; knowing what matters and how to know it, matters the most.

BvG
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1239
Joined: Sat Apr 08, 2006 1:10 pm
Contact:

Re: Layers protocol…

Post by BvG » Fri Apr 22, 2011 11:47 pm

check cookies
it's cookies
check them out right now
why don't you ever listen
check deny list right now.

(sung to childrens tune)
Various teststacks and stuff:
http://bjoernke.com

Chat with other RunRev developers:
chat.freenode.net:6666 #livecode

Randall Lee Reetz
Posts: 28
Joined: Fri Sep 07, 2007 2:04 am
Contact:

Re: Layers protocol…

Post by Randall Lee Reetz » Sat Apr 23, 2011 12:08 am

I have tried every Cookies setting (there are three choices: "Always", "Never", and "To sites I visit") in Safari's preferences. None change the describe behavior (logging in to the runrev forums from safari always results in a confirmation page, and then a second later, a redirect to the original login page).

Randall Lee Reetz
What matters is what matters; knowing what matters and how to know it, matters the most.

Randall Lee Reetz
Posts: 28
Joined: Fri Sep 07, 2007 2:04 am
Contact:

Re: Layers protocol…

Post by Randall Lee Reetz » Sat Apr 23, 2011 12:39 am

On my way to the local Apple store to experiment with logging in to the runrev forums from other machines running safari. Will report results.

Thanks, Randall Lee Reetz
What matters is what matters; knowing what matters and how to know it, matters the most.

doc
Posts: 148
Joined: Fri Jun 09, 2006 4:30 pm

Re: Layers protocol…

Post by doc » Sat Apr 23, 2011 2:11 am

Works just fine for me....

OS X 10.6.7 with Safari 5.05 updated today.

-Doc-

Randall Lee Reetz
Posts: 28
Joined: Fri Sep 07, 2007 2:04 am
Contact:

Re: Layers protocol…

Post by Randall Lee Reetz » Sat Apr 23, 2011 3:48 am

OK, Safari now working on my mac with runrev forums!

Here is what we found at the apple store. Their versions of Safari worked with runrev forums. So we went looking for malware.

There is an extension to Safari called Cooliris… don't ever install it! It has morphed over the months into a kind of virus that has been remotely changed such that it keeps renaming its support files, and moving them to more and more locations deeper and deeper within the system. Some invisible! Took an apple tech with some special tools to find them all and root them out. They were not where the Cooliris site said they should be. The Cooliris uninstaller wouldn't work. And there were many more of these files than their should have been.

I knew it wasn't a cookie issue as I dump them all day long. I knew it wasn't an extension, cause none were listed in the extensions preferences of safari. Looks like Cooliris knew people were dumping their software so they changed the location and spread of their extension files such that people couldn't (easily or automatically) remove it.

I have been having lots of crashes as of late as well and hope the source is now stoppered.

Anyway, problem solved. Thanks for the help.

Randall Lee Reetz
What matters is what matters; knowing what matters and how to know it, matters the most.

Randall Lee Reetz
Posts: 28
Joined: Fri Sep 07, 2007 2:04 am
Contact:

Re: Layers protocol…

Post by Randall Lee Reetz » Sat Apr 23, 2011 4:20 am

I am a SuperCard user from way way way back. Am considering a transition to liveCode. I write self-evolving AI based on thermodynamics and information theory. Nobody has ever labeled my work, or choice of projects, "lazy". That is a first! Crazy maybe. Too ambitious. Impractical. But never lazy. My vocabulary is SuperCard situated. Will take a while (if I do choose LiveCode), to remap, to not sound like a foreigner. I don't mind sounding funny for a while.

One of the disadvantages to an "english-like" coding language is that common natural language words are used to represent concepts specific to programming. I take it that "layers" has met this fate. A layer in common vernacular doesn't usually refer to one thing, but a segment or range made up of many smaller things. Using this word to represent a single thing, is a bit of a meaning bender. Illustrator's use of the word "layer" is a bit more accurate in that layers hold multiple objects. But I don't know what I would have used in place of the word "layer"… "count" or "order"?, The word "ply" is possibly the best match to the meaning here inferred.

In supercard, the keyword "number" is used to refer to the stacking order of objects on a card… as in:

put the number of card graphic "French People" into myGrcNum

It always surprises me to find code-monkey machismo among the users of a "user-level" programming language. That kind of self-superior attitude should be reserved for those who write machine code or who build systems that get rid of the very need for anyone to write code. And even they should know where back-slapping and bullying is appropriate and where it is hurtful and unproductive.

I watched for years as Meta-Card slowly migrated away from its (DOS, Unix, Windows 95) ugly-duckling origins. It is now almost Macintosh (velvety) enough for my rarefied tastes. The work that runrev's team has done in the last few years to drag an xTalk environment into the big leagues is truly astounding! I have often said that SuperCard was too small for its britches.

That said, SuperCard has always been buoyed by its easy access to a (relatively) stable tool box of system level graphical internals. And until recently, metacard and its progeny has been slow to get on the graphics bandwagon (too many target platforms?). And now? Now it looks as if the iphone/ipad/android apps market has pushed the graphics issue to everyones advantage. You can't lead the world unless you provide the tools and primitives that allow developers to push their own ideas well past the status quo. Otherwise you spend all of your time playing catch-up. If runrev wants to gain ground it should build towards the goal of producing a version of LiveCode that makes people ask "How was that app built?" LiveCode users should know that they couldn't have built apps like the ones they built, with any other tool. Making app building intuitive and automatic (as LiveCode has definitely accomplished!) is the first task. Congratulations to the whole LiveCode team! The next step is to offer the LiveCode user much much more than is offered by xCode and Flash.

Playing cheer leader here (even if it doesn't sound like it).

I'd rather live in a world full of profound tools such that anyone can build great things, than in a world where the violins and slide rules are so hard to use that we have to wait around for the next Alexandra the Great, Eisenstein, or Beethoven. XTalk has done more to "empower" the rest of us, and to supercharge the technically adept than almost any other technology. The only thing holding it back was its lack of market buy-in and its platform obscurity. LiveCode looks to be marching up the right mountains.

Randall Lee Reetz
What matters is what matters; knowing what matters and how to know it, matters the most.

Randall Lee Reetz
Posts: 28
Joined: Fri Sep 07, 2007 2:04 am
Contact:

Re: Layers protocol…

Post by Randall Lee Reetz » Sat Apr 23, 2011 4:39 am

I have been working in SuperCard on a "layers" protocol ad-on (substitute). A set of functions that allow easy and intuitive real time control over objects that have been "grouped" or in this case pseudo-grouped. I have found that supercard's native group and ungroup commands and resulting functionality are limiting (you can only group graphic objects, referencing the constituent objects within a group is awkward, ungrouping results in the re-asignment of object IDs, etc.). The one thing a group provides is a script and a name, but both of these can be achieved through other means.

From what I have found, clicking on an object that is part of a group initiates mouse messages sent to the group and to the topmost group member object directly beneath the cursor. The same functionality can be achieved through handlers at the card or window (stack), or project level and activated by messages sent via mouse event handlers that query the target and check for group membership in a custom property populated when the pseudo group is declared or modified.

Should mouse event triage handlers be stored at the fore-script level, all of the native group behaviors can be aped without any of the awkwardness and limits.

But of course all of this could be avoided if the group protocol not have these limits and awkwardness in the first place.

This is why I have asked the questions I have asked. I don't yet have LiveCode and don't want it unless it offers a significant advantage (given the exact needs of my project).

And I DO appreciate any help and insights the members of this forum offer.

Thanks,

Randall Lee Reetz
What matters is what matters; knowing what matters and how to know it, matters the most.

Randall Lee Reetz
Posts: 28
Joined: Fri Sep 07, 2007 2:04 am
Contact:

Re: Layers protocol…

Post by Randall Lee Reetz » Sat Apr 23, 2011 5:18 am

LiveCode's use of the word "control" as a label for "object", (or "instance") seems very awkward and arbitrary to this newbie's ear. I assumed that the word "object" was being used for something else… but it doesn't appear in a search of the LC dictionary. ? Maybe the answer has something to do with this "group" and "layer" topic. Maybe "object" sounded too singular (and a control might be a grouped or composite object)?
What matters is what matters; knowing what matters and how to know it, matters the most.

BvG
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1239
Joined: Sat Apr 08, 2006 1:10 pm
Contact:

Re: Layers protocol…

Post by BvG » Sat Apr 23, 2011 10:21 am

I see now. You're not using the tool and make wild speculative assumptions based on Spuercard superstitions. You do realise that there is a free, 30 day demo? Incidentally, You can even re-download the demo after 30 days, and no one will complain. So please download the demo, and _play_ with the product. No amount of asking on the forum will ever give you the insight of actually trying things out.

As for Object vs Controls, that is a kind of schizophrenic part. Basically everything that can show up on a card is an object, or a control, and the terms are used interchangeable. There is a difference however, because object can't be used within the language, but control can. On the switch side, normally it's the graphic object, and not the graphic control that is mentioned in the documentation. Confused? Well it doesn't really matter, because when using stuff, you never say object in code, and control only if you want all controls:

Code: Select all

put the number of controls of group 1
Various teststacks and stuff:
http://bjoernke.com

Chat with other RunRev developers:
chat.freenode.net:6666 #livecode

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10045
Joined: Sat Apr 08, 2006 7:05 am
Contact:

Re: Layers protocol…

Post by FourthWorld » Sat Apr 23, 2011 4:47 pm

Randall Lee Reetz wrote:I am a SuperCard user from way way way back. Am considering a transition to liveCode.
I don't understand. You've been posting to the mailing list since 2007.

I can't really follow all of your lengthy multiple posts, but maybe this summary will help:

Like SC, LC supports "the number of <controltype>", e.g. "the number of buttons", "the number of fields", etc.

LC also provides a more generic way to work with controls of all types, "the number of controls".

Like SC, LC has cards and groups can be used as background. But there is no limit to the number of groups you can put on a card, nor a limit on the number of shared groups ("backgrounds") you can place on a card. In this respect, LC is more flexible than any xTalk I've seen since Gain Momentum.

The "layer" of a control governs its z-axis positioning, determining which object is on top or below other objects. You can set the layer property of any control.

To change the layer of controls within groups, it can be helpful to use the relayerGroupedControls global property.

Beyond this, I would encourage you to experiment to see if you can get what you're looking for from LC, reviewing the Dictionary as needed for any tokens you're not familiar with.

As you have specific questions we'll see what we can do to answer them.

Happy scripting!
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10045
Joined: Sat Apr 08, 2006 7:05 am
Contact:

Re: Layers protocol…

Post by FourthWorld » Sat Apr 23, 2011 4:50 pm

Randall Lee Reetz wrote:LiveCode's use of the word "control" as a label for "object", (or "instance") seems very awkward and arbitrary to this newbie's ear.
De gustibus non est disputandum.

Stacks and cards are also objects; "controls" is used to distinguish the subset of objects that can be placed on cards.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

Randall Lee Reetz
Posts: 28
Joined: Fri Sep 07, 2007 2:04 am
Contact:

Re: Layers protocol…

Post by Randall Lee Reetz » Sat Apr 23, 2011 7:48 pm

Yes, I agree, cards and windows "stacks" and projects (what does LC call what SC calls a "project"?) are objects as well. Of course. But the word "control" suggests (in english) an actionable or dynamic object. This is as true of cards and stacks. And it isn't true when applied to on-screen (in-card) objects that aren't actionable (have no handlers and are not the target of any logic in any other scripts). Anyway, I guess a word when used in a programming language is ultimately just a name. So "control" it is!

Once in a while, I have downloaded a runrev trial and poked around. And, yes, I have been watching and participating once in a while here at the runrev list and fourms. I feel so comfortable in SC but I have known for a long time that my move to LC is inevitable. Originally, LC came up short in many of the capabilities and methodologies If find the most important in my own work. But slowly (until recently) runrev has evolved into something I could see myself moving over and into.

I usually write code the way an architect draws plans. As prototypes, my projects work, but they aren't meant for prime time use (brittle, segmented, and shame on me, unintuitive to anyone but me). The wonderful thing about xtalk is that it can be read as psuedo-code by anyone tasked with binding it into a "real" language (C, Java, Lisp, etc.). Same goes for a team of people completing a user-ready project meant to remain xtalk-native. The script always reads as english even when it isn't well commented.

That computational hardware has become so fast, cheap, and well distributed is great for the world of interpreted code and its users. Great for me. Vindication for all of us who for what ever reason held on through the dark years.

There was a time when Fourth World (I think it was them?) made an xtalk compiler. Doesn't visual basic offer both? I hate "visual" basic… for not being either visual or basic. To what extent (if any) are LC scripts pre-complied prior to runtime execution?

Randall Lee Reetz
What matters is what matters; knowing what matters and how to know it, matters the most.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10045
Joined: Sat Apr 08, 2006 7:05 am
Contact:

Re: Layers protocol…

Post by FourthWorld » Sat Apr 23, 2011 8:22 pm

Randall Lee Reetz wrote:That computational hardware has become so fast, cheap, and well distributed is great for the world of interpreted code and its users. Great for me. Vindication for all of us who for what ever reason held on through the dark years.
Having moved a lot of my work over the last year to Ubuntu, I've been able to enjoy a wide range of cheap hardware with all the benefits of a Unix-like OS. And from a UI standpoint it's been refreshing to see Ubuntu's take on everyday computing tasks. I like most OSes I've used, but being able to get such usability and security in a free OS that runs on nearly any computer has been a tremendous eye-opener for me. Indeed, good computing has never been cheaper.
There was a time when Fourth World (I think it was them?) made an xtalk compiler. Doesn't visual basic offer both? I hate "visual" basic… for not being either visual or basic.
Maybe you're thinking of Compile-It. I've sold a lot of tools over the years, and was once kinda the Heizer Software of the SuperCard world, but never published a compiler.
To what extent (if any) are LC scripts pre-complied prior to runtime execution?
It may be fairest to say that LC scripts are runtime-compiled, but smartly so: when saving a script it's checked for compilability, alerting you to any errors which would prevent compilation. At runtime, when the object is unpacked from the stack file, the scripts are tokenized in a way very similar to some VMs, with a level of optimization that outperforms most fully-interpreted languages and roughly on par with some compiled languages for many common operations.

If you're coming from a HC/SC background, one area from which LC derives so much of its outstanding performance may initially seem a drawback, but in practice is hardly ever an issue: it doesn't allow custom handlers to override built-in commands and functions.

This small limitation greatly streamlines the work the engine needs to do to set up its message path, since it knows it can safely avoid having to create on-the-fly lookups for any of its thousands of tokens.

When I first started with MC I complained about this to Scott Raney, since I was porting a project which had some code that depended on this. He replied by suggesting that I could do what I needed just as easily using custom handler names, and that if I ever came up with a situation in which it was truly necessary to override built-in commands he'd consider it. In all these years since, I've never found one. :)

I think you'll find this "stinginess" with tokens tremendously beneficial as you spend more time with LC. By keeping the token table lean, the performance is far beyond what I've seen in any other xTalk.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10317
Joined: Wed May 06, 2009 2:28 pm

Re: Layers protocol…

Post by dunbarx » Mon Apr 25, 2011 6:02 am

I have used Safari on several different Macs, from OS 10.4 to 10.6, intel based and G5. No issues. Is the cookie suggestion pertinent?

I hope you have some of the answers you need. I hope you are eager to spend the time to get involved with this world. The good news, as I said, is that you can learn as you go. The bad news, well, it isn't really bad, is that this is a large world, and to become an expert will take time.

You are wrong about this forum, and by inference the people in it. Many, like myself, go back 20 years in the same guise, and I characterize the group in one important way:

We race to see who can answer first, and best. Try that anywhere else on the planet with any particular need you might have, and get back to us.

You cannot have missed that we still, good-naturedly, fully support your entry and success here.

Can you?

Craig Newman

Post Reply