Now that I've got a version of WxMpl that works properly I'd like to
transition it over to being a matplotlib toolkit. From poking around
in svn, it looks like the correct thing to do would be to import the
source directory into '$(SVNROOT)/trunk/toolkits/wxmpl'.
Is that correct?
I'd like
On Jun 12, 2008, at 3:22 PM, John Hunter wrote:
>
> If some wx guru sees an easy fix here, by all means add it.
Not to imply that I'm a guru, but I'll try to look into it this evening.
> Otherwise, we should decide on a minimum wxpython version for the
> trunk and raise an exception.
I'm always
Nils,
To the best of my knowledge the wx.GraphicsContext class is not
present in wxPython 2.6.
Ken
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open S
On Nov 8, 2007, at 10:23 AM, Michael Droettboom wrote:
>
> So, we need to look at the pros/cons of continuing to support these
> legacy APIs going forward.
I've got some more benchmarks for the WX and WXAgg backends in
trunk. It looks like using ssh with compression or the NX remote
desktop b
On Nov 8, 2007, at 12:17 PM, Christopher Barker wrote:
>
> I wonder if there is another way to speed that up with Agg -- can you
> compress the bitmap data to pass it to the Xserver? is that happening
> already?
I'm not aware of any obvious method for enabling compression in
remote X11 connectio
On Aug 29, 2007, at 5:12 PM, Hardeep Nahal wrote:
>
> Yes, I think my libpng library was corrupt, but when I tried
> reinstalling, it still wouldn't work.
It's not corrupt, it's just not the correct kind of library. There
are two types: static libraries (.a), which get compiled into a
program
On Aug 29, 2007, at 1:59 PM, Hardeep Nahal wrote:
>
> build/temp.linux-x86_64-2.3/src/_na_backend_agg.o -L/usr/local/lib
> -L/usr/lib -L/usr/lib64 -L/usr/local/lib -L/usr/lib -L/usr/lib64 -lpng
> -lz -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o
> build/lib.linux-x86_64-2.3/matplotlib/backends/_na_ba
On Jul 25, 2007, at 12:09 PM, John Hunter wrote:
>
> Hi Ken -- sorry for the radio silence, I'm not intentionally ignoring
> you. Real life has made some demands on my time of late, and probably
> will until next week, but I was able to download, read through and
> test your code.
I appreciate yo
On Jul 24, 2007, at 10:46 AM, Gael Varoquaux wrote:
>
> AFAIK chaco is based on this approach.
Not as such. Chaco uses traits for its high-level plot objects but
the rendering system, Kiva, does not appear to use traits all.
mpl1.py is using traits to maintain pre-calculated affine
transform
On Jul 23, 2007, at 7:18 PM, Peter Wang wrote:
On Jul 19, 2007, at 10:42 PM, Ken McIvor wrote:
Code readability is also a concern to me -- the experience of
reading mpl1.py suggests to me that newcomers might find traits a
bit too "voodoo". I'm confident that the same
On Jul 20, 2007, at 6:26 AM, Michael Droettboom wrote:
> Ken McIvor wrote:
>>>
>> I think PIL's ImageTk module would do the trick for converting
>> RGBA ->
>> PIL Image -> Tk Bitmap/PhotoImage.
>
> That's what I was thinking, too. I don
Wow, lots of food for thought. Thanks John!
On Jul 19, 2007, at 12:18 PM, John Hunter wrote:
= Objects that talk to the backend "primitives" =
Have just a few, fairly rich obects, that the backends need to
understand. Clear candidates are a Path, Text and Image, but despite
their names, don'
On Jul 5, 2007, at 3:48 PM, Eric Firing wrote:
>
> This qualifies as a wx bug, doesn't it?
I believe so. I'll file it.
> If wx doesn't retain the reference, then instead of a segfault
> shouldn't it raise an exception?
I'd expect wx.GetApp() to work like the rest of wxPython and always
retu
On Jul 5, 2007, at 2:13 PM, Michael Droettboom wrote:
>
> Interesting. I don't get that, but I do get some random segfaults (I
> got lucky the first time I tested).
It looks like wxPython doesn't retain a reference to the wxApp PyObj
for you:
[EMAIL PROTECTED]:~/Projects/matplotlib-svn
On May 31, 2007, at 12:51 PM, Charlie Moad wrote:
>
> It would be nice to use the pure-python wx so we don't have to
> provide separate 2.6 and 2.8 builds.
At this point it should be possible to include a _wxagg.so built for
wxPython 2.6 and have everything Just Work with 2.8. If mixing
ver
On May 31, 2007, at 12:42 PM, Christopher Barker wrote:
>
> I think all the real work is done, but I"m not totally sure what's
> checked in now. There may be some changes needed to the build
> scripts so
> that it doesn't try to build the accelerator by default.
I'm not sure either. My modifica
On Mar 16, 2007, at 4:24 PM, Berthold Höllmann wrote:
>
> Applying the following patch current matplotlib SVN compiles against
> wxPython 2.8.1.1. The resulting module seems to work.
That test is present in setupext.pu because I don't intend to support
the C++ WXAgg accelerator module with wxPyt
On Mar 16, 2007, at 9:28 AM, Berthold Höllmann wrote:
>
> I need a python compile with VC6. This python also needs a
> matplotlib.
Chris Barker and I worked on this a while ago, and I believe we
decided it was impossible due to bugs/limitations in the VC++ 6
compiler.
Ken
---
On Feb 23, 2007, at 8:00 PM, Andrew Straw wrote:
>
> 2) make our own distutils monkeypatch a la setuptools. Looking at
> setuptools/dist.py, this doesn't look trivial -- certainly beyond my
> free bandwidth capacity.
I've written a script that attempts to simplify writing setup.py's
that include
On Feb 22, 2007, at 5:17 PM, Christopher Barker wrote:
>
> I had written some "smarts" for setup.py (and utilities it uses) to
> do a better job of finding the correct wx-config. Is there any
> point to that now? If so, I'll sent it along to you.
Debian stable is going to be released soon with
FYI Christopher, et al. - Due to operator incompetence the changes I
blabbed about earlier haven't hit the repository yet.
Ken
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and y
On Feb 22, 2007, at 1:11 PM, Christopher Barker wrote:
>
>> More importantly, I written another set of the agg-to-wx.Bitmap
>> conversion routines that uses the new BitmapFromBufferRGBA()
>> function in wxPython 2.8.
>
> Are these in Python or c++?
Since BitmapFromBuffer() and its aforemention
Hello everyone,
I just committed some accelerator-related updates to the WXAgg
backend. I have fixed the problem with the way I was calling the
wxBitmap constructor in _wxagg.src. More importantly, I written
another set of the agg-to-wx.Bitmap conversion routines that uses the
new Bitmap
On Sep 10, 2006, at 9:50 AM, Bill Baxter wrote:
>
> I've just uploaded two patch files that apply the changes discussed
> in this thread.
Thanks Bill. I'm sorry I've been dragging a** on getting your
patches reviewed. I'll try get to it early this week.
Ken
On 08/31/06 13:43, Christopher Barker wrote:
> Ken McIvor wrote:
>
> a wxBitmap is the same format as the native rendering system. While most
> systems use 24b RGB (or 32b RGBA), people can still run displays at
> 16bpp or whatever, so it's still needed.
I can under
On 08/28/06 12:19, Christopher Barker wrote:
>
> wx is really due for an update to support alpha properly. But I guess
> you'll always have problems with different data formats.
I think they added preliminary support for alpha channels in 2.5, in the form
of wx.Image.HasAlpha(). My beef is that
Chris,
Thanks for the cross-post. I'm not sure this approach will help
speed up the wxAgg accelerator, but I'll put it on the list of things
to look into. The problem I foresee is that the Agg renderer's RGBA
data has to be converted to RGB before a wxImage can be created by
convert_agg2
On Jul 30, 2006, at 8:07 AM, Bill Baxter wrote:
> I went ahead and implemented this yesterday on a long plane flight.
> The changed files (backend_bases.py, and widgets.py) are attached to
> the above tracker entry. Also I changed backend_wx.py to grab the
> mouse generally when you click on the
Andrew,
This looks very cool, and I'm looking forward to playing around with
it. Thanks for the hard work!
Shooting from the hip, here are some initial comments. I may be able
to submit patches for some of the more innocuous items later in the
week.
1. It appears that as_sizer_element()
On Jul 24, 2006, at 9:16 PM, Bill Baxter wrote:
> I think all these problems could be fixed if the display interface
> were turned into a separate process that communicates with the Python
> program using pipes or some other IPC mechanism. I used this
> technique in a (C/C++) image debugging utili
Steve,
I am aware of the caveats associated with the "name" attribute, which
is why the code I sent you attempts to do the right thing when it
doesn't exist. I hadn't considered the case of stdout, but you could
probably detect situations like that by testing to see if the
extension is th
31 matches
Mail list logo
