[Top][All Lists]

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

Re: units conversion (was: about contibuting to octave)

From: John Swensen
Subject: Re: units conversion (was: about contibuting to octave)
Date: Fri, 13 Mar 2009 15:57:52 -0400

On Mar 12, 2009, at 7:11 AM, Ben Abbott wrote:

On Mar 12, 2009, at 6:13 PM, Michael Goffioul wrote:

There exist already some code to convert from different "units".
See for instance the convert_position function in graphics.cc used
to convert position rectangles between various possible "units".

Some extension is needed to be able to handle single point instead
of rectangle and also to support data "units". However, the axes object
provides an easy access to the current transformation matrix, so it
shouldn't be that hard.  ... (snip)

Regarding units conversion, should we write a single function that handles this job for all objects with a "units" property?

If we do that, it appears to me that we only need to write a single listener to handle to handle the conversion for all objects with "units" properties.

Actually, given how addlistener works, it should be possible to write a singled listener for everything (at least to have a single function name whose actions depends on the object "type" and the property changed).

For example, if the listener function is called "update_property", and takes the following inputs ...

update_property (h, dummy_arg, property_that_changed, old_property_value)

The listeners for conversion of an object's units would be ...

addlistener (h, "units", address@hidden, "units", get (gca, "units")})

The listener function would then have access to the new and old units as well as the old value.

The listener for objects with a "rotation" property ...

        addlistener (h, "rotation", address@hidden, "rotation"})

In this case the old value isn't needed.

The same approach can be used for objects with the "position" property.

        addlistener (h, "position", address@hidden, "position"})

One advantage of a unified listener is that it is easy to disable recursion. For example, changing "units" changes the "position" property, but need not trigger a new rendering.

I think this approach can handle all cases and sets a consistent standard that would make maintenance easier.

I'm thinking about this from the perspective of m-file implementation. However, as several properties are read-only, this would need to be implemented in c++. So, I may be off base in my approach.



I apologize for getting into this conversation kindof late in the ballgame, but want to clarify a few things. I have included a bit of code I wrote a while back to render latex strings to a GDKPixbuf using the poppler library (we can also use a GDK/GTK free portion of poppler called libSplash, but the GDK solution was easier since there were a lot of examples). When I first wrote this, I was trying to render it in the OpenGL backend, but was having issues with sizes. Are you saying that the handle graphics system now implements properties that tell how big this pixel buffer/OpenGL texture should be?


Attachment: latexpoppler.cc
Description: Binary data

Attachment: Makefile
Description: Binary data

reply via email to

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