Re: __fltk_ginput__ to __qt_ginput__

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

Re: __fltk_ginput__ to __qt_ginput__

Doug Stewart-4



On Fri, Mar 28, 2014 at 10:00 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 9:48 AM, Doug Stewart <[hidden email]> wrote:

I am looking at:
function [x, y, button] = __fltk_ginput__ (f, n = -1)

and would like your advice on how tho change it into
a file that would work with the qt back end.

I think a simple, and not toolkit specific, implementation could leverage the existence of the function waitfor. Conceptually, you can wait for a button press using something along those lines:

    set (gcf, 'windowbuttondownfcn', @(f) set (f, 'userdata', 1));
    waitfor (gcf, 'userdata');

This is the core functionality. Then you need to wrap this up with:
- save/restore windowbuttonfcn and userdata properties
- loop to retrieve multiple mouse clicks
- keep track of the pointer coordinates for each mouse click
- listen for Enter key to stop the process

AFAIK, "waitfor" works in both Qt and FLTK toolkits, so you'd have an implementation that works for both.

Michael.


But waitfor suspends octave.
What we need for sisotool is a non blocking mouse event grabber.
The user , after a plot is drawn, MIGHT want to click on it or might not.

Doug

--
DASCertificate for 206392

Reply | Threaded
Open this post in threaded view
|

Re: __fltk_ginput__ to __qt_ginput__

Michael Goffioul
On Fri, Mar 28, 2014 at 10:30 AM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 10:00 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 9:48 AM, Doug Stewart <[hidden email]> wrote:

I am looking at:
function [x, y, button] = __fltk_ginput__ (f, n = -1)

and would like your advice on how tho change it into
a file that would work with the qt back end.

I think a simple, and not toolkit specific, implementation could leverage the existence of the function waitfor. Conceptually, you can wait for a button press using something along those lines:

    set (gcf, 'windowbuttondownfcn', @(f) set (f, 'userdata', 1));
    waitfor (gcf, 'userdata');

This is the core functionality. Then you need to wrap this up with:
- save/restore windowbuttonfcn and userdata properties
- loop to retrieve multiple mouse clicks
- keep track of the pointer coordinates for each mouse click
- listen for Enter key to stop the process

AFAIK, "waitfor" works in both Qt and FLTK toolkits, so you'd have an implementation that works for both.

Michael.


But waitfor suspends octave.
What we need for sisotool is a non blocking mouse event grabber.
The user , after a plot is drawn, MIGHT want to click on it or might not.

I don't understand your concern. ginput also suspends octave...

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: __fltk_ginput__ to __qt_ginput__

Doug Stewart-4



On Fri, Mar 28, 2014 at 10:51 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 10:30 AM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 10:00 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 9:48 AM, Doug Stewart <[hidden email]> wrote:

I am looking at:
function [x, y, button] = __fltk_ginput__ (f, n = -1)

and would like your advice on how tho change it into
a file that would work with the qt back end.

I think a simple, and not toolkit specific, implementation could leverage the existence of the function waitfor. Conceptually, you can wait for a button press using something along those lines:

    set (gcf, 'windowbuttondownfcn', @(f) set (f, 'userdata', 1));
    waitfor (gcf, 'userdata');

This is the core functionality. Then you need to wrap this up with:
- save/restore windowbuttonfcn and userdata properties
- loop to retrieve multiple mouse clicks
- keep track of the pointer coordinates for each mouse click
- listen for Enter key to stop the process

AFAIK, "waitfor" works in both Qt and FLTK toolkits, so you'd have an implementation that works for both.

Michael.


But waitfor suspends octave.
What we need for sisotool is a non blocking mouse event grabber.
The user , after a plot is drawn, MIGHT want to click on it or might not.

I don't understand your concern. ginput also suspends octave...

Michael.



Is there any way to make a nonblocking mouse event function, using the uixxx type of logic?

If there isn't then I don't see how we can do the sisotool using uixxx functions.
I could be made in qt c++ language but this is quit a different GSoC project.
--
DAS

