Re: Retrieving Mouse Clicks

[guilhelm savin <guilhelm.savin AT gmail.com>]

Hi Sebastian,

ViewerPipe does not only send events about clicks but also about all modifications in the graphic graph.

That means it also send node/edge added/removed events and attribute modification events (layout will produce such events).

So pipe is not blocking after the first "call" but it is blocking when elements have been added and layout is stable.

Regards

G.

2013/5/29 Sebastian Bock <sebastian.bock AT bluewin.ch>

Hi there

First thank you for your fast answer! There's something I don't understand: "in this case you should better put your code in the GUI thread". How can I put my code in the GUI thread? Do you mean to "handle" the graph in the swing thread and not in a own thread? 

I just want to retrieve mouse clicks on a node and then show the node label in the GUI (so that the user can see which node he has "selected"). All this I want to handle in the GUI thread but I don't know how? Is that possible? 

@Guihelm: Thanks for the blocking pipe. Unfortunately the pipe is only blocking after the first "call". Is it possible to block from the beginning?

fromViewer.pump();

        while(loop) {

            fromViewer.pump();

            System.out.println("Pumping.....");

        }

Regards 

Sebastian

Am 29.05.2013 um 08:04 schrieb Antoine Dutot <antoine.dutot AT gmail.com>:

Ok, don't panic, it is not a bug, it's a feature :-)

This part of the tutorial was never intended to be run and used as it is. I recently changed it so that it compiles for another developer.  But I admit it is not very clear. It is too small and nobody would want to run such a loop. Most of the time you even do not have such a loop and just call pump() before using your graph to synchronize it with the GUI (in another thread). 

But when you have such a loop, the idea is that you run your simulation in this loop, and in this case you *do not want* the pump to be blocking, you temporize your loop by yourself. (Here indeed, the loop does nothing else, and therefore if you run it alone, it makes you computer hotter than needed.) In a real development scenario you use the pumping mechanism in the "main" thread, not the GUI thread, because you need such a non blocking behavior.

However, in the case where you want to use an event based model (blocking), for prototyping for example, the behavior proposed by Guilhelm is a good start but we have to document it, and in this case a system with listeners like in GUI would be better.

Indeed, as soon as GraphStream is blocking, it controls your loop (you cannot tell when your code in the loop will be allowed to run). But again, in this case you should better put your code in the GUI thread and avoid this plumbing and pumping machinery only intended to run your own non blocking simulation thread.

I will modify the tutorial to be clearer on this matter.

In the future, after a discussion, we could either add a BlockingViewerPipe as proposed by Guilhelm or a blockingPump() method, but we have to really document it, and maybe have a whole tutorial explaining the two or three ways to run a program in GraphSteam, since I thing the non-blocking pump must stay.

Antoine

P.S. maybe we could think about the actor model...

Le 29 mai 2013 00:58, "guilhelm savin" <guilhelm.savin AT gmail.com> a écrit :

I think it's a really normal behavior if you want to turn your laptop into a heater.

But well .... we agree : this is not the aim of GraphStream.

I think there is a real problem in this case. We have to discuss it with other dev but I made a draft hack of ViewerPipe with a blocking pump method.

You can find it here : http://pastebin.com/a6kcA6xQ

To use it, just change this line :

ViewerPipe fromViewer = viewer.newViewerPipe();

into : 

ViewerPipe fromViewer = new BlockingViewerPipe(viewer);

Your CPU load should fall to a more acceptable rate.

Thanks for reporting this behavior.

Hope this helps.

Regards.

Guilhelm

2013/5/28 Sebastian Bock <sebastian.bock AT bluewin.ch>

Hi there

Just a question to the example from the graphstream site. In the following example a while(true)-loop is used and AFAIK the pump() method is non blocking. This results in a loop which causes a 100% CPU usage.

Is this a normal behavior? Are there any other ways to retrieve mouse clicks without 100% CPU usage?

Thank you in advance

Sebastian

Example:

public class Clicks implements ViewerListener {

    protected boolean loop = true;

 

    public static void main(String args[]) {

        new Clicks();

    }

    public Clicks() {

        // We do as usual to display a graph. This

        // connect the graph outputs to the viewer.

        // The viewer is a sink of the graph.

        Graph graph = new SingleGraph("Clicks");

        Viewer viewer = graph.display();

 

        // The default action when closing the view is to quit

        // the program.

        viewer.setCloseFramePolicy(Viewer.CloseFramePolicy.HIDE_ONLY);

 

        // We connect back the viewer to the graph,

        // the graph becomes a sink for the viewer.

        // We also install us as a viewer listener to

        // intercept the graphic events.

        ViewerPipe fromViewer = viewer.newViewerPipe();

        fromViewer.addViewerListener(this);

        fromViewer.addSink(graph);

 

        // Then we need a loop to wait for events.

        // In this loop we will need to call the

        // pump() method to copy back events that have

        // already occurred in the viewer thread inside

        // our thread.

 

        while(loop) {

            fromViewer.pump();

        }

    }

 

    public void viewClosed(String id) {

        loop = false;

    }

 

    public void buttonPushed(String id) {

        System.out.println("Button pushed on node "+id);

    }

 

    public void buttonReleased(String id) {

        System.out.println("Button released on node "

...

[Message tronqué]  

--
Guilhelm Savin
PhD Student of Computer Science

LITIS, University of Le Havre
\/\/\/\/\/\/

http://gsavin.lewub.org

http://d3-project.org
http://iscn.univ-lehavre.fr
http://graphstream-project.org
/\/\/\/\/\/\