Re: Release plans for the GUI

[Michael Goffioul]

2011/9/5 Jordi Gutiérrez Hermoso <address@hidden>:
> == 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.