Sizing...

[Michael Meeks <michael helixcode com>]

Ok;

	Since Maciej and I had a flamewar about this recently, and
now we are friends again I thought we should extend the battle
ground to the great unwashed:

	Ok; so, the main symptom of the problem is scrolling, and
the main problem is conflicting expectations of what a component
should do:

	a) Scrolling should be done by the containee since this
knows more about the thing being rendered

	b) Scrolling should be done by the container which gives
the containee a large window to render into most of which is never
exposed.

	So; in a) the UI is handled by the containee, in b) the
UI is handled by the container. Now here is the problem.

	a) Maps well to situations where a control is appropriate,
eg. in Nautilis

	b) Maps well to a situation such as gnumeric where having
an image of a fixed size rendering non WYSIWYG scrollbars into
its pane. Quite besides the fact that when you 'size' the
component you just see differing proprtions of the sheet.

	So how do we handle this currently;

	eog has dual factories, one which creates a scrolled
embeddable and the other which creates a scaled one suitable for
situations a) and b) respectively. So; this sucks since it adds
user confusion 'which one to choose in the selector', and
creates unneccessary work.

	So; how does Microsoft do it ? well in the compound
document case we have seemingly two distinct types of behavior

	a) Scalable - eg. an image scales as you re-size it
nicely. 

	b) Non Scalable - eg. a word document inside excel
you see as much as the size of the range allows you to see
of the underlying document.

	So; how do we solve it ?

	My current plan is as follows:

	a) Use components where components are appropriate
and embeddables where embeddables are appropriate

	  i) But how do I know which one I need

	     * An embeddable has views which have a zoom
	     factor which is a double, and should obey it

	     * An embeddable is document / view

	b) For people that want to use an embeddable that
will scale to any size [ ie. eog / xpdf ] we need put the
image in a scrolled window ( as we would with a
GnomePixmap ) and we add the following:

	  i) Default size negotiation

	     The component can tell the container what
	   size it would prefer; eg. the default size of
	   an image.

	  ii) Window size querying

	     For the component to be able to do things
	   such as fit to window it needs to know the
	   viewable, rather than the virtual size of its
	   parent window.


	Ok; so savage criticisms of my above approach:

*	If you start adding size negotiation outside
the view zoom setting you totally screw up that API.

*	Currently if you re-size an image in gnumeric
it doesn't set the zoom factor anyway, so surely the
View's zoom API is redundant for components that can
scale to any size ?

*	What about things such as gnumeric / netscape
( containers ) they must control their own scrolling /
movement, since it works in a strange way / is not
rendering into a large X drawable ? arn't they are
a special case of a component ? how does MS cope with
this ? is it by throwing the scrollbars away totaly
for embedded spreadsheets ? if so, how do we let the
toplevel container act differently ?

	I have answers for none of these criticisms
I just made them up and I'm tired. The more I look at
it the more it seems that we want a different interface
than just a plain 'set zoom' on the View for 'scaled'
components, whereas the 'set zoom' suffices for 'non
scaled' components ( see above for examples ).

	So; let the flames begin...

	Regards,

		Michael.

-- 
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot