Re: Sizing...

[Federico Mena Quintero <federico helixcode com>]

Michael Meeks <michael@helixcode.com> writes:

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

We don't :-)

I don't think you want to make controls be a superset of embeddables.
There are the UI issues I outlined, plus the fact that if you actually
have a service that implements both control and embeddable interfaces,
you certainly don't want to allow making the embeddable look like a
control.

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

I think you are focusing too much on the "wrapping everything with a
scrolled window" issue.  Think of a 3D CAD program; scrollbars are
useless since the panning semantics are much different than that of
plain 2D document-type stuff.  A control for such a thing would be the
full-blown CAD user interface.

An embeddable will just provide a 2D projection that is suitable for
inclusion in a document.  It would still not make sense to want to
provide just the embeddable and just say "wrap it with a scrolled
window" if you wanted to use it as a control.

I don't think there is anything wrong with having to provide both
interfaces if you actually want your code to provide control and
embeddable functionality.  If anything, we should make the boilerplate
easy to write rather than trying to fit everything into the same
straight-jacket.

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

No no no no no.

Gnumeric-as-a-control is "I want a spreadsheet as a super-functional
widget in my application".

Gnumeric-as-an-embeddable can be "I want a range of cells in my
document", "I want a single cell's value to update itself in my word
processor's summary document", etc.

You do not lose the nicety of model/view with this; there should be a
Gnumeric daemon-like thing (i.e. an out-of-process thing launched with
OAF) that centralizes access to a particular spreadsheet.  If you view
a particular spreadsheet with both a control and some embeddables at
the same time, the Gnumeric daemon thingy should synchronize all the
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.

Think of the 3D CAD thingy I put above.

Think of it in terms of what will provide the best user experience.
You can flatten lots of things to make them suitable for inclusion in
a 2D printed document.  That does not mean a traditional 2D document
user interface is suitable for viewing or editing those things:  you
will need a full=blown control with all the custom stuff it may need.

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

Aligning halftone masks at the page level rather than at the
subdocument level, for one.

Yes, you could argue that this could be done by the toplevel printing
system, but think of something that wants to actually render a bitmap
tuned to a particular printer instead of spitting some generic image.
This would pass almost raw through the printing mechanism (i.e. it
wouldn't try to dither it or anything) and just be turned into printer
instructions.

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

As I explained, "zoom level" is ambiguous; a printer does not have a
zoom level.

You *always* need precise measurements.  I do not want to compromise
on this, or quality defects will trickle down everywhere and make us
look like crap.

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

No, it was just an example.  The fact that we are making nested X
windows provide the actual size information is just an implementation
detail.

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

"Zoom factor" is ambiguous.

If you try to use a "zoom factor" for both the printed point size and
the on-screen pixel size, applications may get terribly confused.  A
subdocument's logical size does not change, yet you are implying that
you must change the "zoom factor" to print.  This does not make sense
to me.

Plus, you cannot provide accurate WYSIWYG if you don't know both the
final printed size (which does not change) and the screen size that
the user is using (which can change at any time when you hit the
View/Zoom menu).

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

If you do n-up or split page printing, the embeddable does not care.
The halftone masks still have to be aligned, so the embeddable just
needs to get the "big picture" of its position.

It is up to the printing system to chop things up for n-up or split
page printing.

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

Nautilus should be using controls *only*.

Stuff that you put inside a Gnumeric spreadsheet should be embeddables.

I know Excel lets you put a rectangular web browser inside a range of
cells, for people that like to build complicated UIs inside a
spreadsheet.  This is a special case, anyways, and I assumet that if
you try to print that thing you'll get a blank square where the exotic
control was.

  Federico