On 2009-03-31 15:20+0100 Rochel, Alban wrote: > Alan, > > Here is a (big) patch for the Qt driver, based on revision 9777 (I've also > attached the changed files). This patch should: > - Fix the text clipping issues > - Allow to handle multiple streams > > To be able to manage multiple streams, I've created a MasterHandler object > acting as an interface between the master Qt device and the slave Qt devices, > collecting and dispatching signals from the master. Only the master device > can be waiting for user input (either a right click to go to the next page or > a window closing action), during calls to eop(). > So the following situations should lead to the following behaviours: > - Master Qt, Slave Qt: should work fine. If Master is interactive, actions on > it will be dispatched to the slaves. If Master is non-interactive and Slave > is interactive, Slave will be displayed only for a fraction of second, as > Master will not stop at the eop() calls. > - Master Xwin, Slave QtWidget: The user will have to right-click successively > on each window to go from one page to the following one (the slave is seen as > a master by MasterHandler, so it waits for input on its eop()). Actually, > it's the same behaviour for Master Xwin/Slave XCairo, so I believe this won't > be a problem. > > I have encountered a segmentation fault on the Master QtWidget/Slave Xwin > configuration (when x14c quits), but: > - gdb refused to work after loading the QtWidget device (Error while reading > shared library symbols: > Cannot find new threads: generic error) - I don't know if it is a problem > I've introduced or a configuration issue, I've just reinstalled a clean > OpenSUSE system (about time!), I haven't played with gdb on it before. > Anyway, I'll have to investigate this. > - A segmentation fault also occurs on the Master XCairo/Slave Xwin > configuration at the same point, so it is probably an xwin driver problem. > > Finally, I had to force the QApplication to be a GUI application no matter > what device creates it, as when it is created we cannot know what devices > will be requested on other streams, and only one QApplication can be declared > at once. It seems to work fine, but I haven't had problems with that before > anyway. If I run valgrind with a console device with the QApplication set to > non-GUI, I get less memory issues that when it's set up as a GUI application, > but nothing else. I've also tried to set up a dummy widget for console > devices configured as GUI applications, but it didn't change the valgrind > signature... If no one complains, I suggest we leave it as is, else we will > have to restrain what types of Qt devices will be able to work in the same > time on different streams.
Hi Alban: I am CCing to the list because I think the rest of the developers will be interested in the technical details of your recent qt improvements which I have spot-checked (examples 9 and 14 and a few others) and committed (9780). It appears you have dealt with the last of the currently known issues with this device. Congratulations and thanks! To everybody here on list: The "you" and "your" in the rest of this is directed to everybody here on list. I have written up release notes for the qt device (README.release, revision 9781). Nine new high-quality devices is a tremendous boost for PLplot. N.B. Alban mentions it above, and I do as well in the release notes, but you should be aware that qtwidget paging is now controlled by right clicking on the mouse. Please hammer on the qt devices with your testing on the multiple platforms/configurations accessible to you to make sure the qt device driver is ready for release (along with the rest of 5.9.3) roughly a month from now. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
