Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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 filled). 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 genralizations. STYLESHEETS 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 medium. 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 coder. 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: War of the Worlds.pdf I have reduced a 269 page book to 28 pages (14 sheets) so it can be phtocopied for each student. 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 wider application. 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.