Minimal requirements from a handle graphics package

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Minimal requirements from a handle graphics package

Shai Ayal-2
Hi all,

This is a preliminary list of low-level functions which should be made
available by any handle graphics package. This is my list of course
and I would expect many comments and changes. The documentation to
these functions is available from the octplot CVS repository in the
src directory.

get
set
print
figure
axes
cla
clf
line
text
patch
surface

Any implementation should also provide the root object, handle=0


With these functions in place one can use any of the other high-level
functions available now in octplot
(plot,bar,contour,pcolor,freqz,....). Of course, if the objects lack
certain properties the output will be a bit different (i.e. if the
line object has no marker property, you will not be able to show
different markers), but as long as set/get handle this gracefully
there should be no problem.

Comments, rants, additions welcome

Shai

p.s. The octplot CVS is available for browsing at

http://cvs.sourceforge.net/viewcvs.py/octplot/octplot/src

Reply | Threaded
Open this post in threaded view
|

Re: Minimal requirements from a handle graphics package

Ole Jacob Hagen-3
Hi,

Following objects should also be included into the handle graphics package:

image
uicontrol
uimenu
uicontextmenu
light
rectangle

Command: delete must be included.


And which M*lab version should our handle graphics package be compatible
with?
R11, R12, R13, R14? Mathworks has redesigned their handle graphics
package, from R13 to R14.

Should we strive for R11 or R13 compatibility ?

You can also find similar low-level functions  in oplot as well. You can
browse online here:
http://cvs.sourceforge.net/viewcvs.py/oplot/oplot/src/octave/

You'll find that both octplot and oplot has the same low-level
functions. They both are dispatching, creating aliases for their functions.

The low level function set/get are used in a similar way in both octplot
and oplot

Oplot version of set/get calls oplotcom(....), while octplot versions
calls the octplot_command(....)
See examples at the end of this mail. So octplot and oplot is more
alike, than you would like to prefer, I guess. Octplot uses also a
similar toogle mechanism as enabling/disabling usage of graceplot.
These m-files can be retrieved from octave-forge. It handles the order
of the search directories in the loadpath used in Octave.

Oplot uses props for handle graphics storage, while octplot is a
Props-less implementation...This it not entirely true, or is it Shai?
You are calling MAKE_REF(...) to make properties available to both read
and write.

I can see that you've created your own Props-similar implementation? I
am refering to the prop-prefixed cpp-source files in octplot.

Oplot has a handle graphics storage, that are used by the rendering
classes, and they are not "glued" together.

Therefore I would say and claim that octplot and oplot is very alike.
Same principles, but different software design in some areas.

Besides, we have exchanged files from each other.

The handle graphics functionality restricts developers in designing and
implementing visualisation application to octave supporting handle
graphics.

The same minimum amount of low-level functions have to be shipped: line,
surface, image, patch, text, figure, axes, set, get and delete.  These
must be shipped to ensure minimal visualisation functionality.

This require that the following graphic objects are supported: root,
figure, axes, line, surface, patch, image and text.

If octave shall provide a library for the graphical objects at all, the
Props library or a similar library would be preferable. Props can be
used internally by Octave, or by the visualisation application. It
should be noticable that Props used internally inside Octave doesn't do
any visualisations. For a graphic less props browse
http://cvs.sourceforge.net/viewcvs.py/oplot/oplot/props/octave/

This could be nice to use, if you want to handle/experiment with handle
graphics without visualisation, and to experiment on how props really
works.

Props was designed and developed during a bachelor thesis written by my
brother, Hans O.

Cheers,

Ole J.



Comparison set.m
oplot:

> function *oset*(varargin)
> oplotcom(*"set"*, varargin{:});
> end

octplot:

> function *oset* (varargin)
>   *if* (length(varargin)<3 || mod(length(varargin),2)~=1) ,
>     usage('set(hnd,prop,val[,prop,val])');
>   endif
>  
>   hnd = varargin{1};
>   *for* ii=2:2:length(varargin),
>    *for* jj=1:length(hnd),
>       octplot_command('set',hnd(jj), varargin{ii},varargin{ii+1});
>    endfor
>   endfor
>
> endfunction
>

get.m

oplot:

function x = oget(varargin)
x = oplotcom(*"get"*, varargin{:});
end

octplot:

> function _out = get (varargin)
>  
>   *if*(nargin<1)
>     usage(*"get(hnd,[prop])"*);
>   endif
>  
>   hnd = varargin{1};
>   *out* = cell();
>   oi =1;
>   *for* ii=1:length(hnd)
>     tt = octplot_command(*"get"*,hnd(ii),varargin{2:length(varargin)});
>     *out*(oi:oi+length(tt)-1) = tt;
>     oi += length(tt);
>   endfor
>  
>   *if*(length(*out*) ~= length(hnd))
>     ## means we were returned a list of all properties
>     printf(*"\nProperty list\n\n"*);
>     *for* ii=1:length(*out*),
>       printf(*"  %s\n"*,*out*{ii});
>     endfor
>     printf(*"\n"*);
>   elseif( length(*out*) == 1)
>     _out = *out*{1};
>   elseif( length(*out*) == 0)
>     _out = [];
>   *else*
>     _out = *out*;
>   endif
>
> endfunction





Reply | Threaded
Open this post in threaded view
|

Re: Minimal requirements from a handle graphics package

Shai Ayal-2
In reply to this post by Shai Ayal-2
this is a stiff requirement.

lets just say that you need a print command, and that you should
provide as many output options as possible. I consider eps a must and
all others optional, but others will probably argue with that.

Shai

On 2/16/06, Marcus Vinicius Eiffle Duarte <[hidden email]> wrote:

> Hi folks,
>
>  I believe that saving to/loading from .FIG files should also be included by
> default in any HG package, but this would have to be done by means of
>
>  (i) specific functions that are not called "save" and "load"; or
>
>  (ii) coordination with the octave core package in some way.
>
>  Marcus Vinicius
>

Reply | Threaded
Open this post in threaded view
|

Re: Minimal requirements from a handle graphics package

Shai Ayal-2
In reply to this post by Ole Jacob Hagen-3
Hi Ole,

> image
> uicontrol
> uimenu
> uicontextmenu
> light
> rectangle
> Command: delete must be included.

I'm OK with that

>
> And which M*lab version should our handle graphics package be compatible
> with?
> R11, R12, R13, R14? Mathworks has redesigned their handle graphics
> package, from R13 to R14.
>
> Should we strive for R11 or R13 compatibility ?

lets go for the version w/o the "group" objects.

> You can also find similar low-level functions  in oplot as well. You can
> browse online here:
> http://cvs.sourceforge.net/viewcvs.py/oplot/oplot/src/octave/
>
> You'll find that both octplot and oplot has the same low-level
> functions. They both are dispatching, creating aliases for their functions.
> The low level function set/get are used in a similar way in both octplot
> and oplot
>
> Oplot version of set/get calls oplotcom(....), while octplot versions
> calls the octplot_command(....)

good. This is precisely my point -- lets now share the high level functions

> See examples at the end of this mail. So octplot and oplot is more
> alike, than you would like to prefer, I guess. Octplot uses also a
> similar toogle mechanism as enabling/disabling usage of graceplot.
> These m-files can be retrieved from octave-forge. It handles the order
> of the search directories in the loadpath used in Octave.

nice, but I don't see toggle as place to enforce a standard. lets
leave it to individual packages on how to invoke them.

> Oplot uses props for handle graphics storage, while octplot is a
> Props-less implementation...This it not entirely true, or is it Shai?
> You are calling MAKE_REF(...) to make properties available to both read
> and write.
>
> I can see that you've created your own Props-similar implementation? I
> am refering to the prop-prefixed cpp-source files in octplot.

Every handle graphics objects should have properties, and as such I
have a "Props" implementation by definition. I am not sure it is
similar to yours -- props has a better design in that it is separate
from the "drawing engine. In octplot they are intertwined -- I am not
a very good software designer.


> Therefore I would say and claim that octplot and oplot is very alike.
> Same principles, but different software design in some areas.
>
> Besides, we have exchanged files from each other.
>
> The handle graphics functionality restricts developers in designing and
> implementing visualisation application to octave supporting handle
> graphics.
>
> The same minimum amount of low-level functions have to be shipped: line,
> surface, image, patch, text, figure, axes, set, get and delete.  These
> must be shipped to ensure minimal visualisation functionality.
>
> This require that the following graphic objects are supported: root,
> figure, axes, line, surface, patch, image and text.

You agree with me than ?

> If octave shall provide a library for the graphical objects at all, the
> Props library or a similar library would be preferable. Props can be
> used internally by Octave, or by the visualisation application. It
> should be noticable that Props used internally inside Octave doesn't do
> any visualisations. For a graphic less props browse
> http://cvs.sourceforge.net/viewcvs.py/oplot/oplot/props/octave/
>
> This could be nice to use, if you want to handle/experiment with handle
> graphics without visualisation, and to experiment on how props really
> works.
>
> Props was designed and developed during a bachelor thesis written by my
> brother, Hans O.

This is another issue which I was trying to avoid in this thread --
How the handle graphics system is implemented. JWE wants it top be all
m-files, Ole wants it to be props and Shai doesn't really care since
octplot does this internally. So lets bypass this area of disagreement
on the "wiring" of handle graphics and concentrate on what we can
collaborate on -- the low-level functions.

