Re: Handle Graphics implementation in Octave.

[Paul Kienzle]

On Tue, Nov 11, 2003 at 11:56:22PM +0100, Ole Jacob Hagen wrote:
> > > But a user might want to send many parameters such as
> > > set(gca, 'PropertyName1', 'PropertyValue1',...
> > > 'PropertyName2', 'PropertyValue2',...
> > > 'PropertyName3', 'PropertyValue3');
> > >  which is allowed in Matlab. This is not a problem
> > > really, since we sent these as four messages. 
> > > 1.  send that gca are to be configured. 
> > > 2.  setValue('PropertyName1', 'PropertyValue1');
> > > 3.  setValue('PropertyName2', 'PropertyValue2')
> > > 4.  setValue('PropertyName3', 'PropertyValue3')
> > > 
> > > This will require four transmissions. 
> > > This will be a base for transport unit. 
> > 
> > You probably want a way of batching the ops so that
> > the screen updates happen altogether rather than
> > piecemeal.
> 
> I guess a user wouldn't notice this changes, if they 
> were executed sequentially, or?
> It's not much data to sent.  
> Of course we could always send absolutely all handle graphics data, 
> and not send the modified one. 
> This is not a very good solution, since transmission errors might occur, 
> and what a waste of bandwidth? 
> This will require some kernel memory usage, 
> to send all handle graphics objects every time. 

Hmmm... we seem to be talking past each other.

If I have a complicated visual representation
I want to create, including several different
graphs in a set of windows with a number of
different annotations associated with them, and
if I want to produce this graph from within my GUI
app in response to some user file selections,
I don't want to see one curve plotted, then  another
on top of it (with axis limits scaling automatically),
then have it shrink down because I want to put another
graph beside it, then have it shrink some more because
I add a title, then have it shrink some more because
I add an x-axis label, etc.  Instead I want to see
the whole operation happen as a single update.

The question is how.  Do you mark a start and end
of transaction?  Or do you hold all updates until
the input queue is empty and no more draw commands
have come in the last 200 milliseconds?  Or is
there some other way of batching the commands?
Maybe the second way is best, with an explicit
flush command to update the current graph.  

