From graphics-request at octave dot org Mon Mar 6 14:57:07 2006 Subject: Re: Object Graphics v0.3 From: Bill Denney To: Shai Ayal cc: graphics at octave dot org Date: Mon, 6 Mar 2006 15:58:27 -0500 (EST) On Mon, 6 Mar 2006, Shai Ayal wrote: > Bill, > > Thanks for the time & thought you invested in this. Thank you. > I have a few comments: > > Units: Matlab supports a multitude of units -- pixel, point, cm, > inch,... So I'm not sure what the minimal requirements should be. I want to support many units, but I don't like the idea of there being a real-world unit specified in the middle of the figure. This is because allowing for a mixture of units adds significant confusion to the figure implementation. Perhaps we should have a figure level conversion between pixels and physical world units, a property to figure-level objects that would be something like PixelsPerDistance that would be a 2x1 cell vector containing a number and a unit type (like "in" or "cm" or "pt") then any distances given could be converted to the appropriate units for the figure by the set command. The reason I dislike this is because if I have to think about physical distances while making a figure then I have to think about the conversion that I want to do instead of the general look of the figure. > ticklength -- while specifying it in percent of the axis scale seems > natural, It turns out to be "ugly" -- some things just look better if > they are a fixed number of pixels whatever the axes scale is. It's > like text -- it's size has to specified in points/pixels and not in > axis units. But what about backends that don't have a distinct unit of "pixel" such as any form of paper-like backend? I don't like using pixels because they vary with display device while other scales don't vary. > 3D: I am not planning to implement it soon, so I have many suggestions :) > I think that you should add all the camera, lights etc.. properties. > Most 3D tool kits support it anyway (I know OpenGL does), so it really > does not complicate the code much. OK, I'll look into the camera, light, etc. properties and come up with some suggestions for version 0.4. > layering: > I think it would be more clear to write first child on the bottom, > last child on the top I thought that was what I had written. Could my writing be made more clear somehow since what you describe was definitely my intent. > legend object: > This is my creation and does not exist in matlab. Of course I am > flattered that you like it, but I think you should reconsider whether > it should be in the spec. I think that it makes sense as a separate object because of the fact that it is the only type that I can think of that will be linked to another type. In other words, it has the special property that it will draw generic lines but not use the line data, so it may have children that are also children of another object. > compatibility: > We should probably add some query functions like: > propnames(handle) to return call array of strings with the names of > all properties, > isproperty(handle,propname) to find out of the object supports the property. > the user can use these to develop cross-backend apps. OK, I'll add that to the spec. > Also, I think that get(handle) should return a structure with fields > corresponding to the properties and values corresponding to their > value, like in matlab That was what I planned on it doing; I'll specify that as well. Bill -- "What if they call the Cops?" -- Ted Johnson "You run. That's the most exciting part of trick or treating naked for UNICEF." -- Nick -- Red Meat, 10/22/2002