AFAIK this is both terminally broken and a known issue.
The exit strategy for that at this stage is to enable Robert's
gnomeprint work (probably in the next release). It is still a
work in progress, but has the advantage by virtue of actually
working.
I've been happily 'paperless' for so long now that I'm not
terribly current with this code in 2.5, but searching past
threads in the wx-dev list should shed some clues if you want
better details on the matter.
The printing code used to work in 2.4, I'm not sure exactly
what happened to change that, or precisely what is causing what
you are seeing, but I'd suggest anyone serious about printing
and in a hurry should look at cvs HEAD and build with
--with-gnomeprint.
We have a schedule for the 2.5.4 release now and including this
in the packages is a goal for that, but its a bit early to make
many promises about what will actually make it past the post...
best,
Ron
On Tue, Feb 08, 2005 at 02:01:47AM -0800, Ken Harris wrote:
>
> Yeah, something is definitely wrong. It does appear to be returning a
> string from _windows_.new_Printout() in _windows.py (if you print
> type(newobj), for example). I guess in _wrap_new_Printout() in
> _windows_wrap.cpp 'result' is actually a wxPyPrintout* (C's typing
> system requires it), and it's not jumping to the "fail:" label, which
> means wxPyMake_wxObject(result,1) is turning a wxPyPrintout* into a
> Python string object. (Does that make any sense?) But it uses
> wxPyMake_wxObject(), and everything uses that, so it can't be *that*
> broken, right?
>
> So I suspect there's a problem with the wxPyPrintout object itself, but
> that's no surprise. And now I'm deeper into the wx-Py interface than I
> know what I'm doing (so far).
>
> I looked at the diffs (on ViewCVS) and this function
> (_wrap_new_Printout()) of src/gtk/_windows_wrap.cpp has only changed
> trivially (using true instead of True) since the 2.4 days. So I think
> it's safe to say that's not the problem.
>
> I don't know what's going on. The further I dig, the more complex (and
> undocumented!) it becomes.
>
> There don't seem to be any wxPython binaries in Debian with debugging
> info, and I'm not up for building my own wxPython binaries tonight :-),
> so I'm calling it a night.
>
> If it helps, a really simple way to demonstrate this problem is:
>
> import wxversion
> wxversion.select('2.5.3')
> import wx
> wx.PySimpleApp()
> wx.Printout()
>
> Result:
>
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File
> "/usr/lib/python2.3/site-packages/wx-2.5.3-gtk2-unicode/wx/_windows.py",
> line 4363, in __init__
> self.this = newobj.this
> AttributeError: 'str' object has no attribute 'this'
>
> WX2.4 doesn't require a wx.App object, so the equivalent there is
> simply:
>
> >>> import wx
> >>> wx.Printout()
> <wxPython.printfw.wxPrintout instance; proxy of C++ wxPrintout instance
> at _82431f8_wxPyPrintout_p>
>
> My best guess is that this isn't Debian-specific, but may be GTK
> +-specific. Can the folks upstream offer any help with this?
>
> It would be nice to be able to print. :-)
>
>
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
