Release plans for the GUI

[Jordi Gutiérrez Hermoso]

One of the biggest goals for the next stable release is to address
what is perhaps our most frequent feature request for Octave: a GUI.
Over the years there have been dozens of projects that have sprung up
to give Octave a GUI, and it seems clear that none will stick unless
that GUI is maintained in Octave's own tree. Jacob Dawid's initial
work on a Qt GUI has met a lot of interest, and quickly attracted
several developers (just today I got more people being redirected from
the abandoned QtOctave who are interested in helping with Jacob's
GUI), and I think it could work well.

It has a few problems that really need to be addressed before we can
make it part of a stable release:

1) Overall design.
2) Integration with Octave.
3) Building on Windows (sigh...).

Allow me to address each in turn.

== Design ==

Several people have expressed concern with how to decide on a design
for the GUI. It seems clear that exactly copying Matlab's GUI design
is not a good idea and we can do better. We need to have a healthy
discussion, perhaps slightly flamey [1], about how the GUI should
look. I wish to invite everyone to give their opinion here, and I hope
we can work towards an overall consensus.

Following Pascal Dupuis's retelling of the donkey fable [2], perhaps
the only thing we can agree on is that the GUI should have a high
degree of customisability. However, for issues where we can't
implement every option or we need a sensible default, I think we
should let one benevolent dictator have the final decision. The
natural candidates to make final decisions seem to be either jwe by
project seniority or Jacob since it was his code to begin with. I say
that if we agree to let either one make final decisions and everyone
else attempts to influence those decisions, we may soon move towards
consensus and a GUI design we can all be not too unhappy with (the
essence of compromise).

== Merging into Savannah ==

Although we've been working on a separate clone of the Octave repo in
Bitbucket [3], the goal has always been to work towards merging this
clone back into Savannah when we were confident of the quality of the
GUI. This is why I also opened a GUI category for bugs in Savannah,
because I didn't see this as a separate project, but one that should
be tied in wit Octave. The biggest concern here is integrating the
build system, which is completely different from Octave and has its
own set of problems, with Octave's own build system. I've started
looking into this, but I was unable to find help on how to test for
the presence of Qt with autotools (everyone seems to say to use CMake
instead), so I really need suggestions on how to do this. I'm happy to
attempt it again if someone can point the general path.

There is another issue regarding integration that I've discussed with
Jacob. At present the GUI is also a separate binary, which I think is
unnatural, but Jacob believes to be the best way. It's an internal
design choice, so, should the GUI stay as a separate binary? I think
we're going to be having more and more integration problems as we go
along if we keep them separate instead of trying to merge the
codebases together.

== Windows ==

I've brought up this issue before and Jacob seems to have begun to
tackle it, but it's still present. Jacob's original implementation of
a terminal used ptys which cannot easily be ported into Windows. As a
result, Jacob has started a new implementation of the terminal which
seemingly is minimally functional. However, we need confirmation that
this can be built on Windows. Jacob attempted it, but it appeared to
be a very difficult task, and he seems to have given up on this
attempt. It would be helpful if someone who builds on Windows can help
us build the GUI there too. Like the rest of Octave, we have a big
need for building and testing on Windows.

As I understand it, we have confirmed Mac OS X builds, so that's not
an immediate problem.

That's the overall situation as I see it. I really would like to see
everyone taking the GUI seriously. I know almost all people working on
Octave development, myself included, see little value in a GUI, but I
think this is one major step towards having more people taking Octave
seriously and not just a Matlab clone of mediocre quality for when you
can't afford to pay for a Matlab license. I think there's real
potential here to offer an immediate forward-facing improvement over
Matlab's own GUI without any real need to copy their interface and
make Octave shine on its own.

Opinions, please?

- Jordi G. H.

[1] ;-)
[2] http://octave.1599824.n4.nabble.com/displaying-structures-array-as-table-tp3778402p3779697.html
[3] https://bitbucket.org/jordigh/gnu-octave

[John Swensen]

Post by Jordi Gutiérrez Hermoso
== Windows ==
I've brought up this issue before and Jacob seems to have begun to
tackle it, but it's still present. Jacob's original implementation of
a terminal used ptys which cannot easily be ported into Windows. As a
result, Jacob has started a new implementation of the terminal which
seemingly is minimally functional. However, we need confirmation that
this can be built on Windows. Jacob attempted it, but it appeared to
be a very difficult task, and he seems to have given up on this
attempt. It would be helpful if someone who builds on Windows can help
us build the GUI there too. Like the rest of Octave, we have a big
need for building and testing on Windows.
As I understand it, we have confirmed Mac OS X builds, so that's not
an immediate problem.
That's the overall situation as I see it. I really would like to see
everyone taking the GUI seriously. I know almost all people working on
Octave development, myself included, see little value in a GUI, but I
think this is one major step towards having more people taking Octave
seriously and not just a Matlab clone of mediocre quality for when you
can't afford to pay for a Matlab license. I think there's real
potential here to offer an immediate forward-facing improvement over
Matlab's own GUI without any real need to copy their interface and
make Octave shine on its own.
Opinions, please?

Regardless of how the "terminal component" of the GUI is implemented, it should act identical to the GUI-less CLI. That was the one benefit of pty's on all the *NIX-y platforms. I understand this is problematic for Windows, but shouldn't this be something that can be abstracted away so the *NIX-y solution is to use an extract of the tried and true KDE/Konsole sources (which we get bugfixes for free from those communities) and the Windows solution be whatever is appropriate (using the Console2 solution that has been previously discussed)?

Windows is a separate beast from the *NIX-y platforms and should be treated as such. I don't think there needs to be a catch-all solution for all platforms for the tricky problem of terminal emulation. My only concern with trying to eliminate PTYs from the picture is that I think in the long run the code will eventually turn into a PTY implementation to handle all the current features of the Octave command line interface (e.g. I use CTRL-A, CTRL-K, etc, etc for editing from the command line).

I know I haven't had time to contribute much lately, but that doesn't mean I don't have an opinion ;)

John Swensen

[Michael Goffioul]

Post by Jordi Gutiérrez Hermoso
== Windows ==
I've brought up this issue before and Jacob seems to have begun to
tackle it, but it's still present. Jacob's original implementation of
a terminal used ptys which cannot easily be ported into Windows. As a
result, Jacob has started a new implementation of the terminal which
seemingly is minimally functional. However, we need confirmation that
this can be built on Windows. Jacob attempted it, but it appeared to
be a very difficult task, and he seems to have given up on this
attempt. It would be helpful if someone who builds on Windows can help
us build the GUI there too. Like the rest of Octave, we have a big
need for building and testing on Windows.
As I understand it, we have confirmed Mac OS X builds, so that's not
an immediate problem.
That's the overall situation as I see it. I really would like to see
everyone taking the GUI seriously. I know almost all people working on
Octave development, myself included, see little value in a GUI, but I
think this is one major step towards having more people taking Octave
seriously and not just a Matlab clone of mediocre quality for when you
can't afford to pay for a Matlab license. I think there's real
potential here to offer an immediate forward-facing improvement over
Matlab's own GUI without any real need to copy their interface and
make Octave shine on its own.
Opinions, please?

My opinion is basically similar to John's one:
1) don't try to re-invent the wheel
2) as far as terminal emulation is concerned, treat Windows differently

1) While re-writing a terminal emulation component for Qt can be an interesting
development project, I personally think this is a waste of time in the
context of
octave GUI. It has been proven that the Konsole terminal emulation can be used
outside of KDE (with some modifications) and iirc the Konsole developers were
willing (or at least not against the idea) to extract the PTY emulation into a
re-usable Qt-only library. You would automatically benefit from upstream
developments and optimization. I know that Jacob has objected this because of
performance concerns. But I've looked at the current code on bitbucket and the
terminal implementation there really looks like an embryonic rewrite of the
Konsole terminal component. In the end, when you'll have full VT100 emulation,
will it be that faster than the Konsole component? Is it worth the
effort? For instance
I run Konsole at 142 cols and 56 rows without any visible performance penalty.

2) I've already explained what are the options when coming to terminal emulation
under Windows, along with their problems. IMO the best solution would be to
extract the Console2 component and integrate it into Qt, something I've done a
few months ago. The main problem, when coming to Windows, is that a Win32
"PTY" works in a completely different way than in UNIX. If you look at Console2
implementation, you'll see that it works by having the actual command prompt
window hidden and mirroring every cell of the console into its own widget, with
some optimization in the middle to avoid refreshing cells that do not need to.
This is different under UNIX where all communications are taking place through
a single stream that controls the terminal cursor. The problem usually comes
from the fact that main implementation takes place under UNIX using a PTY
and then you try to "port" it to Windows, thinking there's probably something
equivalent to that cursor-controlling communication stream. And there's none.

Michael.

[Shai Ayal]

Post by Jordi Gutiérrez Hermoso
== Design ==
Several people have expressed concern with how to decide on a design
for the GUI. It seems clear that exactly copying Matlab's GUI design
is not a good idea and we can do better. We need to have a healthy
discussion, perhaps slightly flamey [1], about how the GUI should
look. I wish to invite everyone to give their opinion here, and I hope
we can work towards an overall consensus.
I think one of the most important properties of GUIs is that they should

conform to some known standard that the user is already familiar with. So,
in terms of look and feel, please try to be like some known GUI -- no need
to emulate matlab GUI, but at least make it one of the "big ones" --
windows, osx, gnome or kde. Inventing GUI design from scratch will lead to a
very frustrating user experience.

Shai

[Andriy Shinkarchuck]

Hi, Octave!

I help Jacob to test GUI and to search necessary features to implement.
It is really hard to develop GUI without clear plan now, so
i suggest to discuss here features for «Overall design» of GUI as
Jordi adviced above.

This will help Jacob and testers like me to focus on development of
GUI more flexible and convenient for every of you, not only for Jacob,
me, Torsten and other guys, that tested GUI already and sent their
reviews.

So, i divided gui on the sections and greatly apprecate for your
comments, advices, wishes — down to the smallest detail like even
order of menu items or buttons at the panel :)

1. Global
— main menu items, theirs order, grouping
— subwindow organizing (tabs only or subwindows only or mixed?),
default subwindows layout with subwindows to show and their positions
— status bar and messages in it (help only or some info too?)
— links to official resources (do we need all we currently have?)
— tips and tricks at the start?
— quick start (open editor at the start or switch to terminal by default?)
— some wizard at first launch? (to ask f.e. nick for IRC, select
settings scheme or smth else)
2. Editor
— navigation (go to line - inline or dialog?)
— search/replace (inline like vi or emacs or dialog? do you want
regexp handling?)
— bookmarks (toogle, navigate)
— line numbering
— comment/uncomment code
— indenting/autoindenting code
— autocompletition of functions and operators
— colorizing/color schemes (background, font, current line color...)
— shortcuts/shortcut schemes (KDE-like, GNOME-like, Windows-like, and so on)
— autosaving feature?
— highlight errors in editor feature?
— breakpoints (like in MATLAB®)?
— versioning of files feature?
3. Terminal
— terminal size (default, minimum, color scheme and so on)
— history length in terminal?
4. Documentation Browser
— open locally/from internet?
— single or multiply documentation tabs/subwindows?
5. IRC Client
— autoconnect at first launch or not?
— ask nick at first connect or if default username is set?
6. Settings Dialog
— show all avaliable settins or only the most important?
— dismiss buttin for discurd changes in setting?

Feel free to say «We dont need this feature» or «You havent said about
this feature» or «This should be done in such way...».
All this done to make GUI the best one for Octave ever been

P.S.: If you havent build GUI yet, here is the man
http://xhoch3.dyndns.org/index.php?page=build-gui

[Jordi Gutiérrez Hermoso]

Post by Andriy Shinkarchuck
So, i divided gui on the sections and greatly apprecate for your
comments, advices, wishes — down to the smallest detail like even
order of menu items or buttons at the panel :)
1. Global
— main menu items, theirs order, grouping
— subwindow organizing (tabs only or subwindows only or mixed?),
default subwindows layout with subwindows to show and their positions
— status bar and messages in it (help only or some info too?)
— links to official resources (do we need all we currently have?)
— tips and tricks at the start?
— quick start (open editor at the start or switch to terminal by default?)
— some wizard at first launch? (to ask f.e. nick for IRC, select
settings scheme or smth else)
2. Editor
— navigation (go to line - inline or dialog?)
— search/replace (inline like vi or emacs or dialog? do you want
regexp handling?)
— bookmarks (toogle, navigate)
— line numbering
— comment/uncomment code
— indenting/autoindenting code
— autocompletition of functions and operators
— colorizing/color schemes (background, font, current line color...)
— shortcuts/shortcut schemes (KDE-like, GNOME-like, Windows-like, and so on)
— autosaving feature?
— highlight errors in editor feature?
— breakpoints (like in MATLAB®)?
— versioning of files feature?
3. Terminal
— terminal size (default, minimum, color scheme and so on)
— history length in terminal?
4. Documentation Browser
— open locally/from internet?
— single or multiply documentation tabs/subwindows?
5. IRC Client
— autoconnect at first launch or not?
— ask nick at first connect or if default username is set?
6. Settings Dialog
— show all avaliable settins or only the most important?
— dismiss buttin for discurd changes in setting?

This is a long list. Should we make this a wiki page?

- Jordi G. H.

[Andriy Shinkarchuck]

Yes, it would be great thing. But there arent any comments or suggestions yet :(

Post by Jordi Gutiérrez Hermoso
This is a long list. Should we make this a wiki page?
- Jordi G. H.

[Jacob Dawid]

Hello everybody,

I just came back from the funeral of my grandfather, so I had no time to
reply earlier.

The biggest problem with the GUI is the terminal thing. The reason I threw
out Konsole is that it's drawing itself, which is not a performance issue
but it breaks the overall look and feel of the application and is quite
buggy when losing and gaining focus (sometimes it did not redraw, sometimes
it did). Also, the solution to use a terminal emulation is ugly and can only
be a temporary one. We just use it because we have no other option that
works left over at the moment.

So we have two goals, a short-term goal and a long-term goal.
Short-term: Make it work on all platforms with the terminal emulation,
treating Windows differently, as Michael already said. Probably we can't
come up with a Windows terminal emulation in case no one wants to contribute
here.

Long-term: Tweak octave so we can connect directly to it. We are already
starting octave in the same process (we call octave_main(..) in a separate
(software) thread), so we are sharing memory with octave. We don't need any
pipes and no platform-selective terminal emulation here.

I tried to compile the GUI on Windows, which is not a problem as far as
concerning the GUI. What failed was mingw that apparently did not find the
octave headers though they were at the location I specified them.

[Michael Goffioul]

Post by Jacob Dawid
Hello everybody,
I just came back from the funeral of my grandfather, so I had no time to
reply earlier.

Sorry about that.

Post by Jacob Dawid
The biggest problem with the GUI is the terminal thing. The reason I threw
out Konsole is that it's drawing itself, which is not a performance issue
but it breaks the overall look and feel of the application and is quite
buggy when losing and gaining focus (sometimes it did not redraw, sometimes
it did). Also, the solution to use a terminal emulation is ugly and can only
be a temporary one. We just use it because we have no other option that
works left over at the moment.

I disagree. IMO the reasons we (should) use a terminal emulation are:
1) it's an off-the-shelf component that we don't have to re-develop; and we
can easily benefit from upstream bug fixes and improvements
2) it provides exactly the same behavior, whether you start octave in
a terminal or withing a full blown GUI
So the choice of a terminal emulation is not because there's nothing else
we can use, it's intentional.

Post by Jacob Dawid
Long-term: Tweak octave so we can connect directly to it. We are already
starting octave in the same process (we call octave_main(..) in a separate
(software) thread), so we are sharing memory with octave. We don't need any
pipes and no platform-selective terminal emulation here.

I assume you're talking here about (re-)implementing a REPL system that
would integrate nicely with a GUI?

Michael.

[Jacob Dawid]

Michael,

I think disputing about personal preferences gets us nowhere. Are you able
you tweak the bitbucket source and implement a platform-dependent terminal
solution?

Post by Michael Goffioul

Post by Jacob Dawid
Hello everybody,
I just came back from the funeral of my grandfather, so I had no time to
reply earlier.

Sorry about that.

Post by Jacob Dawid
The biggest problem with the GUI is the terminal thing. The reason I

threw

Post by Jacob Dawid
out Konsole is that it's drawing itself, which is not a performance issue
but it breaks the overall look and feel of the application and is quite
buggy when losing and gaining focus (sometimes it did not redraw,

sometimes

Post by Jacob Dawid
it did). Also, the solution to use a terminal emulation is ugly and can

only

Post by Jacob Dawid
be a temporary one. We just use it because we have no other option that
works left over at the moment.

1) it's an off-the-shelf component that we don't have to re-develop; and we
can easily benefit from upstream bug fixes and improvements
2) it provides exactly the same behavior, whether you start octave in
a terminal or withing a full blown GUI
So the choice of a terminal emulation is not because there's nothing else
we can use, it's intentional.

Post by Jacob Dawid
Long-term: Tweak octave so we can connect directly to it. We are already
starting octave in the same process (we call octave_main(..) in a

separate

Post by Jacob Dawid
(software) thread), so we are sharing memory with octave. We don't need

any

Post by Jacob Dawid
pipes and no platform-selective terminal emulation here.

I assume you're talking here about (re-)implementing a REPL system that
would integrate nicely with a GUI?
Michael.

[John Swensen]

Post by Michael Goffioul

Post by Jacob Dawid
Hello everybody,
I just came back from the funeral of my grandfather, so I had no time to
reply earlier.

Sorry about that.

Post by Jacob Dawid
The biggest problem with the GUI is the terminal thing. The reason I threw
out Konsole is that it's drawing itself, which is not a performance issue
but it breaks the overall look and feel of the application and is quite
buggy when losing and gaining focus (sometimes it did not redraw, sometimes
it did). Also, the solution to use a terminal emulation is ugly and can only
be a temporary one. We just use it because we have no other option that
works left over at the moment.

1) it's an off-the-shelf component that we don't have to re-develop; and we
can easily benefit from upstream bug fixes and improvements
2) it provides exactly the same behavior, whether you start octave in
a terminal or withing a full blown GUI
So the choice of a terminal emulation is not because there's nothing else
we can use, it's intentional.

Also, I just took a quick look through the source code in the gnu-ocatve/gui/src/terminal directory and realized that somewhere along the line the KPty.h, KPty.cpp, KPtyDevice.h and KPtyDevice.cpp has been modified from the original Konsole sources to remove everything that made it platform independent for Linux, BSDs, OSX, Solaris, etc. Now it may only compile and work on Linux with glibc. It definitely doesn't compile for OSX and I would have to go back in and add in all the platform depending #define's that were already there to handle the different platforms.

My opinion based on past experience trying to implement an Octave GUI, which doesn't matter a whole lot since I haven't been contributing much lately, is that a lot of smart people have "solved" the console problem in a platform independent way (excluding Window for the time being). If Jacob wants to re-implement this to scratch the itch that is learning about how UNIX PTYs work and how the guts of terminal emulation works, then that is his prerogative. On the other hand, if the intent is to have something that works across a wide variety of platforms then the Konsole borrowing is definitely the way to go. In the long run, I think that if Jacob continues to go down the route of starting with a PTY and then implementing a simple text widget to interact with the PTY and adding features as he goes, he will eventually converge to a full terminal emulator.

John

[Richard Crozier]

Post by Andriy Shinkarchuck
Yes, it would be great thing. But there arent any comments or suggestions yet :(

Post by Jordi Gutiérrez Hermoso
This is a long list. Should we make this a wiki page?
- Jordi G. H.

Ok, I have a couple of suggestions of features that could be added to
the wish list.

The Matlab editor has a nice feature where when stopped at a breakpoint
in the editor you can hover the mouse over the variables in the file and
their contents are displayed in a context-menu like display. I find this
quite useful when debugging as I generally have the editor full screen
in a separate window from the main GUI in my setup so I can see more code.

You can also navigate up and down the stack from a drop down list and
the appropriate file is opened or switched to in the editor and the
mouse hovering thing continues to function etc.

Richard

[John Swensen]

Post by Richard Crozier

Post by Andriy Shinkarchuck
Yes, it would be great thing. But there arent any comments or suggestions yet :(

Post by Jordi Gutiérrez Hermoso
This is a long list. Should we make this a wiki page?
- Jordi G. H.

Ok, I have a couple of suggestions of features that could be added to
the wish list.
The Matlab editor has a nice feature where when stopped at a breakpoint
in the editor you can hover the mouse over the variables in the file and
their contents are displayed in a context-menu like display. I find this
quite useful when debugging as I generally have the editor full screen
in a separate window from the main GUI in my setup so I can see more code.
You can also navigate up and down the stack from a drop down list and
the appropriate file is opened or switched to in the editor and the
mouse hovering thing continues to function etc.
Richard
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

If you go back and look at my original sources for the octave server in the OctaveDe project (which Jacob improved a lot, but also cut out a big chunk of functionality), there was functionality for requesting individuals variables and their contents and manipulating/interacting with debugging information.
http://octavede.svn.sourceforge.net/viewvc/octavede/branches/OctaveDE_QT/src/server.cpp?revision=91&view=markup

I'm sure this can be added back into the newest incarnation of the class that communicated with Octave quite easily, I just don't think anyone has done it yet.

John Swensen

[Jacob Dawid]

Post by John Swensen
If you go back and look at my original sources for the octave server in the
OctaveDe project (which Jacob improved a lot, but also cut out a big chunk
of functionality), there was functionality for requesting individuals
variables and their contents and manipulating/interacting with debugging
information.
http://octavede.svn.sourceforge.net/viewvc/octavede/branches/OctaveDE_QT/src/server.cpp?revision=91&view=markup
I'm sure this can be added back into the newest incarnation of the class
that communicated with Octave quite easily, I just don't think anyone has
done it yet.
John Swensen

This is possible and will definately happen.

I don't agree with what Michael says, but I am not disputing over personal
preferences. If he is able to offer a working terminal solution on both
Windows and Linux in whatever way he does it, I am with him, though I have
spent lots of time going a different direction. For now I have halted
development on the terminal integration to await his answer.

[Júlio Hoffimann]

Hi all,

I would like to share my modest opinion on Octave GUI development. It's
amazing to have an official GUI, we hope this way Octave can reach more
people, particularly undergraduate courses.

What i think:

1) 90% Octave users are Linux users. (please correct me if i'm wrong)
2) Canonical made easy for every student to have a GNU/Linux operating
system installed and working in dual boot.
3) Octave works on Windows, a GUI is not strictly necessary.

1+2+3 => To implement a feature in a way is not good just to reach other
platforms is not a good paradigm, if there aren't experienced Windows
developers working in Octave, we can't waste time by making this to work
ourselves. It's so much easy for a end-user to install Ubuntu in dual boot
and download Octave GUI from repositories than make it to work well on
Windows.

If people is caring about a GUI, they can install Linux. If not, they just
still running their scripts on the console. Seems radical, maybe it is, it's
just my pragmatic(superficial) vision on the project.

Regards,
Júlio.

P.S.: Jacob is nice to see you again. :-)

Post by Jacob Dawid

Post by John Swensen
If you go back and look at my original sources for the octave server in
the OctaveDe project (which Jacob improved a lot, but also cut out a big
chunk of functionality), there was functionality for requesting individuals
variables and their contents and manipulating/interacting with debugging
information.
http://octavede.svn.sourceforge.net/viewvc/octavede/branches/OctaveDE_QT/src/server.cpp?revision=91&view=markup
I'm sure this can be added back into the newest incarnation of the class
that communicated with Octave quite easily, I just don't think anyone has
done it yet.
John Swensen

This is possible and will definately happen.
I don't agree with what Michael says, but I am not disputing over personal
preferences. If he is able to offer a working terminal solution on both
Windows and Linux in whatever way he does it, I am with him, though I have
spent lots of time going a different direction. For now I have halted
development on the terminal integration to await his answer.
--
*Software Development == Church Development*
Step 1. Build it.
Step 2. Pray.
http://compsoc.dur.ac.uk/whitespace/index.php .

[Richard Crozier]

Post by Júlio Hoffimann
Hi all,
I would like to share my modest opinion on Octave GUI development.
It's amazing to have an official GUI, we hope this way Octave can
reach more people, particularly undergraduate courses.
1) 90% Octave users are Linux users. (please correct me if i'm wrong)
2) Canonical made easy for every student to have a GNU/Linux operating
system installed and working in dual boot.
3) Octave works on Windows, a GUI is not strictly necessary.
1+2+3 => To implement a feature in a way is not good just to reach
other platforms is not a good paradigm, if there aren't experienced
Windows developers working in Octave, we can't waste time by making
this to work ourselves. It's so much easy for a end-user to install
Ubuntu in dual boot and download Octave GUI from repositories than
make it to work well on Windows.
If people is caring about a GUI, they can install Linux. If not, they
just still running their scripts on the console. Seems radical, maybe
it is, it's just my pragmatic(superficial) vision on the project.
Regards,
Júlio.
P.S.: Jacob is nice to see you again. :-)
If you go back and look at my original sources for the octave
server in the OctaveDe project (which Jacob improved a lot,
but also cut out a big chunk of functionality), there was
functionality for requesting individuals variables and their
contents and manipulating/interacting with debugging information.
http://octavede.svn.sourceforge.net/viewvc/octavede/branches/OctaveDE_QT/src/server.cpp?revision=91&view=markup
<http://octavede.svn.sourceforge.net/viewvc/octavede/branches/OctaveDE_QT/src/server.cpp?revision=91&view=markup>
I'm sure this can be added back into the newest incarnation of
the class that communicated with Octave quite easily, I just
don't think anyone has done it yet.
John Swensen
This is possible and will definately happen.
I don't agree with what Michael says, but I am not disputing over
personal preferences. If he is able to offer a working terminal
solution on both Windows and Linux in whatever way he does it, I
am with him, though I have spent lots of time going a different
direction. For now I have halted development on the terminal
integration to await his answer.
--
*Software Development == Church Development*
Step 1. Build it.
Step 2. Pray.
http://compsoc.dur.ac.uk/whitespace/index.php .

I'm not sure about this, the windows binary has been downloaded over 1.2
million times in the last two years according to sourceforge.

On the other hand, having found that Octave compiles fine using
VirtualBox to run Ubuntu in windows, there are several options for
windows users, including dual booting.

Richard

[Jarno Rajahalme]

