Is FLTK the default toolkit for 3.6.0?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Is FLTK the default toolkit for 3.6.0?

Rik-4
11/23/11

John,

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.

--Rik
Reply | Threaded
Open this post in threaded view
|

Is FLTK the default toolkit for 3.6.0?

John W. Eaton
Administrator
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.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Is FLTK the default toolkit for 3.6.0?

bpabbott
Administrator
On Nov 24, 2011, at 2:04 AM, John W. Eaton 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.
>
> jwe

On MacOS the FLTK backend has regressed since the last 3.4 release. I think I can provide an ugly fix, but am skeptical of how robust it will be (see bug 34720)

Also I'm under the impression that Qt will become the default backend (gui and all that).

I'm in favor of leaving the default as gnuplot.

Ben

Reply | Threaded
Open this post in threaded view
|

Re: Is FLTK the default toolkit for 3.6.0?

Jordi Gutiérrez Hermoso-2
In reply to this post by John W. Eaton
On 24 November 2011 02:04, John W. Eaton <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Is FLTK the default toolkit for 3.6.0?

Michael Godfrey
On 11/30/2011 11:56 AM, Jordi Gutiérrez Hermoso wrote:
On 24 November 2011 02:04, John W. Eaton [hidden email] 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 | Threaded
Open this post in threaded view
|

Re: Is FLTK the default toolkit for 3.6.0?

bpabbott
Administrator
In reply to this post by Jordi Gutiérrez Hermoso-2

On Nov 30, 2011, at 2:56 PM, Jordi Gutiérrez Hermoso wrote:

> On 24 November 2011 02:04, John W. Eaton <[hidden email]> 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.
There remains a serious problem with print() when using FLTK on MacOS X. See bug report 34720

        https://savannah.gnu.org/bugs/index.php?34720

I've attached a zip containing a test script and the png's produced using tip 16b3736e534b

Ben


Archive.zip (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is FLTK the default toolkit for 3.6.0?

Rik-4
In reply to this post by Michael Godfrey
On 11/30/2011 12:23 PM, Michael D Godfrey wrote:
On 11/30/2011 11:56 AM, Jordi Gutiérrez Hermoso wrote:
On 24 November 2011 02:04, John W. Eaton [hidden email] 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!!
I'll vote with JWE on this one.  Using the advanced search on the bug tracker there are 28 bugs filed against "Plotting with OpenGL".  Of these, I think using 'single' rather than 'double' in the backend, incorrect mouse coordinates, and the 'bus error' crash would need to be fixed before switching over.  Maybe this is easy, I don't know because I don't spend much time in that section of the code base, but I'm betting that it is more than a month of work.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: Is FLTK the default toolkit for 3.6.0?

tmacchant
In reply to this post by Jordi Gutiérrez Hermoso-2
Hello


--- On Thu, 2011/12/1, Jordi Gutiérrez Hermoso  wrote:

> On 24 November 2011 02:04, John W. Eaton  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.

The fltk print bug has not been solved on MinGW although the extensive effort by
Ben Abbott.
"Cannot print in emf form in fltk printing (MinGW)"
https://savannah.gnu.org/bugs/?31976

The emf printing is important for windows user so that this bug should be solved, I think.

***************
octave:3> fplot ("[cos(x), sin(x)]", [0, 2*pi])
octave:4> print -debug test1.emf
pstoedit command: '"c:\Program Files\pstoedit/pstoedit.exe" -f fig 2> NUL'
fig2dev command: 'c:\Programs\fig2dev/fig2dev.exe -L emf 2> NUL'
fltk-pipeline: '"c:\Program Files\pstoedit/pstoedit.exe" -f fig 2> NUL | c:\Programs\fig2dev/fig2dev.exe -L emf 2> NUL > test1.emf'
*********************
Created test1.emf is empty.


Hello Michael.  Can you test on the MSVC ?

Regards

Tatsuro


Regards
Tatsuro