Review Request: Moving anchor strategy into text shape

[C. Boemann]

On Thursday 27 January 2011 11:15:22 Pierre Stirnweiss wrote:
> On Thu, Jan 27, 2011 at 10:51 AM, C. Boemann <cbo at boemann.dk> wrote:
> > Well this is a step on the road and not the end result. So bear with me.
> > 
> > But I've indeed changed my mind about who does the layout and drawing,
> > and have come up with an abstraction that will allow the kotext library
> > to do just
> > that.
> 
> So you mean, drawing/layouting would be done at kotext level?
> 
> > Well totally controlled by the textshape. This abstraction will allow
> > any application to gain layout and painting.
> 
> This is already the case. kotext provides an abstracted interface for
> layouting. the user of the lib needs to implement his layouting logic. What
> layouting logic/paradigm would you favor for kotext? this would also mean
> that any other layouting paradigm/logic, would still need to carry the
> weight (memory footprint,...) of a layouting logic he does not even care
> about?
> Sounds like a step in the opposite direction of the goal of deploying/using
> on a multitude of devices, for a multitude of use cases.
> A bit like MS having internet explorer right tied up with their kernel. It
> becomes awefully difficult to have a very lean kernel based on windows.
> 
> First app that will benefit from
> 
> > this is our very own Tables.
> > 
> > But shapes and pages will soon be abstracted away as i said. Oh and no
> > one requires those pagesizes and numbers to be filled out by apps that
> > don't use
> > it. For those apps the anchoring mode that relate to these things will
> > simply
> > not be activated.
> 
> Yes, no one has to fill these, but you are bloating a general purpose
> library with specific cases peculiarities. You'll end up with a melting pot
> library of things which do not relate to each other. You mention Tables, so
> why not also add the Spreadsheet/Cell coordinates to the mix? And since
> kotext could also be used in a painting application, the layer to which the
> anchored shape belongs. then, one could use kotext for a music notation
> stuff, so we could add score/voice/bar information.
> 
> I am exaggerating this a lot, but once the box is opened, it is very
> difficult to draw a line.
> 
> 
> Pierre
Well as i said it's going to be abstracted away, and we are creating a layout 
engine for ODF after all. Meaning that a lot of the layout is quite specified 
how should look. If all a user wants is layout of text, then kotext is handly 
a match anyway. And yes there might be a little overhead in terms of memory 
footprint, but it's actually not that much.

And we gain so much by having a shared library in terms of easier, smaller and 
more maintainable code. And the cells and layer coordinates you talk of, are 
actually going to be supplied by the application with the exact same 
abstraction as the pages of a words document.

Casper