I'm not sure about this, the windows binary has been downloaded over 1.2 million times in the last two years according to sourceforge.
On the other hand, having found that Octave compiles fine using VirtualBox to run Ubuntu in windows, there are several options for windows users, including dual booting.

Make a VirtualBox "appliance" with ready-to-use Octave set-up? Make it login w/o password and start Octave at logon. User's just download the VM image and boot it in VirtualBox and use Octave?

Jarno

[John Swensen]

Post by John Swensen
If you go back and look at my original sources for the octave server in the OctaveDe project (which Jacob improved a lot, but also cut out a big chunk of functionality), there was functionality for requesting individuals variables and their contents and manipulating/interacting with debugging information.
http://octavede.svn.sourceforge.net/viewvc/octavede/branches/OctaveDE_QT/src/server.cpp?revision=91&view=markup
I'm sure this can be added back into the newest incarnation of the class that communicated with Octave quite easily, I just don't think anyone has done it yet.
John Swensen
This is possible and will definately happen.
I don't agree with what Michael says, but I am not disputing over personal preferences. If he is able to offer a working terminal solution on both Windows and Linux in whatever way he does it, I am with him, though I have spent lots of time going a different direction. For now I have halted development on the terminal integration to await his answer.

I guess I don't quite get how you disagree with Michael. Is it:
1) you don't think we should use the Konsole sources as unmodified as possible for the Linux/OSX solution?
2) you don't think we should have a different solution for terminal emulation on Windows and Linux?
3) both (1) and (2)?
4) Something altogether different?

I know it would take a little bit of time, but can you write up a paragraph or two about your proposed/current solution for the terminal emulation problem for the UNIX-y and Windows platforms so we have a better idea of what you are planning? I think at this point some of our discussion may be misunderstanding the proposed solutions, rather than a difference in philosophy.

John Swensen

[Michael Goffioul]

Post by Jacob Dawid
I don't agree with what Michael says, but I am not disputing over personal
preferences. If he is able to offer a working terminal solution on both
Windows and Linux in whatever way he does it, I am with him, though I have
spent lots of time going a different direction. For now I have halted
development on the terminal integration to await his answer.

Well, to be honest I'm not willing to waste my (very limited) spare time in
integrating a terminal emulation for Windows, knowing that you'll throw it
away in a few months time, as it appears what your long-term solution is
(cf. one of your previous post).

If people want an immediate solution for Windows, it's already available:
- scrap Windows and use Linux instead
OR
- use a virtual machine to run Linux within Windows
OR
- use a cygwin-based version of octave

Michael.

[Jacob Dawid]

Post by John Swensen
Also, I just took a quick look through the source code in the
gnu-ocatve/gui/src/terminal directory and realized that somewhere along the
line the KPty.h, KPty.cpp, KPtyDevice.h and KPtyDevice.cpp has been modified
from the original Konsole sources to remove everything that made it platform
independent for Linux, BSDs, OSX, Solaris, etc. Now it may only compile and
work on Linux with glibc. It definitely doesn't compile for OSX and I would
have to go back in and add in all the platform depending #define's that were
already there to handle the different platforms.

John, this was very stupid of me, I don't know much about about OSX. I will
revert that, since it breaks compatiblity to OSX without any reason.

[John Swensen]

Post by John Swensen
Also, I just took a quick look through the source code in the gnu-ocatve/gui/src/terminal directory and realized that somewhere along the line the KPty.h, KPty.cpp, KPtyDevice.h and KPtyDevice.cpp has been modified from the original Konsole sources to remove everything that made it platform independent for Linux, BSDs, OSX, Solaris, etc. Now it may only compile and work on Linux with glibc. It definitely doesn't compile for OSX and I would have to go back in and add in all the platform depending #define's that were already there to handle the different platforms.
John, this was very stupid of me, I don't know much about about OSX. I will revert that, since it breaks compatiblity to OSX without any reason.

The KPtyDevice .h and .cpp have the same problem.

John

[Jacob Dawid]

Post by John Swensen
The KPtyDevice .h and .cpp have the same problem.
John

Okay, should be fixed now.

Michael, sounds as if we could put the discussion whether to use a terminal
emulation or not aside then. Contrary to what I expected, it seems that
there is not much demand for Windows anyways. Although Windows has by far
the biggest share on the market for consumer or low-end work applications
(like games or office), I suspect it's a little different for professional,
scientific applications. I admit I feel pedantic to say that, but also
developing and aiming actively for a proprietary operating is exactly what
free software - including GNU Octave - should not be about when there are
free operating systems available. I think I have reached out my hand as much
as I could towards you, even offering to prioritize Windows compatibility
over other goals (in a kind way, I got admonished for that behaviour already
by other people on the mailing list). If you do not invest your spare time
to develop for Windows it will simply mean there will be no native Octave
GUI for Windows for quite a while.

[Chipmuenk]

All,

I really don't know where the impression is coming from that there is no
need or no market for scientific applications under Windows. In the
electronic design automation (EDA) world e.g. there has been a strong shift
towards Windows over the last 10 years.

Looking at the laptops of my students (electronic engineering, Germany), I
usually see Windows or MacOS with Linux being the exception. Most of my
students also seem to prefer a cracked Matlab license over an Octave
installation. Don't get me wrong, I'm not encouraging that behaviour, it's
just an observation.

I'm often told that one of the reasons that Matlab is being preferred over
Octave is the lack of a proper GUI - there might be a hen & egg problem
here. There also have been a multitude of attempts to create Windows GUIs
over the last decade, showing there _is_ a Windows user community for
Octave.

Having said that, I perfectly understand the Octave developers who are not
too keen on supporting a commercial operating system that they are
unfamiliar with, that requires kludges to get things going and that is not
Open Source, giving potential licensing problems. And I also understand
there are only a few people in this project who are familiar with Windows.

Still, it makes me angry to read things like "windows users are dummies who
can't tell pi and a pie apart" (my exaggeration, no offense meant against
you, Jacob) or "if they want Octave, let them switch to Linux" - I, for one,
can't (at work) and won't (at home) do that. In my case, _all_ the
scientific software I need is available for Windows (Labview, Xilinx ISE,
Actel Libero, Matlab, LTSpice, Cadence and Mentor EDA, ...), usually the
performance (stability, graphics, printing, ...) under *nix is worse or the
software isn't available at all.

