[reportlab-users] Widgets as Flowables...

[Andy Robinson]

> It's not about lines (1) and (2)! ;-) It's about using features
> of the PDF canvas in a widget. As there is no canvas available
> there, you need to make use of it in the wrapping drawing. This
> leads to splitting this functionality over the widget and draw-
> ing. E.g. you collect data of active, clickable rectangles in-
> side the widget, and reuse them in the drawings's draw method.

OK, so your goal is clickable elements in a drawing?
I had not understood this.  If in doubt, start with
a clear description of what you're trying to make!
This makes sense; we've been asked about clickable image 
maps for web charts too.

I still think widgets and drawings should know nothing
of PDF or any other renderer.  A better approach is
that widgets carry extra information such as a bounding box
and declarative stuff like "I carry a tooltip with message x",
and we extend the PDF renderer to draw these.  Kind of like
SVG.

Now, here's a problem for you. Let's say I want a bar chart in
a GUI in which the bars are clickable.  A naive implementation
would let me do something like
   drawing.getObjectsUnder(x,y)
and let me see what is under the mouse click.  But not every
thing in the chart should be clickable.  And if you want to
select a data point, it cannot be zero or one point across;
the 'click region' must be a bit bigger.  So in general I
doubt there is a 1-1 correspondence between the widgets in
the drawing and the things you want to click. Maybe a better
approach is to have
   drawing.getInteractiveObjects() 
which you can call after it draws and get the info needed
for, say, an HTML image map.

> My understanding of drawings is that I should not use them instead
> of widgets, isn't it? Building blocks for domain-specific graphics
> libraries are widgets, not drawings, right? 
Right.
> And drawings should be used only within documents.
Or saved directly in some graphics file format...

But we did have some 'functionality leakage' - it was convenient
to let Drawing inherit from Group, assisting in the implementation
of scaling for example.

 
> What then, probably, is misleading is the fact that the code for
> all renderers mentions only drawings as the things they are able
> to render, where in fact they also can render shapes and widgets.

That was not intended - by me, anyway :-)  I think that
with better refactoring we could hide this extra behaviour.
This should not be counted on in future and I should put
a clear warning in the docco and maybe an isinstance test
inside each renderer.

> Alas, they cannot render symbols or flags or markers, although
> all of these are subclasses of Widget (they have a size attribute
> but no width or height)...
Exactly.  In principle you could make the renderer draw such a thing
on a canvas, but couldn't easily use it in Platypus.

The alternative is to say that widgets can be used everywhere,
somehow try to merge the "object graphics" and "canvas"
paradigm, but we have to give them known sizes and I have 
to think abut what capabilities they need.  Widgets are
already straining the limits of Python's OO; and they still
don't do stuff we really need, like per-instance hiding
of attributes depending on their context.  If we have to 
give them extra responsibilities then it may get even harder 
to subclass them.  I'm not against this, I just think it needs 
a clean rethink of the object model, maybe Python 2.2 features, 
and thus belongs in a different major version.

Thanks,

Andy