Shai

Reply | Threaded
Open this post in threaded view
|

Re: Minimal requirements from a handle graphics package

Bill Denney
Shai Ayal wrote:
>> And which M*lab version should our handle graphics package be compatible
>> with?
>> R11, R12, R13, R14? Mathworks has redesigned their handle graphics
>> package, from R13 to R14.
>>
>> Should we strive for R11 or R13 compatibility ?
>>    
> lets go for the version w/o the "group" objects.
>  
I would very much prefer to have the group objects (R14).  I personally
think that matlab's group objects are somewhat broken (I can't assign a
color to the group and have it propagate down to all sub-objects for
example), but I think that it is one of the best and most powerful
features of the new implementation.  It also allows for very good things
such as having a single handle for errorbar plots; in R13 and before,
two line handles were generated: one for the regular line and one for
the error bars, but in R14, there is just one handle, but you can still
get the granular control if you want by going to the children of the
error bar group.

Groups are the most helpful aspect of the handle graphics to me, and for
my purposes (most of my plots get turned into svg before going to eps
for final printout), groups make later editing significantly easier (I
can group together sets of lines and then modify them together in inkscape.

Bill

Reply | Threaded
Open this post in threaded view
|

Re: Minimal requirements from a handle graphics package

Bill Denney
Bill Denney wrote:

> Shai Ayal wrote:
>> lets go for the version w/o the "group" objects.  
> I would very much prefer to have the group objects (R14).  I
> personally think that matlab's group objects are somewhat broken (I
> can't assign a color to the group and have it propagate down to all
> sub-objects for example), but I think that it is one of the best and
> most powerful features of the new implementation.  It also allows for
> very good things such as having a single handle for errorbar plots; in
> R13 and before, two line handles were generated: one for the regular
> line and one for the error bars, but in R14, there is just one handle,
> but you can still get the granular control if you want by going to the
> children of the error bar group.
>
> Groups are the most helpful aspect of the handle graphics to me, and
> for my purposes (most of my plots get turned into svg before going to
> eps for final printout), groups make later editing significantly
> easier (I can group together sets of lines and then modify them
> together in inkscape.
Something just occurred to me:  I would guess that groups would be
mostly manageable outside of the handle visualization.  The only place
where I would envision a problem would be in the selection of objects in
the visualizer (i.e. it would be logical to me that if the user selects
an object in the visualizer the entire group associated with that object
should be selected).  Off the top of my head other than that case,
groups could be just made to exist within the structure of the handle.

I'm sure that I'm missing something (and please explain to me what I'm
missing), but again, I really would like groups to exist.

Bill

Reply | Threaded
Open this post in threaded view
|

Re: Minimal requirements from a handle graphics package

Shai Ayal-2
Bill,

I think you are right in that group objects are higher-level than the
primitive objects. They aid the user in manipulating groups of related
objects. As such they might be implemented in octave itself. I'm not
sure that they can be implemented generically, but each user can
implement them easily enough for his specific plot, since all plotting
commands return the handles of the objects they create.

In any case, the reason I didn't want group objects is that, at least
for me, Implementing the primitives is hard enough, so I wanted to aim
low. However aiming high in the spec is not such a bad thing.

Shai

On 2/20/06, Bill Denney <[hidden email]> wrote:

> Bill Denney wrote:
> > Shai Ayal wrote:
> >> lets go for the version w/o the "group" objects.
> > I would very much prefer to have the group objects (R14).  I
> > personally think that matlab's group objects are somewhat broken (I
> > can't assign a color to the group and have it propagate down to all
> > sub-objects for example), but I think that it is one of the best and
> > most powerful features of the new implementation.  It also allows for
> > very good things such as having a single handle for errorbar plots; in
> > R13 and before, two line handles were generated: one for the regular
> > line and one for the error bars, but in R14, there is just one handle,
> > but you can still get the granular control if you want by going to the
> > children of the error bar group.
> >
> > Groups are the most helpful aspect of the handle graphics to me, and
> > for my purposes (most of my plots get turned into svg before going to
> > eps for final printout), groups make later editing significantly
> > easier (I can group together sets of lines and then modify them
> > together in inkscape.
> Something just occurred to me:  I would guess that groups would be
> mostly manageable outside of the handle visualization.  The only place
> where I would envision a problem would be in the selection of objects in
> the visualizer (i.e. it would be logical to me that if the user selects
> an object in the visualizer the entire group associated with that object
> should be selected).  Off the top of my head other than that case,
> groups could be just made to exist within the structure of the handle.
>
> I'm sure that I'm missing something (and please explain to me what I'm
> missing), but again, I really would like groups to exist.
>
> Bill
>
>