I'm happily paying some money for the luxury to have an operating systems
that installs and runs with no pain and supports all my hardware. In spite
of having worked with Solaris for more than 10 years, my last 3 attempts
over the years to get a Linux distribution running all miserably failed due
to hardware issues. I like to work under *nix (when everything's working)
and I like to work under Windows; I think there is no need for the
"holier-than-thou" attitude of some people when it comes to *nix.

Maybe the Cygwin way should promoted a bit more - for Windows-only users the
idea may be a bit intimidating to install a Unix environment first, although
(in my experience) this is fairly unproblematic.

Best regards and lots of kudos to all programmers who work hard to make
Octave even better,

Christian

--
View this message in context: http://octave.1599824.n4.nabble.com/Release-plans-for-the-GUI-tp3790414p3807386.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.

[Michael D Godfrey]

Post by Chipmuenk
I really don't know where the impression is coming from that there is no
need or no market for scientific applications under Windows. In the
electronic design automation (EDA) world e.g. there has been a strong shift
towards Windows over the last 10 years.
Looking at the laptops of my students (electronic engineering, Germany), I
usually see Windows or MacOS with Linux being the exception. Most of my
students also seem to prefer a cracked Matlab license over an Octave
installation. Don't get me wrong, I'm not encouraging that behaviour, it's
just an observation.

The second paragraph above does not confirm the first. It appears that
different Universities have different experiences. Here at Stanford
nearly all student and staff laptops are Macs. The desktop systems
are either Macs or Linux. What I see in industrial EDA around here is
a shift away from Windows to Linux.

This is, of course, just one observation.

Michael

[Richard Crozier]

Post by Chipmuenk
All,
I really don't know where the impression is coming from that there is no
need or no market for scientific applications under Windows. In the
electronic design automation (EDA) world e.g. there has been a strong shift
towards Windows over the last 10 years.
Looking at the laptops of my students (electronic engineering, Germany), I
usually see Windows or MacOS with Linux being the exception. Most of my
students also seem to prefer a cracked Matlab license over an Octave
installation. Don't get me wrong, I'm not encouraging that behaviour, it's
just an observation.
I'm often told that one of the reasons that Matlab is being preferred over
Octave is the lack of a proper GUI - there might be a hen & egg problem
here. There also have been a multitude of attempts to create Windows GUIs
over the last decade, showing there _is_ a Windows user community for
Octave.
Having said that, I perfectly understand the Octave developers who are not
too keen on supporting a commercial operating system that they are
unfamiliar with, that requires kludges to get things going and that is not
Open Source, giving potential licensing problems. And I also understand
there are only a few people in this project who are familiar with Windows.
Still, it makes me angry to read things like "windows users are dummies who
can't tell pi and a pie apart" (my exaggeration, no offense meant against
you, Jacob) or "if they want Octave, let them switch to Linux" - I, for one,
can't (at work) and won't (at home) do that. In my case, _all_ the
scientific software I need is available for Windows (Labview, Xilinx ISE,
Actel Libero, Matlab, LTSpice, Cadence and Mentor EDA, ...), usually the
performance (stability, graphics, printing, ...) under *nix is worse or the
software isn't available at all.
I'm happily paying some money for the luxury to have an operating systems
that installs and runs with no pain and supports all my hardware. In spite
of having worked with Solaris for more than 10 years, my last 3 attempts
over the years to get a Linux distribution running all miserably failed due
to hardware issues. I like to work under *nix (when everything's working)
and I like to work under Windows; I think there is no need for the
"holier-than-thou" attitude of some people when it comes to *nix.
Maybe the Cygwin way should promoted a bit more - for Windows-only users the
idea may be a bit intimidating to install a Unix environment first, although
(in my experience) this is fairly unproblematic.
Best regards and lots of kudos to all programmers who work hard to make
Octave even better,
Christian
--
View this message in context: http://octave.1599824.n4.nabble.com/Release-plans-for-the-GUI-tp3790414p3807386.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.

I tried going down the Cygwin route, I installed it and found that xterm
wouldn't even work, I just gave up as I didn't even know where to look
for a solution. I would promote Linux in VirtualBox over Cygwin any day.

[John Swensen]

Post by Richard Crozier

Post by Chipmuenk
All,
I really don't know where the impression is coming from that there is no
need or no market for scientific applications under Windows. In the
electronic design automation (EDA) world e.g. there has been a strong shift
towards Windows over the last 10 years.
Looking at the laptops of my students (electronic engineering, Germany), I
usually see Windows or MacOS with Linux being the exception. Most of my
students also seem to prefer a cracked Matlab license over an Octave
installation. Don't get me wrong, I'm not encouraging that behaviour, it's
just an observation.
I'm often told that one of the reasons that Matlab is being preferred over
Octave is the lack of a proper GUI - there might be a hen & egg problem
here. There also have been a multitude of attempts to create Windows GUIs
over the last decade, showing there _is_ a Windows user community for
Octave.
Having said that, I perfectly understand the Octave developers who are not
too keen on supporting a commercial operating system that they are
unfamiliar with, that requires kludges to get things going and that is not
Open Source, giving potential licensing problems. And I also understand
there are only a few people in this project who are familiar with Windows.
Still, it makes me angry to read things like "windows users are dummies who
can't tell pi and a pie apart" (my exaggeration, no offense meant against
you, Jacob) or "if they want Octave, let them switch to Linux" - I, for one,
can't (at work) and won't (at home) do that. In my case, _all_ the
scientific software I need is available for Windows (Labview, Xilinx ISE,
Actel Libero, Matlab, LTSpice, Cadence and Mentor EDA, ...), usually the
performance (stability, graphics, printing, ...) under *nix is worse or the
software isn't available at all.
I'm happily paying some money for the luxury to have an operating systems
that installs and runs with no pain and supports all my hardware. In spite
of having worked with Solaris for more than 10 years, my last 3 attempts
over the years to get a Linux distribution running all miserably failed due
to hardware issues. I like to work under *nix (when everything's working)
and I like to work under Windows; I think there is no need for the
"holier-than-thou" attitude of some people when it comes to *nix.
Maybe the Cygwin way should promoted a bit more - for Windows-only users the
idea may be a bit intimidating to install a Unix environment first, although
(in my experience) this is fairly unproblematic.
Best regards and lots of kudos to all programmers who work hard to make
Octave even better,
Christian
--
View this message in context: http://octave.1599824.n4.nabble.com/Release-plans-for-the-GUI-tp3790414p3807386.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.

I tried going down the Cygwin route, I installed it and found that xterm
wouldn't even work, I just gave up as I didn't even know where to look
for a solution. I would promote Linux in VirtualBox over Cygwin any day.

I like virtual machines, but they are very far from a native experience. On my work laptop (OSX with Core2Duo and 4GB of RAM) I can't get "zippy" performance of both VirtualMachine and host OSX, especially if I am running a minimal set of host OS programs (browser and email). Running a single virtual machine on our behemoth 16 core desktop machine with 16GB of RAM doesn't suffer at all. I can imagine that telling someone with a non-performance machine to "just run VirtualBox" can be prohibitive.

John Swensen

[Richard Crozier]

Post by John Swensen

Post by Richard Crozier

Post by Chipmuenk
All,
I really don't know where the impression is coming from that there is no
need or no market for scientific applications under Windows. In the
electronic design automation (EDA) world e.g. there has been a strong shift
towards Windows over the last 10 years.
Looking at the laptops of my students (electronic engineering, Germany), I
usually see Windows or MacOS with Linux being the exception. Most of my
students also seem to prefer a cracked Matlab license over an Octave
installation. Don't get me wrong, I'm not encouraging that behaviour, it's
just an observation.
I'm often told that one of the reasons that Matlab is being preferred over
Octave is the lack of a proper GUI - there might be a hen & egg problem
here. There also have been a multitude of attempts to create Windows GUIs
over the last decade, showing there _is_ a Windows user community for
Octave.
Having said that, I perfectly understand the Octave developers who are not
too keen on supporting a commercial operating system that they are
unfamiliar with, that requires kludges to get things going and that is not
Open Source, giving potential licensing problems. And I also understand
there are only a few people in this project who are familiar with Windows.
Still, it makes me angry to read things like "windows users are dummies who
can't tell pi and a pie apart" (my exaggeration, no offense meant against
you, Jacob) or "if they want Octave, let them switch to Linux" - I, for one,
can't (at work) and won't (at home) do that. In my case, _all_ the
scientific software I need is available for Windows (Labview, Xilinx ISE,
Actel Libero, Matlab, LTSpice, Cadence and Mentor EDA, ...), usually the
performance (stability, graphics, printing, ...) under *nix is worse or the
software isn't available at all.
I'm happily paying some money for the luxury to have an operating systems
that installs and runs with no pain and supports all my hardware. In spite
of having worked with Solaris for more than 10 years, my last 3 attempts
over the years to get a Linux distribution running all miserably failed due
to hardware issues. I like to work under *nix (when everything's working)
and I like to work under Windows; I think there is no need for the
"holier-than-thou" attitude of some people when it comes to *nix.
Maybe the Cygwin way should promoted a bit more - for Windows-only users the
idea may be a bit intimidating to install a Unix environment first, although
(in my experience) this is fairly unproblematic.
Best regards and lots of kudos to all programmers who work hard to make
Octave even better,
Christian
--
View this message in context: http://octave.1599824.n4.nabble.com/Release-plans-for-the-GUI-tp3790414p3807386.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.

I tried going down the Cygwin route, I installed it and found that xterm
wouldn't even work, I just gave up as I didn't even know where to look
for a solution. I would promote Linux in VirtualBox over Cygwin any day.

I like virtual machines, but they are very far from a native experience. On my work laptop (OSX with Core2Duo and 4GB of RAM) I can't get "zippy" performance of both VirtualMachine and host OSX, especially if I am running a minimal set of host OS programs (browser and email). Running a single virtual machine on our behemoth 16 core desktop machine with 16GB of RAM doesn't suffer at all. I can imagine that telling someone with a non-performance machine to "just run VirtualBox" can be prohibitive.
John Swensen

Agreed, my problem was that Cygwin didn't work at all, there's no 3.4.1
binary for windows, I'm insufficiently skilled to create such a binary,
and dual booting is too inconvenient.

[Marco atzeri]

Post by Richard Crozier
I tried going down the Cygwin route, I installed it and found that xterm
wouldn't even work, I just gave up as I didn't even know where to look
for a solution. I would promote Linux in VirtualBox over Cygwin any day.

xterm is fine on cygwin, I do not see major complaints
on cygwin mailing lists.

Plotting from Octave is suffering a bug on cygwin-1.7.9 ,
current snapshots are fine so next cygwin-1.7.10 should
solve the issue.

Marco

[Richard Crozier]

Post by Marco atzeri

Post by Richard Crozier
I tried going down the Cygwin route, I installed it and found that xterm
wouldn't even work, I just gave up as I didn't even know where to look
for a solution. I would promote Linux in VirtualBox over Cygwin any day.

xterm is fine on cygwin, I do not see major complaints
on cygwin mailing lists.
Plotting from Octave is suffering a bug on cygwin-1.7.9 ,
current snapshots are fine so next cygwin-1.7.10 should
solve the issue.
Marco

Ahh, I remember now, you're right, it was the plot function that was the
problem, although you get a message about being unable to launch xterm
or something like this.

I just thought that if I can't even plot a graph, what's the point in
continuing, who knows what else doesn't work?

[Jussi Lehtola]

On Mon, 12 Sep 2011 17:48:28 +0100

Post by Richard Crozier
Ahh, I remember now, you're right, it was the plot function that was
the problem, although you get a message about being unable to launch
xterm or something like this.
I just thought that if I can't even plot a graph, what's the point in
continuing, who knows what else doesn't work?

IIRC you have to run things from the Cygwin xterm in order for X stuff
to work.

If you just use the normal terminal emulator (or run things
through the Windows command prompt) then GUI stuff doesn't work.

[Marco atzeri]

Post by Richard Crozier

Post by Marco atzeri

Post by Richard Crozier
I tried going down the Cygwin route, I installed it and found that xterm
wouldn't even work, I just gave up as I didn't even know where to look
for a solution. I would promote Linux in VirtualBox over Cygwin any day.

xterm is fine on cygwin, I do not see major complaints
on cygwin mailing lists.
Plotting from Octave is suffering a bug on cygwin-1.7.9 ,
current snapshots are fine so next cygwin-1.7.10 should
solve the issue.
Marco

Ahh, I remember now, you're right, it was the plot function that was the
problem, although you get a message about being unable to launch xterm
or something like this.
I just thought that if I can't even plot a graph, what's the point in
continuing, who knows what else doesn't work?

Hi Richard,
almost everything is working on 3.4.2-1

Summary:

PASS 7022
FAIL 9

and the failure are just NaN vs Inf discrepancy
on complex number representation.

The plot issue is not a octave bug and I suggest
to run octave from a cygwin snapshot

http://cygwin.com/ml/cygwin-announce/2011-08/msg00003.html

Regards
MArco

[Shai Ayal]

Post by Richard Crozier

Post by Chipmuenk
All,
I really don't know where the impression is coming from that there is no
need or no market for scientific applications under Windows. In the
electronic design automation (EDA) world e.g. there has been a strong shift
towards Windows over the last 10 years.
Looking at the laptops of my students (electronic engineering, Germany), I
usually see Windows or MacOS with Linux being the exception. Most of my
students also seem to prefer a cracked Matlab license over an Octave
installation. Don't get me wrong, I'm not encouraging that behaviour, it's
just an observation.
I'm often told that one of the reasons that Matlab is being preferred over
Octave is the lack of a proper GUI - there might be a hen & egg problem
here. There also have been a multitude of attempts to create Windows GUIs
over the last decade, showing there _is_ a Windows user community for
Octave.
Having said that, I perfectly understand the Octave developers who are not
too keen on supporting a commercial operating system that they are
unfamiliar with, that requires kludges to get things going and that is not
Open Source, giving potential licensing problems. And I also understand
there are only a few people in this project who are familiar with Windows.
Still, it makes me angry to read things like "windows users are dummies who
can't tell pi and a pie apart" (my exaggeration, no offense meant against
you, Jacob) or "if they want Octave, let them switch to Linux" - I, for one,
can't (at work) and won't (at home) do that. In my case, _all_ the
scientific software I need is available for Windows (Labview, Xilinx ISE,
Actel Libero, Matlab, LTSpice, Cadence and Mentor EDA, ...), usually the
performance (stability, graphics, printing, ...) under *nix is worse or the
software isn't available at all.
I'm happily paying some money for the luxury to have an operating systems
that installs and runs with no pain and supports all my hardware. In spite
of having worked with Solaris for more than 10 years, my last 3 attempts
over the years to get a Linux distribution running all miserably failed due
to hardware issues. I like to work under *nix (when everything's working)
and I like to work under Windows; I think there is no need for the
"holier-than-thou" attitude of some people when it comes to *nix.
Maybe the Cygwin way should promoted a bit more - for Windows-only users the
idea may be a bit intimidating to install a Unix environment first, although
(in my experience) this is fairly unproblematic.
Best regards and lots of kudos to all programmers who work hard to make
Octave even better,
Christian
--

http://octave.1599824.n4.nabble.com/Release-plans-for-the-GUI-tp3790414p3807386.html

Post by Richard Crozier

Post by Chipmuenk
Sent from the Octave - Maintainers mailing list archive at Nabble.com.

I tried going down the Cygwin route, I installed it and found that xterm
wouldn't even work, I just gave up as I didn't even know where to look
for a solution. I would promote Linux in VirtualBox over Cygwin any day.

Maybe you can try coLinux - it's halfway between virtual and cygwin. Faster
and more linux compatible than cygwin, but not a completely separate machine
like a virtual. colinux runs native elf binaries, so you can even use your
favourite distro, precompiled.
Shai

Post by Richard Crozier

Post by Chipmuenk
All,
I really don't know where the impression is coming from that there is no
need or no market for scientific applications under Windows. In the
electronic design automation (EDA) world e.g. there has been a strong shift
towards Windows over the last 10 years.
Looking at the laptops of my students (electronic engineering, Germany), I
usually see Windows or MacOS with Linux being the exception. Most of my
students also seem to prefer a cracked Matlab license over an Octave
installation. Don't get me wrong, I'm not encouraging that behaviour, it's
just an observation.
I'm often told that one of the reasons that Matlab is being preferred over
Octave is the lack of a proper GUI - there might be a hen & egg problem
here. There also have been a multitude of attempts to create Windows GUIs
over the last decade, showing there _is_ a Windows user community for
Octave.
Having said that, I perfectly understand the Octave developers who are not
too keen on supporting a commercial operating system that they are
unfamiliar with, that requires kludges to get things going and that is not
Open Source, giving potential licensing problems. And I also understand
there are only a few people in this project who are familiar with Windows.
Still, it makes me angry to read things like "windows users are dummies who
can't tell pi and a pie apart" (my exaggeration, no offense meant against
you, Jacob) or "if they want Octave, let them switch to Linux" - I, for one,
can't (at work) and won't (at home) do that. In my case, _all_ the
scientific software I need is available for Windows (Labview, Xilinx ISE,
Actel Libero, Matlab, LTSpice, Cadence and Mentor EDA, ...), usually the
performance (stability, graphics, printing, ...) under *nix is worse or the
software isn't available at all.
I'm happily paying some money for the luxury to have an operating systems
that installs and runs with no pain and supports all my hardware. In spite
of having worked with Solaris for more than 10 years, my last 3 attempts
over the years to get a Linux distribution running all miserably failed due
to hardware issues. I like to work under *nix (when everything's working)
and I like to work under Windows; I think there is no need for the
"holier-than-thou" attitude of some people when it comes to *nix.
Maybe the Cygwin way should promoted a bit more - for Windows-only users the
idea may be a bit intimidating to install a Unix environment first, although
(in my experience) this is fairly unproblematic.
Best regards and lots of kudos to all programmers who work hard to make
Octave even better,
Christian
--

http://octave.1599824.n4.nabble.com/Release-plans-for-the-GUI-tp3790414p3807386.html

Post by Richard Crozier

Post by Chipmuenk
Sent from the Octave - Maintainers mailing list archive at Nabble.com.

I tried going down the Cygwin route, I installed it and found that xterm
wouldn't even work, I just gave up as I didn't even know where to look
for a solution. I would promote Linux in VirtualBox over Cygwin any day.
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

[Jacob Dawid]

Marco, the name of the GUI is not Quint anymore, it's just called Octave
GUI. For quite a while I have set up nightly builds and a detailed
description of what you need and how to build Octave GUI here:

http://xhoch3.dyndns.org/

[Marco atzeri]

Post by Jacob Dawid
Marco, the name of the GUI is not Quint anymore, it's just called Octave
GUI. For quite a while I have set up nightly builds and a detailed
http://xhoch3.dyndns.org/

Hi Jacob,
I was aware of
https://bitbucket.org/jordigh/gnu-octave

It is worth to add the tutorial on the

GNU Octave / gui / README

About requirement, libqscintilla2-devel is a potential problem, as it is
not yet on cygwin but only cygwin-ports.

If Yaakov will succeded to move it on cygwin as planned, following the
deployment of gcc-4.5 I will give it a try.

Regards
Marco

[Marco atzeri]

Post by Chipmuenk
All,
Maybe the Cygwin way should promoted a bit more - for Windows-only users the
idea may be a bit intimidating to install a Unix environment first, although
(in my experience) this is fairly unproblematic.

I have not yet tested Quint on cygwin.

I will appreciate a clear list of requirments for building quint,
possibly on the README, before spending time on guessing wich
QT4 elements are needed

Post by Chipmuenk
Christian

Marco
octave cygwin package maintainer

[Oz Nahum Tiram]

Date: Fri, 9 Sep 2011 09:52:05 -0300
Subject: Re: Release plans for the GUI
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
I would like to share my modest opinion on Octave GUI development. It's
amazing to have an official GUI, we hope this way Octave can reach more
people, particularly undergraduate courses.
1) 90% Octave users are Linux users. (please correct me if i'm wrong)
2) Canonical made easy for every student to have a GNU/Linux operating
system installed and working in dual boot.
3) Octave works on Windows, a GUI is not strictly necessary.
1+2+3 => To implement a feature in a way is not good just to reach other
platforms is not a good paradigm, if there aren't experienced Windows
developers working in Octave, we can't waste time by making this to work
ourselves. It's so much easy for a end-user to install Ubuntu in dual boot
and download Octave GUI from repositories than make it to work well on
Windows.
If people is caring about a GUI, they can install Linux. If not, they just
still running their scripts on the console. Seems radical, maybe it is, it's
just my pragmatic(superficial) vision on the project.
Regards,
J?lio.
P.S.: Jacob is nice to see you again. :-)

