Re: Proposal for GSoC. (address@hidden)

[John Chain]

Hi all,

Just share my 2 cents. 

First, I totally agree with Michael that a professional-like GUI is not trivial at all. I have seen several attempts of creating a GUI for Octave and other scientific packages but all of them ended half-way, no updates for years, obsolete like zombies. It is really a shame since not only the developers wasted their time with an amateur-like work, the end-user also wasted time to give them a try and uninstalled them quickly with a disappointed feeling. My point is: unless we have enough resources and a long term plan for maintenance, we shouldn't start a huge GUI project, otherwise the fate will be the same. GUI is not easy.

Second, my personal wish is that someone can make the plot functionality better. If we have to work on a GUI project, I hope it can be for the plot. As a Linux user, I really like command-line interface and try to avoid any GUI if I can. But once my plot pops up, I miss the Matlab-like GUI so much. It will be a smaller project but will be a great help for all Octave users, at least me.

Thanks,

JC

On Fri, Mar 23, 2012 at 3:27 PM, Michael Goffioul <address@hidden> wrote:

I had a quick look and it seems fine. However, I think the priorities should be the following (this is by definition subjective, so I don't expect everyone to agree with me; take this more as a suggestion):

1) Define the main GUI paradigm.

This is indeed first in your list. Ideally every subwindow should behave equally: you should be able to split them vertically or horizontally, you should be able to merge them into a tab widget, you should be able to pop them out. If you have the opportunity to try the Visual Studio interface, this is more or less what I mean (the docking system, not the whole environment).

It's not as simple as it sound, as this is different from the main Qt paradigm where you have a central widget with satellite dockable windows. I already tried to use a QMainWindow without any central widget, with only dockable windows. This was almost fine, except that once popped out, the window always stays on top of the main octave window, which is not always the desired behavior (for instance an editor window or a documentation browser window).

I looked for other solutions, but couldn't find any acceptable ones. You might need to implement your own widget to achieve that, but this not be a trivial task at all.

2) Enhance user experience in the editor / debugger

This is IMO on the key point in a GUI: providing a powerful editor/debugger tightly integrated with octave. From the editor point of view, this means for instance things like:

- smart auto-completion: not only based on a fixed set of keywords, but using the current content of the file being edited, functions in current octave path...

- ability to go to a function definition (in current file or in another m-file)

- ability to go to the documentation of currently highlighted function

From a debugger point of view, this can mean things like:

- step-into -> open file

- hovering over a variable -> pops up a tooltip with variable content (not only a static tooltip, but a widget allowing to traverse complex data structures, again Visual Studio has some good bits)

3) Documentation browser

Michael.

On Fri, Mar 23, 2012 at 5:08 PM, Atul Jangra (Google Docs) <address@hidden> wrote:

Attached: proposal

Message from address@hidden:

Hey Maintainers
This is my sample proposal for Google Summer of Code 2012. I have included only important things. Will update it with other simple details. 
Please review this proposal and suggest me some changes that I should include. I am applying for Octave GUI Project.

Google Docs makes it easy to create, store and share online documents, spreadsheets and presentations.