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

[REBOL] Re: - R3 GUI

From: greg::schofield::iinet::net::au at: 8-Sep-2007 12:22

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 <> To: Reply-To: 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