Re: Component sizing...

[Lauris Kaplinski <lauris ariman ee>]

On Fri, 21 Apr 2000, Michael Meeks wrote:

> 	* There _must_ be no concept of pagination within the component,
> each component renders a view equivilant to what is seen in the
> application and it renders it to a single infinite print context.
> Scissoring of this is then performed by the client application.
> 
> 	* The advisability of scroll bars within an embedded component is
> extraordinarily questionable, it would seem that this confuses me more
> than it helps. Since there is no way the component can render a larger
> area than it displays ( WYSIWYG ), the exact point of the scroll bars is
> merely to position a viewport, and the number of degrees of freedom are
> rather annoying.

For sodipodi, I have settled for following behaviour (this is borrowed
from SVG spec, so do not blame me :))

Component has its very own viewport PLUS aspect ratio preferences:
* Whether to stretch, if not then anchoring
Container gives to component certain rectangle (GtkWidget).

If component is not activated, it fits its viewport to component's one
according to anchoring rules (there should be also a way for component to
override these). Printing is done similar way - i.e. fitting component's
full "page" into container's allocated rectangle.

Activation is NOT meant for moving/scaling/stretching component relative
to container's page. It is coponent native way to do FULL editing.

So, if sodipodi component is activated, it:
* shows scrollbars
* allows to change zoom factor
so it can be conventionally edited.

But as soon, as it is unactivated, it will:
* remove scrollbars
* sets zooming and scrolling back to initial, rule-defined values

So, if you want to zoom embedded graphic, you cannot use sodipodi zoom
tool. You have either to:
* reduce page size
* zoom graphic relative to page
* increase cropping in container
* increase container size

> 	Furthermore, the distinction between auto / self sizing is really
> annoying with the eog image component, the user has to select which of the
> components he wants, and it seems to me that bonobo _must_ soon be able to
> cope with doing this without 2 separate components. [ the Nautilus folk
> added a scrolled image component ]. Surely we have to face the real issues
> of negotiating size correctly before wandering down a path where a load of
> components have an annoying dual directory entry with a change of
> parenthetical scale ?

Scrollbars are for ACTIVATED component, not for inactive.

There should be a general rule, that every inactive component can
always be replaced with bitmap so that user does not see any difference.

Regards,
Lauris