octave-maintainers
[Top][All Lists]
Advanced

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

Re: Is FLTK the default toolkit for 3.6.0?


From: Michael D Godfrey
Subject: Re: Is FLTK the default toolkit for 3.6.0?
Date: Wed, 30 Nov 2011 12:23:06 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

On 11/30/2011 11:56 AM, Jordi Gutiérrez Hermoso wrote:
On 24 November 2011 02:04, John W. Eaton <address@hidden> wrote:
> On 23-Nov-2011, Rik wrote:
>
> | Are we upgrading the FLTK toolkit to be the default plotting engine?  If
> | yes, then a bunch of FLTK bugs on the tracker probably become blockers.
> | For example, segfaulting when values larger than bitmax ('single') are used
> | or the fact that reported mouse coordinates are not accurate.
>
> If making the OpenGL+FLTK graphics the default turns these bugs into
> blockers, then I don't think we want to make the switch.  I don't know
> how to fix these problems, and since some of the reports are months
> old, I don't see them being fixed quickly.  I don't want to wait
> months for a release because of this.
Do we have any objective way to measure if right now fltk is better or
worse than gnuplot? Of course both are buggy because both are bits of
software, but I do think it's time to take the plunge. It's only about
changing a default and getting more bug reports about OpenGL where we
can actually do something to fix it and fewer about some odd
peculiarity of gnuplot that varies by gnuplot version and platform.

I say we take the plunge.

- Jordi G. H.

It is not possible to decide "objectively" whether fltk should be made the default.
But, my own view, based on using fltk as the default by putting it in my .octaverc
file is that it is preferable to gnuplot for my work.  I use this flow for papers that I
am currently publishing.

Since it is the long term objective to make fltk the default (until something better
can be done), the sooner the switch the better.

When considering this, the most serious problem that, it appears, will not be
resolved by 3.6 release is the handling of numeric values above single precision.
This can be handled by rescaling, but it looks like a fairly serious amount of
work.  The release information should mention this restriction.

So, I agree with Jordi:  take the plunge!!

Michael


reply via email to

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