Sent via BlackBerry from T-Mobile
-Original Message-
From: Ken McIvor <[EMAIL PROTECTED]>
Date: Fri, 27 Jul 2007 17:35:05
To:John Hunter <[EMAIL PROTECTED]>
Cc:matplotlib development list
Subject: Re: [matplotlib-devel] mpl1 draft
On Jul 25, 2007, at 12:09 PM, John
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 Wed, Jul 25, 2007 at 12:09:01PM -0500, John Hunter wrote:
> As for code readability, I'll also add that as a traits newbie, I am
> probably making things harder than necessary. But there are a lot of
> gotchas with traits usage, particularly in the area of instantiation,
> because you can easil
On 7/24/07, Ken McIvor <[EMAIL PROTECTED]> wrote:
> Since my original comment about traits I have been working hard to
> put my money where my mouth is. Attached is an experimental
> rendering system with an alternative transform architecture that does
> not require attribute change notification.
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 Tue, Jul 24, 2007 at 10:31:05AM -0500, Ken McIvor wrote:
> In retrospect, I should've been clearer about my objection to using
> traits in mpl1. I don't have any problem with enthought.traits in an
> abstract sense -- it seems like an excellent solution to the problems
> of attribute vali
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 thing could be
ac
On Jul 19, 2007, at 10:42 PM, Ken McIvor wrote:
>> = Z-ordering, containers, etc =
>>
>> Peter has been doing a lot of nice work on z-order and layers for
>> chaco, stuff that looks really useful for picking, interaction,
>> etc...
>> We should look at this approach, and think carefully about ho
On Jul 19, 2007, at 5:31 PM, Christopher Barker wrote:
>> Also, everything should be numpy enabled,
>> and the sequence-of-python-tuples approach that many of the
>> collections take should be dropped.
>
> who hoo!
>
> However, numpy doesn't handle "ragged" arrays well. I wonder if
> there's
> a
On Jul 19, 2007, at 12:18 PM, John Hunter wrote:
> = Data copying =
>
> Push the data to the backend only once, or only when required. Update
> the transforms in the backend, but do not push transformed data on
> every draw. This is potentially a major win, because we currently
> move the data a
On 7/20/07, Christopher Barker <[EMAIL PROTECTED]> wrote:
> > On Jul 19, 2007, at 12:18 PM, John Hunter wrote:
> >> I also plan to use the SWIG agg wrapper
>
> Where can I find that? I did some googling, and no luck.
mpl1/mpl1.py uses it It is available in matplotlib installs as
from matplot
> On Jul 19, 2007, at 12:18 PM, John Hunter wrote:
>> I also plan to use the SWIG agg wrapper
Where can I find that? I did some googling, and no luck.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600 Sand Point
Darren Dale wrote:
> Is there much demand for BSD-compliant svg, pdf, and ps backends?
Is the demand any different than for any other back end?
I wonder about the demand for BSD MPL over all. I know we want people to
be able to use MPL in proprietary apps, but the LGPL allows that.
How importan
Ken McIvor wrote:
>>But is PIL something we plan to depend on?
>
> I don't know, although I'm warming to the idea myself.
Is PIL's DrawAgg numpy-aware? I suspect not. That could make difference
when drawing lines with LOTS of points, for instance. I suppose we could
contribute the array-aware
On 7/20/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> er concern, though, is that there seems to be no way to update
> just a subregion of the PhotoImage from pure Python. I see that the C
> code in _tkagg.cpp can do this. Does that actually get used or is it
> always a full image?
Yes we
Ken McIvor wrote:
> 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't think there's a way to do this
>> in
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't think there's a way to do
> this
> in a raw Tkinter. B
Ken McIvor wrote:
>> This means someone needs to figure out how to get TkInter talking to
>> a python
>> buffer object or a numpy array.
>
> 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't think
On Thu, Jul 19, 2007 at 10:42:56PM -0500, Ken McIvor wrote:
> >= Traits =
> >I think we should make a major committment to traits and use them from
> >the ground up. Even without the UI stuff, they add plenty to make
> >them worthwhile, especially the validation and notification features.
> Code
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 Thu, Jul 19, 2007 at 12:18:21PM -0500, John Hunter wrote:
> = Z-ordering, containers, etc =
>
> Peter has been doing a lot of nice work on z-order and layers for
> chaco, stuff that looks really useful for picking, interaction, etc...
> We should look at this approach, and think carefully about
On Thu, Jul 19, 2007 at 03:31:26PM -0700, Christopher Barker wrote:
> > In matplotlib, the plot functions are matplotlib.axes.Axes methods and
> > I think there is consensus that this is a poor design.
>
> Well, the OO interface has always felt a bit clunky to me, but I'm not
> sure where else pl
John Hunter wrote:
>>> Do we want to use 3x3 or 4x4 to leave the door open for 3D developers?
>> 4X4 -- is there much cost?
>
> The potential cost is not in the 3x3 vs 4x4, but in the extra row of
> junk data you would store in the data matrix, which is N extra values
> for plotting N points . T
(oops, I meant to send that to the matplotlib list)
Hi,
I was looking at the transform code recently..
On Thu, July 19, 2007 7:31 pm, John Hunter wrote:
> The potential cost is not in the 3x3 vs 4x4, but in the extra row of
> junk data you would store in the data matrix, which is N extra values
On Thursday 19 July 2007 7:31:11 pm John Hunter wrote:
> On 7/19/07, Christopher Barker <[EMAIL PROTECTED]> wrote:
> > How many back-ends does the future hold? It seems if the GUI toolkits
> > all use *Agg, then that's only one render for all of them. Then we need:
> >
> > SVG
> > PDF
> > PS
> > Ca
On Thursday 19 July 2007 6:31:26 pm Christopher Barker wrote:
> > There is also the question of whether
> > we want to pay up and use 4x4 from the ground up and just ignore the
> > 3rd dimension to open the door for 3D support.
>
> I say yes! 3-d really is a very often needed and requested feature.
On 7/19/07, Christopher Barker <[EMAIL PROTECTED]> wrote:
> > This is potentially a major win, because we currently
> > move the data around on every draw.
>
> Is it that expensive to push data around? In any case, it does sound
> cleaner and more efficient not to.
It can be very expensive. Imagi
Lots of god stuff John!
> There is also the question of whether
> we want to pay up and use 4x4 from the ground up and just ignore the
> 3rd dimension to open the door for 3D support.
I say yes! 3-d really is a very often needed and requested feature.
Sure, we can go to VTK or something for re
On Jul 19, 2007, at 3:05 PM, Bill Baxter wrote:
> Chaco may be formidable and complex, but so is the list of features
> and requirements you just posted. What about just focusing on a Pylab
> wrapper for Chaco? And working with Peter to make Chaco everything
> you envison. Or does Chaco have th
On 7/20/07, John Hunter <[EMAIL PROTECTED]> wrote:
> = Chaco and Kiva =
>
> It is a good idea for an enterprising developer to take a careful look
> at the current Chaco and Kiva to see if we can further integrate with
> them. I am gun shy because they seem formiddable and complex, and one
> of m
On Jul 19, 2007, at 12:28 PM, Fernando Perez wrote:
> Is Peter Wang on this list? If not, perhaps you should CC him and tip
> him to come over. I know Robert monitors this, but we shouldn't make
> him the single point of responsibility for keeping tabs on the bridges
> with Chaco/ETS.
Actually
John Hunter wrote:
> On 7/19/07, Eric Firing <[EMAIL PROTECTED]> wrote:
>
>> The instructions still say to check out traits 2.0, but Robert is
>> recommending that we go with traits 3. Do you really want to stick with
>> version 2 now?
>
> No, I'm happy to move over. But I spent way more time g
On 7/19/07, Eric Firing <[EMAIL PROTECTED]> wrote:
> The instructions still say to check out traits 2.0, but Robert is
> recommending that we go with traits 3. Do you really want to stick with
> version 2 now?
No, I'm happy to move over. But I spent way more time getting traits
working and inst
Darren Dale wrote:
> On Thursday 19 July 2007 02:26:05 pm John Hunter wrote:
>> On 7/19/07, Darren Dale <[EMAIL PROTECTED]> wrote
>>
>>> On Thursday 19 July 2007 01:18:21 pm John Hunter wrote:
>>>
>>> I have not been able to install traits by following the instructions in
>>> mtraits.py.
> [...]
>
On Thursday 19 July 2007 02:26:05 pm John Hunter wrote:
> On 7/19/07, Darren Dale <[EMAIL PROTECTED]> wrote
>
> > On Thursday 19 July 2007 01:18:21 pm John Hunter wrote:
> >
> > I have not been able to install traits by following the instructions in
> > mtraits.py.
[...]
> I encountered a similar
On Thu, Jul 19, 2007 at 01:26:05PM -0500, John Hunter wrote:
> On 7/19/07, Darren Dale <[EMAIL PROTECTED]> wrote
> > On Thursday 19 July 2007 01:18:21 pm John Hunter wrote:
> > I have not been able to install traits by following the instructions
> > in
> > mtraits.py. easy_install is pulling in en
On 7/19/07, Darren Dale <[EMAIL PROTECTED]> wrote
> On Thursday 19 July 2007 01:18:21 pm John Hunter wrote:
> I have not been able to install traits by following the instructions in
> mtraits.py. easy_install is pulling in enthought.util-3.0a1, which conflicts
> with enthought.resource-2.0b1. Why
Hi John,
On Thursday 19 July 2007 01:18:21 pm John Hunter wrote:
> I've been working on a laboratory in which we can fruitfully discuss,
> test, implement mpl1 design issues.
[...]
> You will need the latest svn matplotlib and
> the latest svn enthought traits 2 -- see the header of mpl1/mtraits.
On 7/19/07, John Hunter <[EMAIL PROTECTED]> wrote:
> = Chaco and Kiva =
>
> It is a good idea for an enterprising developer to take a careful look
> at the current Chaco and Kiva to see if we can further integrate with
> them. I am gun shy because they seem formiddable and complex, and one
> of m
I've been working on a laboratory in which we can fruitfully discuss,
test, implement mpl1 design issues. I am a big fan of
python-as-modeling-language approach to design. I have tried to solve
from the ground up some of the design flaws in matplotlib -- the
transformation architecture and the d
40 matches
Mail list logo
