Re: looking ahead to 3.6

[Michael Goffioul]

Additional comments:
1) The terminal emulation problem under Windows exists in *all*
toolkits, as there's no pty concept Windows. Whatever the choice,
you'll have to fake terminal through pipes under Windows. To achieve
that, I hacked VTE a lot. But this can be re-done for any other
toolkit.
2) Despite the terminal emulation problem, I'd still go that way in a
GUI, as this would provide the most consistent interface bewteen a
console version and a GUI (like having the same key bindings...). If
you want real hard-core developers ever to use a GUI, that's the right
choice to make. If you need better integration between readline and a
GUI, I think it would be possible to modify readline to add suitable
hooks.
<subjective>
3) I personally wouldn't favor java for performance issues. IMO Qt
provides the best development platform in term of cross-platform
support and look and feel. And I know that the only real drawback is
the lack of built-in terminal emulation widget. But this could be
worked around without too much effort. To say the least, I've been
disappointed by the reaction of GTK+ community to the OpenGL problem
under Windows and I felt like in a dead-end
</subjective>

Michael.


2011/2/13 John Swensen <address@hidden>:
>
> Even though I have done a bit of work on OctaveDE using GTK+, I am not 
> married to the toolkit.  In fact, while GTK+ works great for Linux and OSX, 
> there will still be hurdles for Windows (namely getting VTE to work properly 
> and the already stated OpenGL issues).  The biggest problem I see with QT is 
> that there isn't a terminal emulator widget (Konsole doesn't compile for 
> Windows and the variety of Konsole derivatives that are QT4-only also don't 
> compile on Windows).  AFAIK FLTK doesn't have a terminal emulator widget 
> either.
>
> Having said all this, I think there are a few options that seem reasonable:
> (1) Push forward with OctaveDE and solve any problems that arise on the 
> Windows platform
> (2) Make a decision to use QT4 and find/adapt/make a terminal emulator widget 
> (probably having to solve the same problems associated with Windows not 
> having PTYs that occur for GTK+ and VTE).
> (3) Pick a toolkit like Java (I am probably inviting a lot of flaming here) 
> to implement the IDE in.  In some sense, this seems like the most reasonable 
> solution to make sure we get all platforms.  The backend would be the same 
> for all platforms (with the OpenGL stuff handled in the Octave C++ code) and 
> the IDE would be supported on any platform that has a recent Java runtime.  
> There are toolkits on top of Java, like SWT from the Eclipse project, that 
> provide better UI elements than default Java Swing. I'm not sure if there is 
> a good terminal emulator widget for Java that works across all platforms (I'm 
> assuming there is as Eclipse has one).  There would need to be a small 
> Java<->C++ interface, probably similar in functionality to the octave_server 
> class I use in OctaveDE.
>
> I am not so far into OctaveDE that I would be opposed to switching to 
> whatever is deemed the "best" solution by the powers that be.  I just think 
> it is time that we start combining forces on an IDE and make sure that we do 
> it "right".  I'm not saying that throwing out readline and re-implementing 
> the command line, like QTOctave,  is wrong but it does cause a lot of extra 
> work for some functionalities that already seem there.  I'm not quite sure 
> what "right" is in light of the problems that are apparently posed mostly by 
> the Windows platform, but we should collectively decide what is "right" and 
> push forward.
>
> John Swensen
>
>
>