Re: Deprecating FLTK toolkit

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating FLTK toolkit

Rik-4
On 11/07/2017 04:12 PM, [hidden email] wrote:
Subject:
Deprecate fltk graphics toolkit?
From:
"John W. Eaton" [hidden email]
Date:
11/07/2017 02:49 PM
To:
Octave Maintainers List [hidden email]
List-Post:
[hidden email]
Content-Transfer-Encoding:
7bit
Precedence:
list
MIME-Version:
1.0
Message-ID:
[hidden email]
Content-Type:
text/plain; charset=utf-8; format=flowed
Message:
3

As I understand it, there are some issues with starting Qt graphics when running in non-gui mode, and that the fltk graphics toolkit does not have those problems.  But if we could fix that, and make the Qt plot window work when running in --no-gui mode, could we deprecate the fltk graphics toolkit?

That would be the first step.  There are also performance issues.  Linking in the Qt libraries seems to slow things down.



It seems wasteful to have to maintain both Qt and fltk graphics.  For example, I just made a change for the "Save" and "Save As" menu items in the Qt graphics code.  This change took much longer than it should have when I remembered that the change would also need to be made in the fltk graphics code and that needed to be done in a completely different way.


Conceptually, since there are a limited number of Octave contributors, it would be better to focus our meager efforts on a smaller number of lines of code to maintain.  Using that same argument, we should also get rid of the gnuplot interface.

In practice, there's probably a lot of code that would need to be written just to get rid of FLTK.  In addition to the non-GUI code, and resolving performance issues, there are functional issues as well.  The menus on the figures are supposed to be uimenu objects.  They are uimenu objects in the FLTK toolkit, but not yet for Qt.

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: Deprecating FLTK toolkit

Daniel Sebald
On 11/07/2017 10:29 PM, Rik wrote:

> On 11/07/2017 04:12 PM, [hidden email] wrote:
>> Subject:
>> Deprecate fltk graphics toolkit?
>> From:
>> "John W. Eaton" <[hidden email]>
>> Date:
>> 11/07/2017 02:49 PM
>>
>> To:
>> Octave Maintainers List <[hidden email]>
>>
>> List-Post:
>> <mailto:[hidden email]>
>> Content-Transfer-Encoding:
>> 7bit
>> Precedence:
>> list
>> MIME-Version:
>> 1.0
>> Message-ID:
>> <[hidden email]>
>> Content-Type:
>> text/plain; charset=utf-8; format=flowed
>> Message:
>> 3
>>
>>
>> As I understand it, there are some issues with starting Qt graphics
>> when running in non-gui mode, and that the fltk graphics toolkit does
>> not have those problems.  But if we could fix that, and make the Qt
>> plot window work when running in --no-gui mode, could we deprecate the
>> fltk graphics toolkit?
>
> That would be the first step.  There are also performance issues.
> Linking in the Qt libraries seems to slow things down.

And crashing issues.  I'm not sure if any of that Qt crashing has been
fixed, but from my perspective that toolkit has gotten the reputation of
producing blank figure windows 1 out of 5 plots.  There were at one time
lots of reports of segfaults.  That's the way I think of Qt toolkit;
buggy, right or wrong.


>> It seems wasteful to have to maintain both Qt and fltk graphics.  For
>> example, I just made a change for the "Save" and "Save As" menu items
>> in the Qt graphics code.  This change took much longer than it should
>> have when I remembered that the change would also need to be made in
>> the fltk graphics code and that needed to be done in a completely
>> different way.
>>
>
> Conceptually, since there are a limited number of Octave contributors,
> it would be better to focus our meager efforts on a smaller number of
> lines of code to maintain.

My thinking is it's the lack of planning and good design that is an
impediment.  If programmers know what the plan is, what the goal is,
what the design is, then they can be more focused.  Instead--and this is
what I argued when Qt was hastily given prominence--there's a tendency
to toss code in without it getting a good "design review" with the
thought that others will fix any bugs, as if that were easy.  (Let me
clarify that, bugs are addressed in a thorough way, it's the new
features that get little review.)  In the Qt case it was/is a
challenging thread timing issue, left for others to deal with.  How many
bug reports have there been to deal with pertaining to Qt toolkit
crashes?  Small bugs are easy for someone to fix, poor designs not.


> Using that same argument, we should also get
> rid of the gnuplot interface.

The overriding reason for gnuplot toolkit is *quality* graphics output.
If Octave loses a means to generate quality graphics that can be used in
publications (including true vector based outputs), it's losing a big
advantage to Matlab or some other data processing app.  We still get
occasional bug reports for gnuplot toolkit, which is an indication that
people are using it.  But the bugs certainly aren't at a frequency which
is causing many programmers all sorts of consternation and using up
resources that can be used elsewhere.

There was a big push years ago to go the route of generating pixel-based
EPS files via Mesa (not utilizing the vector quality of EPS, but instead
doing a pixel translation of the plot and save in an EPS file as a
picture).  There are indications this isn't sufficient quality, e.g.,
this recent discussion:

http://octave.1599824.n4.nabble.com/Converting-from-SVG-for-some-printed-output-td4685399.html

It would be one thing to have a robust Qt plotting system and a road-map
to eventually produce quality graphics.  But until then, hey, gnuplot
toolkit works for me.  As I see it, personally, fixing gnuplot toolkit
bugs is more of a service to users than dealing with Qt threading issues.


> In practice, there's probably a lot of code that would need to be
> written just to get rid of FLTK.  In addition to the non-GUI code, and
> resolving performance issues, there are functional issues as well.  The
> menus on the figures are supposed to be uimenu objects. They are uimenu
> objects in the FLTK toolkit, but not yet for Qt.