Reply | Threaded
Open this post in threaded view
|

Re: __fltk_ginput__ to __qt_ginput__

John Swensen-3



On Fri, Mar 28, 2014 at 11:38 AM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 10:51 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 10:30 AM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 10:00 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 9:48 AM, Doug Stewart <[hidden email]> wrote:

I am looking at:
function [x, y, button] = __fltk_ginput__ (f, n = -1)

and would like your advice on how tho change it into
a file that would work with the qt back end.

I think a simple, and not toolkit specific, implementation could leverage the existence of the function waitfor. Conceptually, you can wait for a button press using something along those lines:

    set (gcf, 'windowbuttondownfcn', @(f) set (f, 'userdata', 1));
    waitfor (gcf, 'userdata');

This is the core functionality. Then you need to wrap this up with:
- save/restore windowbuttonfcn and userdata properties
- loop to retrieve multiple mouse clicks
- keep track of the pointer coordinates for each mouse click
- listen for Enter key to stop the process

AFAIK, "waitfor" works in both Qt and FLTK toolkits, so you'd have an implementation that works for both.

Michael.


But waitfor suspends octave.
What we need for sisotool is a non blocking mouse event grabber.
The user , after a plot is drawn, MIGHT want to click on it or might not.

I don't understand your concern. ginput also suspends octave...

Michael.



Is there any way to make a nonblocking mouse event function, using the uixxx type of logic?

If there isn't then I don't see how we can do the sisotool using uixxx functions.
I could be made in qt c++ language but this is quit a different GSoC project.
--
DAS


I'm assuming that many of the UI callbacks are not implemented yet? 

for a description of how you can register for mouse event through a callback function. This is how I normally do little GUI tools in Matlab, rather than ginput. I usually use ginput for cases where it is just a simple script with a known number of points.
Reply | Threaded
Open this post in threaded view
|

Re: __fltk_ginput__ to __qt_ginput__

Michael Goffioul
In reply to this post by Doug Stewart-4
On Fri, Mar 28, 2014 at 11:38 AM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 10:51 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 10:30 AM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 10:00 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 9:48 AM, Doug Stewart <[hidden email]> wrote:

I am looking at:
function [x, y, button] = __fltk_ginput__ (f, n = -1)

and would like your advice on how tho change it into
a file that would work with the qt back end.

I think a simple, and not toolkit specific, implementation could leverage the existence of the function waitfor. Conceptually, you can wait for a button press using something along those lines:

    set (gcf, 'windowbuttondownfcn', @(f) set (f, 'userdata', 1));
    waitfor (gcf, 'userdata');

This is the core functionality. Then you need to wrap this up with:
- save/restore windowbuttonfcn and userdata properties
- loop to retrieve multiple mouse clicks
- keep track of the pointer coordinates for each mouse click
- listen for Enter key to stop the process

AFAIK, "waitfor" works in both Qt and FLTK toolkits, so you'd have an implementation that works for both.

Michael.


But waitfor suspends octave.
What we need for sisotool is a non blocking mouse event grabber.
The user , after a plot is drawn, MIGHT want to click on it or might not.

I don't understand your concern. ginput also suspends octave...

Michael.



Is there any way to make a nonblocking mouse event function, using the uixxx type of logic?

If there isn't then I don't see how we can do the sisotool using uixxx functions.
I could be made in qt c++ language but this is quit a different GSoC project.

I still don't understand what you're trying to achieve. Would you mind describing your use case?

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: __fltk_ginput__ to __qt_ginput__

Michael Goffioul
In reply to this post by John Swensen-3
On Fri, Mar 28, 2014 at 11:46 AM, John Swensen <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 11:38 AM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 10:51 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 10:30 AM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 10:00 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 9:48 AM, Doug Stewart <[hidden email]> wrote:

I am looking at:
function [x, y, button] = __fltk_ginput__ (f, n = -1)

and would like your advice on how tho change it into
a file that would work with the qt back end.

I think a simple, and not toolkit specific, implementation could leverage the existence of the function waitfor. Conceptually, you can wait for a button press using something along those lines:

    set (gcf, 'windowbuttondownfcn', @(f) set (f, 'userdata', 1));
    waitfor (gcf, 'userdata');

This is the core functionality. Then you need to wrap this up with:
- save/restore windowbuttonfcn and userdata properties
- loop to retrieve multiple mouse clicks
- keep track of the pointer coordinates for each mouse click
- listen for Enter key to stop the process

AFAIK, "waitfor" works in both Qt and FLTK toolkits, so you'd have an implementation that works for both.

Michael.


But waitfor suspends octave.
What we need for sisotool is a non blocking mouse event grabber.
The user , after a plot is drawn, MIGHT want to click on it or might not.

I don't understand your concern. ginput also suspends octave...

Michael.



Is there any way to make a nonblocking mouse event function, using the uixxx type of logic?

If there isn't then I don't see how we can do the sisotool using uixxx functions.
I could be made in qt c++ language but this is quit a different GSoC project.
--
DAS


I'm assuming that many of the UI callbacks are not implemented yet? 

for a description of how you can register for mouse event through a callback function. This is how I normally do little GUI tools in Matlab, rather than ginput. I usually use ginput for cases where it is just a simple script with a known number of points.

QtHandles already supports a bunch of callbacks. The most outstanding missing one is the "motion" callback.

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: __fltk_ginput__ to __qt_ginput__

Doug Stewart-4



On Fri, Mar 28, 2014 at 11:51 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 11:46 AM, John Swensen <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 11:38 AM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 10:51 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 10:30 AM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 10:00 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 9:48 AM, Doug Stewart <[hidden email]> wrote:

I am looking at:
function [x, y, button] = __fltk_ginput__ (f, n = -1)

and would like your advice on how tho change it into
a file that would work with the qt back end.

I think a simple, and not toolkit specific, implementation could leverage the existence of the function waitfor. Conceptually, you can wait for a button press using something along those lines:

    set (gcf, 'windowbuttondownfcn', @(f) set (f, 'userdata', 1));
    waitfor (gcf, 'userdata');

This is the core functionality. Then you need to wrap this up with:
- save/restore windowbuttonfcn and userdata properties
- loop to retrieve multiple mouse clicks
- keep track of the pointer coordinates for each mouse click
- listen for Enter key to stop the process

AFAIK, "waitfor" works in both Qt and FLTK toolkits, so you'd have an implementation that works for both.

Michael.


But waitfor suspends octave.
What we need for sisotool is a non blocking mouse event grabber.
The user , after a plot is drawn, MIGHT want to click on it or might not.

I don't understand your concern. ginput also suspends octave...

Michael.



Is there any way to make a nonblocking mouse event function, using the uixxx type of logic?

If there isn't then I don't see how we can do the sisotool using uixxx functions.
I could be made in qt c++ language but this is quit a different GSoC project.
--
DAS


I'm assuming that many of the UI callbacks are not implemented yet? 

for a description of how you can register for mouse event through a callback function. This is how I normally do little GUI tools in Matlab, rather than ginput. I usually use ginput for cases where it is just a simple script with a known number of points.

QtHandles already supports a bunch of callbacks. The most outstanding missing one is the "motion" callback.

Michael.

I will gladly explain what we want.

The sisotool is a tool that take a closed loop transfer function :
[ 1x + 2 ] /[ 3x^3 + 1x^2 + 5x + 7]

and draws the rlocus plot and optionally the bode plot and step response and impulse response, each in a different panel.
Then the user has the option of using the mouse to adjust the transfer function, by grabbing, with the mouse an "x" (root of the denominator polynomial), or an "o"(root of the numerator polynomial), and moving them on the plot panel. The roots my be displayed on different panels, and the user might move them in the rlocus panel or in the bode panel or the user might want to add a different panel to see a different perspective.

  As the user is moving the "x" or "o" we need to dynamically update all the panels.
