Re: Rev Player?

[Richard Gaskin]

James Hurley wrote:

> Richard wrote:
>>
>> I believe RunRev still makes a Player, so there should be one
>> available for the latest engine version.
>>
>> But if you're using Studio or Enterprise it's only a few minutes'
>> work to make your own, allowing you to tailor the user experience
>> and branding for your specific audience while retaining all the
>> conveniences of being able to deliver tiny stack files.
>
> Richard,
>
> This sound intriguing, but I wouldn't know where to begin. How about a
> hint?

At the heart of it is the popular syntax for downloading and opening a 
stack which Rev provides in one simple line:


   go url 

e.g.:

  go url "http://www.fourthworld.net/channels/Revel.rev";

Just include the Internet library when building a standalone, and any 
standalone can do that.


And of course standalones can open stack files locally too, so a custom 
"player" can run files from anywhere and provide a convenient offline 
mode if desired.


Stack files can be pretty small, but with Rev's built-in compress and 
decompress functions you can make them even smaller.  Just run them 
through compress before uploading them to your server like this:


  put compress( url "binfile:/hd/folder/stack.rev" ) \
into url "ftp://user|passw...@ftp.domain.com/stack.rev.gz"

...and then your standalone can decompress them on the fly with:

  go decompress( url "http://domain.com/stack.rev.gz";)

The compress/decompress functions use the gzip algorithm, which is very 
efficient for textual patterns like scripts, so it's not uncommon to see 
compressed stacks save between 30% and 50% in size, sometimes more.


On the user interface side, like everything else in Rev the sky's the 
limit.  You could, for example, provide a sort of "Library" window which 
presents a list of stacks already downloaded and new ones available on 
the server, letting the user download those to a local "cache" folder 
you can maintain locally.


If you don't want to bother your user with keeping track of their stack 
files you can store them all in one place and provide a UI to list and 
open them.  Good places to store such a cache of stack files are the 
Application Data folder -- specialFolderPath("26") -- on Win or the 
Application Support folder -- specialFolderPath("asup") -- on Mac.  See 
Ken Ray's site for a complete listing of codes supported by Rev's 
specialFolderPath function:



Managing the list of available files can be done easily by just posting 
a small text file to your server which contains info about the stacks 
there.  If the file is tab-delimited you can just drop it into a list 
field for display without modification.  At a minimum this file could 
have fields for the stack name, a brief description, and the url, but of 
course you can add any other info that would be useful for your app.


All this is fun, but then consider what you can do by tossing the Rev 
CGI into the mix.  You can build forms in stacks used by your standalone 
which use the post command to send data to a CGI, where the data can use 
your mail server to send you mail, or log posts to a message board, or 
submit test results for courseware for instructor review, or anything 
else you can dream up.


While you're at it you can make whatever tools you need to manage all 
this in just a few minutes in Rev, such as tools for compressing and 
uploading your stacks and updating your stack info list file.


Various forms of all this are used by RevNet, included in the Rev 
install - in Rev, see Development->Plugins->GoRevNet


On my ever-growing To Do list is turning RevNet into a more flexible 
library for broader use across multiple stack-sharing apps, but if you 
can make sense of the code in RevNet you're welcome to borrow from it if 
it's helpful.


These two examples of distributed stackware are also worth looking at, 
inspiring real-world uses of "go url":


The Reactor Lab


Dynamic Digital Maps



IMO, sharing stacks over the Internet within standalones is one of the 
most underutilized capabilities of Rev.  There's a bit of irony with 
that as well, given that we've had this capability for more than a 
decade with Rev and Rev makes it so easy to do.


The new Rev web plugin is way cool and there are a great many uses for 
it, but there's also a universe of opportunities for delivering stacks 
and other media with all the benefits of Internet connectivity in an 
application environment dedicated for specific tasks.


If Web 2.0 is Google Maps, perhaps Web 3.0 is Google Earth.

With OS X's Widgets and Vista's Gadgets, older technologies like Rebol 
and new ones like Adobe AIR, there seems to be an infinite variety of 
ways one can use the Internet in specialized applications.


With all the talk about The End of the Desktop, people sometimes forget 
that the Desktop is where the Browser lives too. :)

Re: Rev Player?

[James Hurley]

Message: 3
Date: Sat, 11 Jul 2009 11:00:30 -0700
From: Richard Gaskin 
Subject: Re: Rev Player?
To: How to use Revolution 
Message-ID: <4a58d33e.9060...@fourthworld.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Paul Gabel wrote:

Does anyone know if Revolution Player is still being supported? All I
can find is Player 2.7.1, and my stack created in Rev 3.5 won't open
in it.


I believe RunRev still makes a Player, so there should be one  
available

for the latest engine version.

But if you're using Studio or Enterprise it's only a few minutes' work
to make your own, allowing you to tailor the user experience and
branding for your specific audience while retaining all the  
conveniences

of being able to deliver tiny stack files.


Richard,

This sound intriguing, but I wouldn't know where to begin. How about a  
hint?


Jim Hurley

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev Player?

[Bill Marriott]

You'll find links to download the Rev Player 3.0 here:

http://www.runrev.com/downloads/all-downloads/full-list/

Specifically:

http://developer.runrev.com/components/revolution/media/3.0.0-gm-3/Revolution%20Player.exe

http://developer.runrev.com/components/revolution/media/3.0.0-gm-3/Revolution%20Player.dmg



"Paul Gabel"  wrote in 
message news:13c97a03-d1fc-4fbf-926f-8b3c87275...@comcast.net...
Does anyone know if Revolution Player is still being supported? All I  can 
find is Player 2.7.1, and my stack created in Rev 3.5 won't open  in it.


Thank you, Paul Gabel
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev Player?

[Richard Gaskin]

Paul Gabel wrote:
Does anyone know if Revolution Player is still being supported? All I  
can find is Player 2.7.1, and my stack created in Rev 3.5 won't open  
in it.


I believe RunRev still makes a Player, so there should be one available 
for the latest engine version.


