[REBOL] Re: - R3 GUI
From: greg:schofield:iinet:au at: 8-Sep-2007 15:21
I apologise to the list, but I cannot help but add more on a slightly different aspect
of my previous post.
And I must add a strange rider on oddities in how I am presenting things.
1) I have not attempted to learn REBOL yet, let alone script with it, in fact I am confining
myself to reading about it.
2) I will learn REBOL from the basics up when R3 appears, the reason is simple, I intend
to write a conceptual introduction to REBOL, based on what I learn in practice, as I
am leaning it (for the simple reason that capturing the moment of understanding soon
escapes when the knowledge is established, I need to make notes as each idea sinks in
rather than try and reconstruct it inaccuratetly - I believe REBOL is significantly different
from other script langauges and that there is a gap in documentation that needs to be
So I only know REBOL in outline at this time and no-doubt my inexperience is fairly obvious,
and could be annoying to some. There is an advantage however to comming from the outside
- though I may say things that are pretty stupid, I hope it also contains some useful
Which brings me to the topic of going well beyond GUI design in seeking a framework that
is flexible, robust and easy to apply.
I am talking here about stylesheets, not the rendering of them (AGG, PS, EPS, OpenGL).
In a rough and ready manner I assign data to XML formats, easily translated into REBOL
series. Aside from processing code, the rest is a question of rendering to the right
Here in a nutshel is the whole problem CSS3 does just about everything that is needed,
but as a language it is far too limited to use and relies on different browsers to implement
it consistently (historically this has been a failure). XSLT works with much the same
limitations, but you have to be a mad to use it unless you are more or less a fulltime
We need a stylesheet system, that is as consistent as PS in rendering, can be transposed
perfectly from one medium to another, or adapted seamlessly to another.
Either PS or EPS could be adapted to produce stylesheets, the latter more effectively
because APPLE has done the work to provide a reader already plugged into browsers. REBOL
language is ideal for web pages, but a really good rendering engine (not speedy but precise)
would make a big difference in how well things could be done and how they can be used.
However, OpenGL and perhaps AGG could equally be used (I think there would be a massive
amount of programming involved).
Speed may well be an issue in any of these.
I know an effective stylesheet language for net and local use is well beyond R3's scheme,
but consider the effect of breaking with browser dependence for static rendering at least.
REBOL as it stands seems easily capable of out perfoming XSL manipulation of XML data.
Inherently it is a better basis for stylesheet rendering, and I am most unhappy with
the choatic implmentation of CSS.
Making a REBOL browser may be good in the long term, but as it has to deal with all the
accumulated sludge of the net compatiblity issues will be a nightmare. Far better to
use existing browsers as a vehicle for a better REBOL way of doing things at least in
the short term. A critical componant of that is the rendering.
In this REBOL could take a decent lead, with a language plugin, and a consistent multiplatorm
rendering engine with borrowed (PDF) or created (PS, EPS, OpenGL, AGG), or anything else
for that matter. What does matter is the stylesheet dialect.
If this hits a chord, I have some equally odd suggestions about how such a dialect might
be constructed (Ultra-Verbose Generated scripts - sounds silly, as a tighter script -
better still a GUI, generates a verbose stylesheet, that includes a DTD, but I will
not burden the list with any more rantings). However, the critical bit is to have a rendering
engine capable of painting a screen or a printed page precisely.
Also consider the ability to solve printer driver issues by creating a consistent raw
raster for the printer and using a REBOL interface for page control (including page imposition),
it might not remove all the problems, but it would significantly simplify many aspects
(EPS and PS have a clear lead in this re colour separation etc,).
Just a simple example:
I have a set of particular problems in mind. As an English teacher I need electronic
resources, that can be easily transformed.
In this example:
http://members.iinet.net.au/%7Egreg.schofield/Literature/The War of the Worlds.pdf
I have reduced a 269 page book to 28 pages (14 sheets) so it can be phtocopied for each
I also need to use a plain text version for Voice Synthesis (accelerated reading program),
and in the future
marked-up for voice synethesis.
I need a fully marked-up XML version (TEI) for reference purposes amongst other things.
I would like to attach to it other material for use by teachers - MP3 of Orsen Welles'
radio version, etc.,
I would like to have screen readable version available as well.
I would like, for other teachers to use, a dynamic system that allows them to combine
various forms making their own package of resources.
Maintaining severval printed versions (A4, A5 compressed, A4 normal, possible page impositions,
plus all the rest) is mind boggling, especially if my library grows.
However, a XML version of the text, the separate files (MP3 etc, bibliogrphies, handouts,
pictures, etc), filtered through a standard set of my own stylesheets, generating useful
packages, makes managing and improving my site easy. Plus I deliver a very useful product
for my fellow teachers and the energy I spend in making things for my own classes has
It all depends on having reliable and precise rendering tools - and CSS and XSLT are
simply never going to do that.
The Philosophy behind it is simple - never reproduce data unneccessarily (the text once
in XML may be re-edited, but never duplicated on site), never construct a rendering agent
that cannot be potentially used elsewhere, use shared modules to do the same tasks in
different conditions. If I make improvements I want all documents to share it, I don't
expect to get things right first time.
I have one more point - no sane person can read a long document on screen - until technology
catches up with paper there is a need to print and read - however what appears on screen
has to be spacy, print that and reams of paper are wasted. Print and screen are two different
things. Same data, but different stylesheets is the answer.