octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: looking ahead to 3.6


From: Richard Campbell
Subject: Re: looking ahead to 3.6
Date: Sun, 13 Feb 2011 13:19:39 -0500

On Feb 13, 2011, at 1:12 PM, John Swensen wrote:

> 
> On Feb 13, 2011, at 9:49 AM, Jordi Gutiérrez Hermoso wrote:
> 
>> 
>> Ok, more seriously, I'm really glad that you've looked favourably upon
>> a GUI. I am a little concerned that GTK+ won't be the best option,
>> though, even if OctaveDE is just about the only one doing the right
>> thing. I think of projects like TortoiseHg (which by the way is an
>> awesome graphical frontend to hg, y'all should try it) which started
>> with GTK+, started experiencing cross-platform difficulties, and
>> switched to Qt. It seems to me that Qt provides the best
>> cross-platform graphical experience, but then again, OctaveDE's
>> developer seems to be a heavy Mac OS X user, and those guys tend to
>> have a respected sense of aesthetics.
>> 
>>> 
> 
> 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
> 
> 

I'd definitely hesitate to hitch our wagons to Java given the current situation 
(Oracle buying Sun and falling out with everyone, major OSes no longer 
distributing builtin JREs). Unfortunately the same could possibly be said for 
Qt given the current Nokia/Microsoft situation, but if it were a choice between 
Java, Qt, and GTK+ I'd definitely say Qt.

I'm not a Qt programmer but I just downloaded FreeMat and played around with it 
based on a tip in another thread. It's Qt based and seems to play pretty well 
with OSX, and I know Windows and Linux people who are big fans of it Qt.

Campbell

reply via email to

[Prev in Thread] Current Thread [Next in Thread]