Hi, It doesn't seem that there is much interest in a
> Visio backend I saw John saying that the list of
> contributors was already huge, etc. so I put up my own
> "local" version of matplotlib, so I can continue easily
> working on the Visio backend.
Sorry for the silence on this -- I confess I had never heard of Visio
before your earlier post and did a little looking on the microsoft web
site. It looked to me more like a flow chart application than a
graphing tool -- is that correct?
It is not an issue of a list of contributors -- I would love to have a
huge list -- it is more an issue of a proliferation of backends. We
have too many, and most are incomplete, so my threshold is getting
higher for what I would like to see in the main distribution, because
often what happens is a developer adds just the features they need and
leave it at that and we have backends that are only partially
functional and poorly maintained. I prefer to see a few core backends
that target the most popular GUIs and image formats. Does you backend
support properly aligned rotated text, mathtext, images, collections
or images? These are the features most people leave out because they
are harder to implement. When we want to make any change to the
backend API we have to port these to all the backends and it is
usually me or one of a couple of developers to do this since the
original developer may have moved on.
That said, I would always be happy to include a (mostly) full featured
backend for a format a large number of users want. Short of that, I
think distributing it through another channel, or making a sandbox in
the mpl distribution, with pointers to the source on the website will
suffice. If you'd like to send a blurb for the website pointing to
your code I'll include it, or if you think given the above that the
Visio backend should be in the main distribution I'm happy to hear the
argument. I don't use Windows so I am not really in tune with that
side of the development world, and am happy to be educated.
That said, I would always be happy to include a (mostly) full featured
backend for a format a large number of users want. Short of that, I
think distributing it through another channel, or making a sandbox in
the mpl distribution,
FWIW, Jeff Whitaker 's basemap and my mplsizer (wx-like sizer
implementation for mpl) live in the "toolkits" directory of the mpl
svubversion tree. I think that partially-implemented backends could also
happily live there.
It's also feasible to allow runtime discovery of backends through the
use of setuptools' plugins (to name one route). I understand completely,
however, that there may be a resistance to adding a dependency on
setuptools.
First, my apologies for being pretty rude by storming in the mailing
list without even introducing myself and by doing so now, it will
answer partly your questions on my intentions concerning the Visio
backend. I’m a researcher in the Nokia Research center (yeah, the
mobile phone thing) and I’m currently working for a standardization
alliance. There, I lead the modeling of a quite complex network-like
system. One very important goal is to have a platform independent
simulation engine, which means that the library used to visualize the
simulation results has to be platform independent too. Since many
companies are involved, it’s pretty important to be tool agnostic: in
practice it means we try to reuse open source software as much as
possible. So I searched quite some time to find an appropriate library
for us and matplotlib was by far the best I could find given our
requirements. Specially so that I have scripted a big part of the
simulation engine (written in C++) by using python, so perfect match
Since standardization means also writing specifications, documents,
reports, etc. and the tools we use are Microsoft based, Visio is the de
facto tool for all drawings, schema, graphics, etc. put in the
specification or any other documents. So in fact, Visio can do much
more than just flowcharts: it’s equivalent in Unix world would be
something like Dia I think. In this standardization context, I need to
have a fully featured backend and in a very short time even: I can’t
afford to wait 6 months to have it done.
I completely understand your point about having a high threshold when
talking of bringing in yet another backend ;-): it’s a good and healthy
attitude to keep the quality of the package high. And indeed, the visio
backend supports aligned rotated text (even if I still have a small bug
to correct). But I have to admit that I didn’t think about the mathtext
so far, I have to look if it’s possible at all to support it and how it
could be done. For the support of images, it doesn’t support it yet,
but it shouldn’t be a problem. I don’t know what you mean by
“collections” … sorry. I’m pretty new to matplotlib and don’t know
all the goodies yet.
My idea to judge the “maturity” of the backend is pretty simple: I will
take all the examples you have made for matplotlib and see how many the
backend can correctly draw in Visio. Based on this, decision can be
made to include it in the “main stream” of matplotlib or leave it as an
offspring. Both solutions are fine by me. So my conclusion is to say
that I will continue the development of the Visio backend as an
offspring. If later people agrees that it adds a value to bring the
Visio backend in the main distribution of matplotlib, I will be happy
to do just that.
Yes, good point. But for the time being, I have enough space on my web
page and uses my own CVS server … it just reduces the “management”
overhead, since I can control everything easily on my own.
For the plugin idea, I will let it to you guys … I’m too new to make
a comment on this
BR,
Michel
Andrew Straw wrote:
···
John Hunter wrote:
That said, I would always be happy to include a (mostly) full featured
backend for a format a large number of users want. Short of that, I
think distributing it through another channel, or making a sandbox in
the mpl distribution,
FWIW, Jeff Whitaker 's basemap and my mplsizer (wx-like sizer
implementation for mpl) live in the "toolkits" directory of the mpl
svubversion tree. I think that partially-implemented backends could also
happily live there.
It's also feasible to allow runtime discovery of backends through the
use of setuptools' plugins (to name one route). I understand completely,
however, that there may be a resistance to adding a dependency on
setuptools.
I saw John saying that the list of
and by doing so now, it will