[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: looking ahead to 3.6
From: |
Søren Hauberg |
Subject: |
Re: looking ahead to 3.6 |
Date: |
Sat, 12 Feb 2011 17:06:14 +0100 |
lør, 12 02 2011 kl. 09:00 -0500, skrev John Swensen:
> On Feb 12, 2011, at 7:53 AM, Søren Hauberg wrote:
>
> >> * Integrate a GUI with the core Octave distribution. My preference
> >> would be to start with OctaveDE since I think it is doing the
> >> right thing by embedding Octave rather than communicating with
> >> Octave using pipes. I'm willing to consider other alternatives,
> >> but it is important to me that we have a way to interact with
> >> Octave's command line without needing to completely reinvent
> >> readline.
> >
> > From what I understand OctaveDE provides class that allows you to create
> > an Octave widget and query things like variable sizes, etc. A first step
> > could be to incorporate that class into Octave. That would also allow
> > people to create nice plugins for editors (such as gEdit as was
> > discussed on this list very recently).
> >
> > Personally, I think we should have an API for interacting with the
> > interpreter (determine if a line of code can be parsed, evaluate a line
> > of code, set debug break points, ...). I hate to say this, but I do
> > believe that reinventing readline is required if we actually want to
> > create a GUI with real value.
> >
>
> I don't think re-inventing readline is needed at all. The
> octave_server class I use can now do most of what you are asking and
> with some changes to octave could do all you are asking it to do:
> 1) Set debug points, clear debug points, determine if in debug mode,
> determine where the debugger is stopped
> 2) I can evaluate lines and blocks by actually sending the selected
> text to the VTE terminal.
> 3) For things like mouse-over variable values and such, octave_server
> provides a mechanism for requesting entire variables.
> 4) Of course it already gets basic variable information and command
> history from octave
For now I think the approach taken by OctaveDE is the right one.
However, it seems to me that the most important part of a GUI is the
prompt, which in OctaveDE is simply an embedded terminal widget. This is
a solution that works well, but I find it limiting (basically, it adds
little value for me; new users most likely does not agree with me here).
I would like to see syntax highlighting in the prompt; I'd like to see
tab completions presented as drop-down lists rather than being printed
in the terminal; I'd like function help texts to be formated like when
viewed in HTML; and much more. Such features would be helpful to me, but
are not possible when using a terminal. That is why I say that I think
we should reinvent readline.
However, in the immediate future, I think the best solution would be to
take the approach used by OctaveDE.
Søren
- looking ahead to 3.6, John W. Eaton, 2011/02/11
- Re: looking ahead to 3.6, Michael Goffioul, 2011/02/12
- Re: looking ahead to 3.6, Michael Goffioul, 2011/02/12
- Re: looking ahead to 3.6, Søren Hauberg, 2011/02/12
- Re: looking ahead to 3.6, Ben Abbott, 2011/02/12
- Re: looking ahead to 3.6, Kai Habel, 2011/02/13
- Re: looking ahead to 3.6, Jordi Gutiérrez Hermoso, 2011/02/13
- Re: looking ahead to 3.6, CdeMills, 2011/02/13
- Re: looking ahead to 3.6, John Swensen, 2011/02/13
- Re: looking ahead to 3.6, Richard Campbell, 2011/02/13
- Re: looking ahead to 3.6, Michael Goffioul, 2011/02/14
- Re: looking ahead to 3.6, John Swensen, 2011/02/14
- Re: looking ahead to 3.6, Michael Goffioul, 2011/02/14
- Re: looking ahead to 3.6, John Swensen, 2011/02/14