Also, when streaming data from some simulation,
you will want to update the graph periodically,
but not if the queue is getting too full, so
you need some way of detecting whether the
graph app is busy (possibly with a command on
the queue which is send("I'm not busy") back
to the app.

There are a lot of details like this that you need
to account for if you want to create apps that
are smooth and responsive.

> > 
> > Different visualisers have different capabilities.  You
> > need some way of testing whether a certain class of
> > features is supported.  The details get messy here.
> > For example, what if one app supports latex style
> > math, another supports mathml and a third supports
> > none of the above?  Do we standardize on one model
> > (e.g. latex since it is human readable) and require
> > the app to translate it as best they can?
> 
> Latex-style support.
> 
> I don't know if VTK supports latex-style fonts, but
> I  guess this could be fixed.
> I know that Coin3d doesn't support latex-styles.  
> 
> > Output is important.  Try to include the page model
> > in the design up front.
> ??? What's on your mind? A design of visualisation 
> frontend? With some features it should have?  

The printed representation of a graph does not match
the screen representation.  You need a way to compose
graphs on a page for printing so that they come out
nicely.  E.g., don't take the postscript representation
of your graph and stretch it to fit since the fonts
will look horrible and your square point markers will
turn into rectangles.  You need a way to preview the
graph so that the user knows what will come out.
Ideally, you need to be able to move the graphs around
on the print canvas.  And finally, since you are doing
this from an end user app, you need a way of storing
the configuration for that particular page layout so
that the next time the user prints that report she
doesn't have to rearrange the graphs again.

Or you can punt and tell the user that they should
use Origin or some such for all their publication
quality work, and just make it easy to export the
data in any format.  Niceties like selecting a line
causing the x,y,dy data which underlies it to be
entered into the clipboard so it is easy to paste
in another application for example.

> 
> Thinking some years from now on....
> 
> This question is raised number of times:
> When is a  GUI-frontend to Octave available? 

Whenever a community gets together to develop
and maintain one.  It's certainly not a priority
for me.

> Will it ever be made one, which is included
> into either sourceforge, or core?

octave-forge initially.

> This will require some rethinking of code, 
> and a choice of gui-API has to be made. 
> Is there anyone, who are developing on this? 

No, not in a sustained manner.  There are a couple
of attempts, but nothing to rally around.

My own efforts have been on developing an end-user
application.  I'm using Tcl/Tk because it is a
full-featured GUI building language with lots of
widgets.  It is really convenient for making simple
GUIs and has the features necessary to support
modular programming in the large.  I'm using
something called freewrap which allows me to bundle
all my Tcl/Tk scripts and dlls into a single
executable for easy deployment.  

What I haven't yet had the opportunity to do is
pop my head up and write the simple wrappers
for figure, plot, etc. which would make it
convenient for my users to explore their
data interactively in ways I haven't anticipated.  
That will come, but only after I've handled the 
needs of the majority of my users.

Personally, I don't see the value in reinventing
Tcl/Tk for Octave.  For one thing, you lose all the
community efforts going into the design and development
of new Tcl widgets.  For another, you then assume
the responsibility for keeping the toolkit up to
date and portable.  Yes, you can start with a
pre-existing widget set such as Qt or Gtk or wxWindows,
but then you are still responsible for keeping the
Octave mapping of these widgets in sync with the
underlying toolkit.  Finally, I doubt you will come
up with anything as convenient for GUI building
as Tcl/Tk.  The GUI code I've seen for Matlab
certainly isn't it.

That being said, it would be nice if stuff targeted
to matlab UI controls would just work, but I wouldn't
recommend writing anything new in that framework
without the addition of a gridded geometry manager.

> A visualiser should be integrated in gui-frontend, 
> but this will narrow down a possibilities of an user. 

No, John and I have both said that the GUI frontend
should be implemented using the tools provided by
the visualiser.  We differ slightly in that he would
prefer to map the entire GUI toolkit into Octave
commands while I prefer to keep the GUI toolkit in
its own language environment.

> 
> I am developing Oplot++ based on Coin3D and Qt, 
> while Nick is developing KVisualiser based on VTK and KDE.
> What if I and Nick agree on a making a gui-frontend 
> to Octave, using e.g Qt for portability.

The rules are simple: show me the code.  If you have something that works
you are welcome to add it to octave-forge.  It is a community project and
the community is us.

Personally, I would much prefer you implement it at a higher level, such as
in Octave, with a mapping from Octave to the underlying toolkit.  I would
recommend the mapping be logical rather than physical:  call a button a
button rather than a QtButton so when the next flavour of the month comes
around we can swap out the widget set without affecting our code.

> Free version of Qt runs on both Mac OS X, Windows and Linux. 
> Octave is still running in Windows using Cygwin?  

I would rather not have Octave depend on Cygwin, and even less
do I want it dependent on an X11 server.  I also don't want
it dependent on ghostview, but pdf would be okay.

> 
> And this GUI-frontend supports both Oplot++, 
> KVisualiser and Gnuplot for starters?
> Me and Nick is pretty much doing the same thing here. 
> This is completely waste of time, if you ask me. 

Agreed.  And I appreciate both of your efforts.  So
far I've been limping along by pasting image markers
on a graph, but soon I'm going to need to represent
structured grids, so a simple image won't work anymore.
Contours would be nice, too.

> Why: handle graphics offers also run-time creation 
> of widgets, so called uicontrol and uimenu. 
> This will require a good base of GUI-frontend, 
> using Qt, we can create run-time widgets, and 
> pushbuttons and so  on.
> And use Oplot and Kvisualiser as plugins to the 
> GUI-frontend, may be?

Yes, separate the plotting from UI so that you
have more control.  Be aware that your users are
going to want several graphs and other user interface
widgets shown on the same panel, with the ability
to interact with objects on the graph.

Paul Kienzle
address@hidden