How revolution can be used to make pretty widgets (was Why is Konfabulator "Pretty?")

Marielle Lange mlange at
Fri Dec 9 06:58:11 CST 2005

Hi Tom,

Tom wrote:

> Bill spurred me on with his wish that REV had a more hip UI. I  
> thought that a template with some buttonGadget style simplicity and  
> some guidelines for coding in Rev would pave the way for a series  
> of simple apps (widgets, dashboards, etc.) I have two projects in  
> the works right now but have not spec'd them out fully yet. They  
> would however fit into a scheme like this.

I would be very much interested to hear about this, privately  
eventually. But I have read the mention that you are not authorized  
to disclose some aspects because they have been developed under  
contract. So I won't encourage you to tell me more than you should.

Your design process sounds familiar :-)

> I would envision a Kit that was the Playground or Sandbox to start  
> with and there would be templates and such and then as you play  
> around you might just spark that idea.

That's *very* much needed. You may be interested to read, or even  
better contribute, to a discussion we had on this on the educators  
list, a few months ago. This discussion is archived at: <http:// 
page=EducationWhatIsNeeded>. After that discussion, I created a space  
to receive explained examples for some widgets: <http://> .  
The history of the page indicates we had this discussion in april-may  

Somehow, this never gained enough momemtum. On the one hand, most of  
us are too busy to contribute regularly to this effort. On the other  
hand, we somehow have the feeling that this is something revolution  
should be doing. I have been in contact with them. I have  
specifically asked them whether there was any material we could reuse  
(exercises, tutorials, texts they acquired when they bought out  
metacard). Got no reply. Private discussions revealed that other  
users had had a similar experience.

I have designed a few toolbars and prewritten widgets... but I am  
always warry to put too much efforts into that as after months of  
hard work I could see revolution come up with a similar product.   
Indeed, if I were revolution, I would have opened a new position to  
have a creative person write such a set of exercises months ago.  
There is no way to know whether they have or whether they haven't. In  
the unknown many of us are careful about not spending too much energy  
on a task that revolution is probably working on presently.

So my approach is to take that approach but in a way that is not too  
much engine dependent.

Richard Gawskin wrote
> Okay, I'll bite: what exactly is an "open source strategy" for an   
> engine which is, and will likely remain, closed-source?

Open Source <> Engine. The fact that the engine is closed source  
doesn't mean that all the code written with that engine must remain  
closed source. The many stacks plugins made freely available by  
members of this list are an example of this.

But yes, it remains that "freely" available doesn't mean available to  
anybody. It's only available to the ones who bought a dreamcard license.

The open source strategy is therefore as follows. Specialized  
components written in revolution. The possibility to parametrize  
these components or to integrate them into a larger workflow without  
the users of these components having to buy a revolution license.  
But, because we believe that it would *really* be in the benefit of  
the users to learn to write such components themselves, a mechanism  
of progressive disclosure, by which users get an opportunity to  
discover the power of dreamcard. In a sense, nagging them "look what  
you could do yourself if only you bought a $99 license!" (which was  
the konfabulator approach).

> [About Thomas Example]. That's a wonderful example, but if I read  
> it correctly it seems you were able to do what you needed on your  
> own, without RunRev lifting a finger.

Yep, exactly. It is of course necessary to respect the licensing  
conditions... If you read them carefully you will find that you are  
asked not to use revolution to develop a tool that is a direct  
concurrent of revolution. This imposes to propose the user to  
parametrize components written in revolution, not to become able to  
write and then execute transcript code from within these components  
without a paid license.

That's the idea behind the pyramid of users graph in the middle of  
page <>. Component creators  
need access to a development environment (for instance, revolution  
IDE) but component editors (those who want to change the look and  
feel or modify some very basic aspects of the components) don't need  
access to revolution development environment. Open source software  
are great, but they are so many persons around for which the unix  
command line is too difficult to manage.

The mission: making open source resources accessible to all, not just  
the geeks among us.

> I've been studying XUL and while it's a great concept, remember  
> that it's limited to the mozilla engine.

I like the use of the word studying ;-). Nope, it isn't limited to  
the mozilla engine. XUL is a standard. Yes, it is currently used by  
mozilla, but the characteristic of an open standard is that you can  
process it in different programming environment. I already have a  
prototype of a XUL 2 revui converter.