This involves
1)  getting a mouse down signal
2) getting the x,y in pixels
3) converting to eng units
4) finding the closest x or o
5) looking for a mouse move before a mouse up
6) with a mouse move calculate new eng. units
7) update the transfer function
8) redraw all panels
etc.

When the user is satisfied with the shape of all the plots on the different panels then the user will want to see the new numerator and denominator.

I hope this helps

Doug     a controls engineer

--
DAS

Reply | Threaded
Open this post in threaded view
|

Re: __fltk_ginput__ to __qt_ginput__

Michael Goffioul
On Fri, Mar 28, 2014 at 12:28 PM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 11:51 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 11:46 AM, John Swensen <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 11:38 AM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 10:51 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 10:30 AM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 10:00 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 9:48 AM, Doug Stewart <[hidden email]> wrote:

I am looking at:
function [x, y, button] = __fltk_ginput__ (f, n = -1)

and would like your advice on how tho change it into
a file that would work with the qt back end.

I think a simple, and not toolkit specific, implementation could leverage the existence of the function waitfor. Conceptually, you can wait for a button press using something along those lines:

    set (gcf, 'windowbuttondownfcn', @(f) set (f, 'userdata', 1));
    waitfor (gcf, 'userdata');

This is the core functionality. Then you need to wrap this up with:
- save/restore windowbuttonfcn and userdata properties
- loop to retrieve multiple mouse clicks
- keep track of the pointer coordinates for each mouse click
- listen for Enter key to stop the process

AFAIK, "waitfor" works in both Qt and FLTK toolkits, so you'd have an implementation that works for both.

Michael.


But waitfor suspends octave.
What we need for sisotool is a non blocking mouse event grabber.
The user , after a plot is drawn, MIGHT want to click on it or might not.

I don't understand your concern. ginput also suspends octave...

Michael.



Is there any way to make a nonblocking mouse event function, using the uixxx type of logic?

If there isn't then I don't see how we can do the sisotool using uixxx functions.
I could be made in qt c++ language but this is quit a different GSoC project.
--
DAS


I'm assuming that many of the UI callbacks are not implemented yet? 

for a description of how you can register for mouse event through a callback function. This is how I normally do little GUI tools in Matlab, rather than ginput. I usually use ginput for cases where it is just a simple script with a known number of points.

QtHandles already supports a bunch of callbacks. The most outstanding missing one is the "motion" callback.

Michael.

I will gladly explain what we want.

The sisotool is a tool that take a closed loop transfer function :
[ 1x + 2 ] /[ 3x^3 + 1x^2 + 5x + 7]

and draws the rlocus plot and optionally the bode plot and step response and impulse response, each in a different panel.
Then the user has the option of using the mouse to adjust the transfer function, by grabbing, with the mouse an "x" (root of the denominator polynomial), or an "o"(root of the numerator polynomial), and moving them on the plot panel. The roots my be displayed on different panels, and the user might move them in the rlocus panel or in the bode panel or the user might want to add a different panel to see a different perspective.

  As the user is moving the "x" or "o" we need to dynamically update all the panels.
This involves
1)  getting a mouse down signal
2) getting the x,y in pixels
3) converting to eng units
4) finding the closest x or o
5) looking for a mouse move before a mouse up
6) with a mouse move calculate new eng. units
7) update the transfer function
8) redraw all panels
etc.

When the user is satisfied with the shape of all the plots on the different panels then the user will want to see the new numerator and denominator.

I hope this helps

Typically, you wouldn't use ginput to do that. You would create your graphs and your UI elements (using uiXXX functions), and you would install mouse callbacks (down/up/motion) to drive your application. The callbacks would then do the required computation and update the data on the plots.

As I said before, I think the main outstanding missing part is support for the motion callback.

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: __fltk_ginput__ to __qt_ginput__

Doug Stewart-4



