Project Proposal for Calligra

Sebastian Sauer mail at dipe.org
Fri Mar 16 03:45:01 GMT 2012


On 03/15/2012 11:17 PM, jigar raisinghani wrote:
> Hi,
>           Sebastian, one thing i personally like about Calligra 
> Sheets(Tables) is its "IMPORT" feature. eg.  you have  10 tables in a 
> document, Calligra Sheets extracts and opens it in 10 different 
> sheets. This is awesome. But supposing you have to make minor changes 
> in 3-4 tables, you would not like to export it or create new files. 
> Rather than exporting it, we could just let the changes be reflected 
> back to the original file itself. I guess extending the 
> functionalities of SHAPE to create streams and wait for streams to 
> save back the data would also be a nice method as Friedrich suggested.

Yes, absolute agree there :)

> As far as Calligra Words is concerned, i guess extending the 
> functionalities of FLAKE/SHAPE would be better option as of now. My 
> idea of opening tables in Calligra words using Calligra Sheets was 
> basically to allow user to implement all the functions of Calligra 
> Sheets using Calligra Words. But this is only possible if Calligra 
> Sheets allows the changes to be reflected back directly.As Friedrich 
> suggested, having ruler plugins for SHAPE would be best.
>
> Moreover the above ideas of just extending the FLAKE/SHAPE to 
> implement the desired features in Calligra Sheets and Calligra Tables 
> would not disturb the concept of FLAKE/SHAPE.
>
> This was just a very rough idea of what i would like Calligra Sheets 
> and Calligra Words to have and not my actual GSOC Proposal.

Ah, good. Note that my objections are not related to such a feature. The 
thing is that the proposal does not name with any word how that the goal 
should be achieved. It names the target but not the way that would lead 
to it. So, we may agree on the target but without having any clue what 
the way would be we may not there since it could mean that you plan to...
a) Write an external Python script the user needs to call and that 
unzip's the embedded ODS, calls Tables and if Tables exists zip's the 
ODS again and puts it into the outer format.
b) Extend flake so the loading+saving works in a way described greatly 
described by Friedrich or
c) Hack an import-export plugin for Calligra Tables/Sheets to allow 
import/export.

There are huge differences between those 3 examples and we, means our 
Calligra mentors, would certainly like to know which way to plan to 
drive. That is imho just a very basic requirement to be able to "judge" 
your proposal. When we have no clue then the possibility is just very 
high that it's rejected (means not chosen) cause we just do not know 
what the proposal really is about. I think very less of us would chose a 
black-box without knowing what's inside when there are alternates that 
make very well clear what may come out of the gsoc and how our users and 
developers would benefit.

Hope that makes more clear where I see the problem with the current 
proposal. So, I would suggest to add details how that should be done. 
Just show us that you already have an idea and how that idea may look 
like. Also imho it would be rather useful to add a time-table where you 
list what milestones you like to achieve within the gsoc-time. I would 
suggest to have a look at other proposals like 
http://wiki.scribus.net/canvas/GSoC_2011_Tables_Proposal or 
http://lists.kde.org/?l=koffice-devel&m=123809166413909 or 
http://lists.kde.org/?l=koffice-devel&m=123817532032221 or 
http://web.archiveorange.com/archive/v/4ztGlXShEYwLSl9jPzX7 .

Best regards
Sebastian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20120316/281ef6c1/attachment.htm>


More information about the calligra-devel mailing list