Re: Deprecating FLTK toolkit

[Daniel J Sebald]

On 11/07/2017 10:29 PM, Rik wrote:
> On 11/07/2017 04:12 PM, address@hidden wrote:
> > Subject:
> > Deprecate fltk graphics toolkit?
> > From:
> > "John W. Eaton" <address@hidden>
> > Date:
> > 11/07/2017 02:49 PM
> >
> > To:
> > Octave Maintainers List <address@hidden>
> >
> > List-Post:
> > <mailto:address@hidden>
> > Content-Transfer-Encoding:
> > 7bit
> > Precedence:
> > list
> > MIME-Version:
> > 1.0
> > Message-ID:
> > <address@hidden>
> > 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