Hi Everyone,
Although I am not an active developer, I do use octave heavily, and I'd like to
get more involved. That is why I read the list daily...

Anyway, I think Julio said what I wanted to say, but didn't dare to.

I feel that Octave has no so much resources to waste on porting to a
non-*NIX like OS.

I'd like to see a GUI, and I'd like to see more features, BEFORE I'd
like to see a windows
port ...

And I think that this is important to make alternative application
which is GOOD, before it
is Cross Platform. After all many people stick to Windows because
there is "no alternative"
for some applications (in their minds ...).
There are many Mathematical Software packages for windows, and not so
many FOSS and
for Linux ... Make octave better, and people will find the way to use
it. Most modern (5 years>)
can easily run a Virtual Machine or a Live CD.

About 3 years ago, I wrote to JWE about my desire to build a live CD
demonstarting Octave.
If needed, I am suggesting again myself to help build a live CD with
octave, which could be easily
downloaded from the Octave website.

Cheers,

Oz

[Michael Creel]

Post by Oz Nahum Tiram

Date: Fri, 9 Sep 2011 09:52:05 -0300
Subject: Re: Release plans for the GUI
<CAFRVdT-=
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
I would like to share my modest opinion on Octave GUI development. It's
amazing to have an official GUI, we hope this way Octave can reach more
people, particularly undergraduate courses.
1) 90% Octave users are Linux users. (please correct me if i'm wrong)
2) Canonical made easy for every student to have a GNU/Linux operating
system installed and working in dual boot.
3) Octave works on Windows, a GUI is not strictly necessary.
1+2+3 => To implement a feature in a way is not good just to reach other
platforms is not a good paradigm, if there aren't experienced Windows
developers working in Octave, we can't waste time by making this to work
ourselves. It's so much easy for a end-user to install Ubuntu in dual

