- R3 GUI

I hope that Carl is considering making a core with no graphics interface or only a bare minimum windowing/text/ graphic co-ordinate system. I feel that the various platform graphics interfaces are best handled as plug-ins. I noticed on OSX that there is a Ruby /Objective-C bridge to access the full Mac Cocoa interface. http://rubycocoa.sourceforge.net/ Perhaps this could be used as a sample to help build a similar bridge in R3? ~chris PS: I have always wondered why Postscript has never been used as an interface for both screen and paper. I know Apple tested it years ago, but could not agree on Adobe's licensing demands, so Apple developed their own GUIs.

On 07/09/2007, at 13.44, Chris Dwyer wrote:

> I hope that Carl is considering making a core with no graphics > interface or only a bare minimum windowing/text/ graphic co-ordinate > system. > > I feel that the various platform graphics interfaces are best handled > as plug-ins.

> I noticed on OSX that there is a Ruby /Objective-C bridge to access > the full Mac Cocoa interface. http://rubycocoa.sourceforge.net/ > > Perhaps this could be used as a sample to help build a similar bridge > in R3?

We have been constantly lobbying for more support for Postscript. That is how I am currently generating all my print documents. However, Gabriele feels PDF is the way to go .... On 9/7/07, Chris Dwyer <chd-1staccess.ca> wrote:

> > PS: I have always wondered why Postscript has never been used as an > interface for both screen and paper. I know Apple tested it years

Chris Dwyer wrote:

> PS: I have always wondered why Postscript has never been used as an > interface for both screen and paper. I know Apple tested it years > ago, but could not agree on Adobe's licensing demands, so Apple > developed their own GUIs.

Graham Chiu wrote:

> We have been constantly lobbying for more support for Postscript. > > That is how I am currently generating all my print documents. > > However, Gabriele feels PDF is the way to go .... >

Hi Jason My belief is that it would be easier to build a simple ( for text, lines etc .. the stuff documents are made of ) postscript viewer in View than a PDF viewer. That's the main thrus of why I prefer PS to PDF. In fact most of that work has been done in the various postscript dialects we have in Rebol now. On 9/8/07, Jason Cunliffe <jasonic-nomadics.org> wrote:

> Graham Chiu wrote: > > We have been constantly lobbying for more support for Postscript. > To unsubscribe from the list, just send an email to > lists at rebol.com with unsubscribe as the subject.

I see PDF as a file format rather than GUI etc. Postscript on the other hand could be print layout , interface and file format. I don't know but PDF appears to be rather stupid and verbose. Postscript to me is more minimal, like REBOL. R3, needs a cross platform basic text/graphics GUI, employing Truetype and supporting FLASH, Quicktime, WMP etc. I don't think it needs 3D capabilities, but perhaps these could be plugins to basic architecture. ~chris

Couldn't/shouldn't PDF and Postscript support both be via plugins, allowing the users to have either, both or none? (And if one needs to be there for the launch of R3, choose the quickest to impliment.) On Friday, 7-September-2007 at 18:32:06 Chris Dwyer wrote,

The problem I see is that AGG is pretty close in terms of functionality to Postscript, but there is a signficant difference in how they do translations, and rotations. The coordinate system is also upside down, but apparently that is not a major. On 9/8/07, Carl Read <carl-cybercraft.co.nz> wrote:

> Couldn't/shouldn't PDF and Postscript support both be via plugins, allowing the users to have either, both or none? (And if one needs to be there for the launch of R3, choose the quickest to impliment.) > On Friday, 7-September-2007 at 18:32:06 Chris Dwyer wrote, > To unsubscribe from the list, just send an email to > lists at rebol.com with unsubscribe as the subject.

