Release plans for the GUI

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Release plans for the GUI

Jordi Gutiérrez Hermoso-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Release plans for the GUI

John Swensen

On Sep 5, 2011, at 1:00 AM, Jordi Gutiérrez Hermoso wrote:

> == 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
Reply | Threaded
Open this post in threaded view
|

Re: Release plans for the GUI

Michael Goffioul
In reply to this post by Jordi Gutiérrez Hermoso-2
2011/9/5 Jordi Gutiérrez Hermoso <[hidden email]>:

> == 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.
Reply | Threaded
Open this post in threaded view
|

Re: Release plans for the GUI

Shai Ayal-2
In reply to this post by Jordi Gutiérrez Hermoso-2


2011/9/5 Jordi Gutiérrez Hermoso <[hidden email]>
== 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
Reply | Threaded
Open this post in threaded view
|

Re: Release plans for the GUI

Andriy Shinkarchuck
In reply to this post by Jordi Gutiérrez Hermoso-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Release plans for the GUI

Jordi Gutiérrez Hermoso-2
On 5 September 2011 17:38, Andriy Shinkarchuck <[hidden email]> wrote:

> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Release plans for the GUI

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

2011/9/9 Jordi Gutiérrez Hermoso <[hidden email]>:
>
> This is a long list. Should we make this a wiki page?
>
> - Jordi G. H.
>
Reply | Threaded
Open this post in threaded view
|

Re: Release plans for the GUI

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.

--
Software Development == Church Development
Step 1. Build it.
Step 2. Pray.

Whitespace - the most ink saving programming language: http://compsoc.dur.ac.uk/whitespace/index.php .

Reply | Threaded
Open this post in threaded view
|

Re: Release plans for the GUI

Michael Goffioul
On Fri, Sep 9, 2011 at 7:01 AM, Jacob Dawid <[hidden email]> wrote:
> Hello everybody,
> I just came back from the funeral of my grandfather, so I had no time to
> reply earlier.

Sorry about that.

> 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.

> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Release plans for the GUI

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?

2011/9/9 Michael Goffioul <[hidden email]>
On Fri, Sep 9, 2011 at 7:01 AM, Jacob Dawid <[hidden email]> wrote:
> Hello everybody,
> I just came back from the funeral of my grandfather, so I had no time to
> reply earlier.

Sorry about that.

> 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.

> 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.



--
Software Development == Church Development
Step 1. Build it.
Step 2. Pray.

Whitespace - the most ink saving programming language: http://compsoc.dur.ac.uk/whitespace/index.php .

Reply | Threaded
Open this post in threaded view
|

Re: Release plans for the GUI

Richard Crozier
In reply to this post by Andriy Shinkarchuck
 On 09/09/2011 01:28, Andriy Shinkarchuck wrote:
> Yes, it would be great thing. But there arent any comments or suggestions yet :(
>
> 2011/9/9 Jordi Gutiérrez Hermoso <[hidden email]>:
>> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Release plans for the GUI

John Swensen

On Sep 9, 2011, at 6:00 AM, Richard Crozier wrote:

> On 09/09/2011 01:28, Andriy Shinkarchuck wrote:
>> Yes, it would be great thing. But there arent any comments or suggestions yet :(
>>
>> 2011/9/9 Jordi Gutiérrez Hermoso <[hidden email]>:
>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Release plans for the GUI

jacob.dawid

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.

Whitespace - the most ink saving programming language: http://compsoc.dur.ac.uk/whitespace/index.php .
Reply | Threaded
Open this post in threaded view
|

Re: Release plans for the GUI

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. :-)

2011/9/9 Jacob Dawid <[hidden email]>

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.

Whitespace - the most ink saving programming language: http://compsoc.dur.ac.uk/whitespace/index.php .

Reply | Threaded
Open this post in threaded view
|

Re: Release plans for the GUI

Richard Crozier
On 09/09/2011 13:52, Júlio Hoffimann wrote:
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. :-)

2011/9/9 Jacob Dawid <[hidden email]>

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.

Whitespace - the most ink saving programming language: 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


  


The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
Reply | Threaded
Open this post in threaded view
|

Re: Release plans for the GUI

Jarno Rajahalme

On Sep 9, 2011, at 16:06 , ext Richard Crozier wrote:

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
Reply | Threaded
Open this post in threaded view
|

Re: Release plans for the GUI

John Swensen
In reply to this post by jacob.dawid

On Sep 9, 2011, at 7:01 AM, Jacob Dawid wrote:

>
> 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


Reply | Threaded
Open this post in threaded view
|

Re: Re: Release plans for the GUI

oz123
In reply to this post by Jordi Gutiérrez Hermoso-2
> Date: Fri, 9 Sep 2011 09:52:05 -0300
> From: J?lio Hoffimann <[hidden email]>
> To: Jacob Dawid <[hidden email]>
> Cc: Octave Maintainers List <[hidden email]>
> Subject: Re: Release plans for the GUI
> Message-ID:
>        <CAFRVdT-=[hidden email]>
> 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.
>
> 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. :-)
>


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
Reply | Threaded
Open this post in threaded view
|

Re: Re: Release plans for the GUI

Michael Creel



On Fri, Sep 9, 2011 at 3:42 PM, Oz Nahum Tiram <[hidden email]> wrote:
> Date: Fri, 9 Sep 2011 09:52:05 -0300
> From: J?lio Hoffimann <[hidden email]>
> To: Jacob Dawid <[hidden email]>
> Cc: Octave Maintainers List <[hidden email]>
> Subject: Re: Release plans for the GUI
> Message-ID:
>        <CAFRVdT-=[hidden email]>
> 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.
>
> 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. :-)
>


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.

Michael
Reply | Threaded
Open this post in threaded view
|

Re: Release plans for the GUI

John Swensen
In reply to this post by Michael Goffioul

On Sep 9, 2011, at 3:36 AM, Michael Goffioul wrote:

> On Fri, Sep 9, 2011 at 7:01 AM, Jacob Dawid <[hidden email]> wrote:
>> Hello everybody,
>> I just came back from the funeral of my grandfather, so I had no time to
>> reply earlier.
>
> Sorry about that.
>
>> 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.
>

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

123