Ted Drain wrote:
> One of the problems we've had is trying to design an auto-scaling
> algorithm that works well with any type date format since the date
> strings can be so large horizontally. I believe that having the draw
> time elements be able to query the renderer for things would help
> this out tremendously since we could then have the tick generator
> space out the dates along nice boundaries without overlapping the date strings.
This is only half of the solution; the other half is controlling the
order in which things are done. In its most general form, this would
involve some sort of dependency tree, automatically generated. I
imagine this is how layout engines work. I know that Andrew contributed
one quite some time ago, and so far I have done nothing with it. (Sorry,
Andrew.) A simpler mechanism suggested by John was a set of pre- and
post- hooks in draw functions that would enable one to manually put in
dependencies and ensure that dependent calculations are done in the
right order. In all of this, it is critical to avoid chicken-and-egg
situations: e.g., label font size depends on physical room available,
but tick spacing adjusts to accommodate the labels.
The transforms module already does part of what we are talking about
here; dependency information is accumulated as BinOps are built from
other BinOps, and everything is resolved at rendering time.
I think that any changes like this need to wait in line behind the
upcoming numpyfication, and it would be nice to have some full outlines
of alternative strategies before picking one and proceeding.
Ideas and strategy sketches tend to get lost in the email stack; would
it help to have a wiki page for discussion of major design questions
like this? Or is this overkill?
> At 01:07 PM 4/7/2007, John Hunter wrote:
>> On 4/7/07, Eric Firing <efiring@...> wrote:
>>> I put back get_lines() in collections and fixed a related bug in legend,
>>> so the test script now works in the sense that it makes a legend. It
>>> puts in an unlabeled line, presumably corresponding to the line
>>> collection making up the error bars. Maybe legend provides a way to
>>> avoid this. I haven't looked.
>> If I'm understanding the problem you are describing correctly, it
>> looks like _nolegend_ needs to be set here. For artists we do not want
>> to be included in the legend, the label should be set to '_nolegend_'
>> and legend will ignore it in auto-legending. Or at least it should
>> and if it is not it is a bug.
>>> The larger problem, and the one that probably made me yank get_lines
>>> (without realizing the legend code was using it--my mistake--I do try to
>>> check for things like that) is that legend really wants to know the
>>> draw-time locations of all plot elements, and for collections (among
>>> other things) this cannot be determined in general. The collection
>>> get_lines and get_verts methods can give the right answer to legend only
>>> if the data and offset transforms are the same. Sometimes they are,
>>> sometimes they are not. LineCollection.get_lines() probably could be
>>> improved to do a better job than at present, but never a perfect one.
>> One approach is to make every artist provide a get window extent which
>> returns a bounding box. There is the issue of how to get the renderer
>> before draw time, but we could fix this. It would be nice for draw
>> time layout algorithms to be able to assume this method, and a few
>> objects already provide it, eg text.
>>> This is an example of a more widespread problem that we have thought
>>> about and discussed (including some good ideas from John, of course),
>>> but solving it is not simple. For the time being, at least, we are
>>> stuck with some imperfections.
>>> In any case, thanks for bringing the legend/LineCollection bug to my
>>> attention. This is the sort of thing it is nice to get cleaned up
>>> before the next release, coming soon. Do you know of some other simple
>>> bugs like this we should look at ASAP?
>> I added unit/legend_unit.py script to create legends using a scatter
>> and vlines, which create RegPolyCollections and LineCollections. We
>> should use more stuff like this in general, unit scripts which
>> exercise the more arcane usages.