[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 <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