> MS is throwing it's copycat cloners into XAML - their version of XUL.

In reallity, they have been many other User Interface Definition  
Standards before that. You will find a list at:

> Another issue with Rev and XUL is the handling of CSS and "tables  
> in html".

You don't need to implement CSS in full. A subset is enough. Same for  
tables in HTML. To start from html and try to parse it is a  
nightmare. But when you start from a table represented in a sensible  
(interoperable) format, it is very easy to convert it into html code  
or integrate it within rev widget.

> I know, there is AltBrowser but for processing it has some  
> limitations i've been told.

I have AltBrowser. I used it to write a wikipad application (<http://>), that is an application  
that let me read and edit the pages of my wiki locally. I have not  
discovered limitations in css handling yet.

> Then there's the more serious problem of transfering html  
> compatible patterns to rev on OSX which is bound to fail miserably -

It's not about porting xml patterns from pc to mac or linux. It's  
about coding them with standards like xul, which can then easily be  
transformed into html code or rev ui elements or mozilla ui lements,  
or python ui elements, or whatever. Sure, you loose in terms of  
flexibility. So the idea is to design a library of "basic widgets"  
and to propose widgets that are designed according to sound HIG  
design principles. But the visual interface will be coded in a text  
file that can be edited outside revolution, so the user has the  
possibility to move that little "hello" button a bit more to the  
left, a bit more to the right or to change the background picture of  
the stack without any access to the transcript code. Even better, the  
user has the possibility to localize the file (for non English  
speakers) without any access to the transcript code.

> Example being that i made some OSX specific skins in W2K to port  
> easier my stacks to OSX later and when i realized my mistake it was  
> too late - damage was done - 20X20 patterns dont work either on  
> macs (they must be specific sizes which
> are just horribly restrictive). This is what i think is really  
> limiting rev in terms of color cursors, and greater integration  
> with the real world out there - xul included...

That's why you need to take a different approach. Rather than try to  
port from pc to mac, you write your code in a format that is then  
converted into an appropriate rendering on the pc and an appropriate  
rendering on the mac. The rendering need to be as similar as possible  
on both platforms. But the routines don't need to be. By having a lot  
of your application logic represented in a format like xul rather  
than have to handle all possible single cases of pc to mac porting  
issues in your code, you can write more generic functions.

Note that you will find more information on "Widget-based Development  
Environments" at < 
page=SoftwareWidgets> and links to some galleries of widgets at:  
page=TechnologiesWidgets>. To learn more about XML specifications,  
feel free to visit: < 

But let's not bother the user of this list too much with this.

Persons with an interest in this, please take contact with me. I will  
minimize information on this list in the future.

As I am only at the start of it, I am a bit warry about disclosing  
too much of my fabrication secrets on this very public mailing list  
(keyword search in google show up this list on top of the list). Il  
will set up some "members only" area somewhere, sometimes soon. When  
I say I, it is rather "we". A small group of persons is presently  
having discussions to try to organize collaborative work on this.

There will probably be 2 or maximum 3 persons to take the lead (and  
two persons with a long time interest in this have already taken a  
commitment in terms of time and money) but we would almost certainly  
welcome contributions from other members of the list. That's what the  
pyramid on the exercist page is for (< 
exercist/>). There is a small number of persons to design the  
infrastructure, but once the infrastructure is in place, a fair  
number of "technically skilled" users can contribute template widgets  
written in ways that allow for interoperability. Once these have been  
written, an even larger number of users can contribute what are  
"variations" of template widgets.

We are in the process of defining our objective and business model.  
By business model I only refer to the way we intend to manage the  
initiative, in terms of person, time, priorities, and money. Most of  
us favour an open standards, open source strategy.  The  
infrastructure will be made available for free. There is a  
possibility, however, for "template widgets" to be made available for  
free or for a very small fee (£5-£10 pounds). Some distribution  
mechanism will be created (independent of revolution company). My  
understanding is that such a project would benefit of all members of  
this community (even more rapid development for professionals,  
possibility to see components outside the revolution community,  
existing components more visible, lower price for specialized  
components for not so technical members, contributing to a better  
world in general).


Marielle Lange (PhD),  Psycholinguist

Alternative emails: mlange at, M.Lange at
Easy access to lexical databases          
Supporting Education Technologists              http://

More information about the use-livecode mailing list