Deprecate fltk graphics toolkit?

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

Deprecate fltk graphics toolkit?

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

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.

Comments?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Deprecate fltk graphics toolkit?

Michael Godfrey
Having just one graphics toolkit is surely a good idea. But, this will
take some work. Qt is not currently available under Fedora so I
can not even try it. What advantages does Qt have over fltk on
systems that support both?


On 11/07/2017 10:49 PM, John W. Eaton wrote:
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?

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.

Comments?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Deprecate fltk graphics toolkit?

Dmitri A. Sergatskov


On Tue, Nov 7, 2017 at 5:16 PM, Michael D Godfrey <[hidden email]> wrote:
Qt is not currently available under Fedora so I
can not even try it.



​What do you mean by that?
Of course it is available.

Dmitri.
--


Reply | Threaded
Open this post in threaded view
|

Re: Deprecate fltk graphics toolkit?

Michael Godfrey


On 11/07/2017 11:33 PM, Dmitri A. Sergatskov wrote:


On Tue, Nov 7, 2017 at 5:16 PM, Michael D Godfrey <[hidden email]> wrote:
Qt is not currently available under Fedora so I
can not even try it.



​What do you mean by that?
Of course it is available.

Dmitri.
--

octave:1> available_graphics_toolkits()
ans =
{
  [1,1] = fltk
  [1,2] = gnuplot
}

I should have added that this seems to be due to hardware?

Reply | Threaded
Open this post in threaded view
|

Re: Deprecate fltk graphics toolkit?

Dmitri A. Sergatskov


On Tue, Nov 7, 2017 at 7:10 PM, Michael D Godfrey <[hidden email]> wrote:

octave:1> available_graphics_toolkits()
ans =
{
  [1,1] = fltk
  [1,2] = gnuplot
}

I should have added that this seems to be due to hardware?

 
octave:1> available_graphics_toolkits
ans =
{
  [1,1] = fltk
  [1,2] = gnuplot
  [1,3] = qt
}

​You just did not compile it.

Dmitri.
--

Reply | Threaded
Open this post in threaded view
|

Re: Deprecate fltk graphics toolkit?

Michael Godfrey


On 11/08/2017 01:14 AM, Dmitri A. Sergatskov wrote:

On Tue, Nov 7, 2017 at 7:10 PM, Michael D Godfrey <[hidden email]> wrote:

octave:1> available_graphics_toolkits()
ans =
{
  [1,1] = fltk
  [1,2] = gnuplot
}

I should have added that this seems to be due to hardware?

 
octave:1> available_graphics_toolkits
ans =
{
  [1,1] = fltk
  [1,2] = gnuplot
  [1,3] = qt
}

​You just did not compile it.

Dmitri.
--
I just used ./configure. On other systems that compiles qt. Not on the system I use now.
But, I have not spent much time on this, so just ignore it. Anyhow, one toolkit instead of
both is better if the result works as well as either of the two.
Michael

Reply | Threaded
Open this post in threaded view
|

Re: Deprecate fltk graphics toolkit?

Andreas Weber-6
In reply to this post by John W. Eaton
Am 07.11.2017 um 23:49 schrieb John W. Eaton:
> ... 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?

I usually use the FLTK toolkit on my Desktop PC and embedded Devices
where I don't want to build and install Qt due to limited disk space and
RAM requirements. So I would vote to not deprecate FLTK yet.

> 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.


If you have such tasks in the feature, I would be glad to help here
since I'm fairly deeps into FLTK development.

Perhaps we can move the FLTK toolkit out of core to a octave-forge
package (after deprecation) as a compromise?

--Andy


Reply | Threaded
Open this post in threaded view
|

Re: Deprecate fltk graphics toolkit?

Michael Godfrey
In reply to this post by Dmitri A. Sergatskov


On 11/08/2017 01:14 AM, Dmitri A. Sergatskov wrote:
You just did not compile it.

Dmitri.
--
Wrong. octave-cli does not allow it.
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate fltk graphics toolkit?

Juan Pablo Carbajal-2
> Wrong. octave-cli does not allow it.
I compile octave and run it using octave --no-gui and qt works
perfectly. It doesn't work if you only compile cli version of octave.

Reply | Threaded
Open this post in threaded view
|

Re: Deprecate fltk graphics toolkit?

Pantxo
In reply to this post by John W. Eaton
John W. Eaton wrote

> 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?
>
> 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.
>
> Comments?
>
> jwe

I am in favor of removing FLTK but first we should ensure we have a way to
run Octave interpreter and Qt figures in the same thread, which is currently
not possible. The main reason is that comparing FLTK and Qt is currently the
best way to determine wether a graphics bug is due to thread management or
to core opengl code. Basically "octave --no-gui" would be single-threaded
"octave" would be multi-threaded.

That would also raise the question wether we want to continue using readline
event loop (callback based mechanism) for Qt figures->interpreter
communication or make a transition to use Qt event loop (signal/slot
mechanism).

Pantxo




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

Reply | Threaded
Open this post in threaded view
|

Re: Deprecate fltk graphics toolkit?

Daniel Sebald
On 11/08/2017 06:25 AM, Pantxo wrote:

> John W. Eaton wrote
>> 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?
>>
>> 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.
>>
>> Comments?
>>
>> jwe
>
> I am in favor of removing FLTK but first we should ensure we have a way to
> run Octave interpreter and Qt figures in the same thread, which is currently
> not possible. The main reason is that comparing FLTK and Qt is currently the
> best way to determine wether a graphics bug is due to thread management or
> to core opengl code. Basically "octave --no-gui" would be single-threaded
> "octave" would be multi-threaded.