I have my Display PostScript manual somewhere. 1:1 vector graphics between platforms and media is worth thiking about, it would also include PDF of course, but I don't want to speculate on formats at all. I wrote earlier to the forum about using real world measurements instead of abstract pixels as the underlying framework for GUI and other designs. This was because I see precision being important especially now HDTV standards are finally consolidating. The basis of converging technology needs a software anchor in the real world. Just as Apples innovation of the 72dpi monitor with the 72dpi printer plus Postscript jumped started not just Desktop Publishing but in some respects the whole idea of a GUI computer itself. Whether REBOL 3 should be thinking about going in this direction at this time is not an issue - whatever the developers are doing - just keep on doing it - PDF will be workable for a good long time and AGG is find and fast combination. OpenGL works well as well. My point is that it is not a matter of of this or that language, but establishing some fixed points of reference, from which the future direction can be shaped (REBOL 4 perhaps, but by what happens now in REBOL 3). The datatypes are critical in this, more so than any other particular language issue. This is what I propose, and hopefully not too late to be seriously considered. Realworld measurements as a series of datatypes, and scale as a means or represnting them on various media (paper, monitors, whatever). That is a datatype capable of handling the really really tiny, to the really really large, and XYZ coordinates in real measure. If this is established well with whatever factoring notation is needed to make it reasonable, then we have a basis of translating from raw scripting to whatever language or respresentation in a stable way without programming "funnies". There are a good deal of complicating factors, and I am a complete novice in this, so others would be better to judge the implications, but using GUI design as example. A dialog 300x200 is a relative measurement, using a single assumed pixel size turns it into a real measure, which can be overridden by declaring a different size (scale) while still maintaining a 1:1 to the real world. Ie one pixel = 1mmx1mm (or 0.01 if this is more convenient, basically any number would do) may be a large size, but is a trivial conversion to sets of real screens, and some simple tricks for converting between large screens (at say 1080p) and much smaller handheld devices with a lot less pixel coverage (ignoring design problems inherent in this). Establishing real measure as the "natural" datatype for all things measured gives us a very stable base for application building. The metric system has much to recommend itself as the native data format for such things. Other measurement systems being transformed into or out of it. Hence 12pt Times, is clearer than the same measurement rendered in mm but the data itself should be in a universal measure nonetheless. Between molecular, astronomical measurement, the printed word, engineering plans or GUIs, each with substantial differences but reduceable to a single system of measurement is a substantial asset and need not be combersome if handled deftly by REBOL. Plus it makes translating the whole or part of rebol script into another display language that much easier and less problematic (with far less exception handling to do so). It may be several interrelated datatypes, others will know better, the point being that one can be positioned into the other accurately. It will need sets of assumptions being made, to make scripting easy, like assumed pixel size, assumed XYZ start positions, we could even assume GUI elements have thickness, even if this is never practically used, it may even help in layering, even if the assumed thickness is very thin indeed (0.01mm perhaps - 100 layers amounting to 1mm, it does not really matter, except of course layers could be addressed via the same system Z0.02). I know this is a strange suggestion, and seems like a complex way to solve problems that don't seem to exist in many areas. For instance why use this to describe video streams when established methods work fine. But it is the implications involved, especially when looking at the long term furture, and in the short term, the reliability factor itself. The fact is that it makes a lot more sense even with arbitrary assumptions that 300x200 means 30cm x 20cm even if this is scaled for use by 75%. If I have a measure, I need only to find the scale factor, I need only establish one thing to bring all the rest into perspective whether on paper, or a particular screen, or between application uses Please consider this suggestion (if it is not too late or too complex to implement), it lays a good foundation for adopting PDF, PS, DPS, OpenGL or whatever, and gives us a stable basis for anything described in two or three dimensions. But it has to integrate the nano to the lightyear in a single continuum of real measurement. It has to be XYZ, even if the third dimension is only used for layering or not at all, and exists 9/10ths of the time as a simple assumption. May I also suggest that all measurements be XYZ with no negative positioning and where negative coordinates are needed they become an object offset (I believe this actually would simplify a lot of transformations - I may be mistaken in this). Sorry fro this long post. Greg Schofield Perth Australia --- Message Received --- From: Chris Dwyer <chd-1staccess.ca> To: rebolist-rebol.com Reply-To: rebolist-rebol.com Date: Fri, 7 Sep 2007 18:32:06 -0400 Subject: [REBOL] Re: - R3 GUI I see PDF as a file format rather than GUI etc. Postscript on the other hand could be print layout , interface and file format. I don't know but PDF appears to be rather stupid and verbose. Postscript to me is more minimal, like REBOL. R3, needs a cross platform basic text/graphics GUI, employing Truetype and supporting FLASH, Quicktime, WMP etc. I don't think it needs 3D capabilities, but perhaps these could be plugins to basic architecture. ~chris

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: 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 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.

No need to apologise for your posts Greg - they're good and interesting and probably very pertinent to REBOL. BTW, have you read Carl Sassenrath's posts on XML/CSS? They're here... http://www.rebol.com/article/0108.html And the follow-up post... http://www.rebol.com/article/0110.html -- Carl Read. On Saturday, 8-September-2007 at 15:21:15 greg.schofield wrote,

>I apologise to the list, but I cannot help but add more on a slightly dif >ferent aspect of my previous post. > from other script langauges and that there is a gap in documentation tha >t needs to be filled).

I haven't read the rest of the messages in this thread yet; but isn't PDF basically postscript? Talking without researching... Cheers, Bluey On Friday 07 September 2007 16:29, Graham Chiu wrote:

Carl thanks for the pointers I have not read it before.Carl thanks for the references I had not read it before. And thanks for the references I had not read them before: <http://www.rebol.com/article/0108.html> http://www.rebol.com/article/0110.html Interestingly, I agree with just about all of it. Yet, I had waited a long time for XML, (that is long before HTML, and before I had heard of SGML). But it is typical of the computer industry to miss the point, the articles are spot-on in their criticism. In a sentence: XML is excellent for marking up Literature - but useless for simple information. Where structure is important, but is only mediated by human understanding, then XML comes into its own, making what is implicit but understood by the human mind, explicit and understandable to the computer. If the point is only to supply software with data and it is the software that makes it useful alone then XML is misplaced. If the data needs to be saved, and may be used for other things =96 then XML is a good format for that (it is put into a passive state). Converting REBOL scripts (ie data scripts especially) to XML is, unlike any other language I know, a trivial thing. Unambiguously converting it back, is likewise trivial (there is a delay naturally). If I am using a REBOL rolladeck to keep my contacts, I don't want to reproduce it in parts when I need sections of its elsewhere, ideally I want it in one place in a form that suits its use (ie in passive saved form, translated into whatever I need at the time). Finally I do not necessarily want to go through a line editor, or my rolladeck software to correct things when perhaps I have made a systematic mistake, the easiest path may well be to use the mark-up as a general editing tool in a decent XML Word Processor (which alas does not yet exist). Even if my data is kept in a DataBase, if I need to edit chunks of it in unexpected ways, I need it to be translated into a form made for editing by human beings. This is awkward, because the essential element is missing. A decent XML Word Processor. In short, where meaning is implied by complex human interpreted structure then explicit XML is a very good means to do so, especially that in general it should be passive (have things done to it) rather than as an active agent. Another simple rule is generally XML is good when the content far outweighs the tag lengths, but not always, sometimes it is the complexity of the overall context that demands mark-up rather than code lines for editing purposes. Editing, writing of all kinds, even if the end product is not to be XML, then XML as a structuring device is very important, I would go as far as saying logically inescapable. Unlike any form of code it is naturally passive, it is just mark-up (problems are created when XML is pushed to do more =96 it doesn't like it and you get a mess). I would suppose everyone reading this treats their line-editors as a natural extension of themselves while coding. Simple and robust technology with a lot of useful features added on top. Some of the more syntax sensitive ones are using XML-like structuring by scanning for markers in the code being written. With experience, line editors work well, but without such experience the problems with handling code this way becomes overwhelming, because, in essence, it is so damn primitive and code is not. However, for anyone who has used any of the current XML editors, the opposite is true. The things are so damn complex using them in the everyday sense would be mental suicide and a productivity blow almost beyond recovery. There problem is not additive, like line editors being simple and then having features piled on them, it is fundamental miss-design. They are in effect not XML editors at all, but tag editors. Tag obsession is a symptom of missing the point of XML. Tags are human determined mark-up rendered in machine readable form. XML itself is not easy to read by human beings, it is possible to make sense of the tags by looking at what they mark-up, but you can no more =93read=94 a complex XML document (like TEI mark-up) than read a text sprinkled with gibberish. Using tags to make up XML documents is silly and always has been, people only really do it because they have no other choice. For instance: The Text Encoding Initiative (TEI) scholarly mark-up of all kinds of Literature means hand placing a massive number of tags into a text. This is done because it is an important way to access text through its tags, annotate them, and reference them sanely. Marking-up for TEI even with the much improved tools of the last few years =96 is simply insane. Yet the very fact that academics do it at all, says much about the power of XML when applied to something as complex as Literature. The trick is a simple one =96 the rules of tag use have to be readable even if produced by a GUI. A DTD has to read as prose, it is not just the instructions for what follows what, but also a description of the type of document being constructed, something human beings have to read, especially when they are deciding whether the document design actually does fit what they have in the text. I mentioned Ultra-Verbose Generated Scripts in an early post. tag <p> does not actually convey much in itself, but a Verbose dialect says it all: =93The tag 'p' is used for a paragraph that can include...=94 It is simple prose, extremely verbose, giving us a help file but also important resources =93p=94 is the tag, but it is in plain language a =93paragraph=94 which is more useful in menus than =93<p>=94. A REBOL dialect for DTD description has to be verbose because in the end people have to read it simply to see if it fits what they want to do, or needs more put into it or deleted. Using tags in that script adds structure for editing purposes, and penalties in processing, but also a display for printing, or screen reading, as well as editing via stylesheets. That is the second trick. Human beings should not deal with tags at all, the tag rules should shape the stylesheet and in effect the stylesheet marks the text. Applying a stylesheet to text, changes its look, but also changes its tags. If applying =93new Paragraph=94 to a chunk of text, may do no more than add a space between it and the rest of the text, but it may also eliminate needless line returns and add in <p> ... </p> to make this explicit. My stylesheet for editing should not resemble the final presentation stylesheet, it has a different purpose. I can have for instance have =93dates=94 in bright pink, underlined in red and with an explanatory supertext in a double spaced edit document. That is the colour makes it easier to see whether I have got all the dates, while the fact that some are Julian dates and others Islamic dates is explicitly shown, but none of this will be shown in the final document. Editing is one environment, what is produced is another. Every Word Processor confounds this difference, and I would argue why many reading this much prefer a line editor than a WP to write their code. And that amongst many others is a problem that needs an elegant solution the solution is not to have several different editors, but essentially one editor that can be presented in a myriad of different ways. For that to work the elements, aside from actual GUI features, boils down to a stable mark-up structure and dynamic graphical stylesheets through which editing is done =96 the rest is simple translation of formats. --- Message Received --- From: Carl Read <carl-cybercraft.co.nz> To: rebolist-rebol.com Reply-To: rebolist-rebol.com Date: Sat, 8 Sep 2007 20:23:45 +1200 Subject: [REBOL] Re: - R3 GUI No need to apologise for your posts Greg - they're good and interesting and probably very pertinent to REBOL. BTW, have you read Carl Sassenrath's posts on XML/CSS? They're here... http://www.rebol.com/article/0108.html And the follow-up post... http://www.rebol.com/article/0110.html -- Carl Read. On Saturday, 8-September-2007 at 15:21:15 greg.schofield wrote,

>I apologise to the list, but I cannot help but add more on a slightly dif >ferent aspect of my previous post. > from other script langauges and that there is a gap in documentation tha >t needs to be filled).