[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Tables for KWord, next iteration
From:       Thomas Zander <zander () kde ! org>
Date:       2008-05-17 7:29:51
Message-ID: 200805170929.51411.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 17. May 2008 08:44:09 Inge Wallin wrote:
> On Thursday 15 May 2008 23:26:22 Sebastian Sauer wrote:
> > Tables are still a huge thing and one that affects a lot of our current
> > code what means, it would be nice to continue the discusions we had so
> > far [1].
> >
> > Possibilities;
> >
> > 1. TableShape
> > I guess this is really the worst thing to go since it would mean we would
> > need one textshape per cell and that sounds like a bad idea specially for
> > large tables.
>
> May I ask why?  Does the textshape has a big overhead?
see my answer at
http://lists.kde.org/?l=koffice-devel&m=120578819326638&w=2
 "This is how it was done in 1.x.
 "This turned out to be a very very bad idea; you are unable to do a lot of
 "things that people expect and the layout code is near impossible to get 
 "right. (mixing of abstraction layers)
 "Also multi page tables are quite impossible to do like that due to the 
 "layout code living at different levels. The text level and the shape 
 "level."

Or, in short, Dipesh is right; I know it sucks since I maintained that way of 
working for several years.

> > Also we would need with various other things like splitting
> > the shape if it's larger then a page and we would need to deal with
> > nested shapes. Also we would probably need to use the same logic for
> > columns then.
>
> Nested tables shouldn't be a problem per se when using a shape since a
> shape can embed other shapes.  The question is then how the splitting can
> be done. 

This was indeed another issue people had with tables; we ended up special 
casing the frame (/shape) interaction everywhere for tables. We never got 
something that felt right.
Remember that if you select a table in any other app you will want to select 
all the text using a text tool and expect the cells to be selected 
automatically.  Unfortunately this is plain impossible using the nested 
shapes approach since only one shape (cell) can have a selection at a time.
Again, mixing of concepts gone wrong.

> Perhaps one table shape can "embed" other table shapes, but render 
> them outside itself, i.e. on subsequent pages. I think that having embedded
> shapes that are drawn outside the parent shape is actually possible. At
> least that's what we found out when we investigated how to split a chart
> and its legend for the chart shape.

We have 2 ways of embedding; one is completely inside the parent and the other 
just uses its offset.  So its indeed possible.
That said; having a shape anywhere on the page might be nice, but that means 
you totally loose interaction with the surrounding text. You for example 
can't use your cursor to get into and out of a table.  So in reality you need 
to have a fully inline shape (which, again, was how KOffice1 did it, and it 
sucks).

Feel free to try it out yourselves, I'm just pointing out the 
not-immediately-obvious pitfalls that this approach has given us.

Cheers!
-- 
Thomas Zander

["signature.asc" (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]