On Tue, Apr 7, 2009 at 18:06, Andrew Straw wrote:
> John Hunter wrote:
>> We are not that far away, at least for src snapshots, os x binaries,
>> and the docs. The windows binary would take some work, as would a
>> linux binary, eg a debian package.
> FWIW, the Debian packagers will want to make
>
> BTW, my ideas were meant more as "how to wedge MPL quickly into glipy
> with a minimum of work" rather than "a talented programmer with one
> year
> of free time to come up with the coolest scientific workflow GUI"
> variety.
Sorry, I did not understood your proposal in the first place...
John Hunter wrote:
[...]
>> And is there a release schedule in mind? Any prospect of more
>> thoroughly automating official releases and of adding svn snapshot
>> releases? And of following numpy's buildbot example?
>>
>> I don't think I can help with any of this; I am just casting about to
>> see
Nicolas Rougier wrote:
>
> What I do generally to have "nice" OpenGL output is to render
> screenshots at high resolution and then use something like gimp to
> resize them. I agree that it is far from optimal but it's pretty
> decent for a scientific paper. Other solutions are vector renderi
What I do generally to have "nice" OpenGL output is to render
screenshots at high resolution and then use something like gimp to
resize them. I agree that it is far from optimal but it's pretty
decent for a scientific paper. Other solutions are vector rendering of
scene (using gl2ps for e
Nicolas Rougier wrote:
>
> I read the thread about mplot3d and the work that has been done by
> Jonathan Taylor. I wonder if an OpenGL backend is necessary at all.
> Jonathan's work seems to be great for simple 3D plotting while the
> mayavi mlab module is here for more "serious" rendering.
I read the thread about mplot3d and the work that has been done by
Jonathan Taylor. I wonder if an OpenGL backend is necessary at all.
Jonathan's work seems to be great for simple 3D plotting while the
mayavi mlab module is here for more "serious" rendering. I think I
will concentrate m
John Hunter wrote:
> In general, only very clear bugfixes which are unlikely to result in
> "surprise" breakages should go in. The _png patch, though a bug fix,
> has more of the feel of a feature enhancement, and given its
> complexity, should probably not go in to the branch unless someone
> mak
On Sun, Apr 5, 2009 at 6:38 PM, Eric Firing wrote:
> It is not always clear what should go in the 0.98.5 maintenance branch.
> For example, is the _png.cpp patch by Tobias, committed by Andrew, a
> bug fix or a new feature? I would have said the latter, but I can see
> arguments either way.
>
>