On Fri, Mar 28, 2014 at 12:38 PM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 12:28 PM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 11:51 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 11:46 AM, John Swensen <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 11:38 AM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 10:51 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 10:30 AM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 10:00 AM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 9:48 AM, Doug Stewart <[hidden email]> wrote:

I am looking at:
function [x, y, button] = __fltk_ginput__ (f, n = -1)

and would like your advice on how tho change it into
a file that would work with the qt back end.

I think a simple, and not toolkit specific, implementation could leverage the existence of the function waitfor. Conceptually, you can wait for a button press using something along those lines:

    set (gcf, 'windowbuttondownfcn', @(f) set (f, 'userdata', 1));
    waitfor (gcf, 'userdata');

This is the core functionality. Then you need to wrap this up with:
- save/restore windowbuttonfcn and userdata properties
- loop to retrieve multiple mouse clicks
- keep track of the pointer coordinates for each mouse click
- listen for Enter key to stop the process

AFAIK, "waitfor" works in both Qt and FLTK toolkits, so you'd have an implementation that works for both.

Michael.


But waitfor suspends octave.
What we need for sisotool is a non blocking mouse event grabber.
The user , after a plot is drawn, MIGHT want to click on it or might not.

I don't understand your concern. ginput also suspends octave...

Michael.



Is there any way to make a nonblocking mouse event function, using the uixxx type of logic?

If there isn't then I don't see how we can do the sisotool using uixxx functions.
I could be made in qt c++ language but this is quit a different GSoC project.
--
DAS


I'm assuming that many of the UI callbacks are not implemented yet? 

for a description of how you can register for mouse event through a callback function. This is how I normally do little GUI tools in Matlab, rather than ginput. I usually use ginput for cases where it is just a simple script with a known number of points.

QtHandles already supports a bunch of callbacks. The most outstanding missing one is the "motion" callback.

Michael.

I will gladly explain what we want.

The sisotool is a tool that take a closed loop transfer function :
[ 1x + 2 ] /[ 3x^3 + 1x^2 + 5x + 7]

and draws the rlocus plot and optionally the bode plot and step response and impulse response, each in a different panel.
Then the user has the option of using the mouse to adjust the transfer function, by grabbing, with the mouse an "x" (root of the denominator polynomial), or an "o"(root of the numerator polynomial), and moving them on the plot panel. The roots my be displayed on different panels, and the user might move them in the rlocus panel or in the bode panel or the user might want to add a different panel to see a different perspective.

  As the user is moving the "x" or "o" we need to dynamically update all the panels.
This involves
1)  getting a mouse down signal
2) getting the x,y in pixels
3) converting to eng units
4) finding the closest x or o
5) looking for a mouse move before a mouse up
6) with a mouse move calculate new eng. units
7) update the transfer function
8) redraw all panels
etc.

When the user is satisfied with the shape of all the plots on the different panels then the user will want to see the new numerator and denominator.

I hope this helps

Typically, you wouldn't use ginput to do that. You would create your graphs and your UI elements (using uiXXX functions), and you would install mouse callbacks (down/up/motion) to drive your application. The callbacks would then do the required computation and update the data on the plots.

As I said before, I think the main outstanding missing part is support for the motion callback.

Michael.


Thanks for your help.
I am looking for an example of a callback for mouse button1 down.

Can you help to get the mouse move callback working?

Doug
--
DAS

Reply | Threaded
Open this post in threaded view
|

Re: __fltk_ginput__ to __qt_ginput__

Michael Goffioul
On Fri, Mar 28, 2014 at 1:16 PM, Doug Stewart <[hidden email]> wrote:
Thanks for your help.
I am looking for an example of a callback for mouse button1 down.

Can you help to get the mouse move callback working?

Yes, I can. It depends when you need it.

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: __fltk_ginput__ to __qt_ginput__

Doug Stewart-4



On Fri, Mar 28, 2014 at 2:06 PM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 1:16 PM, Doug Stewart <[hidden email]> wrote:
Thanks for your help.
I am looking for an example of a callback for mouse button1 down.

