Re: Handle graphics again

[John Swensen]

Shai Ayal wrote:
> 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 <address@hidden> 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
>>
>>     
>
>
>
>   
Unfortunately, I have to side with Shai on this one.  I see the document
portion of the handle graphics as the fairly trivial portion.  When I
was working on this more extensively, I created a solution nearly
identical to that of Ole using C++.  The implementation of all the
"document" side of things could *almost*  be done by  parsing the web
pages of the Handle Graphics Property Browser and auto-generating code
using the Props framework.  It was also much much easier to implement
the get/set for each "type" of object and enforce restrictions on values
and such using simple inheritence and other OO tactics.

On the other side, I think it makes very much good sense to do the
viewer implementation in m files so others can contribute.  This is the
part where we make it behave like the popular brand.  If someone sees
something that acts different than they expect, it makes sense for all
the .m programmers out there to be able to work on making it act how it
should.  Since there are binding for m->C/C++ for a plethora of toolkits
(gtk, fltk, qt, tkinter), the choices are endless and I'm sure each one
would have its trades.

Just my $0.02 (that's $0.04 total now :) )

John Swensen