Octave GUI API: Proposal.

Hello!
Thanks for the reply. I read lots of old posts on the mailing list
for the GUI API, and dropped plans. Hope I can make a difference.

Scliab has a nice GUI too.
Its like this:
 f=figure() //creates a new window.
 h=uicontrol(figure,style,stylename,pos,[x y ht wt],prop1,value1,...)
 f.close() //kills them all!

I didnt read the source code. Mostly some kind of sockets must be involved I 
guess with commands, or some text protocol zipping around between the
client and server.

The help and sime design is really attractive, and atbest
I spent some 10-15 minutes looking and learning the code.
I wouldlove scilab inspired syntax for octave gui tools.

Here is my specification which Ive started working on.
Its not written in stone, to you can change the specs
on a clear rationale, or JWE's specs. But I will not wait
until then, and I'll try to update the stuff whatever I
make now.

Widgets will occupy the common namespace of octave_widget
in the library. Following X concepts, we will inherit all
the widgets/controls from the basic octave_widget type.

Like the octave_base_scalar which acts as a template for 
many other types like Complex, Matrix,and scalar itself,
we will also model the octave_widget type and use it.
We start using it from this octave_widget() method, a octave_widget
for uniformly holding common properties of the widgets, like color, location,
value, orientation, parent[?], name, callbacks list, event list
and similar properties.

octave_widget is used as the parent type for other widgets like 

octave_widget_listbox  
	lists of items for the user to choose.	
signal: change selection, double click selection
event:  changed, activate.

octave_widget_button
	simplest button widget for the user to esetup a callback to.	
signal: click
event: clicked

octave_widget_check
	option check/uncheck control.
signal: toggle
event: toggled

octave_widget_popupmenu
	widget_popup menu gives a context menu for widgets[textview etc],
	 or a stand alone menu on the figure()[main window toolbar].	
signal: click on a menu item.
event: activate.

octave_widget_radio
	mutex way of searching /selecting options.
signal: toggle
event: toggled

octave_widget_sliders
	widget sliders for indicating controls in the user progams, for values 
like
        some framework, for input of range limited values.
signal: slider dragged.
event: value_changed

octave_widget_statictext
	label widget to indicate data	
signal: nothing. get/set the label text.


octave_widget_toggle
	similar in functionality to a check box, but activates controls.
signal: toggle
event: toggled

octave_widget_textview
	a simple text control to load a file into it, and display it 
	on the run.
signal: press enter signal,press key
event: activate, changed

These are graphics tool widgets, act as plot surface for the commands.

Widget hierarchy's top levels, these need only just the window to draw the 
images,
on. somehow the tools that interface to GNU Octve have to be rewritten to adhere
to this new standard. No need to use socket based API, atleast send the widget 
pointer to the plugin for plot, and this plotting plugin will do all the stuff 
necessary.

We have to use the plot() function syntax and argument profile, for the widgets,
and extend them to have controls for 

	rotation,
	color scales,
	point labelling,
	legend,
	colormap,
	mouse cursor interaction.
Generally they must also support the currently used GNU Plot,  Octplot 
versions from the first even if it is in the making.

octave_widget_axes
		Incomplete specification
octave_widget_figures
		Incomplete specification
octave_widget_frames
		Incomplete specification



Each octave_widget type holds the signal name, and the callback handler 
function for that particular signal used.

We provide accessors to the various widgets like GTK callbacks
by passing the widget handle and the global data type structure to it
which has all the references to the various widgets in that frame.

Also scilab like findobj(obj_uniq_property,prop_val) to get the 
objects for use within callbacks can be used. But our syntax will
be cleaner with widget_get_name("nameofwidget") which will return the function
handle.

simple callback will be
%eg:
function v=ohmsaw(btn,events,globalhandler,userdata):
set(btn,"string","clicked me!")
i=str2num(get(current,"string"))
r=str2num(get(resistance,"string"))
set(voltage,"val",i*r)
v=i*r
endfunction

This is the draft.
It is derived from Scilab and lush(though lisp). As ESR puts it
I want to follow the principle of 'least' surprise in interface design.


Quoting Rafael Laboissiere <[email protected]>:
> I think it is high time to design a toolkit-independent GUI layer for
> integration in the core code of Octave.
Great! We might finally make the big leap!!

Cheers
Muthu.

Lets Hack Octave-Gtk.
http://octave-gtk.sourceforge.net

-------------------------------------------------
This mail sent through IMP(http://www.nitt.edu)