Hypercard: the missing link to the web

[Bernard Devlin]

http://arstechnica.com/apple/2012/05/25-years-of-hypercard-the-missing-link-to-the-web/

It might be useful if some of you who can compare Hypercard and
Livecode posted a comment to the article showing that the grandchild
of Hypercard is alive and well. I've left a comment on the aggregating
site that led me to the Ars Technica article, so don't want to be
accused of spamming by writing on both of them. I never even knew
about Hypercard until I found Runrev.

Bernard

[René Micout]

under name "pmbrig " ?

Le 31 mai 2012 à 13:15, Bernard Devlin a écrit :

> http://arstechnica.com/apple/2012/05/25-years-of-hypercard-the-missing-link-to-the-web/
>
> It might be useful if some of you who can compare Hypercard and
> Livecode posted a comment to the article showing that the grandchild
> of Hypercard is alive and well. I've left a comment on the aggregating
> site that led me to the Ars Technica article, so don't want to be
> accused of spamming by writing on both of them. I never even knew
> about Hypercard until I found Runrev.
>
> Bernard
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Peter M. Brigham, MD]

On May 31, 2012, at 8:44 AM, René Micout wrote:

> under name "pmbrig " ?

Yes, I just posted something on this forum mentioning LC. So did Lynn Fredericks.

-- Peter

Peter M. Brigham
***@gmail.com
http://home.comcast.net/~pmbrig


> Le 31 mai 2012 à 13:15, Bernard Devlin a écrit :
>
>> http://arstechnica.com/apple/2012/05/25-years-of-hypercard-the-missing-link-to-the-web/
>>
>> It might be useful if some of you who can compare Hypercard and
>> Livecode posted a comment to the article showing that the grandchild
>> of Hypercard is alive and well. I've left a comment on the aggregating
>> site that led me to the Ars Technica article, so don't want to be
>> accused of spamming by writing on both of them. I never even knew
>> about Hypercard until I found Runrev.
>>
>> Bernard
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-***@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Bob Sneidar]

You know, advertising for Livecode should really focus on informing the old Hypercard community that Hyper Programming is not gone forever, that it lives on in Livecode. There seems to be a LOT of people mourning "the good ol' days" of Hypercard, who are completely oblivious of Livecode. Posting to a blog is ok, but who out of all the initial readers is actually following that post? Probably not a lot. And who reads through all the replies before posting themselves? Far less still. I'd say almost no one.

I put in a good word there, but RR really needs to put a little more effort in running ads targeted at old HC, SC and MC devs.

Bob


On May 31, 2012, at 9:06 AM, Peter M. Brigham, MD wrote:

> On May 31, 2012, at 8:44 AM, René Micout wrote:
>
>> under name "pmbrig " ?
>
> Yes, I just posted something on this forum mentioning LC. So did Lynn Fredericks.
>
> -- Peter
>
> Peter M. Brigham
> ***@gmail.com
> http://home.comcast.net/~pmbrig
>
>
>> Le 31 mai 2012 à 13:15, Bernard Devlin a écrit :
>>
>>> http://arstechnica.com/apple/2012/05/25-years-of-hypercard-the-missing-link-to-the-web/
>>>
>>> It might be useful if some of you who can compare Hypercard and
>>> Livecode posted a comment to the article showing that the grandchild
>>> of Hypercard is alive and well. I've left a comment on the aggregating
>>> site that led me to the Ars Technica article, so don't want to be
>>> accused of spamming by writing on both of them. I never even knew
>>> about Hypercard until I found Runrev.
>>>
>>> Bernard
>>>
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-***@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-***@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Bernard Devlin]

I'm not sure they would use Livecode anyway. They want to moan about
"the good old days", but when presented with language xyz which is
free, and which has hundreds of free libraries, etc. they will find
something to bitch about when it comes to Livecode. "What? I have to
pay for it! But, I get my travel, gas, electricity, food, etc. for
free; why should I pay?" Or else they will complain about there not
being source code control, or something else.

I think that those who will come to Livecode have either never used
Hypercard before and want a visual development environment without an
arcane language, or they will be people who appreciate dynamic
languages and late binding who somehow don't want to use
javascript/browsers as their presentation layer. Or possibly there
are those who just find all the other options for mobile development
too unamenable (5 years ago I would never have guessed that Objective
C would have come back from the dead).

That's my 2c.

Bernard

On Thu, May 31, 2012 at 5:29 PM, Bob Sneidar <***@twft.com> wrote:
> You know, advertising for Livecode should really focus on informing the old Hypercard community that Hyper Programming is not gone forever, that it lives on in Livecode. There seems to be a LOT of people mourning "the good ol' days" of Hypercard, who are completely oblivious of Livecode. Posting to a blog is ok, but who out of all the initial readers is actually following that post? Probably not a lot. And who reads through all the replies before posting themselves? Far less still. I'd say almost no one.
>
> I put in a good word there, but RR really needs to put a little more effort in running ads targeted at old HC, SC and MC devs.
>
> Bob

[Bob Sneidar]

TANSTAAFL. There Ain't No Such Thing As A Free Lunch. Even Hypercard was not free. We paid for it when we paid for the Mac it was installed on. People who want things to always be free need to also consider the term "freeloader". Someone somewhere pays for the "free" thing.

Even if Apple gave away Hypercard to people who bought a mac without it, Apple would still be paying for it. In the case of all those other things, the taxpayer is paying for it, or else the company that hired him is paying for it, and actually he is likely himself paying for it because he is probably getting paid less considering he is getting paid in benefits instead of salary.

I am always very wary when people offer me something for free. Either they are trying to sell me something else later, or they are performing a social experiment.

Bob


On May 31, 2012, at 11:45 AM, Bernard Devlin wrote:

> I'm not sure they would use Livecode anyway. They want to moan about
> "the good old days", but when presented with language xyz which is
> free, and which has hundreds of free libraries, etc. they will find
> something to bitch about when it comes to Livecode. "What? I have to
> pay for it! But, I get my travel, gas, electricity, food, etc. for
> free; why should I pay?" Or else they will complain about there not
> being source code control, or something else.
>
> I think that those who will come to Livecode have either never used
> Hypercard before and want a visual development environment without an
> arcane language, or they will be people who appreciate dynamic
> languages and late binding who somehow don't want to use
> javascript/browsers as their presentation layer. Or possibly there
> are those who just find all the other options for mobile development
> too unamenable (5 years ago I would never have guessed that Objective
> C would have come back from the dead).
>
> That's my 2c.
>
> Bernard
>
> On Thu, May 31, 2012 at 5:29 PM, Bob Sneidar <***@twft.com> wrote:
>> You know, advertising for Livecode should really focus on informing the old Hypercard community that Hyper Programming is not gone forever, that it lives on in Livecode. There seems to be a LOT of people mourning "the good ol' days" of Hypercard, who are completely oblivious of Livecode. Posting to a blog is ok, but who out of all the initial readers is actually following that post? Probably not a lot. And who reads through all the replies before posting themselves? Far less still. I'd say almost no one.
>>
>> I put in a good word there, but RR really needs to put a little more effort in running ads targeted at old HC, SC and MC devs.
>>
>> Bob
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Richmond]

On 05/31/2012 10:08 PM, Bob Sneidar wrote:
> TANSTAAFL. There Ain't No Such Thing As A Free Lunch. Even Hypercard was not free. We paid for it when we paid for the Mac it was installed on. People who want things to always be free need to also consider the term "freeloader". Someone somewhere pays for the "free" thing.
>
> Even if Apple gave away Hypercard to people who bought a mac without it, Apple would still be paying for it. In the case of all those other things, the taxpayer is paying for it, or else the company that hired him is paying for it, and actually he is likely himself paying for it because he is probably getting paid less considering he is getting paid in benefits instead of salary.
>
> I am always very wary when people offer me something for free. Either they are trying to sell me something else later, or they are performing a social experiment.

For "social experiment" read 'cult'.

>
> Bob
>
>
> On May 31, 2012, at 11:45 AM, Bernard Devlin wrote:
>
>> I'm not sure they would use Livecode anyway. They want to moan about
>> "the good old days", but when presented with language xyz which is
>> free, and which has hundreds of free libraries, etc. they will find
>> something to bitch about when it comes to Livecode. "What? I have to
>> pay for it! But, I get my travel, gas, electricity, food, etc. for
>> free; why should I pay?" Or else they will complain about there not
>> being source code control, or something else.
>>
>> I think that those who will come to Livecode have either never used
>> Hypercard before and want a visual development environment without an
>> arcane language, or they will be people who appreciate dynamic
>> languages and late binding who somehow don't want to use
>> javascript/browsers as their presentation layer. Or possibly there
>> are those who just find all the other options for mobile development
>> too unamenable (5 years ago I would never have guessed that Objective
>> C would have come back from the dead).
>>
>> That's my 2c.
>>
>> Bernard
>>
>> On Thu, May 31, 2012 at 5:29 PM, Bob Sneidar <***@twft.com> wrote:
>>> You know, advertising for Livecode should really focus on informing the old Hypercard community that Hyper Programming is not gone forever, that it lives on in Livecode. There seems to be a LOT of people mourning "the good ol' days" of Hypercard, who are completely oblivious of Livecode. Posting to a blog is ok, but who out of all the initial readers is actually following that post? Probably not a lot. And who reads through all the replies before posting themselves? Far less still. I'd say almost no one.
>>>
>>> I put in a good word there, but RR really needs to put a little more effort in running ads targeted at old HC, SC and MC devs.
>>>
>>> Bob
>> _______________________________________________
>> use-livecode mailing list
>> use-***@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[François Chaplais]

