Re: [Plplot-devel] Removed dynamic casts from Qt driver

2009-07-20 Thread Andrew Ross
On Mon, Jul 20, 2009 at 03:29:56PM +0100, Rochel, Alban wrote:
 Hello all,
 
 Due to the issues related to dynamic_casts, and as those were only used to 
 make the code compacter, I`ve changed the way the driver works as follows:
 - Before: 1 callback function common to all Qt devices (e.g. plD_line_qt), 
 calling the proper implementations making tests on the results of 
 dynamic_casts
 - After: 1 callback function for every Qt device (e.g. plD_line_svgqt), using 
 simple C-style casts. If you prefer C++ reinterpret_casts, just ask.
 This is by far the simplest solution I can think about.
 
 If this suits your needs, I will then proceed with other updates later.
 
 While I`m working on this, Dmitri Gribenko complained about the fact that all 
 the class definitions were bulked in one header, which is not conventional in 
 C++, but is functional and avoids having many header files for a single 
 driver. I can change that of course, I just want an official green light for 
 this, as it remained as the state of a discussion.

Dear Alban,

As an aside, make sure you get the latest update. I've been looking at 
fixing the qt visibility issues today and have made a few changes as
a result. 

Looking at the code I only see 2 versions of all the callback functions 
a standard one and an extended one for extqt and qtwidget. Is this
correct? If so, then it is not a large increase in code size to 
remove the dynamic casting if it is problematic. 

In terms of splitting up qt.h into lots of class specific files, I know
this is the normal C++ way of doing things, but this will generate a 
lot of extra headers for just 1 driver. I think the clutter this
makes will outway any C++ elegance benefits. That's my opinion. Others
may disagree.

Slightly off topic - I've now got gcc -fvisibility=hidden working with
the qt driver and with the C++ qt_example.cpp. It does not work with 
the pyqt4 bindings yet. There are a couple of issues here (I think). 
1) The sip generated code does not export the symbols that python
requires. It should be possible to massage the source code if required.
2) The moc generated code for qt also is not visibility aware and I 
think this is what is leading to the missing symbols in plplot_pyqt4.so
at the moment. I've not yet worked out how (or indeed even if it is
possible) to massage the code by hand to fix this.

Andrew

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


[Plplot-devel] QT rpath bug

2009-07-20 Thread Andrew Ross

Alan,

When implementing rpath support for the libplplotqtd library you have
added the qt path in front of the rest of the rpath directories. From
the comments you added I think this is to ensure that you pick up 
your custom built qt libraries rather than the system ones. Unfortunately
if you are using the system qt libraries this adds /usr/lib at the
front of the rpath directory list and therefore you end up linking
with system version of the plplot libraries rather than those in the
install location. For me this is a headache. Of course the proper
solution is to order the rpath variables so that the install prefix
always appears first, but I can't see an easy way of doing that with
your current approach. Any thoughts?

Andrew


--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


[Plplot-devel] RE : Removed dynamic casts from Qt driver

2009-07-20 Thread Rochel, Alban
Hello Andrew,

Here is a version of the same patch based on R10166. There were indeed 
conflicts with your changes.
There should be about 5 versions for the callbacks:
- rasterqt (for png, bmp...), sometimes specialised as pngqt, bmpqt... where 
needed
- svgqt
- epspdfqt (sometimes epsqt and pdfqt)
- qtwidget
- extqt

