octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: graphics future


From: Daniel J Sebald
Subject: Re: graphics future
Date: Thu, 26 Apr 2007 15:03:25 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020

Shai Ayal wrote:
On 4/26/07, Daniel J Sebald <address@hidden> wrote:

Shai Ayal wrote:
> On 4/26/07, Daniel J Sebald <address@hidden> wrote:
>
>> John W. Eaton wrote:
>>
>> > | While group objects make these a LITTLE bit more convenient, I
>> fail to
>> > | see what qualitative added value they have.
>> >
>> > It is impossible to implement some fairly common plot types (stem,
>> > bar, hist, stairs) in a compatible way without them.
>>
>> Take stem for example.  Where is the incompatibility?  What portion of
>> this
>> incompatibility has to do with the graphics engine?
>
> Well, stem should return a stemseries object:
> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/stem.html
> so, the incompatibility is only in the return values. All input
> parameters can be parsed and drawn in a compatible way with core
> objects only

OK, so there's another doll inside the Matryoshka, a 'v6' option. Apparently
what John implemented is version 6 and must remain.  The hggroup is an
additional factor. The stem series was may have been introduced because of the
fact the more object-like handle for each line was too slow to render.


I don't think so -- the back end will have to render all the lines
anyway. I think the stem series was introduced so that the user will
have easier control over properties -- i.e. with one "set" the user
can change the color of all stem series objects (in this case, markers
and lines)

That too. Rather than having to work with 100 objects, the whole set can be handled at once. This seems, to me, to make things easier in terms of working with any graphics engine. I don't know any of the "type/tag" things, but from that info, one should be able to garner whether there is a series of data. Sure, mayber there still needs to be a fundamental line object, but that doesn't mean the series needs to be a composite of lines. It seems to me the complication is (and the reason for the "type/tag", as opposed to simply a more extensive list of "type") that MathWorks wanted to make changes for the reasons you state, but they also wanted/needed to maintain backward compatibility.

So, the desire it seems is to have 100% compatibility with handles and associated properties. But if one goes that direction, implementation of an "obsolete" interface is a short step away.

Dan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]