You had to pay Apple for the development version (v.s. player) of Hypercard. I think this started with version 2.
Le 31 mai 2012 à 21:08, Bob Sneidar a écrit :

> TANSTAAFL. There Ain't No Such Thing As A Free Lunch. Even Hypercard was not free. We paid for it when we paid for the Mac it was installed on. People who want things to always be free need to also consider the term "freeloader". Someone somewhere pays for the "free" thing.
>
> Even if Apple gave away Hypercard to people who bought a mac without it, Apple would still be paying for it. In the case of all those other things, the taxpayer is paying for it, or else the company that hired him is paying for it, and actually he is likely himself paying for it because he is probably getting paid less considering he is getting paid in benefits instead of salary.
>
> I am always very wary when people offer me something for free. Either they are trying to sell me something else later, or they are performing a social experiment.
>
> Bob
>
>

[Peter Alcibiades]

You're not taking account of the Open Source movement. Were I starting again
at this point, the choice would be Python. Genuinely free in every way, and
not just as in beer. There is actually an impulse in many of us, which
neither Friedman, Thatcher nor Marx were able to admit, to contribute to the
common good. There is a price for free software of the Open Source kind,
that is correct. The price is considering oneself as a member of a
community, not simply as a consumer. But for many of us it is a price we
are happy to pay, and at this point we are not participating in a social
experiment. Its not an experiment, its a well established alternative.

Think about Android....

The problem with Hypercard, and what led to its demise, was fundamentally
that it was not free. It was the same thing that led to the crazed
ambitions and failure of e-world, the desire to have a closed ecosystem
totally controlled by Apple. If they had turned Hypercard loose to open
source, it would have become multiplatform at once, and would be thriving
today. The thing that killed it was a dog in the manger approach to things.

Peter


slylabs13 wrote
>
> TANSTAAFL. There Ain't No Such Thing As A Free Lunch. Even Hypercard was
> not free. We paid for it when we paid for the Mac it was installed on.
> People who want things to always be free need to also consider the term
> "freeloader". Someone somewhere pays for the "free" thing.
>
> Even if Apple gave away Hypercard to people who bought a mac without it,
> Apple would still be paying for it. In the case of all those other things,
> the taxpayer is paying for it, or else the company that hired him is
> paying for it, and actually he is likely himself paying for it because he
> is probably getting paid less considering he is getting paid in benefits
> instead of salary.
>
> I am always very wary when people offer me something for free. Either they
> are trying to sell me something else later, or they are performing a
> social experiment.
>
> Bob
>
>
>
>
>


--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Hypercard-the-missing-link-to-the-web-tp4650010p4650105.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[Kay C Lan]

Peter,

I like your prior comments but I have to disagree with this:

>
> The problem with Hypercard, and what led to its demise, was fundamentally
> that it was not free.


I also don't understand this:


> The thing that killed it was a dog in the manger approach to things.
>
> Unless you are talking about Steve's management style.

My understanding of the situation was quite simple, Steve returned to
Apple, decided they needed to focus on 4 things, and if Steve was good at
anything, it was focus. HyperCard was not in that focus, so it was turfed,
it wouldn't have mattered if someone showed him how to turn desktop lead
into internet gold, it wasn't in his focus, and therefore would never be.
My understanding of Steve is that he could become so focused that he could
easily lie through his teeth; which I understand is exactly what he did
with regards to where HyperCard was headed.

People would have happily contiuned paying for HyperCard, it may have never
reached it's full potential, other happenings may have overtaken it, and
they did, but it certainly wasn't price that was it's demise - if it were
then we all wouldn't be here paying for LC.

[Peter Alcibiades]

It wasn't free as in open source free. It was proprietary and restricted and
there was no way to jail break it.

The dog in the manger approach was, we don't want it, we cannot use it (eat
it) and so we will not let anyone else who could use it and make good things
out of it have it either.

They would rather kill it than let someone else do something with it. I
fully agree - focus was essential for Apple. But why not turn it over to
open source? Because that way you lose control. The dog could not eat the
hay, but would not let the horse who could eat it either.

--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Hypercard-the-missing-link-to-the-web-tp4650010p4650114.html
Sent from the Revolution - User mailing list archive at Nabble.com.

["-=>JB]

Apple may have done the best thing by both letting hyperCard die and
not allowing it to be open source. What if they have a program that was
written in hyperCard but they totally rewrote for OS X that is revolutionary
and holding the rights to the pattens and source helped secure pattens
for their new program. It is possible had they opened up hyperCard like
everyone wanted them to it would infringe on future pattens. This would
not need to be software for programming like LiveCode and hyperCard.
It could be revolutionary ideas in programming for business & government.

I love hyperCard but it was getting very buggy as the OS advanced. Steve
Jobs needed to focus on the future and hold on to the rights of the past in
hopes it will help Apple survive and prosper for many years to come.

Steve Jobs had the ability to focus but he also had a vision that he could
see and he needed to stay true to his vision. He got things done and we
might understand more in the future. Apple and Steve Jobs keep things
secret and retain pattens and source code for good reasons.

It would take only one revolutionary idea to make it important for Apple
to keep hyperCard with its pattens and source closed.

-=>JB<=-



On Jun 1, 2012, at 4:11 AM, Peter Alcibiades wrote:

> It wasn't free as in open source free. It was proprietary and restricted and
> there was no way to jail break it.
>
> The dog in the manger approach was, we don't want it, we cannot use it (eat
> it) and so we will not let anyone else who could use it and make good things
> out of it have it either.
>
> They would rather kill it than let someone else do something with it. I
> fully agree - focus was essential for Apple. But why not turn it over to
> open source? Because that way you lose control. The dog could not eat the
> hay, but would not let the horse who could eat it either.
>
> --
> View this message in context: http://runtime-revolution.278305.n4.nabble.com/Hypercard-the-missing-link-to-the-web-tp4650010p4650114.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>

[Mark Wieder]

Peter-

Friday, June 1, 2012, 4:11:18 AM, you wrote:

> The dog in the manger approach was, we don't want it, we cannot use it (eat
> it) and so we will not let anyone else who could use it and make good things
> out of it have it either.

Kind of like the on-rev client.

--
-Mark Wieder
***@ahsoftware.net

[Bob Sneidar]

You could just offer the dog a steak, but then the analogy seems to be breaking down. ;-)

Bob


On Jun 1, 2012, at 8:22 AM, Mark Wieder wrote:

> Peter-
>
> Friday, June 1, 2012, 4:11:18 AM, you wrote:
>
>> The dog in the manger approach was, we don't want it, we cannot use it (eat
>> it) and so we will not let anyone else who could use it and make good things
>> out of it have it either.
>
> Kind of like the on-rev client.
>
> --
> -Mark Wieder
> ***@ahsoftware.net
>
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Kay C Lan]

On Fri, Jun 1, 2012 at 7:11 PM, Peter Alcibiades <
palcibiades-***@yahoo.co.uk> wrote:

>
> The dog in the manger approach was, we don't want it, we cannot use it (eat
> it) and so we will not let anyone else who could use it and make good
> things
> out of it have it either.
>
> You are certainly right there. Now I understand what you meant.

[Bernard Devlin]

Well, python was available when I started using Livecode, and I still
chose Livecode. I still wouldn't choose Python for a GUI app, but I
would use python on servers (for everything from system admin to
system monitoring to web templating) over Livecode. On the server I
don't see that Livecode offers me as much as python does. Python has
libraries that interface with mail servers, with LDAP, and even with
SNMP. And then there are a whole slew of web application servers to
choose from written in python. But where Livecode shines for me is as
a simple, dynamic presentation layer, with access to a variety of
forms of local storage. That's not to say I wouldn't code business
logic in Livecode, but to say that different tools (and ecospheres)
have different strengths, and its not a question of choosing a
language without regard to the strengths of the language and the
ecosphere.


Bernard

On Fri, Jun 1, 2012 at 8:40 AM, Peter Alcibiades
<palcibiades-***@yahoo.co.uk> wrote:
> You're not taking account of the Open Source movement.  Were I starting again
> at this point, the choice would be Python.  Genuinely free in every way, and
> not just as in beer.

[Glen Bojsza]

Back in the early 2000 pythonware was formed by several prominent leaders in the python community.

It was delivering an IDE for python...I actually was one of the first and few who bought a license.

They eventually shut down. From a conversation with one of the founders I learnt that people expected anything and everything dealing with python to be free. Ergo the business model failed.

I still have the t-shirt that came with the license :-)


Glen

On Jun 1, 2012, at 5:02 AM, Bernard Devlin <***@gmail.com> wrote:

> Well, python was available when I started using Livecode, and I still
> chose Livecode. I still wouldn't choose Python for a GUI app, but I
> would use python on servers (for everything from system admin to
> system monitoring to web templating) over Livecode. On the server I
> don't see that Livecode offers me as much as python does. Python has
> libraries that interface with mail servers, with LDAP, and even with
> SNMP. And then there are a whole slew of web application servers to
> choose from written in python. But where Livecode shines for me is as
> a simple, dynamic presentation layer, with access to a variety of
> forms of local storage. That's not to say I wouldn't code business
> logic in Livecode, but to say that different tools (and ecospheres)
> have different strengths, and its not a question of choosing a
> language without regard to the strengths of the language and the
> ecosphere.
>
>
> Bernard
>
> On Fri, Jun 1, 2012 at 8:40 AM, Peter Alcibiades
> <palcibiades-***@yahoo.co.uk> wrote:
>> You're not taking account of the Open Source movement. Were I starting again
>> at this point, the choice would be Python. Genuinely free in every way, and
>> not just as in beer.
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Bernard Devlin]