boot

and download Octave GUI from repositories than make it to work well on
Windows.
If people is caring about a GUI, they can install Linux. If not, they

just

still running their scripts on the console. Seems radical, maybe it is,

it's

just my pragmatic(superficial) vision on the project.
Regards,
J?lio.
P.S.: Jacob is nice to see you again. :-)

Hi Everyone,
Although I am not an active developer, I do use octave heavily, and I'd like to
get more involved. That is why I read the list daily...
Anyway, I think Julio said what I wanted to say, but didn't dare to.
I feel that Octave has no so much resources to waste on porting to a
non-*NIX like OS.
I'd like to see a GUI, and I'd like to see more features, BEFORE I'd
like to see a windows
port ...
And I think that this is important to make alternative application
which is GOOD, before it
is Cross Platform. After all many people stick to Windows because
there is "no alternative"
for some applications (in their minds ...).
There are many Mathematical Software packages for windows, and not so
many FOSS and
for Linux ... Make octave better, and people will find the way to use
it. Most modern (5 years>)
can easily run a Virtual Machine or a Live CD.
About 3 years ago, I wrote to JWE about my desire to build a live CD
demonstarting Octave.
If needed, I am suggesting again myself to help build a live CD with
octave, which could be easily
downloaded from the Octave website.
Cheers,
Oz

PelicanHPC is a live CD/USB image that has Octave installed. In fact, a lot
of the example programs for MPI-based parallel computing and also
econometric modeling use Octave. I use it for research and teaching. For
students who run Windows, I have them boot it up with Virtualbox. This works
pretty well.
http://pareto.uab.es/mcreel/PelicanHPC/

Michael

[tilas]

Hi,

I'd like to provide a user perspective which seems to be missing here.

Post by Jordi Gutiérrez Hermoso
One of the biggest goals for the next stable release is to address
what is perhaps our most frequent feature request for Octave: a GUI.

Many thanks. Just keep in mind that since Octave/Matlab is also a language -
the more appropriate term (with all the consequences) is IDE, not GUI.

Post by Jordi Gutiérrez Hermoso
It seems clear that exactly copying Matlab's GUI design
is not a good idea and we can do better.

Well, Matlab's IDE is actually very good. Doing better is cool, but at least
as good will be enough. At least for the first time.

Post by Jordi Gutiérrez Hermoso
the only thing we can agree on is that the GUI should have a high
degree of customisability.

Keep it simple. You can always improve later. For the IDE to be useful IMHO
it must contain at least three panels:
1. Editor
2. Command window
3. Workspace

My personal preference is a five panels layout
Center Up: Editor
Center Down: Command window
Side: Workspace
another side: current dir and/or command history

Remember that screen estate is usually not an issue and the editor window
that contains 80-90 columns is absolutely enough.

Of all the blows and whistles, to be useful, only the integration of the
debugger is really important for the first release. The rest can be
gradually added later.

Post by Jordi Gutiérrez Hermoso
== Windows ==
I've brought up this issue before and Jacob seems to have begun to
tackle it, but it's still present. Jacob's original implementation of
a terminal used ptys which cannot easily be ported into Windows. As a
result, Jacob has started a new implementation of the terminal which
seemingly is minimally functional. However, we need confirmation that
this can be built on Windows. Jacob attempted it, but it appeared to
be a very difficult task, and he seems to have given up on this
attempt. It would be helpful if someone who builds on Windows can help
us build the GUI there too. Like the rest of Octave, we have a big
need for building and testing on Windows.

I am not a programmer, so can't help much on this one, except to point to
the GUIoctave (http://guioctave.com/) - it's a native Windows app written
with MFC (according to the author). It works with octave 3.2.4 - Have a
look. Maybe you can contact the author.
Concerning the terminal in windows - see the command line interface
http://en.wikipedia.org/wiki/Comparison_of_Windows_and_Linux here
Perhaps the following can be of some help:
1. A .NET-based command line environment called Windows PowerShell
2. MS's own Services for Unix provides a bash terminal for Windows.
3. Posix subsystem is built in but not enabled by default.
Sorry if I'm completely off.

Post by Jordi Gutiérrez Hermoso
I know almost all people working on
Octave development, myself included, see little value in a GUI, but I
think this is one major step towards having more people taking Octave
seriously and not just a Matlab clone of mediocre quality for when you
can't afford to pay for a Matlab license.

To see a value - stop thinking about it like a developer, think like a user.
Users need an IDE ("most frequent feature request"). BTW, I do not think
anyone sees Octave as "just a Matlab clone of mediocre quality". Though it
is a Matlab clone and it is nice to have when you can't afford to pay for a
Matlab license.

Post by Jordi Gutiérrez Hermoso
1) 90% Octave users are Linux users. (please correct me if i'm wrong)
2) Canonical made easy for every student to have a GNU/Linux operating
system installed and working in dual boot.
3) Octave works on Windows, a GUI is not strictly necessary.

1) maybe. but that's because of the lack of an IDE.
2) not always possible. Especially in companies/corporations with
all-windows pcs. Even if one can get an open source SW to be blessed and
installed by the IT department - it must be 100% windows compatible.
3) you quite contradict yourself: "It's amazing to have an official GUI, we
hope this way Octave can reach more people" unless you don't count windows
users as people...

