Re: Rev Player?
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 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: http://sonsothunder.com/devres/revolution/tips/file010.htm 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 http://www.revjournal.com/features/reactorlab.html Dynamic Digital Maps http://ddm.geo.umass.edu/ 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?
Message: 3 Date: Sat, 11 Jul 2009 11:00:30 -0700 From: Richard Gaskin ambassa...@fourthworld.com Subject: Re: Rev Player? To: How to use Revolution use-revolution@lists.runrev.com 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
Rev Player?
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
Re: Rev Player?
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
Re: Rev Player?
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 paulga...@comcast.net 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
quicktime player in stackrunner and rev player with macbook air
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
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
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: http://www.runrev.com/revolution/developers/bugdatabase/show_bug.cgi?id=867 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
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: http://www.runrev.com/revolution/developers/bugdatabase/show_bug.cgi?id=867 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 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: http://www.runrev.com/revolution/developers/bugdatabase/show_bug.cgi?id=867 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
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 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
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 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
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
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
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
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
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
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
playing the player (was Re: Rev player)
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 quotecrif 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
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
Re: Rev player
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
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
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
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
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
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: http://www.runrev.com/revolution/developers/bugdatabase/show_bug.cgi?id=867 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
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
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
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 - part of distribution of download?
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
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
Re: Rev player
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
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 - part of distribution of download?
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
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
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
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: http://www.sanke.org 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
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
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 x millisecs 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
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 x millisecs 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
Rev player
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
Rev Player
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
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
Re: Rev Player
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
Re: Rev Player engine
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] http://www.runrev.com/ 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