Well, things could be hotting up in the dynamic IDE world.

http://www.kickstarter.com/projects/ibdknox/light-table?ref=history

Light Table looks like it is a modern take on the old Smalltalk IDE
(Visualage, Squeak). It's going back to the idea of having code in an
image (stacks in our case), compared to separate files on the
filesystem (and of course, it will meet with the same issues of source
code control).

In some ways an IDE for Livecode could already be doing many of these
things that Light Table proposes. Maybe I'm misremembering the impact
of GLX2 on our community, but with enough resources I'm sure Runrev
could have taken up the ideas in it and gone much further, given the
dynamic nature of Livecode. We might have had our own Light Table by
now if Runrev had the funds to dedicate to that task (I'm sure some
are aghast at the idea of Light Table, and I'm far from convinced
myself).

It is quite amazing that from within the Livecode IDE we can switch
between script editors with very different conceptions of how things
should be done (and those conceptions have been narrowed because
Runrev was inspired to adopt some of the ideas used in GLX2).

[Lynn Fredricks]

> Even if Apple gave away Hypercard to people who bought a mac
> without it, Apple would still be paying for it. In the case
> of all those other things, the taxpayer is paying for it, or
> else the company that hired him is paying for it, and
> actually he is likely himself paying for it because he is
> probably getting paid less considering he is getting paid in
> benefits instead of salary.

Costs do not automatically get passed on to customers in the same way. Some
business models work that way in a dollar-to-dollar sense, but most
successful ones (other than oil companies) do not.

Apple used to bundle various products either to differentiate one model from
another (esp after they started differentiating between business and home
use), to keep customers happy in key markets or, to keep customers from
looking at total solutions from competitors.

The key applications that Apple gave away for free back when were critical
for them to maintain their hold on the education market, esp in the era when
desktop publishing was in its childhood. They could easily afford to do that
because they charged a premium for their hardware/software packages.

Best regards,

Lynn Fredricks
President
Paradigma Software
http://www.paradigmasoft.com

Valentina SQL Server: The Ultra-fast, Royalty Free Database Server

[Bob Sneidar]

Exactly my point. Maybe it's a matter of semantics, or perhaps I imagine things work a certain way inside a corporation, but I always envision a bunch of suits sitting around a conference table, deciding how to price a product, and taking into consideration all the "free" stuff they are putting into it.

If Apple had no included anything for free, (not sure how to measure that) would they have charged less? Hmmm... no way to test it, so it must remain a mystery.

Bob


On Jun 1, 2012, at 7:54 AM, Lynn Fredricks wrote:

> The key applications that Apple gave away for free back when were critical
> for them to maintain their hold on the education market, esp in the era when
> desktop publishing was in its childhood. They could easily afford to do that
> because they charged a premium for their hardware/software packages.
>
> Best regards,
>
> Lynn Fredricks

[Lynn Fredricks]

> If Apple had no included anything for free, (not sure how to
> measure that) would they have charged less? Hmmm... no way to
> test it, so it must remain a mystery.

The point of a bundle is to justify the price you want your target customer
to pay - in Apple's case, they wanted you to pay premium prices (at the
time). Consider why Apple never themselves didn't offer a barebones system.
It was never in their corporate chemistry (certainly never in SJ's) to
pursue that kind of strategy. When he killed off the clone market (which had
players who did that), he could have simply had really basic cheap systems
made inside Apple - but that's contrary to the premium product market
strategy, and more like the white box or "value" market that Dell used to
pursue.

Within each product line (Macs, iPod, iPhone, iPad) you have very clear and
very simple differentiated levels - the low end is cheapest and sports fewer
features, but it offers a complete solution in itself for specific target
market and expected follow up sales of other products. You can only
"configure" away so much from these.

There's an extremely dry (thinking about it makes me reach for lotion!) but
very interesting book called the Strategy and Tactics of Pricing that delves
into the topic of...well, you can guess :-)

Best regards,

Lynn Fredricks
President
Paradigma Software
http://www.paradigmasoft.com

Valentina SQL Server: The Ultra-fast, Royalty Free Database Server

[Richard Gaskin]

Macworld UK gave LiveCode a 5-out-of-5-star review:
<http://www.macworld.co.uk/mac/reviews/?reviewid=3361007>

That's a nice follow-up to LiveCode being voted "Best Developer Tool" at
the MacTech conference in November:
<http://runrev.com/newsletter/november/issue122/newsletter1.php>

Rackin' up the accolades - congrats, RunRev.

--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv

[Mark Wieder]

Richard Gaskin <***@...> writes:

>
> Macworld UK gave LiveCode a 5-out-of-5-star review:
> <http://www.macworld.co.uk/mac/reviews/?reviewid=3361007>

"Cons: Complex licensing matrix"

Well said, MacWorld UK.

--
Mark Wieder
***@ahsoftware.net

[Richard Miller]

What are people doing to sell and license an LC-created Android app?

I looked at Google Play, but that appears to use a non-LC-compatible
licensing process. What can be done to restrict illegal app copying,
short of writing a custom app registration process, as would be done for
any desktop app?

Also, I don't believe Google Play's in-app billing system is LC
compatible yet. So that apparently means it is necessary to submit a
version of our app that requires payment in advance by the customer (in
addition to a free test version). Is that right?

Has anybody published an Android app through any market other than
Google Play? For example, Amazon? Is that a better choice?

In our case, we are not focused on using any service/market to help
promote our app, as we can do that directly from our web site. Our app
is highly targeted. Just looking for the easiest way to install our app
on a customers device, and potentially restrict illegal copying.

Thanks.
Richard Miller

[Colin Holgate]

Amazon is more straightforward. Not sure if they have the same DRM options you have in Google Play. With Google Play you can take an easy route, and hope there isn't too much piracy, or you can go for another option they have that somehow encrypts the app to make sure it will only play on the purchaser's devices.

One big thing to watch out for is that when you first submit an app to Google Play, and haven't yet set up how they will pay you, the app will be instantly available as a free app. You're not allowed to charge for an app that started off as a free app. That can be solved by creating a new app with a different app ID, but that's a shame to have to do, just because you didn't notice that your app was placed as a free one.

[Richard Miller]

Thanks, Colin.

The problem I have with Amazon is that it is U.S. only, and many of our
customers are elsewhere.

Sounds like you used Google Play. Did you go without the encryption
option? Did you somehow use in-app purchasing or simply publish a paid app?

Thanks.
Richard



On 6/2/2012 9:51 AM, Colin Holgate wrote:
> Amazon is more straightforward. Not sure if they have the same DRM options you have in Google Play. With Google Play you can take an easy route, and hope there isn't too much piracy, or you can go for another option they have that somehow encrypts the app to make sure it will only play on the purchaser's devices.
>
> One big thing to watch out for is that when you first submit an app to Google Play, and haven't yet set up how they will pay you, the app will be instantly available as a free app. You're not allowed to charge for an app that started off as a free app. That can be solved by creating a new app with a different app ID, but that's a shame to have to do, just because you didn't notice that your app was placed as a free one.
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>

[Colin Holgate]

Without encryption, and yes it was just a paid app.


On Jun 2, 2012, at 2:14 PM, Richard Miller <***@together.net> wrote:

> Sounds like you used Google Play. Did you go without the encryption option? Did you somehow use in-app purchasing or simply publish a paid app?

[Andrew Henshaw]

I have an app in both the Google Play and Amazon stores, and find Google is the much better option for me.

With the Amazon system you have to submit every update for review and then wait. If you want to withdraw a product from sale you have to write to them. With the Google system you can simply upload a new apk, activate it and its good to go. You can also remove it from sale, change the price etc etc. Also sales wise, for me the Google store sells in a 6/1 ratio compared to the Amazon store.

A couple of things to watch are, as mentioned beforeand unlike the Apple store, you cannot switch a product from free to paid, and the manifest is used to work out the devices the app will run on and this will include Android tablets bey default so make sure you app resizes to all the different Android resolutions or wait for the negative reviews to roll in.

As far as protection on Android goes, I dont think ive seen an app that has not been cracked and is not available for download through a torrent site. My apps rely on quite a lot of interaction with a web feed, so I can simply change the location of the feed between releases which renders any cracked copies useless. Its not ideal, but the best I can do with my abilities at the moment.

Andy


On 2 Jun 2012, at 19:14, Richard Miller wrote:

> Thanks, Colin.
>
> The problem I have with Amazon is that it is U.S. only, and many of our customers are elsewhere.
>
> Sounds like you used Google Play. Did you go without the encryption option? Did you somehow use in-app purchasing or simply publish a paid app?
>
> Thanks.
> Richard
>
>
>
> On 6/2/2012 9:51 AM, Colin Holgate wrote:
>> Amazon is more straightforward. Not sure if they have the same DRM options you have in Google Play. With Google Play you can take an easy route, and hope there isn't too much piracy, or you can go for another option they have that somehow encrypts the app to make sure it will only play on the purchaser's devices.
>>
>> One big thing to watch out for is that when you first submit an app to Google Play, and haven't yet set up how they will pay you, the app will be instantly available as a free app. You're not allowed to charge for an app that started off as a free app. That can be solved by creating a new app with a different app ID, but that's a shame to have to do, just because you didn't notice that your app was placed as a free one.
>> _______________________________________________
>> use-livecode mailing list
>> use-***@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Richard Miller]

Thanks, Andy, for that useful information.

To post both a free and a paid version of an app at Google, does one
need to repeat the entire application process twice?



On 6/2/2012 4:41 PM, Andrew Henshaw wrote:
> I have an app in both the Google Play and Amazon stores, and find Google is the much better option for me.
>
> With the Amazon system you have to submit every update for review and then wait. If you want to withdraw a product from sale you have to write to them. With the Google system you can simply upload a new apk, activate it and its good to go. You can also remove it from sale, change the price etc etc. Also sales wise, for me the Google store sells in a 6/1 ratio compared to the Amazon store.
>
> A couple of things to watch are, as mentioned beforeand unlike the Apple store, you cannot switch a product from free to paid, and the manifest is used to work out the devices the app will run on and this will include Android tablets bey default so make sure you app resizes to all the different Android resolutions or wait for the negative reviews to roll in.
>
> As far as protection on Android goes, I dont think ive seen an app that has not been cracked and is not available for download through a torrent site. My apps rely on quite a lot of interaction with a web feed, so I can simply change the location of the feed between releases which renders any cracked copies useless. Its not ideal, but the best I can do with my abilities at the moment.
>
> Andy
>
>
> On 2 Jun 2012, at 19:14, Richard Miller wrote:
>
>> Thanks, Colin.
>>
>> The problem I have with Amazon is that it is U.S. only, and many of our customers are elsewhere.
>>
>> Sounds like you used Google Play. Did you go without the encryption option? Did you somehow use in-app purchasing or simply publish a paid app?
>>
>> Thanks.
>> Richard
>>
>>
>>
>> On 6/2/2012 9:51 AM, Colin Holgate wrote:
>>> Amazon is more straightforward. Not sure if they have the same DRM options you have in Google Play. With Google Play you can take an easy route, and hope there isn't too much piracy, or you can go for another option they have that somehow encrypts the app to make sure it will only play on the purchaser's devices.
>>>
>>> One big thing to watch out for is that when you first submit an app to Google Play, and haven't yet set up how they will pay you, the app will be instantly available as a free app. You're not allowed to charge for an app that started off as a free app. That can be solved by creating a new app with a different app ID, but that's a shame to have to do, just because you didn't notice that your app was placed as a free one.
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-***@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-***@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>

[Andrew Henshaw]

Yes, free and paid versions are treated as separate apps in all the stores ive used, including both Apple and Android. However it doesn't take very long as most of the time is taken preparing descriptions, screen shots etc. which can be mostly the same for both versions of the app.

The actual time taken to complete the application process on any of the stores is usually very short, its the review period that takes the time.

In my experience, Googles Play store doesnt have a review period so its instant, Amazon seem to take 2-3 days (ive read it can take longer but 2-3 days is my experience) while Apple take almost exactly a week for iOS apps.

You can of course distribute an Android app without a store at all if it helps.

Andy




On 2 Jun 2012, at 23:16, Richard Miller wrote:

> Thanks, Andy, for that useful information.
>
> To post both a free and a paid version of an app at Google, does one need to repeat the entire application process twice?
>
>
>
> On 6/2/2012 4:41 PM, Andrew Henshaw wrote:
>> I have an app in both the Google Play and Amazon stores, and find Google is the much better option for me.
>>
>> With the Amazon system you have to submit every update for review and then wait. If you want to withdraw a product from sale you have to write to them. With the Google system you can simply upload a new apk, activate it and its good to go. You can also remove it from sale, change the price etc etc. Also sales wise, for me the Google store sells in a 6/1 ratio compared to the Amazon store.
>>
>> A couple of things to watch are, as mentioned beforeand unlike the Apple store, you cannot switch a product from free to paid, and the manifest is used to work out the devices the app will run on and this will include Android tablets bey default so make sure you app resizes to all the different Android resolutions or wait for the negative reviews to roll in.
>>
>> As far as protection on Android goes, I dont think ive seen an app that has not been cracked and is not available for download through a torrent site. My apps rely on quite a lot of interaction with a web feed, so I can simply change the location of the feed between releases which renders any cracked copies useless. Its not ideal, but the best I can do with my abilities at the moment.
>>
>> Andy
>>

[Richard Miller]

Andy,

Thanks again. I've been studying the issue of self-publishing from our
web site, but have yet to determine a clear, simple process that I can
offer any customer for installing an Android app. Seems every method has
a step or two that could confuse some significant percentage of Android
device users. Do you know how best to proceed with this?

Richard




On 6/2/2012 6:54 PM, Andrew Henshaw wrote:
> Yes, free and paid versions are treated as separate apps in all the stores ive used, including both Apple and Android. However it doesn't take very long as most of the time is taken preparing descriptions, screen shots etc. which can be mostly the same for both versions of the app.
>
> The actual time taken to complete the application process on any of the stores is usually very short, its the review period that takes the time.
>
> In my experience, Googles Play store doesnt have a review period so its instant, Amazon seem to take 2-3 days (ive read it can take longer but 2-3 days is my experience) while Apple take almost exactly a week for iOS apps.
>
> You can of course distribute an Android app without a store at all if it helps.
>
> Andy
>
>
>
>
> On 2 Jun 2012, at 23:16, Richard Miller wrote:
>
>> Thanks, Andy, for that useful information.
>>
>> To post both a free and a paid version of an app at Google, does one need to repeat the entire application process twice?
>>
>>
>>
>> On 6/2/2012 4:41 PM, Andrew Henshaw wrote:
>>> I have an app in both the Google Play and Amazon stores, and find Google is the much better option for me.
>>>
>>> With the Amazon system you have to submit every update for review and then wait. If you want to withdraw a product from sale you have to write to them. With the Google system you can simply upload a new apk, activate it and its good to go. You can also remove it from sale, change the price etc etc. Also sales wise, for me the Google store sells in a 6/1 ratio compared to the Amazon store.
>>>
>>> A couple of things to watch are, as mentioned beforeand unlike the Apple store, you cannot switch a product from free to paid, and the manifest is used to work out the devices the app will run on and this will include Android tablets bey default so make sure you app resizes to all the different Android resolutions or wait for the negative reviews to roll in.
>>>
>>> As far as protection on Android goes, I dont think ive seen an app that has not been cracked and is not available for download through a torrent site. My apps rely on quite a lot of interaction with a web feed, so I can simply change the location of the feed between releases which renders any cracked copies useless. Its not ideal, but the best I can do with my abilities at the moment.
>>>
>>> Andy
>>>
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>

[J. Landman Gay]

On 6/2/12 7:04 PM, Richard Miller wrote:
> Andy,
>
> Thanks again. I've been studying the issue of self-publishing from our
> web site, but have yet to determine a clear, simple process that I can
> offer any customer for installing an Android app. Seems every method has
> a step or two that could confuse some significant percentage of Android
> device users. Do you know how best to proceed with this?

If you send the apk as an email attachment, clicking the link in the
email will install the app provided the customer reads the email on
their Android device.

There are many other ways too, but they usually involved an Android file
manager. Dropbox is another easy, direct way to install but not all your
customers may have that.

--
Jacqueline Landman Gay | ***@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com

[Richard Miller]

Are you certain that this works this easily on most Android devices?

[Shawn Blc]

I'm definitely still learning when it comes to LC, however I've installed
hundreds of apk files on various Android enabled devices using
apkInstaller.

[Richard Miller]

Shawn,

The question I have (not owning an Android device myself), is if we post
an apk at our web site, will the average Android owner be able to
install it?
Do we need to point them to apkInstaller? Is it reasonable to require
them to hook their Android device to their computer in order to transfer
the apk to their sd card? Or is it even easier for them to navigate to
our web site via their Android device browser, click a link, and then
basically have the apk installed?

Thanks.
Richard





On 6/3/2012 6:32 PM, Shawn Blc wrote:
> I'm definitely still learning when it comes to LC, however I've installed
> hundreds of apk files on various Android enabled devices using
> apkInstaller.

[Shawn Blc]

Richard,

I believe "MOST" Android users will be able to install an apk file with no
further instruction. That being said though, there will be the "few" that
won't be able to figure it out, either because they're a new Android device
owner, or they simply never needed to install an apk file (app) outside of
the Android Market. I believe most Android device owners figure out
fairly quickly how to install apk files. I know with my first Android
device, I was installing apk files the moment I learned that I could.
Within days of owning the device. :)

I no longer use an Android device as my primary device, but my daughter has
one that I use from time to time.

If anything, in a FAQ you could link to apkInstaller or advise them to
install the apk on their sd card and install from there. I don't know what
kind of app you have, but I'm betting most will be able to install it
without assistance.









On Sun, Jun 3, 2012 at 6:59 PM, Richard Miller <***@together.net> wrote:

> Shawn,
>
> The question I have (not owning an Android device myself), is if we post
> an apk at our web site, will the average Android owner be able to install
> it?
> Do we need to point them to apkInstaller? Is it reasonable to require them
> to hook their Android device to their computer in order to transfer the apk
> to their sd card? Or is it even easier for them to navigate to our web site
> via their Android device browser, click a link, and then basically have the
> apk installed?
>
> Thanks.
> Richard
>
>
>
>
>
>
> On 6/3/2012 6:32 PM, Shawn Blc wrote:
>
>> I'm definitely still learning when it comes to LC, however I've installed
>> hundreds of apk files on various Android enabled devices using
>> apkInstaller.

[Shawn Blc]

Richard,

I don't know what kind of app you have, but since I'm online for the next
couple of hours, if you want to email me privately with a download link to
your apk file, I'll check it out and let you know how easy the install
went. I'll then delete the apk file from my daughter's phone and give you
feedback.





On Sun, Jun 3, 2012 at 8:10 PM, Shawn Blc <***@gmail.com> wrote:

> Richard,
>
> I believe "MOST" Android users will be able to install an apk file with no
> further instruction. That being said though, there will be the "few" that
> won't be able to figure it out, either because they're a new Android device
> owner, or they simply never needed to install an apk file (app) outside of
> the Android Market. I believe most Android device owners figure out
> fairly quickly how to install apk files. I know with my first Android
> device, I was installing apk files the moment I learned that I could.
> Within days of owning the device. :)
>
> I no longer use an Android device as my primary device, but my daughter
> has one that I use from time to time.
>
> If anything, in a FAQ you could link to apkInstaller or advise them to
> install the apk on their sd card and install from there. I don't know what
> kind of app you have, but I'm betting most will be able to install it
> without assistance.
>
>
>
>
>
>
>
>
>
> On Sun, Jun 3, 2012 at 6:59 PM, Richard Miller <***@together.net> wrote:
>
>> Shawn,
>>
>> The question I have (not owning an Android device myself), is if we post
>> an apk at our web site, will the average Android owner be able to install
>> it?
>> Do we need to point them to apkInstaller? Is it reasonable to require
>> them to hook their Android device to their computer in order to transfer
>> the apk to their sd card? Or is it even easier for them to navigate to our
>> web site via their Android device browser, click a link, and then basically
>> have the apk installed?
>>
>> Thanks.
>> Richard
>>
>>
>>
>>
>>
>>
>> On 6/3/2012 6:32 PM, Shawn Blc wrote:
>>
>>> I'm definitely still learning when it comes to LC, however I've installed
>>> hundreds of apk files on various Android enabled devices using
>>> apkInstaller.

[Richard Gaskin]

Richard Miller wrote:

> The question I have (not owning an Android device myself), is if we post
> an apk at our web site, will the average Android owner be able to
> install it?

Not by default. As with the Amazon app store and other non-Google
outlets, the user will have to turn on the checkbox in
Settings->Applications to let them install apps from third-party sites.

While some find it enjoyable to perpetuate the meme that Android is a
haven for malware, once you read past the headlines you'll find that
actual infections are very small relative to their majority audience,
and more importantly most infections have come from downloads outside of
Google Play.

Obviously this hasn't been a problem for Amazon, but with all due
respect I'm guessing your web site isn't as popular as Amazon.com, and
therefore less trusted.

The savviest users will think twice before downloading an app from your
site, and some of those who would download it may not know how to unlock
their device to allow it to install.

Why not just put it in Google Play?

--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv

[Richard Miller]

Hi Richard,

Our main reason for not wanting to use Google Play is that the vast
majority of our customers will find our app through our site, which is
well known in our sector. We'd be giving away 30% of a $10 app for
little return.



On 6/4/2012 10:12 AM, Richard Gaskin wrote:
> Richard Miller wrote:
>
>> The question I have (not owning an Android device myself), is if we post
>> an apk at our web site, will the average Android owner be able to
>> install it?
>
> Not by default. As with the Amazon app store and other non-Google
> outlets, the user will have to turn on the checkbox in
> Settings->Applications to let them install apps from third-party sites.
>
> While some find it enjoyable to perpetuate the meme that Android is a
> haven for malware, once you read past the headlines you'll find that
> actual infections are very small relative to their majority audience,
> and more importantly most infections have come from downloads outside
> of Google Play.
>
> Obviously this hasn't been a problem for Amazon, but with all due
> respect I'm guessing your web site isn't as popular as Amazon.com, and
> therefore less trusted.
>
> The savviest users will think twice before downloading an app from
> your site, and some of those who would download it may not know how to
> unlock their device to allow it to install.
>
> Why not just put it in Google Play?
>
> --
> Richard Gaskin
> Fourth World
> LiveCode training and consulting: http://www.fourthworld.com
> Webzine for LiveCode developers: http://www.LiveCodeJournal.com
> LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>

[J. Landman Gay]

On 6/3/12 5:16 PM, Richard Miller wrote:
> Are you certain that this works this easily on most Android devices?
>

[Richard Miller]

Thanks Jacqueline & Shawn,

I did more testing at Verizon, and it seems several of these methods
work reliably and can be mastered by most Android owners.

Richard



On 6/3/2012 9:49 PM, J. Landman Gay wrote:
> On 6/3/12 5:16 PM, Richard Miller wrote:
>> Are you certain that this works this easily on most Android devices?
>>

[J. Landman Gay]

On 6/2/12 3:41 PM, Andrew Henshaw wrote:
>Also sales wise, for me the Google
> store sells in a 6/1 ratio compared to the Amazon store.

Mine was just the opposite, I make more sales on Amazon. Maybe it
depends on what type of app, or the phase of the moon.

--
Jacqueline Landman Gay | ***@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com

[Ken Ray]

On Jun 1, 2012, at 1:51 PM, Richard Gaskin wrote:

> Macworld UK gave LiveCode a 5-out-of-5-star review:
> <http://www.macworld.co.uk/mac/reviews/?reviewid=3361007>
>
> That's a nice follow-up to LiveCode being voted "Best Developer Tool" at the MacTech conference in November:
> <http://runrev.com/newsletter/november/issue122/newsletter1.php>
>
> Rackin' up the accolades - congrats, RunRev.

Sweet! Well done guys!

Ken Ray
Sons of Thunder Software, Inc.
Email: ***@sonsothunder.com
Web Site: http://www.sonsothunder.com/

[Igor de Oliveira Couto]

Congratulations, RunRev!

On 02/06/2012, at 4:51 AM, Richard Gaskin wrote:

> Macworld UK gave LiveCode a 5-out-of-5-star review:
> <http://www.macworld.co.uk/mac/reviews/?reviewid=3361007>

Well deserved!

And, talking about reviews, I came across a rather scathing write-up on LiveCode at the very popular "MacUpdate" site. Because of that negative review, I missed out on trying out LiveCode earlier. It is sad to see that LiveCode is rated so poorly in MacUpdate, and that other developers, like me, might be missing out on adding a great tool to their toolbox.

With this in mind, I ask you guys, that if you have the time and inclination, please head over to MacUpdate, register, and give a positive star rating to LiveCode.

Kind regards to all,

--
Igor Couto
Sydney, Australia

[Kay C Lan]

What a great write up, congrats Runrev Team.

In light of the other thread about HyperCard, the only thing that makes me
wince in the write-up is the multiple references to the stack/card metaphor.

Whilst a knowledge of the past is all well and good, for the rising
generation of potential programmers, "is based on the ground breaking
HyperCard" would have been all the reference needed. Anyone looking for
HC's replacement would have had their interest peaked. For new programmers
the Stack, and particularly Card metaphor is a sidetrack.

The biggest hurdle I had to cross when transitioning from HC to LC, was the
move AWAY from the use of Cards as a storage system. To take better
advantage of all those improvements over HC I had to STOP thinking of data
as Cards.

I haven't written a Stack with multiple Cards in quite a while. Stacks and
SubStacks, yes. When was the last time anyone here created a Stack full of
Cards?

If I was to take a room full of students, brand new to programming, I would
teach them about seperating the GUI from the data. I'd refer to the data in
terms that LC loves; lines, words, items, chars - chunks. And how to take
advantage of that. Apart from being forced to mention Card because scripts
are going to be written on the Card Script, and there is going to be
openCard and closeCard handlers, I know I'd ever mention the Card metaphor
because it's just not valid anymore.

The reason MacUpdate might have given it LC a lower rating is an assumption
that you are stuck building Stacks full of Cards.

If I were to use a metaphor for todays kids, I'd say LC is like iTunes:

You can click on a button and you can display a vast list of just text
(your music Library)
You can click on a button and display images and text (music Library with
Artwork)
You can click on a button and display just images.
You can double click on a line/word and start playing music or movies.
You can click on a button and connect to the internet
You can click on a button and download from the internet
You can create your own button that do their own custom sorts so you only
see the music/movies that meet whatever mood you feel like.

BUT it's not just for music or movies, it's for anything you can think of,
photos, emails, SMS, homework notes, athletic training records, football
scores, ANYTHING you do on a computer, you can do with LC.

When kids import another song into iTunes, they know it just becomes
another line of data, thats EXACTLY how they need to think about data with
LC.

But that's just me.

[Alejandro Tejada]

Hi Kay,


Kay C Lan wrote
>
> [snip]
> I haven't written a Stack with multiple Cards in quite a while. Stacks and
> SubStacks, yes. When was the last time anyone here created a Stack full of
> Cards?
> [snip]
>

Yes, I do. That stack in particular was a Course to apply for a specific
License
in California. The Course text in each card have a different and sometimes
unique
design format that was really difficult to recreate on the fly.

If we could have a complete typographic control over text fields using
kerning
(spacing between letters) and tracking (spacing between words) then, it
would
have been possible to recreate them from scratch.
Until then...

Alejandro

--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Hypercard-the-missing-link-to-the-web-tp4650010p4650193.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[Richard Gaskin]

Igor de Oliveira Couto wrote:

> Congratulations, RunRev!
>
> On 02/06/2012, at 4:51 AM, Richard Gaskin wrote:
>
>> Macworld UK gave LiveCode a 5-out-of-5-star review:
>> <http://www.macworld.co.uk/mac/reviews/?reviewid=3361007>
>
> Well deserved!
>
> And, talking about reviews, I came across a rather scathing write-up on LiveCode at the very popular "MacUpdate" site. Because of that negative review, I missed out on trying out LiveCode earlier. It is sad to see that LiveCode is rated so poorly in MacUpdate, and that other developers, like me, might be missing out on adding a great tool to their toolbox.
>
> With this in mind, I ask you guys, that if you have the time and inclination, please head over to MacUpdate, register, and give a positive star rating to LiveCode.