Can you help to get the mouse move callback working?

Yes, I can. It depends when you need it.

Michael.


At this point in time I don't need it. I was just trying all the functions needed to do the sisotool project.
So if you are confident that it can and will be done then I think we can go ahead with the sisotool GSoC project.


--
DAS

Reply | Threaded
Open this post in threaded view
|

Re: __fltk_ginput__ to __qt_ginput__

Michael Goffioul
On Fri, Mar 28, 2014 at 2:23 PM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 2:06 PM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 1:16 PM, Doug Stewart <[hidden email]> wrote:
Thanks for your help.
I am looking for an example of a callback for mouse button1 down.

Can you help to get the mouse move callback working?

Yes, I can. It depends when you need it.

Michael.


At this point in time I don't need it. I was just trying all the functions needed to do the sisotool project.
So if you are confident that it can and will be done then I think we can go ahead with the sisotool GSoC project.

This should get you started.


Michael.

Reply | Threaded
Open this post in threaded view
|

Re: __fltk_ginput__ to __qt_ginput__

Michael Goffioul
On Tue, Apr 1, 2014 at 8:58 PM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 2:23 PM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 2:06 PM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 1:16 PM, Doug Stewart <[hidden email]> wrote:
Thanks for your help.
I am looking for an example of a callback for mouse button1 down.

Can you help to get the mouse move callback working?

Yes, I can. It depends when you need it.

Michael.


At this point in time I don't need it. I was just trying all the functions needed to do the sisotool project.
So if you are confident that it can and will be done then I think we can go ahead with the sisotool GSoC project.

This should get you started.


And here's an example of mouse callback usage.

Michael.