But if you're using Studio or Enterprise it's only a few minutes' work 
to make your own, allowing you to tailor the user experience and 
branding for your specific audience while retaining all the conveniences 
of being able to deliver tiny stack files.


In fact, with just a little more work you can build in RevNet-like 
capabilities to download stacks from your server to run in your player, 
opening up options for even simpler deployment to your users - they 
download your app once, and have access to anything you want to share 
with them over the 'net.


--
 Richard Gaskin
 Fourth World
 Revolution training and consulting: http://www.fourthworld.com
 Webzine for Rev developers: http://www.revjournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Rev Player?

[Paul Gabel]

Does anyone know if Revolution Player is still being supported? All I  
can find is Player 2.7.1, and my stack created in Rev 3.5 won't open  
in it.


Thank you, Paul Gabel
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

quicktime player in stackrunner and rev player with macbook air

[Randolph Valentine]

 Hi, I¹ve got a pretty complex stack that has always worked on both macs
(ppc/intel) and windows computers, which utilizes a player to play mp3
snippets‹ I distribute this to students via Stackrunner (or the Rev player
application). With my new Macbook Air, however, I notice that the quicktime
player doesn¹t seem to work, with either Stackrunner or the Rev Player,
though the player _does_ work when I open the stack in Studio 2.9 on my
MacBook Air. In Stackrunner (and the Player), there is no player visible and
no audio. Is there anything I can do to make this work in Stackrunner (which
I love)? Thanks.

rand valentine


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Rev Player

[Jeff Honken]

Does anyone know if the source code for the rev player is available?
I've searched the internet and there seems to be some people that have a
modified version so I'm thinking it's available.  If so can someone show
me where it can be obtained?


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Peter Reid]

On Jul 27, 2004, at 12:18 PM, Dan Shafer wrote:
The HC player was needed because there was no authorized way to 
compile stacks into applications, leaving anyone without the 
HyperCard program itself no way to use stacks. That is not the 
case with Rev.

So what am I not understanding?
Only that it is available to you, but not really meant for you.
OK, but *in general*, who aside from the Dreamcard developer would 
really want to use this approach to delivery? I am sure there must 
be some folks, I just can't figure out who they are!
If you're delivering to some government organisations, there's a big 
hurdle to get over for any program to be accepted from a security 
point of view.  If you want to deliver an initial product and then 
come back with future offerings, it's easier to get a Player cleared 
for use once and for all and then deliver a series of stacks using 
that Player.  I've done this with MetaCard as a Player and several 
training stacks.

Also, such organisations hate having to retrofit programs to 100s or 
even 1000s of existing workstations and they'd never let users 
download and install new applications for themselves.  However, if 
you can get a Player included in the standard build of a workstation, 
they have no problem letting users download and use stacks (with 
certain safeguards of course).

They view an xTalk Player plus stack as simply another example like 
the Flash Player + Flash animation, the QuickTime Player + QuickTime 
movie, etc.  It's an easier sell, especially if you can supply a 
plug-in installer for the Player so new users can simple click on a 
link on an intranet page and the Player can be quickly and easily 
installed!

This issue of what's seen as a browser plug-in vs what's seen as a 
separate application can be a complete enabler/show stopper for large 
organisations - they will happily allow "plug-ins". but little to do 
with "programs"!!  This is why I REALLY hope that RunRev will follow 
up the Player approach with something that makes it easy to provide a 
"plug-in installer".  I assume that the security model that's been 
the subject of much discussion recently, is a tilt in that direction?!

Cheers
Peter
--
Peter Reid
Reid-IT Limited, Loughborough, Leics., UK
Tel: +44 (0)1509 268843 Fax: +44 (0)8700 527576
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
Web: http://www.reidit.co.uk
 http://www.reidit.demon.co.uk
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Scott Rossi]

Recently, Ken Norris wrote:

>> OK, but *in general*, who aside from the Dreamcard developer would
>> really want to use this approach to delivery? I am sure there must be
>> some folks, I just can't figure out who they are!
> 
> I have some friends who just bought a business and need some offline
> archiving software for images, and a few other widgets and gadgets. It would
> be helpful if I could give them some stacks to run and see if they like
> them, if they work out OK. I can build quick & dirty solutions to get them
> by while I work out detaills, get rid of bugs, and dress up the SA apps.
> They use Macs for the workshop production setups and a Sony Vaio for the
> business front end. It'll be a big advantage to not have to build separate
> applications every time.

You don't need to do this with a standalone either if the bulk of your
scripts are stored in a stack that is separate from the standalone engine
stack.

Regards,

Scott Rossi
Creative Director
Tactile Media, Development & Design
-
E: [EMAIL PROTECTED]
W: http://www.tactilemedia.com

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Dan Shafer]

Ah. OK, good point.
Dan
On Jul 27, 2004, at 8:49 PM, Ken Norris (dialup) wrote:

Date: Tue, 27 Jul 2004 09:39:30 -0700
From: Dan Shafer <[EMAIL PROTECTED]>
Subject: Re: Rev player

So what am I not understanding?
Only that it is available to you, but not really meant for you.
OK, but *in general*, who aside from the Dreamcard developer would
really want to use this approach to delivery? I am sure there must be
some folks, I just can't figure out who they are!
Well, I might use it like this:
I have some friends who just bought a business and need some offline
archiving software for images, and a few other widgets and gadgets. It 
would
be helpful if I could give them some stacks to run and see if they like
them, if they work out OK. I can build quick & dirty solutions to get 
them
by while I work out detaills, get rid of bugs, and dress up the SA 
apps.
They use Macs for the workshop production setups and a Sony Vaio for 
the
business front end. It'll be a big advantage to not have to build 
separate
applications every time.

Like that.
Ken N.
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Ken Norris (dialup)]

> Date: Tue, 27 Jul 2004 09:39:30 -0700
> From: Dan Shafer <[EMAIL PROTECTED]>
> Subject: Re: Rev player
 
>>> So what am I not understanding?
>> 
>> Only that it is available to you, but not really meant for you.
>> 
> OK, but *in general*, who aside from the Dreamcard developer would
> really want to use this approach to delivery? I am sure there must be
> some folks, I just can't figure out who they are!

