Re: Object Graphics v0.3

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