Re: Sizing...

[Maciej Stachowiak <mjs eazel com>]

Michael Meeks <michael@helixcode.com> writes:

> Hi,
> 
> On 27 Jul 2000, Federico Mena Quintero wrote:
> > Scrolling is not the only consideration.  You need to handle two
> > cases; for the sake of this discussion let's call them case Batman and
> > case Robin.
>         
>         You present a compelling expansion of my:
> 
> "        a) Use controls where controls are appropriate
>  and embeddables where embeddables are appropriate,"
> 
>         which you rename Batman and Robin. You present a nice discussion
> of why EOG can be optimized to be both a control and an embeddable, which
> is all well and good.
> 
>         You then describe 'Robin' and give a nice description of
> embeddables to a point.
> 
>         The problem is that none of this addresses the real issue which is
> this: 'How can we work out a generic sizing strategy that will allow
> people to use embeddables as controls' ?

One such strategy is to always provide both an embeddable and a
control. However, this seems highly inelegant. Embeddables differ from
controls primarily in that they provide Model/View separation. Why
should this be tied to scrolling policy? What if I want to use MVC
_and_ have component-side scroll policy? Am I just screwed?

Also, I raised the issue of things that might want to be embeddables
that _can't_ be scrolled externally (mozilla), so this would have to
mean you can't put an embeddable in a scrolled window.

>         So the question again is how to do this sensibly. Furthermore this
> raises a number of interesting issues such as the difference between a
> toplevel container; and a sub container, if you do not see a distinction,
> consider that it would be nice if we could embed eg. gnumeric in an empty
> shell with no loss of functionality. Now; perhaps this is the control /
> component split you suggest, gnumeric needs to export a control interface
> that does its own scrolling etc. as well as an embeddable interface for
> WYSIWYG. The thing that concerns me is that this seems to discard the
> document view capabilities that gnumeric has which is a shame.

It seems afully inelegant to me in general to require having both a
control and an embeddable for every application. It doesn't seem much
better than having two different flavors of embeddable, to be honest.

>         So then you summarise:
> 
> > So yes, we may need two factories for components that want to export
> > both controls and embeddable views.
> 
>         But this is essentialy _every_ embeddable; I find it extremely
> hard to think of an embeddable that people will not want to use as a
> control ( eg. in order to view files inside nautilus ). Can you ? so
> perhaps this 'may need' becomes 'everyone must implement 2 interfaces'
> which seems to suck badly to me.
> 

Me too.
 
> >                  This lets the embeddable know its final size for
> >                  when it is printed.
> >                                                  
> >               2. The application which presents the parent document
> >                    has to tell the embeddable about how it should be
> >                    shown in the screen:
> >
> >                       Your parent X window is <blah>.
> >
> >                       By the way, due to the current scrolling
> >                       position of the document's view, will you
> >                       please paint yourself at (220, 304) pixels
> 
> >
> >                       Also please use a size of (400, 320) pixels.
> 
>         Currently for non-canvas item embeddables we give the embeddable
> its own window  ( as you know ) and we let X handle the difficulties of
> scrolling, updating contained windows etc. This seems to work well; do you
> propose a set of CORBA methods to do this for each scroll movement ?

I hope we don't do that, it would result in a _lot_ of CORBA traffic
when scrolling.
 
> 
>         Anyhow, at least we are agreed that controls and embeddables are  
> distinct and separate, and that Nautilus should primarily be using  
> controls, whereas gnumeric should be using embeddables. The issue then is
> still how to scroll an embeddable when it is being used in a control
> scenario.

I still don't agree with the specific distinctions drawn between
controls and embeddables, since it seems like they require you to
implement both a control and an embeddable always, and inappropriately
tie M/V separation with details like scroll policy. This is silly, and
will require _more_ code mangling and duplication than generating two
kinds of embeddables (the current state of the world). So it really
sounds like a step backwards to me.

Also, some (for now theoretical) embeddables can't be externally
scrolled, so we cannot just write both a control and an embeddable for
everything and punt the scrolling issue.

 - Maciej