Well, I might use it like this:

I have some friends who just bought a business and need some offline
archiving software for images, and a few other widgets and gadgets. It would
be helpful if I could give them some stacks to run and see if they like
them, if they work out OK. I can build quick & dirty solutions to get them
by while I work out detaills, get rid of bugs, and dress up the SA apps.
They use Macs for the workshop production setups and a Sony Vaio for the
business front end. It'll be a big advantage to not have to build separate
applications every time.

Like that.

Ken N.

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Troy Rollins]

On Jul 27, 2004, at 12:39 PM, Dan Shafer wrote:
So what am I not understanding?
Only that it is available to you, but not really meant for you.
OK, but *in general*, who aside from the Dreamcard developer would 
really want to use this approach to delivery? I am sure there must be 
some folks, I just can't figure out who they are!
Well, I don't have the Hypercard background, but I do have the Director 
background. The closest thing I can relate it to is Shockwave. Many 
Director developers produce shockwave, which has similar advantages and 
limitations to the DreamCard player. It allows them to produce small 
lightweight content which is easily distributed, attatched to emails, 
etc. and their users can be confident that it is "safe."

In my case, I never produced shockwave. It didn't fit my business 
model. I guess it is just a matter of what you are making, and who you 
are making it for.
--
Troy
RPSystems, Ltd.
http://www.rpsystems.net

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

playing the player (was Re: Rev player)

[Wouter]

For those who like to toy.
And want to test the versatility of the player and admire its 
secureMode.
The recipe:

In RR produce a stack with 1 field and 1 button
Set the script of the button to:
on mouseUp
  get fld 1
  if it is not "" then do it
end mouseUp
Set the stack's name  to anything but "test" and save it.
Put the player on its own in a separate folder/directory outside the RR 
folder/directory together with the newly created stack.
Start the stack with the player and enter/paste the following complete 
block of text in the field:

create invisible stack "test"
set the defaultstack to "test"
create button "save"
show stack "test"
put  "on mouseup" & cr & "ask file" && quote& "where" & quote&&  "with" 
&& quote & "test.rev"& quote&cr&"if it is not empty then save this 
stack as it" & cr&  "end mouseup" into tText
set the script of control 1 of cd 1 of stack "test" to tText

Watch the mail text wrap
Push the button and have a look in the directory it saved.
This is only tested on Mac OS X.
And I like it the way it is :-)
Greetings,
WA
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Dan Shafer]

On Jul 27, 2004, at 9:42 AM, Alex Tweedly wrote:
This may count as a specialized situation, but if you are particularly 
concerned about size, then there may be a case for distributing 
stacks. Stacks can be small (5-20K), but standalones are (I think) 
typically upwards of 1.75M   If you have many dial-up (or even GSM 
modem) connected users, that might be a case for distributing stacks.

OK, I could see that, I suppose. Although even 2M isn't an enormous 
download by most of today's standards, I don't think. And the player is 
2.4M (though obviously it only needs to be downloaded once unless there 
are auto updates involved).

So I can see if you had a business where you were creating lots of 
stackware apps for an installed base that could all have the Player 
installed then each download of your stuff would be small and painless. 
I'm not sure what business or business model that would be, but I can 
imagine it is possible.


~~
Dan Shafer, Revolutionary
Author of  "Revolution: Software at the Speed of Thought"
http://www.revolutionpros.com for more info
Available at Runtime Revolution Store (http://www.runrev.com/RevPress)
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Dan Shafer]

On Jul 27, 2004, at 9:28 AM, Troy Rollins wrote:
On Jul 27, 2004, at 12:18 PM, Dan Shafer wrote:
The HC player was needed because there was no authorized way to 
compile stacks into applications, leaving anyone without the 
HyperCard program itself no way to use stacks. That is not the case 
with Rev.

So what am I not understanding?
Only that it is available to you, but not really meant for you.
OK, but *in general*, who aside from the Dreamcard developer would 
really want to use this approach to delivery? I am sure there must be 
some folks, I just can't figure out who they are!


~~
Dan Shafer, Revolutionary
Author of  "Revolution: Software at the Speed of Thought"
http://www.revolutionpros.com for more info
Available at Runtime Revolution Store (http://www.runrev.com/RevPress)
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Alex Tweedly]

At 12:28 27/07/2004 -0400, Marian Petrides wrote:
I guess one other advantage would be if one purchased a single-platform 
license for Rev and wanted to distribute across multiple platforms.
(Doesn't apply to me or probably to you, Dan.)

Otherwise, I can see no advantage.
I thought that, in the new world, it doesn't (won't) apply to anyone.
Dreamcard allows only Player stacks.
Studio runs on one platform but builds for any.
Enterprise runs and builds for any.
-- Alex.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.719 / Virus Database: 475 - Release Date: 12/07/2004
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Alex Tweedly]

At 09:18 27/07/2004 -0700, Dan Shafer wrote:
Robert Brenstein said:
it will surely be the runtime environment for stacks produced in 
DreamCard, but I suspect that a number of people using Rev will also opt 
to distribute their products as stacks, like it used to be with HyperCard 
player.
I may be missing something here, but I can't imagine any situation in 
which I would choose to prefer to distribute a product I create as a stack 
to be run in the Player rather than as a compiled standalone application. 
I suppose in some specialized situations or closed environments like 
classrooms one might for some reason prefer this approach. But I see the 
Player as a natural companion to Dreamcard, a way for a Dreamcard 
developer to distribute stacks to others who don't own Dreamcard or Revolution.
This may count as a specialized situation, but if you are particularly 
concerned about size, then there may be a case for distributing stacks. 
Stacks can be small (5-20K), but standalones are (I think) typically 
upwards of 1.75M   If you have many dial-up (or even GSM modem) connected 
users, that might be a case for distributing stacks.

-- Alex.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.719 / Virus Database: 475 - Release Date: 12/07/2004
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Marian Petrides]

