Re: Sizing...

[Michael Meeks <michael helixcode com>]

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' ?

        My thesis is that it is _far_ easier to aggregate a simple
interface to the embeddable (or its views) that will allow it to work well
in a situation where a control is more appropriate than it is to
everywhere have duplicated code, 2 factories per embeddable, with a scad
of boilerplate code sticking a nasty scrolled window around the rendering
infastructure.
                                                   
        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.

        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.


        Some more specific points interest me:
  
>               1. The parent document has to tell the embeddable its
>                    position and size on the final page, i.e.
>
>                       Your top-left corner is (5.5 cm, 7.6 cm) on
>                       the page.

        Whilst I agree that we are going to need to get some rigour into
our sizing interfaces for embeddables, I rather object to the embeddable
being told where it is on the page; what purpose can this possibly serve ?

>                       Your rectangular size is (10 cm, 8 cm).

        This would perhaps be useful, however assuming that both the
embeddable and the container are using the same point -> pixel
calculations for a given zoom level an acceptable degree of precision can
be obtained without needing a precice point size; at least until print
time as you point out here, however I would like perhaps to change this to
use points.

>                  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 ?

>                  If you relate this to (1), you will see that the   
>                  document is being rendered to the screen at 40
>                  pixels per centimeter.  This thing applies to the
>                  *whole document*, since it is the main WYSIWYG
>                  view.
  
        Or you could take the point size and the zoom factor and work this
information out; clearly it is a terrible idea to have redundant
information in this process.

>       - Note that the document view's zoom factor has NOTHING to do
>           with the physical dimensions of the printed document.  This
>           is why having Bonobo::View::set_zoom_factor() is *WRONG*.   

        Wwhat you have described above seems very close to how canvas
components work, do you envisage a different approach for Views ? or are
you merely saying it should not be called 'zoom' but perhaps   
'scale_factor' ?
        
>           What you really want is
>
>               Bonobo::View::set_document_position (double x_points, 
>                                                    double y_points,
>                                                    double width_points,
>                                                    double
height_points);
>                  
>               Bonobo::View::set_screen_position (XWindow parent,
>                                                  int x_pixels,
>                                                  int y_pixels,
>                                                  int width_pixels,  
>                                                  int height_pixels);
>
>         That is, you need to inform the view about the size/position
>         it will have on the printed page and the size/position it
>         will have on the screen.

        Again, I think setting the position on the printed page is a total
disaster, this information is virtualy useless to the containee and
possibly dangerous. The container can chop the containee's print
information up into arbitarily small pieces with wierd margin sizes, and
discontinuities in-between ( eg. a label printer ), and then do some
strange page ordering, so I suspect this is not a good plan.

        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.

        Regards,

                Michael.

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