How revolution can be used to make pretty widgets (was Why is Konfabulator "Pretty?")
mlange at lexicall.org
Fri Dec 9 06:58:11 CST 2005
> 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 <http://projects.lexicall.org/exercist/>. 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://
projects.lexicall.org/portal/wikipad.php>), 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 <http://revolution.lexicall.org/wiki/tiki-index.php?
page=SoftwareWidgets> and links to some galleries of widgets at:
page=TechnologiesWidgets>. To learn more about XML specifications,
feel free to visit: <http://revolution.lexicall.org/wiki/tiki-
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 (<http://projects.lexicall.org/
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 blueyonder.co.uk, M.Lange at ed.ac.uk
Easy access to lexical databases http://lexicall.org
Supporting Education Technologists http://
More information about the use-livecode