I guess one other advantage would be if one purchased a single-platform 
license for Rev and wanted to distribute across multiple platforms.  
(Doesn't apply to me or probably to you, Dan.)

Otherwise, I can see no advantage.
M
On Jul 27, 2004, at 12:18 PM, Dan Shafer wrote:
Robert Brenstein said:
it will surely be the runtime environment for stacks produced in 
DreamCard, but I suspect that a number of people using Rev will also 
opt to distribute their products as stacks, like it used to be with 
HyperCard player.
I may be missing something here, but I can't imagine any situation in 
which I would choose to prefer to distribute a product I create as a 
stack to be run in the Player rather than as a compiled standalone 
application. I suppose in some specialized situations or closed 
environments like classrooms one might for some reason prefer this 
approach. But I see the Player as a natural companion to Dreamcard, a 
way for a Dreamcard developer to distribute stacks to others who don't 
own Dreamcard or Revolution.

The HC player was needed because there was no authorized way to 
compile stacks into applications, leaving anyone without the HyperCard 
program itself no way to use stacks. That is not the case with Rev.

So what am I not understanding?
~~
Dan Shafer, Revolutionary
Author of  "Revolution: Software at the Speed of Thought"
http://www.revolutionpros.com for more info
Available at Runtime Revolution Store (http://www.runrev.com/RevPress)
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Troy Rollins]

On Jul 27, 2004, at 12:18 PM, Dan Shafer wrote:
The HC player was needed because there was no authorized way to 
compile stacks into applications, leaving anyone without the HyperCard 
program itself no way to use stacks. That is not the case with Rev.

So what am I not understanding?
Only that it is available to you, but not really meant for you.
--
Troy
RPSystems, Ltd.
http://www.rpsystems.net
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Dan Shafer]

Robert Brenstein said:
it will surely be the runtime environment for stacks produced in 
DreamCard, but I suspect that a number of people using Rev will also 
opt to distribute their products as stacks, like it used to be with 
HyperCard player.
I may be missing something here, but I can't imagine any situation in 
which I would choose to prefer to distribute a product I create as a 
stack to be run in the Player rather than as a compiled standalone 
application. I suppose in some specialized situations or closed 
environments like classrooms one might for some reason prefer this 
approach. But I see the Player as a natural companion to Dreamcard, a 
way for a Dreamcard developer to distribute stacks to others who don't 
own Dreamcard or Revolution.

The HC player was needed because there was no authorized way to compile 
stacks into applications, leaving anyone without the HyperCard program 
itself no way to use stacks. That is not the case with Rev.

So what am I not understanding?
~~
Dan Shafer, Revolutionary
Author of  "Revolution: Software at the Speed of Thought"
http://www.revolutionpros.com for more info
Available at Runtime Revolution Store (http://www.runrev.com/RevPress)
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Wouter]

•From: Kevin Miller
• Subject: Re: Rev player
• Date: Mon, 26 Jul 2004 09:26:54 -0700
On 25/7/04 10:16 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> So if we want to distribute a stack such as a simple address stack 
where cards
> will be added and data will need to be saved by the enduser. We will 
have to
> create a standalone to run the stack. Therefore dreamcard will not 
do the job.
> Correct?

The Player application is by default configured to have secureMode 
turned
on.  This makes it "secure" preventing a stack from destroying a users 
hard
drive.  However, the end user does have the option to turn of 
secureMode as
a preference included with the Player, so if you have a stack you want 
to
distribute you need to tell the end user to turn this option off if 
they
want to be able to save data.  In a future version we may look more 
closely
at an intermediate "level" of security, right now the user must be 
asked to
turn this off.
Not completely true.
If the player is distributed *on it's own* (in this version) any other 
stack who needs full access to the disk can do so *without* needing to 
turning off secureMode.

Kind regards,
Kevin
Kevin Miller ~ [EMAIL PROTECTED] ~ http://www.runrev.com/
Runtime Revolution - User-Centric Development Tools

Greetings,
WA
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Robert Brenstein]

Robert Brenstein wrote:
But as Kevin said, adding limited file I/O to secure modes it 
being worked on, so any inconvenience should be short-lived.
I read that but it sounded that this will happen some time in the 
future, well after player's introduction. As someone interested in 
its success, I am just concerned that this may come a tad late, as 
in spoiling the impression made by the player and thus its broad 
acceptance. I'd love to be wrong, though.

PS A malicious person can include an external which I don't think 
can be prevented from accessing disks and system.

SecureMode shuts down not just file I/O, but also shell, 
AppleScript, and registry access.  I agree that if it doesn't 
currently shut down the externals API it should.  Is that the case?
If it shuts down externals, then, for example, it would not be 
possible to access databases.
I'm not clear on what you're after, as your post raises good 
arguments in both directions.  Are you advocating more security, 
less, or something altogether different?

--
 Richard Gaskin
 Fourth World Media Corporation
Exactly that, I am raising issues. I don't have a clear enough 
picture of what RunRev envisions for the player in their product 
strategy; it will surely be the runtime environment for stacks 
produced in DreamCard, but I suspect that a number of people using 
Rev will also opt to distribute their products as stacks, like it 
used to be with HyperCard player. As we know from past, players are 
funky beasts, solving many problems but creating a number of new ones.

In terms of saving, the issue is whether implementing it can be 
really postponed. In terms of externals, RR must decide between full 
security and functionality. I'd like just to know what the sandbox 
is. I gather we will be able to distinguish at runtime whether we are 
in the player or in a standalone, and in the former case, whether 
secureMode is on.

Robert
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Richard Gaskin]

Robert Brenstein wrote:
But as Kevin said, adding limited file I/O to secure modes it being 
worked on, so any inconvenience should be short-lived.
I read that but it sounded that this will happen some time in the 
future, well after player's introduction. As someone interested in its 
success, I am just concerned that this may come a tad late, as in 
spoiling the impression made by the player and thus its broad 
acceptance. I'd love to be wrong, though.

PS A malicious person can include an external which I don't think can 
be prevented from accessing disks and system.

