I am currently trying to integrate plplot to an application formerly relying on pgplot. Our application should allow the user to open a plot window (X driver), then close it, and generate another plot and so on... Which I cannot find how to do!
My problem is as follows. Let's suppose that my user starts myFunction() when clicking a button:
- While in pleop(), my application interface in the background is completely stuck, which I do not want
- If the user clicks the "close" button on the window during pleop, plplot crashes (IO error: client killed). I do not want this behaviour, as it is the most natural one to close a window, and it worked using pgplot.
- Then I can plspause(0). But plend() closes my window, which I don't want either.
Thus my idea would be to replace myFunction() by something like:
plend1(); // Closing my window
pldev("xwin"); // Creating a new one
and add plend() when quitting my program.
The problem is if the user calls myNewFunction(), closes the window, and calls myNewFunction() again, plend1() will crash.
Is there an easy solution to my issue? I suppose that the clean way to do it would be to have a cleanup routine called when destroying a window, with a status flag set somewhere, but this doesn't seem to be the case.
Any suggestion would be greatly welcome.
Hi, I never used the xwin driver, but I assume if you call the xwin driver from a X-application and close the window, that your application and the xwin application try to process the close event and this leads to an crash. The xwin driver creates its own X application the way you call it. I'm no X expert so I might be completely wrong. But there is the cairo driver and there were some discussions and patches which allow to use the cairo driver (that is the memcairo driver) in a X application. You will find more information here: https://sourceforge.net/mailarchive/forum.php?thread_name=200803050236.m252aFI4014082%40turbo.physics.adelaide.edu.au&forum_name=plplot-devel .
Thanks for your answer :)
I've made some progress hacking through the xwin driver, and I can actually catch the "close request" event. I am currently figuring out how to handle it cleanly without messing up other stuff (I am very new to X too).
The cairo driver is an option I do not want to use, I would like the software to be as light as possible and require as few dependencies as possible. If I don't manage to do what I want from X, I may try and see how the tk driver works, as it is -I believe- more widespread than cairo.
You could at least look at the code of the memcairo how this is done with the handle of the canvas. In principle it is possible to initialize a device without opening a window, setting the handle to an existing canvas/window, and the driver will plot into this windows/canvas than. The wxWidgets driver, the gnome driver and the memcairo driver do it that way. It should be then not too problematic to add this feature to the xwin driver, and I'm sure that others may be interested as well. You should ask further question on the PLplot developer mailing list, since there more developers are around as in this forum here.
Thanks a lot for your suggestion, as it gave me the idea to do a kind of "memQt" device (well, a Qt widget wrapping the mem driver). My first tests seem to work perfectly, and this allows lots of possibilities for interaction with the (Qt-based) software I work on.
this is actually possible and the mem driver is for these purposes. Mind though that the mem driver is fast but not "modern", no antialising, no ttf-fonts. The "better" way would be to write a Qt driver, similar to the wxWidgets driver. In case you only want to provide a canvas and not a standalone application, this is actually not too much work - you would only need to "port" the wxWidgets calls of 1/4 of the existing wxWidgets driver to Qt calls. The basic PLplot drawing functions rely only on 4 or 5 driver functions. It would actually need only some hours of coding to get a complete driver (sensa debugging :). This would have the advantage that Qt calls are used to draw lines and text.
Anyway, if you are interested in doing this (the PLplot community would be I think) I could help you identifying the parts of the wxWidgets driver which would need to be ported. I have no knowledge about the Qt library, so I can't help you here, but as I said, this shouldn't be hard.
It would be more problems though to get the cmake build system ready for the new driver, but here I as well as others PLplot developers could help you.
For the moment, I am quite pleased with what I have using the mem driver. I understand that a "pure" Qt driver would be much greater for the community, but for now I prefer to focus on what is sufficient for the software I work on, as integrating this plot system is only one of the many works to do.
Anyway, I will keep that advice in mind if I find myself limited, or when I have more time to experiment.
I will not be able to answer this thread for the next two weeks, as I will be on holiday, far from computers :)
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.