octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GUI design


From: Daniel J Sebald
Subject: Re: GUI design
Date: Wed, 28 Mar 2012 23:49:37 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 03/28/2012 05:37 AM, Richard Crozier wrote:
On 28/03/2012 11:06, Daniel J Sebald wrote:
On 03/28/2012 04:07 AM, Richard Crozier wrote:
On 28/03/2012 09:55, Daniel J Sebald wrote:



I think what Michael and I are saying is

Nothing =>  Lay groundwork for GUI/IDE code that can grow =>  Get the ball
rolling =>  When there are a reasonable amount of features on the order
of GUI Octave, release the inaugural version =>  Improvements


Isn't this what I proposed? I agree with Michael about the rearrangement
of windows by the way, but this already works according to Jacob. Maybe
I needed to say:

Nothing =>  GUI Octave feature set =>  GUI Octave feature set plus some of
The Mathworks feature set =>  Mathworks feature set =>   Improvements

As I understand it the devs are close to achieving the GUI Octave
feature set already, or have possibly exceeded them?

And the big part is laying the groundwork because the group needs to
decide on what GUI building utilities and technology to use across
platforms, so on.  I assume it is across platforms because 1) Robert
points out an IDE may be the only viable option under Windows, 2) John
states that Octave needs to still be functional in its current
form--implying the IDE would also be on unix-based systems.


I was under the impression this was decided, i.e. Qt, which is
cross-platform.

I know at least once John has stated "I wish I hadn't gone that route"
with regard to plotting.  The problem is that the GUI Octave direct
approach could be the same thing:

Nothing =>  GUI Octave =>  Dead end =>  Struggle to advance things for
years =>  Startover =>  Mathworks feature set =>  Improvements



I'm not sure I understand this, I meant to replicate the features of GUI
Octave in, say, Qt. Not the actual code implementation of GUI Octave
exactly. How would this result in a dead end? This would be extensible
to the new desired features later.

It sounds like developers have looked at the GUI development tools enough to conclude that Qt provides the power and flexibility for future growth of an IDE. Correct?


I am confused about what you are saying I think, I thought you wanted to
not produce a GUI with features the same as GUI Octave and hold off
until there were all the features you suggested implemented.

Not all, but something more substantial than what GUI Octave offers. Yes, that would be my preference, but...


 Whereas I
think it better to produce something with the minimum feature set of GUI
Octave, and add further features later, as a GUI with these features is
better than nothing in my opinion.

...it sounds like the majority want to get something out there that works in Windows.


And again, I point out that one doesn't have to copy the look and feel
of Mathworks or GUI Octave.  IF there are better ways of organizing and
presenting things, that would be welcome as I see it.



Sure, this is where I would see the 'Improvements' stage, but how
different can a GUI be to these examples? There's only so many ways to
organise an IDE. Most of the IDEs I have seen are very similar, e.g.
Visual Studio, QT Creator, Matlab, Eclipse, Code::Blocks etc. They're
all just collections of windows with stuff in them are they not?

Well, in the broad universal set of computer programs all those you described fall in the "collections of windows with stuff in them" category. But they all have their own features unique to what they do. Visual Studio is for programming. Mathworks' IDE has some programming elements--watch variables, step through a debugger, etc.--but it should have features with working with and processing data to truly. I listed a few things that would be nice but probably aren't in Matlab's IDE: the two monitor feature for example. There is this whole new dimension of "processing and working with data", i.e., extracting and conveying information which lends itself to new features.

It's certainly better to start out small and let the look and feel develop on its own. If one works toward GUI Octave look and feel then goes some other direction it will just confuse users.


I'm most interested in the debugging features, but others will have their
own priorities.

JWE speculated on the debugging feature. I'll respond to that in a separate email.

A lot of the work concerning an IDE at the start is just getting organized so that developers can move. Here are some thoughts:

Come up with a name for what will be Octave's IDE, and I think we agree now that it is IDE we're aiming for. This will make clear what is being discussed. Expressions like devs GUI is slightly obscure. If I'm not mistaken, Octave developers already have a start...something that was called QtOctave perhaps? But QtOctave isn't a good name because it implies Qt and who knows if down the road Qt doesn't work out or something better comes along. It's the look and feel and features that sort of define the IDE. I've suggested one name: IDEO -- marketing gimmick being "Your ideas + Octave = IDEO"

Maybe a Wiki is a good thing for organizing development. John gave a list of desired features for the first beta version. But that sort of thing gets lost in a discussion list. If a Wiki described the expected features, roadmap, time frame, so on, it might focus things a bit.

Will the cross platform IDE look exactly the same on all systems?

Will an IDE be in the same source tree as Octave? Or does it make sense to have an ancillary project? It might be best to not have Octave compilation dependent on the presence of a library needed for the IDE.

IDE development presents a challenge in the sense that it is difficult to convey GUI and feature ideas via written text in a discussion list. How often has someone tried describing something to you and it doesn't quite make sense, but then when one sees it on the screen or in action it's voila? Is there some way to assist a team of developers in that regard when working with Qt?

Dan


reply via email to

[Prev in Thread] Current Thread [Next in Thread]