SecureMode shuts down not just file I/O, but also shell, AppleScript, 
and registry access.  I agree that if it doesn't currently shut down 
the externals API it should.  Is that the case?
If it shuts down externals, then, for example, it would not be possible 
to access databases.
I'm not clear on what you're after, as your post raises good arguments 
in both directions.  Are you advocating more security, less, or 
something altogether different?

--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Robert Brenstein]

Robert Brenstein wrote:
Any changes to the behavior of secureMode must be done in the 
engine. If they are handled in script then a script can change the 
behavior, leaving the door open to hackers.

An engine-level solution has been bandied about in Bugzilla:

Until such a change is made at the engine level, I agree with 
Kevin's position of erring on the side of safety.
While I agree with Richard, I am also somewhat concerned that this 
omission may become sour grapes for the player. Capability to save 
is so fundamental to operation of most programs that it is very 
likely the first thing any player user will do (will have to do) is 
to disable secure mode. That may thus become a support issue (why 
my data is not saved?) aside from making the secureMode sort of 
useless.
But at that point it's the user's decision.  You can decide to turn 
off your Windows firewall too, if you want your machine hijacked for 
spamming in under 15 minutes. ;)
What I was meant is that user will likely be forced to do so because 
using many stacks will be pointless without capability to save. And 
we can't expect out users to be savvy and persistent in toggling that 
setting depending on which stack they want to use. The nature of 
player should be that it works quietly in the background.

When the user decides to turn off secureMode, they are assuming the 
same level of risk that they would downloading any executable from 
Download.com, VersionTracker, etc. (and arguably less risk than 
normal usage of any Microsoft operating system).
Well, these are wrong comparisons IMO. Firewall is a different 
category and downloading stacks is parallel to downloading other 
software. I don't see Metrowerks trying to impose i/o protection in 
CodeWarrior, although I gather the inspiration for player's security 
comes from Java Runtimes.

But as Kevin said, adding limited file I/O to secure modes it being 
worked on, so any inconvenience should be short-lived.
I read that but it sounded that this will happen some time in the 
future, well after player's introduction. As someone interested in 
its success, I am just concerned that this may come a tad late, as in 
spoiling the impression made by the player and thus its broad 
acceptance. I'd love to be wrong, though.

PS A malicious person can include an external which I don't think 
can be prevented from accessing disks and system.
SecureMode shuts down not just file I/O, but also shell, 
AppleScript, and registry access.  I agree that if it doesn't 
currently shut down the externals API it should.  Is that the case?
If it shuts down externals, then, for example, it would not be 
possible to access databases.

Robert Brenstein
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Richard Gaskin]

Robert Brenstein wrote:
Any changes to the behavior of secureMode must be done in the engine. 
If they are handled in script then a script can change the behavior, 
leaving the door open to hackers.

An engine-level solution has been bandied about in Bugzilla:
 

Until such a change is made at the engine level, I agree with Kevin's 
position of erring on the side of safety.
While I agree with Richard, I am also somewhat concerned that this 
omission may become sour grapes for the player. Capability to save is so 
fundamental to operation of most programs that it is very likely the 
first thing any player user will do (will have to do) is to disable 
secure mode. That may thus become a support issue (why my data is not 
saved?) aside from making the secureMode sort of useless.
But at that point it's the user's decision.  You can decide to turn off 
your Windows firewall too, if you want your machine hijacked for 
spamming in under 15 minutes. ;)

When the user decides to turn off secureMode, they are assuming the same 
level of risk that they would downloading any executable from 
Download.com, VersionTracker, etc. (and arguably less risk than normal 
usage of any Microsoft operating system).

But as Kevin said, adding limited file I/O to secure modes it being 
worked on, so any inconvenience should be short-lived.

PS A malicious person can include an external which I don't think can be 
prevented from accessing disks and system.
SecureMode shuts down not just file I/O, but also shell, AppleScript, 
and registry access.  I agree that if it doesn't currently shut down the 
externals API it should.  Is that the case?

--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Robert Brenstein]

what about a sandboxed enviroment, like a function to save a stack 
and another to load. You cannot specify where to save for the 
Dreamcard app will save it to it's own folder. This way we can save 
stuff and load stuff, and there will be no harm in it. Also we 
could only save and load stacks. maybe this handler could be 
something like secureSave and secureLoad. The user could be 
prompted and asked if he would allow to save or load from this app, 
much like the Apple Keychain does.

What about this approach, it can be easily implemented without 
altering Dreamcard code, this could be done in transcript level, no 
need to put that on the engine itself it could be done in 
couple hours and would make big time for us...
Any changes to the behavior of secureMode must be done in the 
engine. If they are handled in script then a script can change the 
behavior, leaving the door open to hackers.

An engine-level solution has been bandied about in Bugzilla:

Until such a change is made at the engine level, I agree with 
Kevin's position of erring on the side of safety.

--
 Richard Gaskin
 Fourth World Media Corporation
While I agree with Richard, I am also somewhat concerned that this 
omission may become sour grapes for the player. Capability to save is 
so fundamental to operation of most programs that it is very likely 
the first thing any player user will do (will have to do) is to 
disable secure mode. That may thus become a support issue (why my 
data is not saved?) aside from making the secureMode sort of useless.

Robert Brenstein
PS A malicious person can include an external which I don't think can 
be prevented from accessing disks and system.
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Kevin Miller]

On 26/7/04 7:39 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> Glad to hear we can select preferences in the rev player. Where are
> preferences  choices located as I can't find them on my rev player?

They are located in the icon to the right of the navigation bar.  We're
aware of an issue with them coming up behind the Player on some platforms,
and an issue with the secure mode preference not reliably saving values,
both of these will be fixed in beta 2.

Kind regards,

Kevin

Kevin Miller ~ [EMAIL PROTECTED] ~ http://www.runrev.com/
Runtime Revolution - User-Centric Development Tools

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Revinfo1155]

Glad to hear we can select preferences in the rev player. Where are preferences  
choices located as I can't find them on my rev player?

jack
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Richard Gaskin]

Andre Garzia wrote:
On Jul 26, 2004, at 1:18 PM, Kevin Miller wrote:
The Player application is by default configured to have secureMode turned
on.  This makes it "secure" preventing a stack from destroying a users 
hard
drive.  However, the end user does have the option to turn of 
secureMode as
a preference included with the Player, so if you have a stack you want to
distribute you need to tell the end user to turn this option off if they
want to be able to save data.  In a future version we may look more 
closely
at an intermediate "level" of security, right now the user must be 
asked to
turn this off.

what about a sandboxed enviroment, like a function to save a stack and 
another to load. You cannot specify where to save for the Dreamcard app 
will save it to it's own folder. This way we can save stuff and load 
stuff, and there will be no harm in it. Also we could only save and load 
stacks. maybe this handler could be something like secureSave and 
secureLoad. The user could be prompted and asked if he would allow to 
save or load from this app, much like the Apple Keychain does.

What about this approach, it can be easily implemented without altering 
Dreamcard code, this could be done in transcript level, no need to put 
that on the engine itself it could be done in couple hours and would 
make big time for us...
Any changes to the behavior of secureMode must be done in the engine. 
If they are handled in script then a script can change the behavior, 
leaving the door open to hackers.

An engine-level solution has been bandied about in Bugzilla:

Until such a change is made at the engine level, I agree with Kevin's 
position of erring on the side of safety.

--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Andre Garzia]

On Jul 26, 2004, at 1:18 PM, Kevin Miller wrote:
The Player application is by default configured to have secureMode 
turned
on.  This makes it "secure" preventing a stack from destroying a users 
hard
drive.  However, the end user does have the option to turn of 
secureMode as
a preference included with the Player, so if you have a stack you want 
to
distribute you need to tell the end user to turn this option off if 
they
want to be able to save data.  In a future version we may look more 
closely
at an intermediate "level" of security, right now the user must be 
asked to
turn this off.

Kind regards,
Kevin,
what about a sandboxed enviroment, like a function to save a stack and 
another to load. You cannot specify where to save for the Dreamcard app 
will save it to it's own folder. This way we can save stuff and load 
stuff, and there will be no harm in it. Also we could only save and 
load stacks. maybe this handler could be something like secureSave and 
secureLoad. The user could be prompted and asked if he would allow to 
save or load from this app, much like the Apple Keychain does.

What about this approach, it can be easily implemented without altering 
Dreamcard code, this could be done in transcript level, no need to put 
that on the engine itself it could be done in couple hours and 
would make big time for us...

cheers
andre
--
Andre Alves Garzia  2004  BRAZIL
http://studio.soapdog.org
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Kevin Miller]

On 25/7/04 10:16 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> So if we want to distribute a stack such as a simple address stack where cards
> will be added and data will need to be saved by the enduser. We will have to
> create a standalone to run the stack. Therefore dreamcard will not do the job.
> Correct?

The Player application is by default configured to have secureMode turned
on.  This makes it "secure" preventing a stack from destroying a users hard
drive.  However, the end user does have the option to turn of secureMode as
a preference included with the Player, so if you have a stack you want to
distribute you need to tell the end user to turn this option off if they
want to be able to save data.  In a future version we may look more closely
at an intermediate "level" of security, right now the user must be asked to
turn this off.

Kind regards,

Kevin

Kevin Miller ~ [EMAIL PROTECTED] ~ http://www.runrev.com/
Runtime Revolution - User-Centric Development Tools

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev Player - part of distribution of download?

[Kevin Miller]

On 25/7/04 9:47 pm, "Troy Rollins" <[EMAIL PROTECTED]> wrote:

>> Standalones can still be built and distributed just as they always
>> were. The Player just adds an additional delivery option.
> 
> I thought it was to be the only real delivery option with the new
> "DreamCard" though...

It is the only option with Dreamcard.  You cannot build standalones with
that version.

Kevin

Kevin Miller ~ [EMAIL PROTECTED] ~ http://www.runrev.com/
Runtime Revolution - User-Centric Development Tools

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Richard Gaskin]

Wouter wrote:
Some other annoyances of the player (and why better not use it in this 
version):
It  hogs the cpu-time enormously on its own. Waving between 32 - 50 
percent.
And is slowing down the execution of other handlers containing "wait  with messages" or something alike.
Sounds like a bug.  Have you reported it?
I wonder what it thinks it needs to be doing.
When closing the revonline window it shuts down the player, even if 
there is still another window open.
Should definitely be a bug.  How else could the player be used to 
distribute stacks gracefully?

Please do report those...
--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Wouter]

•From: Richard Gaskin
• Subject: Re: Rev player
• Date: Sun, 25 Jul 2004 16:11:16 -0700
Wilhelm Sanke wrote:
On Sun, 25 Jul 2004 [EMAIL PROTECTED] wrote:
Did as you suggested and the player would not save the changes. How 
come?

 jack
and Troy Rollins <[EMAIL PROTECTED]> wrote:
 It could be the player is configured for maximum security (whatever
 that is called in Rev.) It is supposed to act something akin to the
 shockwave player, which prevents "harmful" activities (saving files,
 deleting files, etc.) on the end-user's computer.
 --
 Troy
 It is no big deal to produce your own player that saves modified 
stacks.

 While that would be a necessity if indeed a RunRev-supplied player 
didn't allow changes, it might be in everyone's best interest to see 
the player made more useful by allowing saves.

If security is the concern it would not be difficult to have an 
opening dialog that asks if the user wants to run with secureMode on 
or off (with a more end-user-oriented description, of course).

--
 Richard Gaskin
 Fourth World Media Corporation

Hi,
Some other annoyances of the player (and why better not use it in this 
version):
It  hogs the cpu-time enormously on its own. Waving between 32 - 50 
percent.
And is slowing down the execution of other handlers containing "wait  with messages" or something alike.
When closing the revonline window it shuts down the player, even if 
there is still another window open.

Greetings,
WA
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Richard Gaskin]

