Release goals for 3.6

[John W. Eaton]

On  2-Aug-2011, Jordi Gutiérrez Hermoso wrote:

| This means that if we keep with this plan, we have one more month
| before we hit a feature freeze?

I would be mostly OK with that.

| > Next, I have a few projects that I would personally like to work on
| > (these might not all happen for 3.6, but they are things I'm
| > currently most interested in):
| >
| >  * Improve textscan. I promised Ben Abbott that I would look at what
| >    is needed to handle the textscan-specific format specifiers. I
| >    started doing that, but never finished the job.
| 
| This seems to be well underway.

But I think the changes I had in mind have not been made.  I was
planning to write something similar to the *scanf function that would
handle the format specifiers used by textscan.  The last time I looked
at this, it did not seem possible to map all of the formats used by
textscan to scanf.

| >  * Look at whether octave idx type should be an unsigned type. See
| >    
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2011-February/022980.html
| >    for some motivation for a change like this.
| 
| I haven't seen any work on this. Has there been any?

No, and I don't think it is urgent.

| >  * Fix lsode, dassl, daspk, etc. to accept an options structure as
| >    an argument instead of using a global option structure (losde
| >    options, dassl options, etc.). If possible, this should be done
| >    in a way that allows a smooth transition, so that code using the
| >    options functions can be deprecated but will continue to work for
| >    at least one release cycle.
| 
| Same here, no work yet?

Right.

| >  * Make the current FLTK+OpenGL plotting system work better so that
| >    we can make it the default.  For this to happen, there are a lot
| >    of little bugs that need to be fixed, plus we need to make
| >    printing reliable.  If possible, we need to make printing work
| >    even when a plot is not displayed on the screen.
| 
| This one is a big release goal. Do we have a specific set of bugs that
| we should patch? We have several related to fltk in the bug tracker.
| Perhaps begin by prioritising those? This one looks like a very
| important user-visible change for 3.6.

I don't think we have had major changes, but we have had a number of
bug fixes.

| >  * 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.
| 
| Quint, or as Jacob Dawid has been calling it recently, simply "the
| Octave GUI", seems to be ready to at least be an experimental GUI for
| 3.6. It is doing readline and Jacob is doing a lot of work on it (plus
| he keeps recruiting more people to help). I'm going to try to
| integrate it with Octave's build system and push to Savannah on the
| default branch within a few weeks. We can spend time after September
| polishing it for release.

I haven't looked at it recently.  I can help you with integration, but
I don't know that I have time to do the work myself, as I earlier
thought I would.

| >  * Make a gtk+OpenGL graphics system.  Or use wxWidgets, or
| >    something (anything!) that looks better than FLTK (sorry, FLTK
| >    fans).
| 
| I don't think this is ready yet. Jacob expressed some interest in
| making this work with Qt, but I don't believe he's managed to
| understand how plotting works well enough to begin the Qt
| implementation.

I think all that is needed is to have the functional equivalent of the
__init_fltk__.cc file but that uses Qt instead.  Similarly, we could
use something corresponding to __fltk_uigetfile__.cc.

| So, anyways, feature freeze in one month? Perhaps in two? Time to
| think about it?

I'd say a feature freeze in 2-3 months would be reasonable, regardless
of whether we have implemented many more of the above wish-list items.

We should be able to have a reasonably complete profiler for the 3.6
release, yes?  That's a nice new feature for a release.  Plus many bug
fixes, and I expect some improved Matlab compatibility.

jwe