I`m afraid I cannot help a lot with the Python bindings as I have absolutely no 
experience with them (or with Python more generally). But if you have ideas of 
what should be changed in the C++ aspects of the driver, feel free to ask.

Alban


De : an.r...@virgin.net [an.r...@virgin.net] de la part de Andrew Ross 
[andrewr...@users.sourceforge.net]
Date d'envoi : lundi 20 juillet 2009 15:55
À : Rochel, Alban
Cc : PLplot development list
Objet : Re: [Plplot-devel] Removed dynamic casts from Qt driver

On Mon, Jul 20, 2009 at 03:29:56PM +0100, Rochel, Alban wrote:
 Hello all,

 Due to the issues related to dynamic_casts, and as those were only used to 
 make the code compacter, I`ve changed the way the driver works as follows:
 - Before: 1 callback function common to all Qt devices (e.g. plD_line_qt), 
 calling the proper implementations making tests on the results of 
 dynamic_casts
 - After: 1 callback function for every Qt device (e.g. plD_line_svgqt), using 
 simple C-style casts. If you prefer C++ reinterpret_casts, just ask.
 This is by far the simplest solution I can think about.

 If this suits your needs, I will then proceed with other updates later.

 While I`m working on this, Dmitri Gribenko complained about the fact that all 
 the class definitions were bulked in one header, which is not conventional in 
 C++, but is functional and avoids having many header files for a single 
 driver. I can change that of course, I just want an official green light for 
 this, as it remained as the state of a discussion.

Dear Alban,

As an aside, make sure you get the latest update. I've been looking at
fixing the qt visibility issues today and have made a few changes as
a result.

Looking at the code I only see 2 versions of all the callback functions
a standard one and an extended one for extqt and qtwidget. Is this
correct? If so, then it is not a large increase in code size to
remove the dynamic casting if it is problematic.

In terms of splitting up qt.h into lots of class specific files, I know
this is the normal C++ way of doing things, but this will generate a
lot of extra headers for just 1 driver. I think the clutter this
makes will outway any C++ elegance benefits. That's my opinion. Others
may disagree.

Slightly off topic - I've now got gcc -fvisibility=hidden working with
the qt driver and with the C++ qt_example.cpp. It does not work with
the pyqt4 bindings yet. There are a couple of issues here (I think).
1) The sip generated code does not export the symbols that python
requires. It should be possible to massage the source code if required.
2) The moc generated code for qt also is not visibility aware and I
think this is what is leading to the missing symbols in plplot_pyqt4.so
at the moment. I've not yet worked out how (or indeed even if it is
possible) to massage the code by hand to fix this.

Andrew


qt_patch
Description: qt_patch
--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


Re: [Plplot-devel] unexported symbols for libplplotqtd.so (and plplot_pyqt4.so)

2009-07-20 Thread Andrew Ross
On Mon, Jul 20, 2009 at 11:22:32AM -0700, Alan Irwin wrote:
 Hi Andrew:

 I have changed the subject line appropriately.

 On 2009-07-20 15:55+0100 Andrew Ross wrote:

 Slightly off topic - I've now got gcc -fvisibility=hidden working with
 the qt driver and with the C++ qt_example.cpp. It does not work with
 the pyqt4 bindings yet. There are a couple of issues here (I think).
 1) The sip generated code does not export the symbols that python
 requires. It should be possible to massage the source code if required.
 2) The moc generated code for qt also is not visibility aware and I
 think this is what is leading to the missing symbols in plplot_pyqt4.so
 at the moment. I've not yet worked out how (or indeed even if it is
 possible) to massage the code by hand to fix this.

 Thanks very much for dealing with the visibility issues caused by splitting
 the old qt.cpp source code into qt.cpp and plqt.cpp.  I have now added one
 additional cleanup there (revision 10167) to remove some unneeded logic in
 pldll.h.in.

 I agree with your comment (1) above that the visibility of the symbols
 defined in plplot_pyqt4.so will be an issue when python attempts to
 dynamically load that shared object.  But I believe the first priority is to
 deal with the remaining unexported symbols in libplplotqtd.so that are
 causing undefined symbols for plplot_pyqt4.so.

 The current undefined symbol status is as follows.

 softw...@raven ldd -r drivers/qt.so 21 |grep undefined
 softw...@raven ldd -r bindings/qt_gui/libplplotqtd.so 21 |grep undefined
 softw...@raven ldd -r bindings/qt_gui/pyqt4/plplot_pyqt4.so 21 |grep 
 undefined
 undefined symbol: _ZTI11QtExtWidget
 (bindings/qt_gui/pyqt4/plplot_pyqt4.so)
 undefined symbol: _ZTI10QtPLWidget
 (bindings/qt_gui/pyqt4/plplot_pyqt4.so)
 undefined symbol: _ZN11QtExtWidget16staticMetaObjectE
 (bindings/qt_gui/pyqt4/plplot_pyqt4.so)
 undefined symbol: _ZN10QtPLWidget16staticMetaObjectE
 (bindings/qt_gui/pyqt4/plplot_pyqt4.so)
 undefined symbol: _ZN10QtPLWidget11qt_metacastEPKc
 (bindings/qt_gui/pyqt4/plplot_pyqt4.so)
 undefined symbol:
 _ZN11QtExtWidget11qt_metacallEN11QMetaObject4CallEiPPv(bindings/qt_gui/pyqt4/plplot_pyqt4.so)
 undefined symbol: _ZN10QtPLWidget11qt_metacallEN11QMetaObject4CallEiPPv
 (bindings/qt_gui/pyqt4/plplot_pyqt4.so)
 undefined symbol: _ZN11QtExtWidget11qt_metacastEPKc
 (bindings/qt_gui/pyqt4/plplot_pyqt4.so)

 I have double-checked that all these eight symbols are defined in but not
 exported from libplplotqtd.  You are probably aware of this already, but I
 just discovered you can correlate these symbols with the demangled symbols
 using the appropriate nm options and grep.  For example:

 softw...@raven nm --defined-only bindings/qt_gui/libplplotqtd.so |grep
 _ZTI11QtExtWidget
 00214b50 d _ZTI11QtExtWidget
 softw...@raven nm --defined-only --demangle bindings/qt_gui/libplplotqtd.so
 |grep 00214b50
 00214b50 d typeinfo for QtExtWidget

 That demangled symbol information for all eight symbols may help you to
 figure out what is really going on with visibility.

 I am curious about your comment (2) above.  Is there an example of a
 externally required symbol in the generated moc_qt.cxx that cannot be
 exported by some qt.h change involving the PLDLLIMPEXP_QT macro?

Alan,

I've also done the same thing with ldd / nm. I get the same missing
symbols as you. When you run moc it generates some extra 
functions in the the C++ class to deal with the qt signals / slots. The
Q_OBJECT line in the C++ classes denotes the classes that this applies
to. If you look through qt.h you will see that there are unexported 
typeinfo information for _only_ those classes which contain Q_OBJECT,
even though everything else is that same (e.g. c.f. the typeinfo entries 
for QtPLDriver and QTPLWidget). The other entries, those containing
metaObject or metacast are generated by moc (look in the source file).
I've tried manually adding in the required attribute information to
these files but it doesn't compile. It seems that these are being defined
elsewhere through QT macros - I imagine an expansion of the Q_OBJECT tag 
- and the definitions conflict. I will need to look into this further.
I'm not quite sure why this only affects the pyqt4 bindings. Presumable 
qt.cpp is not using the typeinfo information. 

Andrew

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


Re: [Plplot-devel] QT rpath bug

2009-07-20 Thread Andrew Ross
On Mon, Jul 20, 2009 at 11:28:31AM -0700, Alan Irwin wrote:
 On 2009-07-20 15:59+0100 Andrew Ross wrote:
 
 
  Alan,
 
  When implementing rpath support for the libplplotqtd library you have
  added the qt path in front of the rest of the rpath directories. From
  the comments you added I think this is to ensure that you pick up
  your custom built qt libraries rather than the system ones. Unfortunately
  if you are using the system qt libraries this adds /usr/lib at the
  front of the rpath directory list and therefore you end up linking
  with system version of the plplot libraries rather than those in the
  install location. For me this is a headache. Of course the proper
  solution is to order the rpath variables so that the install prefix
  always appears first, but I can't see an easy way of doing that with
  your current approach. Any thoughts?
 
 Leave this with me for now.  I agree the described behaviour would be
 most annoying, and I will try to figure out a fix.

Thanks

Andrew

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


Re: [Plplot-devel] RE : Removed dynamic casts from Qt driver

2009-07-20 Thread Alan W. Irwin
On 2009-07-20 16:46+0100 Rochel, Alban wrote:

 Hello Andrew,

 Here is a version of the same patch based on R10166. There were indeed 
 conflicts with your changes.
 There should be about 5 versions for the callbacks:
 - rasterqt (for png, bmp...), sometimes specialised as pngqt, bmpqt... where 
 needed
 - svgqt
 - epspdfqt (sometimes epsqt and pdfqt)
 - qtwidget
 - extqt

This patch only makes the code 20 per cent larger, and I think that is a
completely acceptable price to pay for peace of mind about issues with how
dynamic casting is implemented on Linux.  Furthermore, qt.so built without
issues and make test_noninteractive in the installed examples tree generated
epsqt, pdfqt, bmpqt, jpgqt, pngqt, ppmqt, tiffqt, and svgqt results without
issues.  Also, c++/qt_example (which exercises extqt) worked fine.
Therefore, I have committed this as revision 10168.

Thanks, Alban!

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
__

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


[Plplot-devel] [ plplot-Feature Requests-2824647 ] Qt designer plugin for plplot widget

2009-07-20 Thread SourceForge.net
Feature Requests item #2824647, was opened at 2009-07-21 04:40
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=352915aid=2824647group_id=2915

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Qt designer plugin for plplot widget 

Initial Comment:
Create a plplot Qt Designer plugin.
Attached, please find the a file with the designer.pro, qtplplotplugin.h, 
qtplplotplugin.cpp and Makefiles.
Also, I have include the release binaries.
You will need to make sure plplotd.dll, qsastime.dll and qt.dll (this is the 
Plplot Qt driver are in your path). I simply copied these to $QTDIR\bin.
Then place qtplplotplugin.dll, qtplplotplugin.lib in $QTDIR\plugins\designer.

The module is loaded under Display Widgets with name QtPLWidget


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=352915aid=2824647group_id=2915

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel