Re: Proposal for a GUI extension to Octave

Driss,

It looks very nice -- I might consider using it as the communication
layer for octplot. However, does it works on cygwin? -- loadable
libraries work there but I'm not sure about IPC. Not working on cygwin
would be a big drawback as octave is now fully operational on windows
and this could break compatibility.

About toolkits -- I recommend fltk -- ti is very easy to learn and
very small. However, look in the mailing list archive for gtk binding
for octave

Licensing -- I'm no lawyer, but it seems to me that mimicking the
matlab API is OK -- but don't copy any code from them !

Shai


On Wed, 02 Mar 2005 10:14:44 +0100, Driss Ghaddab <[email protected]> wrote:
> Hi,
> 
> I'm planning to add a Matlab like GUI commands to Octave, using the
> infrastructure provided by the extension I just published days ago (CMO,
> http://driss.ghaddab.free.fr/cmo/).
> 
> To be brief, CMO is a framework that adds an event queue handling to
> Octave, provides an abstract class to easily develop modules using this
> event queue, and also an abstract class to easily develop objects (an
> object is an entity that has properties and methods and which are
> created by the module. The properties and methods are accessible from
> within Octave's interpreter using the dot syntax). As the objects are
> represented as a new octave type, they can be regarded as equivalent to
> handle graphics.
> 
> The new CMO module will be called OGM (for Octave GUI Module).
> 
> There will be an abstract layer that is independent from any graphical
> toolkit, and on top of it there will be a toolkit dependent layer.
> 
> I would like to hear what users expect from such a GUI.  I think, that
> Matlab compatibility is a must, but we may also improve it and add
> missing features (users feedback requested).
> 
> I have currently some questions:
> 
> 1. Widget toolkits: should the widget toolkit be selected at compile
> time or should it be made a runtime option? The runtime option will add
> to the user the burden of the choice, so I'm inclined to use the compile
> time approach.
> 
> 2. What enhancements should be added? What do users miss from Matlab's
> way of doing GUIs?
> 
> 3. Concerning an eventual GUI builder (like GUIDE): this will be
> postponed.  An idea would be to use available GUI builders (glade &
> similar builders) and use external scripts to create the relevant .m
> files.  As we use the Matlab syntax, a parallel project can already be
> started without waiting for OGM to finish.
> 
> 4. Does the implementation of such a GUI compatible with Matlab imply
> some licensing or IP problems? I'm using the Matlab documentation as
> seen on their site.
> 
> I do not plan to implement the plotting functions, I'll just try to
> adapt an existing one (octaviz, gnuplot, plplot come to mind. I'm not
> using a specific desktop (nor KDE, nor GNOME), so I do not plan to use
> desktop specific libraries).
> 
> Every comment is welcome,
> 
> Cheers
> 
> --
> Driss Ghaddab
> 
>