This is where the design aspect comes in.  What is the menuing system
interface?  How does one devise communication back and forth between
these GUI windows and the core program?  I think I've added some real
basic interactive dialogue boxes years ago, but I know I did it in the
only manner for which I knew there'd be no threading issues: by
suspending the core while it waits for the user to respond.  Otherwise,
there needs to be a robust means of having feedback in a multithreaded
environment.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Deprecating FLTK toolkit

Rik-4
On 11/08/2017 08:45 AM, Daniel J Sebald wrote:

>
>
>> Using that same argument, we should also get rid of the gnuplot interface.
>
> The overriding reason for gnuplot toolkit is *quality* graphics output.
> If Octave loses a means to generate quality graphics that can be used in
> publications (including true vector based outputs), it's losing a big
> advantage to Matlab or some other data processing app.  We still get
> occasional bug reports for gnuplot toolkit, which is an indication that
> people are using it.  But the bugs certainly aren't at a frequency which
> is causing many programmers all sorts of consternation and using up
> resources that can be used elsewhere.
>

I might have been too subtle.  I don't think it is a good idea to get rid
of gnuplot, not just yet anyways.  I was trying to argue that the logical
extension of getting rid of one toolkit because of manpower issues, is to
get rid of *all* toolkits save for the one selected for continuing
development.  In this case, I don't feel we can get rid of FLTK because Qt
is still not 100% reliable and 100% capable of doing everything that a
graphics toolkit needs to do.

--Rik



Reply | Threaded
Open this post in threaded view
|

Re: Deprecating FLTK toolkit

Pantxo
In reply to this post by Daniel Sebald
Daniel Sebald wrote
>> Using that same argument, we should also get
>> rid of the gnuplot interface.
>
> The overriding reason for gnuplot toolkit is *quality* graphics output.

How can you speak about *quality* when the output does not even have the
same aspect ratio as the the expected figure?


Daniel Sebald wrote
> There was a big push years ago to go the route of generating pixel-based
> EPS files via Mesa (not utilizing the vector quality of EPS, but instead
> doing a pixel translation of the plot and save in an EPS file as a
> picture).  

This is *bullshit*, please check your assertions and provide links!


Daniel Sebald wrote
> There are indications this isn't sufficient quality, e.g.,
> this recent discussion:
>
> http://octave.1599824.n4.nabble.com/Converting-from-SVG-for-some-printed-output-td4685399.html

This discussion has nothing to do with raster versus vector graphics.

Sorry but can provide a few *actual* examples of *useful* (not 10Mb 3D
graphics that anyone would print to raster formats)  graphics that are
really better looking when printed with  gnuplot ?

Pantxo



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: Deprecating FLTK toolkit

bpabbott
Administrator
> On Nov 8, 2017, at 12:35 PM, Pantxo <[hidden email]> wrote:
>
> Daniel Sebald wrote
>>> Using that same argument, we should also get
>>> rid of the gnuplot interface.
>>
>> The overriding reason for gnuplot toolkit is *quality* graphics output.
>
> How can you speak about *quality* when the output does not even have the
> same aspect ratio as the the expected figure?

Gnuplot does have some attractive features. Especially if some specific tweaks are needed. Ex: the plot stream can be captured and then modified manually/

> Daniel Sebald wrote
>> There was a big push years ago to go the route of generating pixel-based
>> EPS files via Mesa (not utilizing the vector quality of EPS, but instead
>> doing a pixel translation of the plot and save in an EPS file as a
>> picture).  
>
> This is *bullshit*, please check your assertions and provide links!

Actually, there was a push, but I don’t think anything was implemented.

> Daniel Sebald wrote
>> There are indications this isn't sufficient quality, e.g.,
>> this recent discussion:
>>
>> http://octave.1599824.n4.nabble.com/Converting-from-SVG-for-some-printed-output-td4685399.html
>
> This discussion has nothing to do with raster versus vector graphics.
>
> Sorry but can provide a few *actual* examples of *useful* (not 10Mb 3D
> graphics that anyone would print to raster formats)  graphics that are
> really better looking when printed with  gnuplot ?

Personally, I think vector is preferred (except for photos and such).

Ben
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating FLTK toolkit

Michael Godfrey
In reply to this post by Rik-4


On 11/08/2017 04:58 PM, Rik wrote:
On 11/08/2017 08:45 AM, Daniel J Sebald wrote:

          
Using that same argument, we should also get rid of the gnuplot interface.
The overriding reason for gnuplot toolkit is *quality* graphics output.
If Octave loses a means to generate quality graphics that can be used in
publications (including true vector based outputs), it's losing a big
advantage to Matlab or some other data processing app.  We still get
occasional bug reports for gnuplot toolkit, which is an indication that
people are using it.  But the bugs certainly aren't at a frequency which
is causing many programmers all sorts of consternation and using up
resources that can be used elsewhere.

I might have been too subtle.  I don't think it is a good idea to get rid
of gnuplot, not just yet anyways.  I was trying to argue that the logical
extension of getting rid of one toolkit because of manpower issues, is to
get rid of *all* toolkits save for the one selected for continuing
development.  In this case, I don't feel we can get rid of FLTK because Qt
is still not 100% reliable and 100% capable of doing everything that a
graphics toolkit needs to do.

--Rik


It may be worth adding that Matlab does not use gnuplot. Many people use
Matlab plots for publication. However, I do not
find that their plot quality is all that good, but better than gnuplot.

--Michael

--Michael