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

- XYZ

 [1/2] from: chd::1staccess::ca at: 8-Sep-2007 10:37


Hi Greg I agree with your concept of a real world XYZ. In a sense on the web there is already a pseudo scale factor "em". We us it a lot since it scales well for different browsers and different screen resolutions. However it is a stupid workaround, but it does support the need for a scaling factor on the internet at least. I have always seen the GUI as an open book, with "0" as the top left corner of the right page and the top left corner of the left page. Only the right page is actually ever seen. It starts at 0 and runs to infinity. The left page starts at 0 and runs to negative infinity. In the good old days (1983) on the Mac we used a great deal of the negative page as an off screen buffer. Not just for animation sprites etc, but actually some assembly of " page parts". I have never understood why off screen buffers have never been used on the internet, especially for dial-up situations. I guess it is a matter of not knowing what the user will do next the prohibits its usefulness. But graphics, buttons, fonts etc could be sent from the server to a buffer while someone is reading a page "just in case". On another matter I would like to see "the chunks" sent by to browsers reduced from pages to "containers". Containers could contain anything and would travel with their XYZ positions attached. So when the browsers gets it, it would position it at X and Y top left and X and Y bottom right on layer Z. I find the current "page" system highly restrictive and use JSON more and more for page layout. I suppose container rotation would also be nice. As REBOLs we must keep questioning the status quo... there are much better ways of doing things! ~chris

 [2/2] from: greg:schofield:iinet:au at: 9-Sep-2007 23:03


Hi Chris, thanks for the reply. I agree that it is much easier thinking of things in terms of coordinates and using the virtual negative spaces for hiding things. It seems to me that XxYxZxUnit (Z=0 can be implied most of the time) the problem would be designating units being employed. I am not very REBOL aware especially with style, so I have used =93x=94 as a marker for the measurement datatype (it is kinda ugly though). If this is taken seriously and =93real world=94 is made the essential characteristic of such a datatype then the bare unit (XxYxZ or XxYxZx) would be in metres. Perhaps appending either =9310 ** -3=94 (mm), =9310 ** 3=94 (km), ie., 10 to the power of 3 or minus 3. Because all the relations are essentially mathematical it is just as easy to nominate a unit value in terms of a metre, =930.0003527=94 being a printer's point; 1/72 of an inch. Mixing units would be nice (4 * 10 ** -3)x4x(4 * 10 ** 3)x being a 4mm wide, 4m high block 4km deep. Hence: Point: 0.0003527 x12xxPoint or x(12 * Point)xx This is pure vertical measure of 4.2324mm or 12points. I don't know whether it is REBOL style to have =93x=94 as identifiers, or that 0x12x0xPoint would be more consistent =96 however others could come up with something prettier it need only cover XYZ plus unit, based on a metre assumption. Some standard assumption units (conversion tables, virtual units for such things as GUIs, etc.,) could be very useful and need only to be a data set to draw-upon, and fed into the measure datatype as required. Offset is important, but negative measures are not real world, I don't believe they should have a place in a measurement datatype, rather as an object positioning function. Using Z with =930=94 as visible =93-1=94 is a convenient way of keeping data buffered but invisible, just as =93Z = 1=94 can bring in something to be buffered but invisibly behind, and it can be done by simply incrementing a measure datatype as a series, via offsets. I am not thinking in any way of computing efficiency so much as scriptors being able to have dialects that follow the practicalities of what they are doing. Offset can be a very simple way to shuffle graphical elements and with it control data loading and erasing. Likewise scale, or viewport. Margin of error and precision do effect measure as a reliable dataype, I don't know an elegant way to include this, but in many scientific applications these can be very important, eg +- 0.01 might be added to the datatype unambiguously and rounding could always be a surrounding function. Just suggestions, but a real world datatype like measure seems a very handy thing to have. Greg Schofield Perth Australia --- Message Received --- From: Chris Dwyer <chd-1staccess.ca> To: rebolist-rebol.com Reply-To: rebolist-rebol.com Date: Sat, 8 Sep 2007 10:37:18 -0400 Subject: [REBOL] Re: - XYZ Hi Greg I agree with your concept of a real world XYZ. In a sense on the web there is already a pseudo scale factor "em". We us it a lot since it scales well for different browsers and different screen resolutions. However it is a stupid workaround, but it does support the need for a =20 scaling factor on the internet at least. I have always seen the GUI as an open book, with "0" as the top left corner of the right page and the top left corner of the left page. Only the right page is actually ever seen. It starts at 0 and runs to =20 infinity. The left page starts at 0 and runs to negative infinity. In the good old days (1983) on the Mac we used a great deal of the negative page as an off screen buffer. Not just for animation sprites =20 etc, but actually some assembly of " page parts". I have never understood why off screen buffers have never been used on the internet, especially for dial-up situations. I guess it is a matter of not knowing what the user will do next the prohibits its usefulness. But graphics, buttons, fonts etc could be sent from the server to a buffer while someone is reading a page "just in case". On another matter I would like to see "the chunks" sent by to browsers reduced from pages to "containers". Containers could contain =20 anything and would travel with their XYZ positions attached. So when the browsers gets it, it would position it at X and Y top left and X =20 and Y bottom right on layer Z. I find the current "page" system highly restrictive and use JSON more and more for page layout. I suppose container rotation would also be nice. As REBOLs we must keep questioning the status quo... there are much better ways of doing things! ~chris