Wilhelm Sanke wrote:
On Sun, 25 Jul 2004 [EMAIL PROTECTED] wrote:
Did as you suggested and the player would not save the changes. How come?
jack
and Troy Rollins <[EMAIL PROTECTED]> wrote:
It could be the player is configured for maximum security (whatever
that is called in Rev.) It is supposed to act something akin to the
shockwave player, which prevents "harmful" activities (saving files,
deleting files, etc.) on the end-user's computer.
--
Troy 
It is no big deal to produce your own player that saves modified stacks.
While that would be a necessity if indeed a RunRev-supplied player 
didn't allow changes, it might be in everyone's best interest to see the 
player made more useful by allowing saves.

If security is the concern it would not be difficult to have an opening 
dialog that asks if the user wants to run with secureMode on or off 
(with a more end-user-oriented description, of course).

--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Wilhelm Sanke]

On Sun, 25 Jul 2004 [EMAIL PROTECTED] wrote:
Did as you suggested and the player would not save the changes. How come?
jack

and Troy Rollins <[EMAIL PROTECTED]> wrote:
It could be the player is configured for maximum security (whatever
that is called in Rev.) It is supposed to act something akin to the
shockwave player, which prevents "harmful" activities (saving files,
deleting files, etc.) on the end-user's computer.
--
Troy

It is no big deal to produce your own player that saves modified stacks.
What you need:
- create a new stack
- create a button "open" with the script
"answer file "Plase select a stack" with filter "*.mc;*.rev"
  go to it"
- create a button "save" with a script
"put the short name of the topstack into Oldname
ask file "Please choose a new name for the stack! (extension mc will b 
added" with Oldname
put it into NewName
put Newname&".mc" into Newname
save stack Oldname as Newname"

- important: set the style of your player to "modeless"
"on preOpenStack
  if the short name of this stack is "my-player" then
set the style of this stack to modeless
set the loc of this stack to 200,170
  end if
end preopenstack"
Change the scripts accordingly if you prefer rev-stacks.
- And finally: produce a standalone.
That's all.-
You can find and download such an example of an elementary player for 
Metacard and Revolution stacks on my website:


English version,
page "Sample stacks"
stack "MC-Player" (for Windows)
Regards,
Wilhelm Sanke

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Revinfo1155]

Ken,
 I hope your right but I built a test stack with a button scripted to save on 
mouseUp and it didn't work. I agree with you-A rev player that won't allow updating 
and saving of data won't help me much. Can someone else run some tests. Maybe I'm 
overlooking something.

jack
In a message dated 7/25/2004 5:53:21 PM Eastern Daylight Time, "Ken Norris (dialup)" 
<[EMAIL PROTECTED]> writes:

>Hi Troy, Stephen, Klaus, et al,
>
>> Date: Sun, 25 Jul 2004 15:32:18 -0400
>> From: Troy Rollins <[EMAIL PROTECTED]>
>> Subject: Re: Rev player
>> 
>> 
>> On Jul 25, 2004, at 3:19 PM, [EMAIL PROTECTED] wrote:
>> 
>>> Did as you suggested and the player would not save the changes. How
>>> come?
>> 
>> It could be the player is configured for maximum security (whatever
>> that is called in Rev.) It is supposed to act something akin to the
>> shockwave player, which prevents "harmful" activities (saving files,
>> deleting files, etc.) on the end-user's computer.
>
>I don't think so. I haven't tried it yet, but I bet if you incorporate
>normal "Save" or "Save as" scripted menu items in your stacks, then they
>should save according to the scripts, otherwise what good would the player
>be? I mean, it should disallow access to code, but not to updating files
>which are specifically interacted with, and handled by, the code in your UI.
>
>All the best,
>Ken N.
>
>
>
>___
>use-revolution mailing list
>[EMAIL PROTECTED]
>http://lists.runrev.com/mailman/listinfo/use-revolution
>
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Ken Norris (dialup)]

Hi Troy, Stephen, Klaus, et al,

> Date: Sun, 25 Jul 2004 15:32:18 -0400
> From: Troy Rollins <[EMAIL PROTECTED]>
> Subject: Re: Rev player
> 
> 
> On Jul 25, 2004, at 3:19 PM, [EMAIL PROTECTED] wrote:
> 
>> Did as you suggested and the player would not save the changes. How
>> come?
> 
> It could be the player is configured for maximum security (whatever
> that is called in Rev.) It is supposed to act something akin to the
> shockwave player, which prevents "harmful" activities (saving files,
> deleting files, etc.) on the end-user's computer.

I don't think so. I haven't tried it yet, but I bet if you incorporate
normal "Save" or "Save as" scripted menu items in your stacks, then they
should save according to the scripts, otherwise what good would the player
be? I mean, it should disallow access to code, but not to updating files
which are specifically interacted with, and handled by, the code in your UI.

All the best,
Ken N.



___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev Player - part of distribution of download?

[J. Landman Gay]

On 7/25/04 5:54 AM, Stephen King wrote:
Hi All,
Sorry if this is a question answered by the latest Rev Beta, but my
subscriptioon has currently expired, so I probably can't evaluate the
2.5Beta.
I understand that there are no standalones as such, but stacks play in the
Rev player (presumably a different one per platform?). Is this player part
of the built distributable (ie like the old standalone) or does the und user
of the application have to download and install the appropriate player
before the stack can be used?
There's a misunderstanding here. Rev still builds standalones exactly as 
it used to. The Player is an addition to the existing feature set, and 
separate from any standalones. There may be cases where you would rather 
distribute stacks; for example, if you plan to send someone lots of 
different stacks but you don't want to build standalones for each one. 
In that case, you would just send them the Player along with all your 
stacks. This saves a lot of disk space and the user can play all your 
stacks with a single application.

Standalones can still be built and distributed just as they always were. 
The Player just adds an additional delivery option.

--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Troy Rollins]

On Jul 25, 2004, at 3:19 PM, [EMAIL PROTECTED] wrote:
Did as you suggested and the player would not save the changes. How 
come?
It could be the player is configured for maximum security (whatever 
that is called in Rev.) It is supposed to act something akin to the 
shockwave player, which prevents "harmful" activities (saving files, 
deleting files, etc.) on the end-user's computer.
--
Troy
RPSystems, Ltd.
http://www.rpsystems.net

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Klaus Major]

