Where Rev could be going...

Alex Shaw alex at harryscollar.com
Mon Nov 20 10:24:34 EST 2006


Hi

I wrote recently on the improve list that it was good news about 
altBrowser becoming an official cog in the rev engine.

I've only just started using altBrowser more seriously to embed legacy 
web-apps into a more user-friendly and controlled rev based environment. 
The ability to create multiple browser instances (since version 2) has 
made this project a reality..

but I think it just needs the following enhancements to be perfect..

- ability to trigger webpage javascript functions from rev (a very 
powerful & useful interface between rev & html)

- it would obviously be nice if it where a 'native' control that can be 
dragged & dropped like others from the ide into a stack etc

At the moment Javascript is the 'defacto' web language. It comes with 
any proper web browser. It works.

But the fact remains that browsers (html) where never designed to be 
great at layout. CSS has improved things but to be honest complex 
consistent dhtml is still hard to achieve across browsers. Remember the 
days before Dreamweaver or GoLive? Even proper design layout tools like 
Quark and Indesign can't give perfect web results.

It seems nothing does html better than using proper html tools eg. I 
recently had to find a solution to a rev-based cms I had developed. The 
program allowed simple html editing but could not easilly do dot points 
(ie <ul> tags). Live editing and previewing WYSIWYG-style proved to hard 
a task so I decided to use a javascript editor (http://rtef.info) 
embedded within altBrowser embedded within rev :)

I choose rtef because it did dot points and seemed to work best on both 
ie and safari. I looked at a number of options and am still finalising 
things but gee it would be nice to have rev buttons controlling the 
styling and editing of proper browser rendered html via the pages 
javascript functions.

Anyway, my point is.. Editing html with rev is like editing an image 
with rev's built-in tools. You just don't do it. Most use photoshop or a 
similar tool for images. Images are quite a simple data construct to 
display consistently but html isn't. The compromise that altBrowser 
makes is to use the "default" web browser for your operating system. 
Fine, it's like displaying a jpeg with your default system image viewer. 
It does the job.

What rev does well is it allows us to precisely layout a bunch of these 
media elements (whether jpeg , html or quicktime) and manipulate them 
rev style.

Html, like any other file format will stay around as long as it serves a 
purpose. Anyone remember .pcx files? (http://en.wikipedia.org/wiki/PCX)

Html does a lot, it is important today and rev does need to support it 
better.

As I believe a photoshop level tool for editing images withing rev is a 
waste of time for the rev development team so would a maze of rev<->html 
functions and commands. Javascript already does a good job of 
controlling the Document Object Model (DOM). If rev could call 
javascript functions then a whole universe of great pre-made commercial 
and open-source solutions opens up to be accessed and utilized from rev. 
All that AJAX stuff, and plugins for media types not supported natively 
by rev.

I have been curiously looking into some of these web-based operating 
systems eg youos.com & eyeos.org and still don't believe browsers will 
take over our desktops (but that is probably better discussed as a 
separate thread). I've noticed a greater diversity of systems in today's 
workplace than say 10 years ago. MacOS along side Windows and now 
Windows within MacOSX and vise-versa. And sometimes I spy a linux box in 
the corner. Revolution is an extremely flexible tool for making software 
across the main platforms.

A web rev plugin would be nice but that doesn't mean I'd be able to view 
rev content in IE on my PocketPC unless the rev team develop one. Html 
is cross-platform but plugins aren't.

Revolution is better suited to embrace html as a media container which 
has it own internal control mechanisms (via javascript). We just need to 
easilly be able to tap into those mechanisms and let the browser 
machinery do the rest.

regards
alex








Bernard Devlin wrote:
> 
> It would be good if we could have more discussion of what the 
> possibilitiies might be.
> 
> Bernard



More information about the use-livecode mailing list