Now in general to all the unix(ego)centered "scrap Windows and use Linux
instead " etc.
1. grow up and change your attitude. The fact that you can do something does
not mean everybody else can or must do it.
2. consider this simple fact of life: between 80%-90% of all desktops are
windows vs about 1%-5% linux (see the estimated desktop usage share
http://en.wikipedia.org/wiki/Comparison_of_Windows_and_Linux here ).
It means - if you are really concerned with getting a bigger user base - you
*must target the windows platform* as part of your strategy.


Best wishes,
Victor

--
View this message in context: http://octave.1599824.n4.nabble.com/Release-plans-for-the-GUI-tp3790414p3853711.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.

[Michael D Godfrey]

Post by tilas
Hi,
I'd like to provide a user perspective which seems to be missing here.

Well, actually, your view was missing. Other users have other
views.

Speaking as a user, in my environment, many Matlab users set by default
-nodesktop. The Matlab GUI uses so much time and space that it
is often not helpful. I just do not have the time to wait for it to come up
on the screen.

It appears that the Octave GUI is attempting to meet a fairly wide range
of preferences.

In any case, it seems reasonable to get something done and see how
various users like it. It is not possible to make everyone feel that their
particular preferences have been given priority over everyone else.

Michael

[Levente Torok]

Hi Guys,

I dont like the matlab GUI either for the very same reasons.
However, it helps a lot for newbies. Which is a great plus and I
believe we need to be very much aware that
power users begin their life with a product as a newbie.

Instead, if I can push the focus of this discussion toward something,
I would prefer the comparision of the community of octave and R.
I guess the attitude of the two communities are much more alike than
octave and maltab communities.
I would be very happy if someone can give a good analysis on the
reasons why R became so popular versus octave which existes well
before R
it was always free unlike matlab, SAS or SPSS. So why and how did they
took over us?

Lev

On Thu, Sep 29, 2011 at 4:09 AM, Michael D Godfrey

Post by tilas
Hi,
I'd like to provide a user perspective which seems to be missing here.
Well, actually, your view was missing.  Other users have other
views.
Speaking as a user, in my environment,  many Matlab users set by default
 -nodesktop.  The Matlab GUI uses so much time and space that it
is often not helpful.  I just do not have the time to wait for it to come up
on the screen.
It appears that the Octave GUI is attempting to meet  a fairly wide range
of preferences.
In any case, it seems reasonable to get something done and see how
various users like it.  It is not possible to make everyone feel that their
particular preferences have been given priority over everyone else.
Michael

[tilas]

Post by Michael D Godfrey
Well, actually, your view was missing. Other users have other
views.

Partially true. Indeed I expressed my personal opinion. However this list is
a developer's list and the opinions I (subjectively) see here seem to miss
the more general user perspective.

Post by Michael D Godfrey
many Matlab users set by default -nodesktop.

does not mean all Matlab users and not all the time. For a development I
prefer to work within an IDE. For 'production' runs I also sometimes set
-nodesktop. The fact that GUI is the "most frequent feature request" means
the majority of users need it. You can't argue with stats.
As for the start times - well, it's Java. Since the development here seems
to be based on Qt - it should be naturally faster.

Post by Michael D Godfrey
It appears that the Octave GUI is attempting to meet a fairly wide range
of preferences.

This is good in general, but I'll stick to my guns - start simple. The first
release should be functional and usable. Not necessarily perfect or 'better
than Matlab'.
For me (and here I again express strictly personal view) it seems the
time-till-first-release is most important. It will show that this project is
serious and not just academic discussion on what features should or should
not be in a GUI.
That said, I do understand that "functional and usable" is a wide and
arguable definition.

Post by Michael D Godfrey
It is not possible to make everyone feel that their
particular preferences have been given priority over everyone else.

No and I do not ask it for myself. If you got this impression - sorry, this
was not my intention.
What I am trying to convey is following:
A. discussion of whether the users need a GUI is counter productive. It is a
waste of everybody's time given the fact that the GUI is the most frequent
feature request, at least according to the first poster.
B. I do understand that Windows OS is very different and poses challenges,
but cutting it off because some people just do not like it - sounds
childish/not serious/stuck up? and definitely counter productive given the
waste numbers of WinOS users.
C. Instead of aiming too high for all the feature that 'must' be in such an
IDE, the devs should get a clear picture of what is the bare acceptable
minimum for the first release.
Since the latter one is again a matter of personal views, I propose that
everyone who cares, list here his/her personal minimal set of features.
Developers then will decide on the final set.

The 'three-panels' setup (Editor, Command window and Workspace viewer) is my
personal visual minimum. Whether the panels should seat in a one central
window - is indeed a matter of personal preferences, but I believe that
making the panels dockable is not a big problem from the implementation
point of view.

To summarize (my personal minimum for the 1st release):

A resizable main window which is basically the command window with menus

dockable: Editor, Workspace viewer, Command history

optional dockable: Current dir

non-dockable: doc/manual, graphics/plot window(s)

Editor features:
'evaluate selection' (Matlab's F9)
integrated debugger (break points, step, step in, step out...)

Everything else I'll consider as a bonus.

@Devs: please someone set a reasonable time limit for this phase. Entries
that'll appear afterwards should be considered for the next release.

Victor

--
View this message in context: http://octave.1599824.n4.nabble.com/Release-plans-for-the-GUI-tp3790414p3855266.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.

[Richard Crozier]

Post by tilas
Keep it simple. You can always improve later. For the IDE to be useful IMHO
1. Editor
2. Command window
3. Workspace
My personal preference is a five panels layout
Center Up: Editor
Center Down: Command window
Side: Workspace
another side: current dir and/or command history
Remember that screen estate is usually not an issue and the editor window
that contains 80-90 columns is absolutely enough.

Well, I personally always use the editor popped out in a separate window
and think screen space is at a premium, as I like to see as much code in
one go, but there you go.

I do not necessarily expect this functionality in the first iteration of
the GUI. I believe customisability in this way and others should be a
goal though.

[Levente Torok]

Post by Richard Crozier

Post by tilas
Keep it simple. You can always improve later. For the IDE to be useful IMHO
1. Editor
2. Command window
3. Workspace
My personal preference is a five panels layout
Center Up: Editor
Center Down: Command window
Side: Workspace
another side: current dir and/or command history
Remember that screen estate is usually not an issue and the editor window
that contains 80-90 columns is absolutely enough.

Well, I personally always use the editor popped out in a separate window
and think screen space is at a premium, as I like to see as much code in
one go, but there you go.
I do not necessarily expect this functionality in the first iteration of
the GUI. I believe customisability in this way and others should be a
goal though.

What do you think of having panels like this?
Loading Image...


Lev

[Mark Everitt]

In my opinion only one thing really needs to be addressed, and that's
interactive plotting. The bare-bones gnuplot window offers rotations and
little else right now, and that's a huge obstacle to the people I work with,
who use Matlab to plot data more often than any numerical tasks. Think
laboratory data, plotting of functions worked out on paper. These
individuals even enjoy playing and interacting with their data, and placing
labels etc. This is the number one reason that my peers give when I
suggest using Octave and it locks me into Matlab too.

Everything else is little more than gloss. Remembering back to when I
was first trying Octave as a student I had similar frustrations. I had no
problems using a separate terminal and text editor, and I didn't really
missed the variable inspector panel. As I write this I'm using gedit with a
terminal plugin which performs very well, is /nimble/, and doesn't
take up a lot of extra space like dockable environments usually do,
especially on Linux.

My personal wish list is the following in order of preference:

1) Better plot plot tools integrated in the plotting window. Labels, axis
editing etc. Buttons.
2) Live syntax checking. This is a very useful feature in recent releases of
Matlab.
3) Variable inspector panel.

At the risk of getting flamed, I'm going to go as far as suggesting
ditching a grand unified GUI because much of it will be reinventing the
wheel. Enhance the plotting, maybe add the inspector panel using a
lightweight toolkit, and leave the rest 'til later. I know that this
contradicts
point two. ;)

Mark

Loading Image...

--
View this message in context: http://octave.1599824.n4.nabble.com/Release-plans-for-the-GUI-tp3790414p3855978.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.

[Steph Bredenhann]

Post by Mark Everitt
In my opinion only one thing really needs to be addressed, and that's
interactive plotting. The bare-bones gnuplot window offers rotations and
little else right now, and that's a huge obstacle to the people I work with,
who use Matlab to plot data more often than any numerical tasks. Think
laboratory data, plotting of functions worked out on paper. These
individuals even enjoy playing and interacting with their data, and placing
labels etc. This is the number one reason that my peers give when I
suggest using Octave and it locks me into Matlab too.

I wouldn't go as far as saying "only one thing", but enhanced graphics
would go a long way to make Octave perfect.

And this big argument about Windows vs Linux is totally counter productive!

As an after thought, I've installed QtOctave again on my Ubuntu 11.04
64bit as a new update is available. It works very well, so in the mean
time I am using it again, although I continuously find myself in the
command mode again.

*/Steph Bredenhann/*

[Mark Everitt]

I've been avoiding that debate too, but here I go...

This really depends on what the goal is. If the goal is to win over a lot of
users, then we need to address Windows. In fact the tools are so good on
Linux already that, barring my plot rant above, perhaps we should focus
attention exclusively on Windows. Linux users, and to a certain extent Mac
users, are comfortable using a command line and editors that aren't joined
at the hip.

I'm not sure about bundling all this together though. Having Octave as it is
is very nice. It has dependencies, but these aren't too difficult to work
with. Keeping the GUI separate makes it an option, and I think that many
current users will be happy to do without it, at least for a while. For
Windows, this could be thrown together as a single application, in keeping
with the platform.

How about a well documented API and a simple referece GUI that uses it? In
the short term this could be used as the "official" GUI, and in the long
term we may see people code platform specific GUIs of their own accord. I
think this is the Python approach and it's working out well for them!

Mark

--
View this message in context: http://octave.1599824.n4.nabble.com/Release-plans-for-the-GUI-tp3790414p3858107.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.

[jozuko]

Hi all,

I don't really understand the problematic of creating the gui for Octave,
but in my opinion a great inspiration can be taken form the RStudio project
(http://rstudio.org/). The RStudio is a gui front-end for the R-language and
it contains an interacting editor (code completion, F1 key = jump to a help
window, etc.), *command window*, workspace etc. The project seems to be very
mature and it is also available for different platforms including Windows.

Jozuko

--
View this message in context: http://octave.1599824.n4.nabble.com/Release-plans-for-the-GUI-tp3790414p4087327.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.