I think the issue there is that Qt graphics has to be run in the main
thread.  So the --no-gui option (different from octave-cli) is a means
to get Qt graphics support in the main thread.  But you are right.
Perhaps the code could be configured so that compiling the octave-cli
version puts everything in a single thread.  Then there'd be no need for
the --no-gui option anymore.  The Qt graphics/GUI variation would still
have the worker-process paradigm.  Is there an advantage to that?


> That would also raise the question wether we want to continue using readline
> event loop (callback based mechanism) for Qt figures->interpreter
> communication or make a transition to use Qt event loop (signal/slot
> mechanism).

You are asking the right questions.  I did a prototype years ago that
removed the callback approach.  It used signal/slot on the GUI side of
things, but without Qt code in Octave core proper.  (In my view, it
would be a mistake to integrate any Qt code into the core.)  Basically,
on the Qt GUI side of things it looked like a signal/slot mechanism for
issuing commands and getting results.  On the core side of things it
looked like a simple passageway where all data travels, very similar to
the already existing queuing system for user-input octave commands.  Not
worth going into details, but suffice it to say I felt then and now that
this was/is an important design issue.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Deprecate fltk graphics toolkit?

John W. Eaton
Administrator
On 11/08/2017 12:50 PM, Daniel J Sebald wrote:

> I think the issue there is that Qt graphics has to be run in the main
> thread.  So the --no-gui option (different from octave-cli) is a means
> to get Qt graphics support in the main thread.

Qt graphics needs the Qt event loop.  The original QtHandles code
managed this somehow, because it was implemented as an add-on to Octave
before Octave had a GUI based on Qt.  So it must be possible to use a
Qt-based graphics widget from Octave that does not have a GUI running
initially.

> But you are right.
> Perhaps the code could be configured so that compiling the octave-cli
> version puts everything in a single thread.  Then there'd be no need for
> the --no-gui option anymore.

I think we'd still want a --no-gui option to avoid starting the GUI.

Some people will still want a minimal version of Octave that doesn't
directly link to Qt libraries.  And it would be nice to be able to start
and stop the GUI from the command line, same as Matlab can do.  If we
could do that (dynamically load the GUI instead of linking it directly
to the main program), then we wouldn't need octave-cli.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Deprecate fltk graphics toolkit?

John W. Eaton
Administrator
In reply to this post by Daniel Sebald
On 11/08/2017 12:50 PM, Daniel J Sebald wrote:

> You are asking the right questions.  I did a prototype years ago that
> removed the callback approach.  It used signal/slot on the GUI side of
> things, but without Qt code in Octave core proper.

I agree that this is a better way to go.  I believe this is also how the
Octave interpreter currently communicates with the Qt graphics code.

For example, see the way that drawnow (DEV, FILE) calls the graphics
toolkit's print_figure function.  For Qt, the print_figure function uses
a signal (sentPrint) and slot (slotPrint) connection to do this job.

I would like to fix this for the other parts of the GUI as well.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Deprecate fltk graphics toolkit?

Daniel Sebald
In reply to this post by John W. Eaton
On 11/08/2017 12:15 PM, John W. Eaton wrote:

> On 11/08/2017 12:50 PM, Daniel J Sebald wrote:
>
>> I think the issue there is that Qt graphics has to be run in the main
>> thread.  So the --no-gui option (different from octave-cli) is a means
>> to get Qt graphics support in the main thread.
>
> Qt graphics needs the Qt event loop.  The original QtHandles code
> managed this somehow, because it was implemented as an add-on to Octave
> before Octave had a GUI based on Qt.  So it must be possible to use a
> Qt-based graphics widget from Octave that does not have a GUI running
> initially.

That would be one way to go, i.e., to run the plotting graphics separate
from the GUI graphics.  I would have to guess, thought, that this
QtHandles had to have an event loop and main thread.  Was it a separate
process that somehow interacted?  Still, it might be best to keep the
plotting graphics in the same process and thread as the GUI graphics.
This is a design issue to think about.


>> But you are right. Perhaps the code could be configured so that
>> compiling the octave-cli version puts everything in a single thread.  
>> Then there'd be no need for the --no-gui option anymore.
>
> I think we'd still want a --no-gui option to avoid starting the GUI.
>
> Some people will still want a minimal version of Octave that doesn't
> directly link to Qt libraries.  And it would be nice to be able to start
> and stop the GUI from the command line, same as Matlab can do.  If we
> could do that (dynamically load the GUI instead of linking it directly
> to the main program), then we wouldn't need octave-cli.

Remember, though, that Octave-GUI is using the model of Octave core
running in a worker thread.  That's a pretty common model for Qt design.
  What happens when someone launches Matlab from the command line in
non-GUI mode and then calls "gui"?  Do both the shell command line and
terminal inside the GUI accept input?  That would seem strange.  Does
the shell command line just freeze until the GUI is exited?  That would
be my guess because I'm recalling Matlab being able to launch its own
user-designed GUI's which behave that way.

The command-line octave in its own process/main-thread would have to
somehow move to the GUI's worker thread.  Maybe it is possible to do
that somehow in Qt; I never investigated.  One other thing might be
possible is to launch the GUI version of Octave and then somehow
transfer all the variables and history from the shell Octave-core into
the worker-process Octave-core.  It would look right, but I'm not sure I
like that approach.

Dan