Thanks for posting that, Igor.

I went to MacUpdate but haven't been able to post because their reg
system seems to have lost my account (I'm working with their support on
that).

I was surprised to see that a majority of the comments there were
negative. In a few cases the specifics related to not understanding the
product well, but others were quite valid from the perspective of a new
user (e.g., "no native controls on iOS"). IMNSHO, even the
misunderstandings could arguably be attributed to the product design,
since first impressions need to be accounted for in guiding the user.

Once my account is fixed I'll be happy to note my own experiences there,
but in all fairness I can understand why those who've posted negative
comments did so.

Of course those of us who know how to use the tool understand that many
of those aren't preventing us from getting work done, but I can see how
a quick-glance review of the demo would lead to some of the perceptions
noted there.

For example, option controls look so very different between how you lay
them out in the IDE and how they appear in iOS that it's very difficult
to lay out screens correctly.

Similarly, not getting the metrics for the screen keyboard or Android
pixel density also makes it difficult to design.

We know those are being addressed, but it's understandable that
newcomers seeing the product for the first time may find it initially
daunting.

--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv

[Lynn Fredricks]

> I was surprised to see that a majority of the comments there
> were negative. In a few cases the specifics related to not
> understanding the product well, but others were quite valid
> from the perspective of a new user (e.g., "no native controls
> on iOS"). IMNSHO, even the misunderstandings could arguably
> be attributed to the product design, since first impressions
> need to be accounted for in guiding the user.

It is unfortunate when there is a system that doesn't allow for vendor
response.

Ive had the experience before where some buyers have used review systems as
a form of blackmail, meaning, they demanded some feature or some special
service, and told that if they didn't get it that they'd trash the product
in a public place.

Consider also, if a competitor or a "champion" of another product buys yours
in a public venue that works this way, such as the Mac App Store. They can
heap abuse on your product pretty much freely and there is nothing you can
do about it.

Best regards,

Lynn Fredricks
Mirye Software Publishing
http://www.mirye.com

[Richard Gaskin]

Lynn Fredricks wrote:

> It is unfortunate when there is a system that doesn't allow for vendor
> response.
>
> Ive had the experience before where some buyers have used review systems as
> a form of blackmail, meaning, they demanded some feature or some special
> service, and told that if they didn't get it that they'd trash the product
> in a public place.
>
> Consider also, if a competitor or a "champion" of another product buys yours
> in a public venue that works this way, such as the Mac App Store. They can
> heap abuse on your product pretty much freely and there is nothing you can
> do about it.

Does MacUpdate really have such a restriction?

If so, they're no VersionTracker. Back before it was gobbled up by
CNET, VT was da bomb. Folks might post a bad comment now and then, but
I could step in to offer an explanation, or not that something's already
been fixed, and that provided a productive environment.

This MacUpdate restriction just seems prone to competitor abuse.

Has anyone here written MacUpdate about lifting this counterproductive
limitation?

--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv

[Lynn Fredricks]

> > Consider also, if a competitor or a "champion" of another
> product buys
> > yours in a public venue that works this way, such as the Mac App
> > Store. They can heap abuse on your product pretty much freely and
> > there is nothing you can do about it.
>
> Does MacUpdate really have such a restriction?

My understanding is that this is how it works with the Mac App Store.

Best regards,

Lynn Fredricks
President
Paradigma Software
http://www.paradigmasoft.com

Valentina SQL Server: The Ultra-fast, Royalty Free Database Server

[Igor de Oliveira Couto]

On 03/06/2012, at 10:09 AM, Lynn Fredricks wrote:

>>> Consider also, if a competitor or a "champion" of another
>> product buys
>>> yours in a public venue that works this way, such as the Mac App
>>> Store. They can heap abuse on your product pretty much freely and
>>> there is nothing you can do about it.
>>
>> Does MacUpdate really have such a restriction?
>
> My understanding is that this is how it works with the Mac App Store.

I have seen direct responses from developers many times in MacUpdate. These responses have been extremely useful, not only to clear out misunderstandings reported by users, by also to let others see how the developers deal with their customers. Indeed, if RunRev had posted a response to some of the comments there, it may prove useful in attracting more people willing to try out the product.

--
Igor Couto
Sydney, Australia

[Lynn Fredricks]

> >>> Consider also, if a competitor or a "champion" of another
> >> product buys
> >>> yours in a public venue that works this way, such as the Mac App
> >>> Store. They can heap abuse on your product pretty much freely and
> >>> there is nothing you can do about it.
> >>
> >> Does MacUpdate really have such a restriction?
> >
> > My understanding is that this is how it works with the Mac
> App Store.
>
> I have seen direct responses from developers many times in
> MacUpdate. These responses have been extremely useful, not
> only to clear out misunderstandings reported by users.

Right - Ive only talked about the Mac App Store, not MacUpdate - just to be
clear :-)

Best regards,

Lynn Fredricks
President
Paradigma Software
http://www.paradigmasoft.com

Valentina SQL Server: The Ultra-fast, Royalty Free Database Server

[Peter Haworth]

Hi Lynn,
I guess I'm somewhat confused by this. Anyone with an App Store account
can comment can't they? Or do Apple overtly prevent logins who they
identify as an app's developer from commenting?

I'm considering putting an app on the Mac App Store so this is definitly of
interest to me.

Pete
lcSQL Software <http://www.lcsql.com>



On Sat, Jun 2, 2012 at 5:09 PM, Lynn Fredricks <
***@proactive-intl.com> wrote:

> > > Consider also, if a competitor or a "champion" of another
> > product buys
> > > yours in a public venue that works this way, such as the Mac App
> > > Store. They can heap abuse on your product pretty much freely and
> > > there is nothing you can do about it.
> >
> > Does MacUpdate really have such a restriction?
>
> My understanding is that this is how it works with the Mac App Store.
>
> Best regards,
>
> Lynn Fredricks
> President
> Paradigma Software
> http://www.paradigmasoft.com
>
> Valentina SQL Server: The Ultra-fast, Royalty Free Database Server
>
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>

[Paul Hibbert]

On 2012-06-02, at 10:29 AM, Richard Gaskin wrote:

> Has anyone here written MacUpdate about lifting this counterproductive limitation?

I haven't written to MacUpdate, but I did take the time to write a positive review on their site about my experience with LiveCode, especially now that I have seen first hand how it can be used very successfully.

I'm not quite a complete novice developer (although not far off), I have tried several different options, but with LiveCode everything just fell into place so much easier.

When I saw the poor reviews I just wanted to help balance them off a little, with a few more positive reviews maybe people won't be put off so much.

Paul

[Mark Wieder]

Richard-

Friday, June 1, 2012, 11:51:17 AM, you wrote:

> Macworld UK gave LiveCode a 5-out-of-5-star review:
> <http://www.macworld.co.uk/mac/reviews/?reviewid=3361007>

Interesting tidbit here: one of my coworkers spotted the article this
afternoon. Never having heard of LiveCode, but remembering HyperCard,
he clicked his way over to the runrev web site, ran the promo video,
and came running over to my desk all excited about having seen me in
the video. Asked lots of questions about mobile development, and I'll
have to get back to him on Monday about some things I couldn't quite
remember off the top of my head, but looks like he'll be coming on
board soon.

--
-Mark Wieder
***@ahsoftware.net

[J. Landman Gay]

On 6/1/12 8:22 PM, Mark Wieder wrote:
> Richard-
>
> Friday, June 1, 2012, 11:51:17 AM, you wrote:
>
>> Macworld UK gave LiveCode a 5-out-of-5-star review:
>> <http://www.macworld.co.uk/mac/reviews/?reviewid=3361007>
>
> Interesting tidbit here: one of my coworkers spotted the article this
> afternoon. Never having heard of LiveCode, but remembering HyperCard,
> he clicked his way over to the runrev web site, ran the promo video,
> and came running over to my desk all excited about having seen me in
> the video. Asked lots of questions about mobile development, and I'll
> have to get back to him on Monday about some things I couldn't quite
> remember off the top of my head, but looks like he'll be coming on
> board soon.
>

Wow, cool. I bet Kevin would like to hear that.

--
Jacqueline Landman Gay | ***@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com

[Bob Sneidar]

The performa series was an attempt at making Apple systems to compete with the PC's of the time. A few were pretty good, but there were some pigs too. In the final analysis what Apple produced in an attempt to market cheap computers, was... well... cheap computers! Good riddance I say! I'll pay the extra for premium parts.

Bob


On Jun 1, 2012, at 11:45 AM, Lynn Fredricks wrote:

> Consider why Apple never themselves didn't offer a barebones system.
> It was never in their corporate chemistry (certainly never in SJ's) to
> pursue that kind of strategy.

[David C.]

Interestingly enough, as a Window and Linux user, I had never even
heard of Hyper-Card when I found MetaCard, then Rev and finally
LiveCode... I was just looking for a decent development tool for those
two platforms only. Mac's or anything to do with Apple never even
crossed my mind. (Seldom does still, although I do have a Mac-Mini
that I largely ignore.)

-David C.


On Fri, Jun 1, 2012 at 1:52 PM, Bob Sneidar <***@twft.com> wrote:
> The performa series was an attempt at making Apple systems to compete with the PC's of the time. A few were pretty good, but there were some pigs too. In the final analysis what Apple produced in an attempt to market cheap computers, was... well... cheap computers! Good riddance I say! I'll pay the extra for premium parts.
>
> Bob
>
>
> On Jun 1, 2012, at 11:45 AM, Lynn Fredricks wrote:
>
>> Consider why Apple never themselves didn't offer a barebones system.
>> It was never in their corporate chemistry (certainly never in SJ's) to
>> pursue that kind of strategy.
>
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



--
Best regards,
David C.

[Lynn Fredricks]

> The performa series was an attempt at making Apple systems to
> compete with the PC's of the time. A few were pretty good,
> but there were some pigs too. In the final analysis what
> Apple produced in an attempt to market cheap computers,
> was... well... cheap computers! Good riddance I say! I'll pay
> the extra for premium parts.

Indeed - they were not well constructed, but often they were differentiated
not just by price and poorly performing subsystems but with the included
software. In the mid 90s I was directly involved with several of those
pre-installed licensing deals with Apple.

Sadly, in that OS 8.x era, Apple began copying features from third party
products into the OS, even ones from products Apple bundled. Marketshare
shrank terribly. Vendors took huge risks on technologies that were later
killed off (hellooooo OpenDoc!).

Best regards,

Lynn Fredricks
President
Paradigma Software
http://www.paradigmasoft.com

Valentina SQL Server: The Ultra-fast, Royalty Free Database Server

[Kay C Lan]

On Sat, Jun 2, 2012 at 2:45 AM, Lynn Fredricks <
***@proactive-intl.com> wrote:

>
> Within each product line (Macs, iPod, iPhone, iPad) you have very clear and
> very simple differentiated levels - the low end is cheapest and sports
> fewer
> features,
>

Very interesting you should write that, that way. If I have my timeline
right, I think at the time HC got axed was about same time SJ walked into a
managers meeting, drew a simple cross on a whiteboard dividing it into 4
squares and placed the iMac and iBook (MacBook) in the top two, and the
PowerBook (MacBook Pro) and PowerMac (G5, Mac Pro) in the bottom two
squares. A stylised version of it became part of their ad campaign.

Which then brings me full circle to another thread on this List about where
OS X is headed, and my feeling that '...and a touch sensitive screen' will
be part of the future OS X requirement.

The 4 square focus seems to have shifted markedly.

[Colin Holgate]

I'm less sure about that. Steve Jobs spoke out about how touch screens are not the right way to work with desktop machines, and I've made enough touch screen kiosk applications to know that it's tiring to work that way.

The gestural stuff that is in Lion and Mountain Lion is great. But, it's geared towards trackpad use. I don't mind that, I've just used trackpads for years, and although I was very reluctant to install Lion, I'm liking the way I work with Mountain Lion and my Magic Trackpad. It makes a mouse feel clumsy.


On Jun 1, 2012, at 8:06 PM, Kay C Lan <***@gmail.com> wrote:

> >Which then brings me full circle to another thread on this List about where
> OS X is headed, and my feeling that '...and a touch sensitive screen' will
> be part of the future OS X requirement.

[Richard Gaskin]

Colin Holgate wrote:

> On Jun 1, 2012, at 8:06 PM, Kay C Lan wrote:
>
>> >Which then brings me full circle to another thread on this List
>> about where OS X is headed, and my feeling that '...and a touch
>> sensitive screen' will be part of the future OS X requirement.
>
> I'm less sure about that. Steve Jobs spoke out about how touch
> screens are not the right way to work with desktop machines...

Steve said a lot of things, and frequently did the opposite. It's part
of the secrecy culture, not tipping their hand to the competition and
all that - here's a brief rundown of some of them, including "no phone"
and "no tablet":
<http://www.tuaw.com/2010/05/18/when-jobs-says-no-we-hear-maybe-heres-why/>

When Apple launched the iPad Steve said, "If you see a stylus they blew
it", but last month Apple filed a patent application for a stylus:
<http://www.engadget.com/2012/05/24/apple-applies-for-stylus-patent/>

Like TUAW says, "When Steve says 'no', we hear 'maybe'". :)

Tipping their hand is just now how Apple works.


> ...and I've made enough touch screen kiosk applications to know
> that it's tiring to work that way.

Indeed it is, but only for long work sessions and only when the monitor
is oriented vertically.

ATMS and other kiosks have have revolutionized whole industries with
touch screens, and for the sort of longer-session workflows we use PCs
for Asus and others make touchscreen monitors that are designed to be
either vertically oriented or laid down at a 30-degree angle - very much
like a drafting table.

The drafting table orientation has been optimal for long work sessions
for centuries, so it seems inevitable that as computer form factors
continue to diversify we'll see an increasing number of those.

Windows 7 already includes support for touch gestures, as does Ubuntu
with UTouch, and as you noted Apple is increasingly supporting touch
gestures on their desktop as well.

The bigger question is precision: occupying only a single pixel, the
action point of a mouse makes it significantly more precise than any
finger can be. But that's ultimately a software design issue, not an
inherent flaw in the nature of touch devices as a whole.

We're seeing an increasing variety of productivity software for touch
devices, and there's no reason to believe these must be limited to 10"
screens.

Computing devices will get both smaller and larger as form factors
continue to diversify, with Google goggles leading the way on the small
end and touch monitors like Asus' leading the way on the large end.

The tablet is not the end of the evolutionary road. Every form factor
in current use is best recognized as a transitional technology.

--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv

[Kay C Lan]

On Sat, Jun 2, 2012 at 10:52 PM, Richard Gaskin
<***@fourthworld.com>wrote:

> The drafting table orientation has been optimal for long work sessions for
> centuries, so it seems inevitable that as computer form factors continue to
> diversify we'll see an increasing number of those.
>
> An iMac that tilts all the way back doesn't seem to hard to envisage.

>
> The bigger question is precision: occupying only a single pixel, the
> action point of a mouse makes it significantly more precise than any finger
> can be. But that's ultimately a software design issue, not an inherent
> flaw in the nature of touch devices as a whole.
>
> Which has been addressed in iOS already. If I prod my finger long enough
on some text the magnifying glass pops up and I can more precisely position
the insertion point. Clearly something similar could happen with graphics
programs to magnify 100 fold, a pixel becomes 10x10 pixels.

Which brings us all the way back to HC which had something similar in it's
image editor.

[Lynn Fredricks]

> I'm less sure about that. Steve Jobs spoke out about how
> touch screens are not the right way to work with desktop
> machines, and I've made enough touch screen kiosk
> applications to know that it's tiring to work that way.

This is why I miss Fake Steve. SJ validated or invalidated anything to suit
whatever his plans were at the moment. I loved how Fake Steve would point
out these personality foibles of the original.

Best regards,

Lynn Fredricks
President
Paradigma Software
http://www.paradigmasoft.com

Valentina SQL Server: The Ultra-fast, Royalty Free Database Server

[J. Landman Gay]

On 5/31/12 1:45 PM, Bernard Devlin wrote:
> I'm not sure they would use Livecode anyway.

I'm not so sure. A large number of the old HC mailing list are here now. :)

--
Jacqueline Landman Gay | ***@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com

[stephen barncard]

yeah, like me, I was devoted to read the Evangelist and Hypercard forums
every day. I piped the forums into the studio First Class systems.

On Thu, May 31, 2012 at 2:12 PM, J. Landman Gay <***@hyperactivesw.com>wrote:

> On 5/31/12 1:45 PM, Bernard Devlin wrote:
>
>> I'm not sure they would use Livecode anyway.
>>
>
> I'm not so sure. A large number of the old HC mailing list are here now. :)
>
> --
> Jacqueline Landman Gay | ***@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
>
>
Stephen Barncard
San Francisco Ca. USA

more about sqb <http://www.google.com/profiles/sbarncar>

[Peter M. Brigham, MD]

On Jun 1, 2012, at 1:47 AM, stephen barncard wrote:

> yeah, like me, I was devoted to read the Evangelist and Hypercard forums
> every day. I piped the forums into the studio First Class systems.

First Class! Now that brings back memories! Is there a museum somewhere for dead software?

-- Peter

Peter M. Brigham
***@gmail.com
http://home.comcast.net/~pmbrig

[Kay C Lan]

On Fri, Jun 1, 2012 at 11:12 PM, Peter M. Brigham, MD <***@gmail.com>wrote:

>
> First Class! Now that brings back memories! Is there a museum somewhere
> for dead software?
>
> What?? I still access the local Mac User Group via FirstClass 9.1 - not
that I would recommend it to anyone, there is certainly better options out
there to run an online non-profit community.

FirstClass may not be great, but it's not dead.

[Richmond]

On 06/01/2012 12:12 AM, J. Landman Gay wrote:
> On 5/31/12 1:45 PM, Bernard Devlin wrote:
>> I'm not sure they would use Livecode anyway.
>
> I'm not so sure. A large number of the old HC mailing list are here
> now. :)
>

I started with Hypercard in 1993 when it came bundled on a Mac LC475:

the first time I had seen an object-oriented programming language -
after PASCAL, FORTRAN and BASIC:

Wow! What a breath of fresh air; never looked back . . .

Very cheesed-off in 2001 when I went to Scotland and found that Mac OS X
would not work with Hypercard,
when, Bang! I found Metacard, and, a week later, Runtime Revolution.

[Bernard Devlin]

:) I know they (and you) are here! I even remember the days when Ms.
De Voto used to also grace this list. And, of course, the late, great
Eric Chatonet.

It is all those coulda-woulda-shouldas over at Ars Technica I was
referring to. After all, I was able to discover Runrev by accident 10
years back, when I followed up a reference to it on a mailing list for
a little-known relational database. If someone with no knowledge and
no experience of Hypercard could find Runrev, you'd think that all
those people on Ars Technica would have found Runrev by now. After
all, Ars is hardly a website about HTML for Dummies.

