|
| From: | Moritz Borgmann |
| Subject: | Re: Octave workshop for Octave 3.0.0 on windows Xp |
| Date: | Sat, 29 Mar 2008 04:00:03 +0100 |
On 28-Mar-2008, Moritz Borgmann wrote: | I'm not an expert at all in these matters, so please take my | statements with caution. I wasn't actually alluding so much to the | handling of the command-line input. I guess it would indeed by hard | to have a GUI on top of Octave, but still have Octave handle all | command-line editing including readline. But is that a problem? I | mean, doesn't the GUI simply have to include decent readline support | by itself and it's done? If Octave runs in a separate process, then getting at information like which variables are in the workspace becomes more difficult. It makes much more sense to me to have the GUI and the interpreter more closely integrated. It's also somewhat difficult to deal with partial statements (think about for loops or if statements that span multiple lines) if the function that handles input from the user is not called directly from the parser. Yes, it can be done, but this kind of interface relies on parsing the output from Octave and looking for the prompt.
yes, there are some arguments pro tight integration, as you're saying, but I'm not sure this is the only way possible. Looking at Ryan Rusaw's Octclipse console proxy, it's an oct file that's basically called once and never returns, listening to a socket for commands from the IDE. He's implemented completion, symbol list, the full thing, without parsing Octave output - all the information comes directly from the bowels of Octave via the oct file (I don't know if he gets partial statements right, though). There seems to be some sort of XML protocol defined by the Dynamic Languages Toolkit Project, which implements the GUI interaction on the Eclipse side. I'm not saying that this is the way to go, only that this whole question warrants somewhat more scrutiny before a conclusion is found - at least it's been proven that Octave and GUI do not necessarily need to be in the same process.
Is it really an advantage to have numerous half-baked efforts floating about? I think it might be best to have a single standard GUI interface so that all users of Octave would have a common environment. It also seems to me that our resources are already severely limited, so it would make more sense to work together on a single GUI rather than N of them.
In principle, I agree. The current status seems highly suboptimal, with at least 7 projects lying around in various states from dead to pretty alive. However, choice and even some competition may not necessarily be that bad; this being possible at all is one of the core advantages that comes with free software. After all, it would probably be illusionary anyway that, say, GUI developers from the Java and the Qt camp will develop too many synergies. But what can certainly be done from the Octave side of things is to provide a solid, stable interface for IDEs that does as much of the heavy lifting as possible, so that the GUIs can concentrate on the GUI aspects. On top of that, I do agree that the Octave community should focus and endorse one or maybe two promising GUI projects as the "standard".
Compare this with the current gnuplot vs. jhandles graphics situation. When someone reports a problem, we have to ask, "Which graphics system are you using?" and then say, "Oh, you have to deal with bugs A, B, and C if you are using that one. You can avoid those with the other interface, but then you'll have to deal with bugs X, Y, and Z." I'd rather have a single graphics backend so that there is no confusion about what does or doesn't work (and hopefully, more things would work because we would be concentrating our efforts on one thing rather than many). Thanks to the efforts of of Michael and Shai, I think we are approaching this situation fairly rapidly for the graphics system.
Yes, you have a valid point there. -M
| [Prev in Thread] | Current Thread | [Next in Thread] |