From maintainers-request at octave dot org Mon Feb 13 13:39:41 2006
Subject: Handle graphics again
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: Shai Ayal <shaiay at gmail dot com>, Ole Jacob Hagen <waterthrill@yahoo.no>,         John Swensen <jswensen@intergate.com>,         Sebastien Loisel <sloisel@gmail.com>
cc: octave maintainers mailing list <maintainers at octave dot org>
Date: Mon, 13 Feb 2006 14:40:22 -0500


It seems that we have several independent implementation of handle
graphics capabilities developing.  I think that's a good thing, at
least in that there is some interest and activity.

OTOH, we seem to also be developing N implementaitons of the code that
manages the handle graphics data.  I would much prefer to have Octave
manage this data in one consistent and mostly Matlab-compatible way.
It does not make sense to have each GUI/graphics package for Octave
reinventing solutions to the problem of managing the data and
properties.  In the end, I expect that only one implementation of the
code for managing this data will be included in Octave, and it will be
best for people who want to implement graphics and GUI tools to use
that as it will make it simpler for multiple graphics backends to
peacefully coexist while sharing the same data and properties.

We have spent some time discussing this in the past.  See for example
the discussion on the maintainers list with the subject "handle
grapics with Document/View design" (note the misspelling of
"graphics"; oops), in particular this message:

  http://www.octave.org/mailing-lists/octave-maintainers/2005/853

which points to example code that I wrote entirely in .m files that
does more or less what I would like to see.  It is not perfect.  I
asked for comments back when I posted the link to the code, but I
don't recall any significant further discussion about it.  I would
like to see some.

So can we please put some effort in to converging on one set of
functions to managing the data for handle graphics capabilities?  I
think we should start by discussing what capabilities are needed, and
whether it will be possible to implement most of what we need in .m
files (along the lines of what I proposed).  If another implementation
is better than what I've proposed, then please explain how it is
better.  That it is faster is not a sufficient reason, as I
suspect my implementation could be significantly faster by converting
a just few key functions to C++.  Also, it would be helpful to be able
to  implement significant portions of this code in .m files, as I
would like to make it accessible to as many Octave hackers as
possible.

Thanks,

jwe