I see the editor at Ars has at least had the good sense to highlight
an informative comment about Livecode. That balances the article
better.

Bernard

On Thu, May 31, 2012 at 10:12 PM, J. Landman Gay
<***@hyperactivesw.com> wrote:
> On 5/31/12 1:45 PM, Bernard Devlin wrote:
>>
>> I'm not sure they would use Livecode anyway.
>
>
> I'm not so sure. A large number of the old HC mailing list are here now. :)
>
> --
> Jacqueline Landman Gay         |     ***@hyperactivesw.com
> HyperActive Software           |     http://www.hyperactivesw.com
>
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Bob Sneidar]

Done. Stunning isn't it, that people who knew about Hypercard can write articles about it and not know about Livecode?

Bob


On May 31, 2012, at 4:15 AM, Bernard Devlin wrote:

> http://arstechnica.com/apple/2012/05/25-years-of-hypercard-the-missing-link-to-the-web/
>
> It might be useful if some of you who can compare Hypercard and
> Livecode posted a comment to the article showing that the grandchild
> of Hypercard is alive and well. I've left a comment on the aggregating
> site that led me to the Ars Technica article, so don't want to be
> accused of spamming by writing on both of them. I never even knew
> about Hypercard until I found Runrev.
>
> Bernard
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Graham Samuel]

On Sat, 2 Jun 2012 09:18:47 +0800, Kay C Lan <***@gmail.com> wrote:

> I haven't written a Stack with multiple Cards in quite a while. Stacks and
> SubStacks, yes. When was the last time anyone here created a Stack full of
> Cards?

Well, I'm in the middle of creating one right now! It makes an ideal structure for a particular style of iOS app, where there are several small datasets, all with identical form - like a tiny database (with say less than 100 entries). Each dataset has an identical form to the others, and consists of data entry screens, summaries and projections (it's a financial app). This fits very nicely into a structure where there is set of template cards, and when a new dataset is required, these cards are cloned to instantiate the new set, and given scripts through behaviors (since all the business logic in each set is the same). This doesn't tie one down to a specific form factor, as the actual layout of the templates can be adjusted for different screen sizes and resolutions; but it is true that if there is a button or a data entry field on a template, then these objects will appear on the corresponding card whatever its actual shape or size. This really seems to me the very best way to handle this type of application, and the added bonus is that all the data can be saved as one stack.

Of course there are much simpler applications like catalogues (I bought an iOS app for example which describes the most common birds in the UK) where the information displayed is really pretty much like cards in an old-fashioned card index (maybe this is called a Rolodex in the US), and none the worse for that."Birds UK" is read-only, but it accommodates stuff like a button you can press to hear the bird's song, which wouldn't have worked in the paper version, but conceptually it's the same thing. I'm sure it predates LC for iOS, but it would have been a very good candidate for a stack full of cards…


Graham

[John Dixon]

Graham...

Sounds like a job for just the one card and an SQLlite db ...

> On Sat, 2 Jun 2012 09:18:47 +0800, Kay C Lan <***@gmail.com> wrote:
>
> > I haven't written a Stack with multiple Cards in quite a while. Stacks and
> > SubStacks, yes. When was the last time anyone here created a Stack full of
> > Cards?
>
> Well, I'm in the middle of creating one right now! It makes an ideal structure for a particular style of iOS app, where there are several small datasets, all with identical form - like a tiny database (with say less than 100 entries). Each dataset has an identical form to the others, and consists of data entry screens, summaries and projections (it's a financial app). This fits very nicely into a structure where there is set of template cards, and when a new dataset is required, these cards are cloned to instantiate the new set, and given scripts through behaviors (since all the business logic in each set is the same). This doesn't tie one down to a specific form factor, as the actual layout of the templates can be adjusted for different screen sizes and resolutions; but it is true that if there is a button or a data entry field on a template, then these objects will appear on the corresponding card whatever its actual shape or size. This really seems to me the very best way to handle this type of application, and the added bonus is that all the data can be saved as one stack.
>
> Of course there are much simpler applications like catalogues (I bought an iOS app for example which describes the most common birds in the UK) where the information displayed is really pretty much like cards in an old-fashioned card index (maybe this is called a Rolodex in the US), and none the worse for that."Birds UK" is read-only, but it accommodates stuff like a button you can press to hear the bird's song, which wouldn't have worked in the paper version, but conceptually it's the same thing. I'm sure it predates LC for iOS, but it would have been a very good candidate for a stack full of cards…
>
> Graham

[Francis Nugent Dixon]

Hi from Beautiful Brittany,

Kay C. Lan wrote :

>> I haven't written a Stack with multiple Cards in quite a while. Stacks and
>> SubStacks, yes. When was the last time anyone here created a Stack full of
>> Cards?
>

I came from Hypercard, and have been creating data bases for multiple
reasons for 20 years +. I dig into genealogy quite a lot, and have
many stacks containing multiple cards. My biggest stack does distance
calculation between cities in the world, and has 5000 cards, one for each
city. I certainly could merge all the data into one field and gain some
execution time, but it works fine like it is. As I write songs, I also have
built a song catalogue containing lyrics, MP3 files and video clips, and even
Sacem data, Royalties, etc. for nearly 1000 songs, written withmy composer
colleague.
I reckon I create a multiple card stack about once a week, sometimes used
once only, for selecting, modifying and merging data from the internet sites.
Any excuse is good for spending a day or so in building a stack and furiously
scripting, mostly for pleasure, just to produce a list of compiled data from
many sources.I even have model stacks and a graveyard of scripts which I use
to build multiple card stacks in record time.

I never got around to using arrays, or any method fur putting data into more
compact forms on single cards. Too lazy to learn, I guess !

-Francis

[Peter Haworth]

Personally, I'm a big fan of separating code and data so always use
external storage for the data in my applications, be it a flat file or a
database. However, that entails learning how to access files efficiently
and/or learning SQL so I can see that folks would prefer to keep the data
within Livecode.

For applications which are purely personal in nature, I think that's fine.
But I would guess if you are writing an application for commercial use,
customers would not be happy about their data being stored in a proprietary
format which they cannot access other than through Livecode.

Pete
lcSQL Software <http://www.lcsql.com>



On Sun, Jun 3, 2012 at 3:41 AM, Francis Nugent Dixon <***@wanadoo.fr>wrote:

> Hi from Beautiful Brittany,
>
> Kay C. Lan wrote :
>
> >> I haven't written a Stack with multiple Cards in quite a while. Stacks
> and
> >> SubStacks, yes. When was the last time anyone here created a Stack full
> of
> >> Cards?
> >
>
> I came from Hypercard, and have been creating data bases for multiple
> reasons for 20 years +. I dig into genealogy quite a lot, and have
> many stacks containing multiple cards. My biggest stack does distance
> calculation between cities in the world, and has 5000 cards, one for each
> city. I certainly could merge all the data into one field and gain some
> execution time, but it works fine like it is. As I write songs, I also have
> built a song catalogue containing lyrics, MP3 files and video clips, and
> even
> Sacem data, Royalties, etc. for nearly 1000 songs, written withmy composer
> colleague.
> I reckon I create a multiple card stack about once a week, sometimes used
> once only, for selecting, modifying and merging data from the internet
> sites.
> Any excuse is good for spending a day or so in building a stack and
> furiously
> scripting, mostly for pleasure, just to produce a list of compiled data
> from
> many sources.I even have model stacks and a graveyard of scripts which I
> use
> to build multiple card stacks in record time.
>
> I never got around to using arrays, or any method fur putting data into
> more
> compact forms on single cards. Too lazy to learn, I guess !
>
> -Francis
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>

[Kay C Lan]

On Mon, Jun 4, 2012 at 12:49 AM, Peter Haworth <***@lcsql.com> wrote:

> Personally, I'm a big fan of separating code and data so always use
> external storage for the data in my applications, be it a flat file or a
> database. However, that entails learning how to access files efficiently
> and/or learning SQL so I can see that folks would prefer to keep the data
> within Livecode.
>
> You missed the other option available, custom properties; which can also
take long time HC users a while before they have their 'ah ha' moment.

I note Graham's, Francis' and Alejandro's uses of multi-card stacks, and
whilst I'd tackle Graham's and Francis' problems differently, I would not
suggest they change their work method because if it works for them, great,
that's the great thing about LC, there are multiple ways to skin the cat.

Alejandro's is a difficult feline, and it certainly made me pause to think
how I'd tackle something similar. I noted his other post and I too would
like to see if anyone has done some amazing things with the new field
features. My own work with them have been nothing more than rudimentary
tests. I had a look at LC's own Dictionary, which has a lot of formatted
text, and could use a separate card for each entry but doesn't. It only
uses three cards and from what I can tell only one of them is for us
'users', the other two I think are used by the Runrev team to
add/remove/update entries. The LC Dictionary predates the new field
features and only seems to use htmlText to do its special formatting.

But the mention of skinning cats gave me my own 'ah ha' moment. I'm under
the impression that 'skinning' is a term used in other 'modern' programming
environments. I see no reason why, for the current iTunes generation, that
the LC programming metaphor could not be changed to one of windows (Stacks)
and skins (Cards).

[Robert Brenstein]

Kay C. Lan wrote :
> I haven't written a Stack with multiple Cards in quite a while. Stacks and
> SubStacks, yes. When was the last time anyone here created a Stack full of
> Cards?
>

When using card-size tab button to switch among various sets of
functional views, hiding and showing groups of controls is optimal in
most cases but switching between cards works better in some cases.

Robert