[reportlab-users] Widgets as Flowables...

[Dinu Gherman]

Andy Robinson:

>> Hi,
>>
>> taking the previous thread further... Isn't it unfortunate that
>> Widgets can't be used directly as Flowables in Platypus?
>
> I think the primitive concept is a Shape, not a Widget, and I'd do
> it there if I did it anywhere, so you could do a rectangle as easily
> as a pie chart.
>
> Drawings are Flowables so you only need to wrap once, not twice.
>
> At present Drawings have a defined size (at least, they did until
> somebody demanded scaling :-) ) but the Shapes and Widgets inside
> them do not know their own sizes or bounding boxes.  I can see it
> is desirable one day for Shapes and Widgets to know their size,
> but until we do that, how can we make them wrap?
>
> Also, I am a bit worried about excessive permissiveness and
> flexibility.
> The whole 'graphics' package has a clean boundary between itself and
> pdfgen/platypus, and the boundary is the Drawing class.  If that gets
> relaxed and bits start leaking through, I can see we will end up
> with "too many ways to do things".
>
> It's a fair topic for "version 2" whether we should use "resuable
> shape objects everywhere" or a "canvas metaphor everywhere". Being
> able to use either one everywhere makes my head hurt, but I have
> not analysed it properly yet so feel free to argue back.


The problem is that the Graphics subsystem has already become much
of a complex beast. There are shapes, widgets & drawings which in
principle have their defined "application domain", but in practice
I never found myself writing a new shape (except for Image), and
widgets are so thin that they are hardly useful, while drawings are
really heavy-weight citizens.

The widget problem manifests itself nicely in the sample collections
in graphics/widgets (except for grids and signsandsymbols) which are,
if I dare say so, less reusable than I'd expect (I pointed this out
at length for markers).

Another problem with widgets is: if you want them to appear in PDF
files and make use of special PDF features (say a clickable rect.
taking you to the table of contents), you need to wrap them inside
drawings.

I've just tried doing this with a very thin Drawing around a widget
that has a Null canvas instance accepting any method invocations.
I hoped to swap this out against the Drawing's real canvas object,
but it turns out that this comes into existence very lazily, pro-
bably only when the PDF renderer touches the drawing, so this other-
wise elegant solution was also impossilble and I had to distribute
the functionality across the Widget and Drawing wrapper.

It's stuff like this which is frustrating when using the graphics
package that makes me believe that something should be done about
it to lay out clearly what the interactions and responsibilities
of objects really are or are expected to be.

Of course, this is equally true for the rest of the toolkit if a new
version 2 should be anything else but 1.x plus 100 other features.

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"Honest disagreement is often a good sign of progress." (Gandhi)