[reportlab-users] Widgets as Flowables...

[Robin Becker]

In article <9720DEE0-D2BD-11D6-A41F-00039345C610@darwin.in-berlin.de>,
Dinu Gherman <gherman@darwin.in-berlin.de> writes
>I've also seen examples of widgets returning a Drawing instance in
>their demo() method, which I guess is not the way it should be (un-
>less, of course, that was the proclaimed idea behind the demo method).
as I recall the rewrite it was Andy and Dinu who demanded a working demo
and as most of the demos were by Dinu I guess he takes credit in our
non-blame culture. 

The demo has to be a drawing otherwise Dinu's graphdocpy wouldn't work
at all.

Andy insisted that all the higher level things (ie above shape) be
instantiatable (if that's the way we spell it) without arguments so by
my reasoning all those classes are already their own widget demo as soon
as you get one it's potentially addable to a drawing.

I think the main problem (or advantage if that's the way you think) is
that there are two phases i.e. construction and rendering and these are
kept completely separate. It's very hard to talk about a widget's size
when it's unknown until you draw it. That makes things very hard for
common things like geometry management (eg I would like to attach this
widget's C(enter) to the NW corner of that widget) so that is always
postponed to the render phase. The Label class can be positioned from
the compass points, but while building a drawing we can't normally ask
how big a Label is (pity).

On the other hand it should not be impossible to determine the bounding
box for any widget; it's a simple calculation. I know Andy was worried
that too much use of such a calculation would lead to extremely poor
performance.

What is the easier task:
1) Define a bounding box method and use that as the implied dimension
when needed. Typical problem is use my bounding box to position my sub
widget and then (perhaps stupidly) change some attribute which affects
either my or the sub widget bb. To properly solve this we need to do
symbolic manipulation (the bb is a lazily evaluatable symbol which
cannot properly be determined until draw time). If we ever define a bb
in terms of itself (which is very easy) then we need to do equation
solving.

2) Assert a size at the outset and then ensure or assume that things are
inside it. Problems are obvious unless we are either preternaturally
clever or accept that everything must be clipped.
-- 
Robin Becker