figure_windowbuttonmotionfcn_demo.m (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: __fltk_ginput__ to __qt_ginput__

Doug Stewart-4



On Tue, Apr 1, 2014 at 9:33 PM, Michael Goffioul <[hidden email]> wrote:
On Tue, Apr 1, 2014 at 8:58 PM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 2:23 PM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 2:06 PM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 1:16 PM, Doug Stewart <[hidden email]> wrote:
Thanks for your help.
I am looking for an example of a callback for mouse button1 down.

Can you help to get the mouse move callback working?

Yes, I can. It depends when you need it.

Michael.


At this point in time I don't need it. I was just trying all the functions needed to do the sisotool project.
So if you are confident that it can and will be done then I think we can go ahead with the sisotool GSoC project.

This should get you started.


And here's an example of mouse callback usage.

Michael.


Thank you thank you !!!

Are you going to push this on gui-release?
Doug
PS I will try it tomorrow


--
DAS

Reply | Threaded
Open this post in threaded view
|

Re: __fltk_ginput__ to __qt_ginput__

Michael Goffioul
On Tue, Apr 1, 2014 at 11:24 PM, Doug Stewart <[hidden email]> wrote:



On Tue, Apr 1, 2014 at 9:33 PM, Michael Goffioul <[hidden email]> wrote:
On Tue, Apr 1, 2014 at 8:58 PM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 2:23 PM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 2:06 PM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 1:16 PM, Doug Stewart <[hidden email]> wrote:
Thanks for your help.
I am looking for an example of a callback for mouse button1 down.

Can you help to get the mouse move callback working?

Yes, I can. It depends when you need it.

Michael.


At this point in time I don't need it. I was just trying all the functions needed to do the sisotool project.
So if you are confident that it can and will be done then I think we can go ahead with the sisotool GSoC project.

This should get you started.


And here's an example of mouse callback usage.

Michael.


Thank you thank you !!!

Are you going to push this on gui-release?

Done:

I didn't realize that the gui-release branch had already integrated QtHandles.

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: __fltk_ginput__ to __qt_ginput__

Doug Stewart-4



On Wed, Apr 2, 2014 at 10:51 AM, Michael Goffioul <[hidden email]> wrote:
On Tue, Apr 1, 2014 at 11:24 PM, Doug Stewart <[hidden email]> wrote:



On Tue, Apr 1, 2014 at 9:33 PM, Michael Goffioul <[hidden email]> wrote:
On Tue, Apr 1, 2014 at 8:58 PM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 2:23 PM, Doug Stewart <[hidden email]> wrote:



On Fri, Mar 28, 2014 at 2:06 PM, Michael Goffioul <[hidden email]> wrote:
On Fri, Mar 28, 2014 at 1:16 PM, Doug Stewart <[hidden email]> wrote:
Thanks for your help.
I am looking for an example of a callback for mouse button1 down.

Can you help to get the mouse move callback working?

Yes, I can. It depends when you need it.

Michael.


At this point in time I don't need it. I was just trying all the functions needed to do the sisotool project.
So if you are confident that it can and will be done then I think we can go ahead with the sisotool GSoC project.

This should get you started.


And here's an example of mouse callback usage.

Michael.


Thank you thank you !!!

Are you going to push this on gui-release?

Done:

I didn't realize that the gui-release branch had already integrated QtHandles.

Michael.


Wow Thanks Michael this works great!!

I puled the latest gui-release and used the demo you made and all works great

I am now confident that the sisotools is fully doable.
Doug

--
DAS

Reply | Threaded
Open this post in threaded view
|

Re: __fltk_ginput__ to __qt_ginput__

Daniel Sebald
In reply to this post by Michael Goffioul
Re: __fltk_ginput__ to __qt_ginput__

On 03/28/2014 10:51 AM, Michael Goffioul wrote:

> QtHandles already supports a bunch of callbacks. The most outstanding
> missing one is the "motion" callback.

and

Re: [PATCH #8316] Variable Editor

On 02/24/2014 11:45 AM, John W. Eaton wrote:

>now would probably be a good time to take another look at the
> changes you proposed last year. Can you tell me where they are again? I
> thought they were in the patch tracker but I don't see them now.

---

I'm surmising that the UI callback (there is a distinction between UI
callback and C++ code callback) and what we have from time to time
discussed as "background queue" are in fact one and the same.  That is,
when a GUI object does a callback, all it is doing really is calling
Octave with the script command that is assigned to it in the list of
properties.  It's just that the command doesn't appear at the command
line or end up in the history.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: __fltk_ginput__ to __qt_ginput__

Michael Goffioul
On Sat, Apr 5, 2014 at 6:12 PM, Daniel J Sebald <[hidden email]> wrote:
Re: __fltk_ginput__ to __qt_ginput__

On 03/28/2014 10:51 AM, Michael Goffioul wrote:

QtHandles already supports a bunch of callbacks. The most outstanding
missing one is the "motion" callback.

and

Re: [PATCH #8316] Variable Editor

On 02/24/2014 11:45 AM, John W. Eaton wrote:

now would probably be a good time to take another look at the
changes you proposed last year. Can you tell me where they are again? I
thought they were in the patch tracker but I don't see them now.

---

I'm surmising that the UI callback (there is a distinction between UI callback and C++ code callback) and what we have from time to time discussed as "background queue" are in fact one and the same.  That is, when a GUI object does a callback, all it is doing really is calling Octave with the script command that is assigned to it in the list of properties.  It's just that the command doesn't appear at the command line or end up in the history.

Yes, I think it's pretty similar. Basically it's about pushing some action to be executed synchronously in the octave thread, from another thread.

The graphics manager maintains an event queue, which can be populated from any thread. The events in the queue are processed in the octave thread, using the readline input hook. In the graphics system, there's no need (yet) for a feedback or a return value. So it's only push-and-forget. The pair base_graphics_event/graphics_event form the base of the event class hierarchy; at the moment, mainly 2 events are used: change property of graphics object, execute callback.

The main problem in the mechanism is that it relies on readline. So first readline must be compiled in and active (octave must run in interactive mode), second it has a pretty big lag (~100ms, which is huge on modern computers, but it's hard to make it lower without CPU increase).

Michael.