Re: Object Graphics Issues

On Fri, 12 May 2006, Shai Ayal wrote:

> On 5/12/06, Bill Denney <[email protected]> wrote:
>
>> Text Objects
>>  *The widthheight property seems as though it would be both backend
>>   specific and as if it doesn't really belong.  Can we remove it?
>
> I agree that this is backend specific -- in octplot it is read-only.
> This property is essential if you want to control placement of text
> objects from m-files -- it gives you the dimensions of the text box.

I think that it would be a wonderful feature for backends to have, but I 
don't think that it belongs as a regular property (perhaps some or most 
backends would have something like octplot_textarea(h) would give you the 
width and height of the text object).

>> Root Object
>>  *It would be much easier if the default properties were listed as
>>   Default.Type.Property instead of DefaultTypeProperty.
>
> I agree, but this would break matlab compatibility

I think that I'm going to be writing a compatibility layer that will 
translate matlab commands to octave commands for graphics (after I get 
this frontend working).  When I do this, I'll make the files that will be 
these mappings.

>>  *I've created a Required.Type (e.g. required.line) as a child of the root
>>   object that lists the required properties as {'prop1' 'prop1', ...} so
>>   that object creation can be one simple function instead of many
>>   more complex functions.
> I don't understand this. Wouldn't you also need to store the type of
> the properties? (i.e. in linesm xdata & ydata are matrices, while
> linestyle is what I call "Radio" or multiple choice).

This is slightly different, and it shouldn't matter to the backend 
developers.  Essentially, when creating a new object, there are two types 
of checks that have to happen: is the type of the data in this correct and 
is the field required to be non-empty.  You're talking about the first 
type of test; I'm talking about here is for the second type of test.  Both 
have to be done, but with this small feature (that again, won't matter to 
backends) the second type of test is significantly easier.

>>  *Create an "Orphans" property that will keep a list of all handles that
>>   have been created but do not yet have parents.  This is to prevent the
>>   need for garbage collection in case of an error while an object is being
>>   created when its children may have already been created.
>
> Isn't this backend specific -- The backend can choose whatever method
> is approproiate for memory management.

This is for in the front end.  For example, when I am moving an object 
from one parent to another (perhaps it is being put into a group).  If 
there is an error while moving from the old parent to the new one, there 
is either a point in time when the child has two parents or no parents. 
Since, to me, having two parents is an undefined state (what do I delete 
when I delete one parent but not the other) I prefer having one defined 
state (no parents).  Having an orphan list allows for this movement. 
Also, if an object has a parent, but is for some reason still on the 
orphan list, then keeping the parent is the correct result.

Hopefully that makes more sense.  Again, this could be considered an 
implementation detail of the front end since the backends don't have to 
know anything about it, but I thought I'd throw it out there in case there 
is a better idea of how to handle this case.

Bill

-- 
"Let the worthy citizens of Chicago get their liquor the best way they
can. I'm sick of the job. It's a thankless one and full of grief."
   -- Al Capone