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

List:       calligra-devel
Subject:    Re: Project Proposal for Calligra
From:       "Friedrich W. H. Kossebau" <kossebau () kde ! org>
Date:       2012-03-15 15:37:33
Message-ID: 1880885.rAh7dMA1Vp () klux ! site
[Download RAW message or body]

Hi Jigar,

Am Mittwoch, 14. M=E4rz 2012, 17:23:16 schrieb jigar raisinghani:
> Hi
>                Here is a project proposal which i would like to implement
> in Calligra Tables and Calligra Words.
> http://dl.dropbox.com/u/49042576/Project%20Proposal_JIGAR.pdf

Instead of opening a different window (and technically starting a separate =

program) I would prefer to be able to edit the table directly inside the =

current document, which could be the page of a document, the slide of a =

presentation or whatever other virtual object the table is inside.
At least if the table is self-contained, and not linked to some bigger tabl=
e =

or other data source.

This is what I find so great about the Flake/Shape concept of Calligra, so =
you =

can have a document composed from all kinds of objects and are able to edit =

all the objects directly where they are located.

So instead of implementing support to extract the data of a table, start =

another program, stream the data there, wait until they are modified and =

saved, stream the data back to the current program, I think you can rather =

look into improving the existing tools for the spreadsheet shape and how th=
ey =

are provided in the different Calligra programs, so the user can do all the =

operations which are able in the spreadsheet centred program Calligra Sheet=
s =

also on the spreadsheet shape in the other Calligra programs, e.g. doing th=
e =

sorting or editing the formulas.
This could/would also involve support for having the shape influence the =

rulers, e.g. for the spreadsheet shape the ruler should have the row and ce=
ll =

markers A,B,C... and 1,2,3,... for the range where the shape is located. Co=
uld =

be done by having the shape also provide ruler plugins which would take ove=
r =

the handling of these areas.

While talking about tables:
currently there are two types of tables offered, once the table from the te=
xt =

editing tool and once the table from the spreadsheet shape. I wonder why th=
ese =

could not be merged somehow, and just have different tools, one for simple =

text editing and one for calculation/sorting related operations. Because th=
e =

first is basically a subset of the latter for me. Besides the ability of th=
e =

text table to embed another text table in a cell.
So I see a chance to do something about this at well.
A typical workflow I remember from myself: start a text table, then find ou=
t =

you want to do some operation on it, e.g. sorting the rows or calculating a =

percent value into an additional column. From my user point of view I alway=
s =

disliked it, that so far I then had to do all kind of complicated stuff to =
get =

my current table transformed into a table which also supports calculations, =

while having it still look like it did before.

So in my perfect world there is only one type of table in non-spreadsheet =

documents (like pages document, presentation slides, etc.) which is easily =

layoutable (like the current text table is, e.g. takes as width the whole =

width of the container element, like the text frame, by default), but also =

supports all kind of operations a spreadsheet table does.

Cheers
Friedrich
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
[prev in list] [next in list] [prev in thread] [next in thread]