Hi Jack,
Did as you suggested and the player would not save the changes. How 
come?
AH, thanks for the info :-)
That means that the player will start in "secureMode", as Kevin Miller 
wrote...

See the docs for "secureMode", this prohibits ANY write action on the 
users hd!

And it looks like it works ;-)
jack
Regards
Klaus Major
[EMAIL PROTECTED]
http://www.major-k.de
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Revinfo1155]

Did as you suggested and the player would not save the changes. How come?

jack
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Rev Player - part of distribution of download?

[Stephen King]

Hi All,

Sorry if this is a question answered by the latest Rev Beta, but my
subscriptioon has currently expired, so I probably can't evaluate the
2.5Beta.

I understand that there are no standalones as such, but stacks play in the
Rev player (presumably a different one per platform?). Is this player part
of the built distributable (ie like the old standalone) or does the und user
of the application have to download and install the appropriate player
before the stack can be used?

Cheers
Steve

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev player

[Klaus Major]

Hi Jack,
Is it possible to open a stack with the new rev player2.5 and make 
changes to a field like add data etc. and save the changes?
Why not check it by yourself? ;-)
Create a stack with one editable field and a button with this script:
on mouseup
  save this stack
end mouseup
Save it, drop it onto the player, type something into that field, click 
that button and
close that stack...

Then open it again and tell us what you experienced...
Thanks ;-)
jack
Regards
Klaus Major
[EMAIL PROTECTED]
http://www.major-k.de
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Rev player

[Revinfo1155]

Is it possible to open a stack with the new rev player2.5 and make changes to a field 
like add data etc. and save the changes? 

jack
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev Player

[Hershel Fisch]

On Thursday, July 22, 2004, at 11:32 AM, Klaus Major wrote:
Hi all,
after i once started the Rev player i find a 2.2 MB "executable unix 
file"
called "Revolution Launcher" in my REV folder...
I Had the same thing, I didn't know what that was, I thought that 
didn't realize that there was another file on till Klaus brought this 
up.
Hershel
Any hints?
Regards
Klaus Major
[EMAIL PROTECTED]
http://www.major-k.de
P.S.
Looks like the REV player will load "Rev online" when doubleclicked,
but only as long it is in the same folder as REV...
Put it somewhere else and nothing will happen on doubleclick...
OK, i might have exspected something like the SuperCard player where 
an open dialog
would pop uzp to let the user select a SuperCard stack...

But when dropping a stack on that icon, it work as exspected :-)
And i am sure, if REV is NOT on our HD, the player will start when we 
doubleclick a
rev stack in the finder... Not tested on windows yet...

This is COOOL, so we don't have to create something like that on our 
own ;-)
But there might be an issue with (not present) externals...

But is it just the first beta ;-)
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Rev Player

[Klaus Major]

Hi all,
after i once started the Rev player i find a 2.2 MB "executable unix 
file"
called "Revolution Launcher" in my REV folder...

Any hints?
Regards
Klaus Major
[EMAIL PROTECTED]
http://www.major-k.de
P.S.
Looks like the REV player will load "Rev online" when doubleclicked,
but only as long it is in the same folder as REV...
Put it somewhere else and nothing will happen on doubleclick...
OK, i might have exspected something like the SuperCard player where an 
open dialog
would pop uzp to let the user select a SuperCard stack...

But when dropping a stack on that icon, it work as exspected :-)
And i am sure, if REV is NOT on our HD, the player will start when we 
doubleclick a
rev stack in the finder... Not tested on windows yet...

This is COOOL, so we don't have to create something like that on our 
own ;-)
But there might be an issue with (not present) externals...

But is it just the first beta ;-)
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev Player

[Revinfo1155]

In a message dated 9/23/03 4:58:05 PM, [EMAIL PROTECTED] writes:


>I have one for my own needs, but I think a player for general use should
>come from the mother ship to maximize standardization and distribution.
>
>Just curious:  What would you like to do with a player than couldn't be done
>as a standalone?
>
>Richard Gaskin

I have produced a small number of CBTs for a UK government
organisation who need to validate all executables for security
reasons.  Supplying a single player with add-on stacks makes life
easier in this respect. It is easier to persuade public sector
customers that they are only running a single program with
downloadable modules than it is to say they need to allow an
increasing number of new executables.  They get twitchy about the
security implications of new EXE files!

Also, it minimises network traffic if each client workstation has a
single player installed which is set up as the helper-app within the
browser so the user can download any of a number of CBT stacks
without having to download the player engine each time or have to
decide what to do with an executable (with attendant "security
warnings" from their browser!).

Cheers

Peter


Peter-have you got a sample player we could look at?

Jack

Rev Player

[Revinfo1155]

Has anyone designed a rev player along the lines of the Hypercard player?

Jack

Re: Rev Player engine

[Kevin Miller]

On 18/1/02 1:32 pm, Sivakatirswami <[EMAIL PROTECTED]> wrote:

> Is there a "player" engine of rev that we can distribute like the mc engine
> without the home stack so that users can boot a rev stack without access to
> the development environment and without need to have that in use being a
> stand alone... 

The revolution or revolution.exe file will do this.  Or you can build
yourself a simple standalone that loads stacks - with your own icons and
creator if you prefer.

Kevin

Kevin Miller <[EMAIL PROTECTED]> 
Runtime Revolution Limited - Power to the Developer!
Tel: +44 (0) 870 747 1165.  Fax: +44 (0)1639 830 707.

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Rev Player engine

[Sivakatirswami]

Is there a "player" engine of rev that we can distribute like the mc engine
without the home stack so that users can boot a rev stack without access to
the development environment and without need to have that in use being a
stand alone... 

thanks
Hinduism Today

Sivakatirswami
Editor's Assistant/Production Manager
[EMAIL PROTECTED] 
www.HinduismToday.com, www.HimalayanAcademy.com,
www.Gurudeva.org, www.hindu.org

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution