Re: Sizing...

[Maciej Stachowiak <mjs eazel com>]

Michael Meeks <michael@helixcode.com> writes:

> 	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

This sounds like you are implying that Controls should be
self-scrolling (if they need scrolling), while Embeddables should be
scrolled externally. Am I understanding correctly? If so, I see at
least one problem that you didn't already cite below.

* Now you need both a control and an embeddable for each mime type,
because a different one is appropriate depending on your use-case.


> 	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 ).

I don't see how `set zoom' suffices for anything if you can't see the
size, or know if the thing is generating it's own scrollbars, or
anything.

 - Maciej