From graphics-request at octave dot org Mon Feb 13 14:02:16 2006
Subject: Re: Handle graphics again
From: Shai Ayal <shaiay at gmail dot com>
To: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
Cc: octave maintainers mailing list <maintainers at octave dot org>,         octave-graphics <graphics@octave.org>
Date: Mon, 13 Feb 2006 22:00:31 +0200

John,

I agree with you completely -- your way is a very good way to go and
will allow a bigger number of people to help development. The biggest
problem with your proposal is that, in my opinion, it is hard, tedious
and dirty work to do -- you basically have to bend over backwards and
use the m-language in ways it was never meant to be used. This is why
I think you did not get many volunteers to do it.

My reasons for writing octplot in c++ are purely selfish -- I knew
m-files but I wanted to learn c++. At this stage I am too committed to
octplot to just abandon it and I suspect that other projects are in
the same situation.

If this proposal was on the table at the time I started octplot I
probably wouldn't have started octplot because I realise your way is
better OTOH I would also not put as much time into helping with your
proposal as I would into octplot for the reasons I gave above

Anyway, that's why I Started the thread on creating a repository -- as
a sort of compromise -- I and others will contribute all of our
top-level code and at least there we will not duplicate effort.

Shai
On 2/13/06, John W. Eaton <jwe at bevo dot che dot wisc dot edu> wrote:
>
> 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
>