I would like to ask you if there is plan to include wxPseudoDC into wxWidgets?
In our wxPython application is used wx.PseudoDC. Small part of the
code is written in C++. Constructor of the C++ class has argument
pointer to wxPseudoDC instance. Basic ideas is
import cdriver
dc = wx.PseudoDC()
driver = cdriver.CDisplayDriver(dc) # wrapped by SWIG
driver->DrawContent()
...
Ideally C++ constructor should accept pointer to wxDC instead of
wxPseudoDC, problem is that some operations request wxPseudoDC, e.g.
moving selected objects (TranslateId), etc.
The basic problem is that this C++ library must be link against
_gdi_.so which is basically not so good idea (linking against Python
extension). Moreover it requests ugly hacks like creating symlink in
/usr/local/lib to _gdi_.so.
Any ideas how this could solved without replacing wxPseudoDC with wxDC?
I would like to ask you if there is plan to include wxPseudoDC into wxWidgets?
No plans, but if you create a patch for it that includes docs and a C++ sample app then it might be.
In our wxPython application is used wx.PseudoDC. Small part of the
code is written in C++. Constructor of the C++ class has argument
pointer to wxPseudoDC instance. Basic ideas is
import cdriver
dc = wx.PseudoDC()
driver = cdriver.CDisplayDriver(dc) # wrapped by SWIG
driver->DrawContent()
...
Ideally C++ constructor should accept pointer to wxDC instead of
wxPseudoDC, problem is that some operations request wxPseudoDC, e.g.
moving selected objects (TranslateId), etc.
The basic problem is that this C++ library must be link against
_gdi_.so which is basically not so good idea (linking against Python
extension). Moreover it requests ugly hacks like creating symlink in
/usr/local/lib to _gdi_.so.
Any ideas how this could solved without replacing wxPseudoDC with wxDC?
It would be very ugly but you could probably build a PseudoPseudoDC C++ class that during initialization imports the _gdi_ module and extracts from it the function pointers for the methods of the real PseudoDC class, and then redirects calls to those methods through the function pointers. Like I said, very ugly.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
I would like to ask you if there is plan to include wxPseudoDC into
wxWidgets?
Robin Dunn:
No plans, but if you create a patch for it that includes docs and a C++
sample app then it might be.
In our wxPython application is used wx.PseudoDC. Small part of the
code is written in C++. Constructor of the C++ class has argument
pointer to wxPseudoDC instance. Basic ideas is
import cdriver
dc = wx.PseudoDC()
driver = cdriver.CDisplayDriver(dc) # wrapped by SWIG
driver->DrawContent()
...
Ideally C++ constructor should accept pointer to wxDC instead of
wxPseudoDC, problem is that some operations request wxPseudoDC, e.g.
moving selected objects (TranslateId), etc.
The basic problem is that this C++ library must be link against
_gdi_.so which is basically not so good idea (linking against Python
extension). Moreover it requests ugly hacks like creating symlink in
/usr/local/lib to _gdi_.so.
Any ideas how this could solved without replacing wxPseudoDC with wxDC?
Robin Dunn:
It would be very ugly but you could probably build a PseudoPseudoDC C++
class that during initialization imports the _gdi_ module and extracts from
it the function pointers for the methods of the real PseudoDC class, and
then redirects calls to those methods through the function pointers. Like I
said, very ugly.
sorry for ignorance, but is it really needed? E.g. on Mac it's
possible to avoid it by using '-bundle -undefined dynamic_lookup'
linker switches. Symbols are already imported by 'wx' or at least
'wx._gdi' module. No way how to avoid undefined symbols on Linux or MS
Windows without PseudoPseudoDC or similar hacks?