A good, interactive plotting package

Any sense of when this might happen?

Is there anybody outside of enthought who are deploying applications
based on TraitsUI for Windows/Mac/Linux? I would love to hear about
successful examples before committing to more dependencies in our own
applications.

What's going to happen with Qt/Gtk/Tkinter backends? We are already
using wx so this isn't an issue for us, but last time I looked TraitsUI
only had wx support.

A specific concern we had when investigating Traits a couple of
years ago was long start up times. The lack of clear boundaries
between traits and other parts of enthought was a further concern,
since it would make deployment more difficult.

- Paul

···

On Wed, Feb 13, 2008 at 08:24:35AM -0600, John Hunter wrote:

As I mentioned in my earlier post, when we migrate to traits
for matplotlib artist properties, we will get a pretty rich
interactive UI configuration layer.

> As I mentioned in my earlier post, when we migrate to traits
> for matplotlib artist properties, we will get a pretty rich
> interactive UI configuration layer.

Any sense of when this might happen?

There is no specific timeline, but Darren did a bunch of the hard work
getting a traits enabled rc configuration option (off by default) in
0.91.2. The plan is to turn get this turned on by default in the next
release of the trunk (0.98) so we can get as much pain in at once
rather than in doses. Since migrating apps to the trunk requires some
changes in the API (transformations, bounding boxes) already, this
would probably be a good time to migrate the rc configuration too.

Is there anybody outside of enthought who are deploying applications
based on TraitsUI for Windows/Mac/Linux? I would love to hear about
successful examples before committing to more dependencies in our own
applications.

Well, we are already installing enthought.traits and have not
experienced any significant user problems, so I don't think we will be
introducing a significant dependency here. This can be done so that
users who have a UI enabled traits will get the UI benefits and those
who don't will get the basic traits benefits minus the UI. So we
wouldn't need to depend on the UI components, and we have already
(mostly) solved the dependency problem on the non UI component (see
matplotlib/lib/enthought).

I say mostly because there is a problem that Gael first reported
recently that having our enthought traits installed ahead of
enthought's version can break some enthought apps, so we need to
address this. And yes, there are some startup time problems with a
namespace enabled version of enthought's packages that have caused
some concern.

What's going to happen with Qt/Gtk/Tkinter backends? We are already
using wx so this isn't an issue for us, but last time I looked TraitsUI
only had wx support.

As far as I understand, there is a fully featured wx version and qt is
coming along nicely. Again, matplotlib would continue to work as
before with the other UI backends, your just wouldn't get the traits
dialogs.

A specific concern we had when investigating Traits a couple of
years ago was long start up times. The lack of clear boundaries
between traits and other parts of enthought was a further concern,
since it would make deployment more difficult.

This is getting much better, but it is still a work in progress.
traits is now in debian, for example.

JDH

···

On Feb 13, 2008 10:04 AM, Paul Kienzle <pkienzle@...537...> wrote:

On Wed, Feb 13, 2008 at 08:24:35AM -0600, John Hunter wrote:

Is there anybody outside of enthought who are deploying applications
based on TraitsUI for Windows/Mac/Linux? I would love to hear about
successful examples before committing to more dependencies in our own
applications.

I, in the lab. People at Airbus research labs (Bristol, UK), people at
Estimages (http://www.estimages.com/), people at jgeophysics, and quite a
few other researchers, for in house applications in labs (just have a
look at the enthought-dev mailing list. Airbus have actually paying a
former Enthought employee (Martin Chilvers) to develop Envisage3, and
have payed Phil Thompson (author of PyQT) to do the QT backend. This
backend is working now quite well as they are using it for their
day-to-day work.

A specific concern we had when investigating Traits a couple of
years ago was long start up times.

I don't really think this has improved a lot. You would have to try it
out to see. However my experience is that if you are not loading Wx,
traits by itself is fast, if you are loading Wx, you are limited by the
cost of loading Wx. I may be wrong, as I have no hard numbers.

The lack of clear boundaries between traits and other parts of
enthought was a further concern, since it would make deployment more
difficult.

That's pretty much solved. The Enthought Tool Suite has been split in
projects, each of them that can be further split in packages (just a look
at their SVN structure will tell you exactly how it is done:
https://svn.enthought.com/enthought/browser ).

Cheers,

Ga�l

···

On Wed, Feb 13, 2008 at 11:04:13AM -0500, Paul Kienzle wrote: