From ve4jhj+scribus at gmail.com  Wed Mar  2 19:38:23 2011
From: ve4jhj+scribus at gmail.com (Gord Caswell)
Date: Wed, 2 Mar 2011 12:38:23 -0600
Subject: [scribus-dev] PortableApps.com package of Scribus 1.4.0
Message-ID: <D3A6EA6B-E06B-49F9-8C4F-5BF70F5C3D5D@gmail.com>

Hello,

As the 1.4.0 release gets closer, we at PortableApps.com are eagerly looking forward to officially releasing Scribus inPortableApps.com Format[1]. We are happy to do all the work, host, maintain, promote and link back to Scribus.net for the local version and for donations to the Scribus project. If you're interested in blessing the PortableApps.com release with a spot on the download page or some other similar manner, that would be great.

If you have any questions, or feel there's some other way we can help, feel free to contact John T. Haller, CEO & Founder of PortableApps.com, at developers_developers at portableapps.com

Thanks,

Gord Caswell
PortableApps.com developer

[1]http://portableapps.com/about/what_is_a_portable_app#whypaf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110302/82116011/attachment.htm>

From ale.comp_06 at xox.ch  Wed Mar  2 23:06:36 2011
From: ale.comp_06 at xox.ch (a.l.e)
Date: Wed, 2 Mar 2011 23:06:36 +0100
Subject: [scribus-dev] PortableApps.com package of Scribus 1.4.0
In-Reply-To: <D3A6EA6B-E06B-49F9-8C4F-5BF70F5C3D5D@gmail.com>
References: <D3A6EA6B-E06B-49F9-8C4F-5BF70F5C3D5D@gmail.com>
Message-ID: <20110302230636.56e6270f@eisflach>

hi gord

> As the 1.4.0 release gets closer, we at PortableApps.com are eagerly
> looking forward to officially releasing Scribus inPortableApps.com
> Format[1]. We are happy to do all the work, host, maintain, promote
> and link back to Scribus.net for the local version and for donations
> to the Scribus project. If you're interested in blessing the
> PortableApps.com release with a spot on the download page or some
> other similar manner, that would be great.
> 
> If you have any questions, or feel there's some other way we can
> help, feel free to contact John T. Haller, CEO & Founder of
> PortableApps.com, at developers_developers at portableapps.com

since the team is quite busy at the moment, i guess that the best thing is to come back when 1.4 *is* released, tell us where the portable app is and ask us to put the link on our website.

ciao
a.l.e


From elvstone at gmail.com  Sun Mar  6 15:03:44 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Sun, 6 Mar 2011 15:03:44 +0100
Subject: [scribus-dev] Tables as Summer of Code project
Message-ID: <AANLkTin4c_zZxQi1rUN8uvDJeB7ET6D-mnNz8R+p0rYk@mail.gmail.com>

Hello Scribus folks,

In 2009 I implemented basic support for table layout in the KWord word
processor as part of Google Summer of Code. This year I'm again
considering applying for GSoC.

I've always had a soft spot for Scribus, having used it quite a lot
for doing flyers and ads in the past. Hence I started looking into
applying with Scribus as a mentoring organization and found out that
you guys are considering tables support for Scribus as a GSoC.

Even though I'm sure you're very much aware that tables support would
be a big undertaking for a GSoC, I would first off like to raise a
warning finger, having been through it once; I think you'll be hard
pressed to find a student that will finish something that can be
called feature complete in one summer, unless the student is already a
core dev. Although my GSoC for KWord in 2009 was considered a success,
I did not finish all features specified in my original project
proposal. The reason it was still considered a success was that due to
the complexity of the task, me and my mentor early on agreed to have
certain features as optional in the project description. Among the
features that were not finished was table breaking across pages and
interactive table editing.

That said, I'd be very much interested in taking on tables support for
Scribus as a GSoC this summer, provided that we can can conclude which
parts of the support are to be considered mandatory, which are
optional and which of them that are out of scope for the project.

I have experience with Qt and C++, naturally, but apart from a small
feature I added a couple of years ago [1], I have no experience with
the Scribus code. Especially not with its core layout code.

I did a checkout of Scribus and tried to get an overview of the code,
and I must say that I'm a little worried; whereas in my KWord project
in 2009, due to a pretty strict documentation policy in KOffice,
almost every class and function was documented. In Scribus,
documentation of the classes seems to be the exception rather than the
rule.

So I have a few questions:

1) Am I right in that a table in Scribus would be a new PageItem?
2) Would tables leverage Scribus' existing layout mechanisms by having
each cell in the table be (or contain) a PageItem_TextFrame?
3) What about the ideas at [2], are they relevant?
4) Is there any "birdseye" developer documentation of how Scribus does
its layout, from loading to final glyph? Classes involved, patterns
used et.c.? If not, is this something that any of the core devs would
be willing to jot down off the top of their head? Wouldn't have to be
anything ambitious, just some notes. It would really help as a guide
when reading the source code.
5) Are there any refactorings, big or small, that needs to be done in
order to accommodate tables support? In my KWord project I was able to
do my work in a plugin, plus some reasonably small and isolated
changes to core layout code. What's the situation in Scribus?

I realize now that this mail sounds awfully negative :) But don't
worry, it's just me trying to be down to earth, as I know it's
important to iron these things out beforehand. Especially important is
to iron out what will be the scope of the project.

If you're interested I dug out my old patches from GSoC 2009 [3] and
if you want to read my blog posts regarding the project from back then
it's at [4].

Looking forward to your input!

Best regards,
Elvis Stansvik

[1] http://bugs.scribus.net/view.php?id=7126
[2] http://wiki.scribus.net/canvas/Tables
[3] http://dose.se/elvis_stansvik_gsoc_2009/
[4] http://estan.dose.se/tag/gsoc


From elvstone at gmail.com  Sun Mar  6 15:32:06 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Sun, 6 Mar 2011 15:32:06 +0100
Subject: [scribus-dev] Tables as Summer of Code project
In-Reply-To: <AANLkTin4c_zZxQi1rUN8uvDJeB7ET6D-mnNz8R+p0rYk@mail.gmail.com>
References: <AANLkTin4c_zZxQi1rUN8uvDJeB7ET6D-mnNz8R+p0rYk@mail.gmail.com>
Message-ID: <AANLkTikKv=Fd-QbizW_qHLmZZs+p-e+KA6UjbwpM-ZZ2@mail.gmail.com>

Forgot to say; I'll be hanging around the IRC channel under the nick
'estan' if you wish to chat.

Elvis

2011/3/6 Elvis Stansvik <elvstone at gmail.com>:
> Hello Scribus folks,
>
> In 2009 I implemented basic support for table layout in the KWord word
> processor as part of Google Summer of Code. This year I'm again
> considering applying for GSoC.
>
> I've always had a soft spot for Scribus, having used it quite a lot
> for doing flyers and ads in the past. Hence I started looking into
> applying with Scribus as a mentoring organization and found out that
> you guys are considering tables support for Scribus as a GSoC.
>
> Even though I'm sure you're very much aware that tables support would
> be a big undertaking for a GSoC, I would first off like to raise a
> warning finger, having been through it once; I think you'll be hard
> pressed to find a student that will finish something that can be
> called feature complete in one summer, unless the student is already a
> core dev. Although my GSoC for KWord in 2009 was considered a success,
> I did not finish all features specified in my original project
> proposal. The reason it was still considered a success was that due to
> the complexity of the task, me and my mentor early on agreed to have
> certain features as optional in the project description. Among the
> features that were not finished was table breaking across pages and
> interactive table editing.
>
> That said, I'd be very much interested in taking on tables support for
> Scribus as a GSoC this summer, provided that we can can conclude which
> parts of the support are to be considered mandatory, which are
> optional and which of them that are out of scope for the project.
>
> I have experience with Qt and C++, naturally, but apart from a small
> feature I added a couple of years ago [1], I have no experience with
> the Scribus code. Especially not with its core layout code.
>
> I did a checkout of Scribus and tried to get an overview of the code,
> and I must say that I'm a little worried; whereas in my KWord project
> in 2009, due to a pretty strict documentation policy in KOffice,
> almost every class and function was documented. In Scribus,
> documentation of the classes seems to be the exception rather than the
> rule.
>
> So I have a few questions:
>
> 1) Am I right in that a table in Scribus would be a new PageItem?
> 2) Would tables leverage Scribus' existing layout mechanisms by having
> each cell in the table be (or contain) a PageItem_TextFrame?
> 3) What about the ideas at [2], are they relevant?
> 4) Is there any "birdseye" developer documentation of how Scribus does
> its layout, from loading to final glyph? Classes involved, patterns
> used et.c.? If not, is this something that any of the core devs would
> be willing to jot down off the top of their head? Wouldn't have to be
> anything ambitious, just some notes. It would really help as a guide
> when reading the source code.
> 5) Are there any refactorings, big or small, that needs to be done in
> order to accommodate tables support? In my KWord project I was able to
> do my work in a plugin, plus some reasonably small and isolated
> changes to core layout code. What's the situation in Scribus?
>
> I realize now that this mail sounds awfully negative :) But don't
> worry, it's just me trying to be down to earth, as I know it's
> important to iron these things out beforehand. Especially important is
> to iron out what will be the scope of the project.
>
> If you're interested I dug out my old patches from GSoC 2009 [3] and
> if you want to read my blog posts regarding the project from back then
> it's at [4].
>
> Looking forward to your input!
>
> Best regards,
> Elvis Stansvik
>
> [1] http://bugs.scribus.net/view.php?id=7126
> [2] http://wiki.scribus.net/canvas/Tables
> [3] http://dose.se/elvis_stansvik_gsoc_2009/
> [4] http://estan.dose.se/tag/gsoc
>


From gpittman at iglou.com  Sun Mar  6 16:42:24 2011
From: gpittman at iglou.com (Gregory Pittman)
Date: Sun, 06 Mar 2011 10:42:24 -0500
Subject: [scribus-dev] Tables as Summer of Code project
In-Reply-To: <AANLkTin4c_zZxQi1rUN8uvDJeB7ET6D-mnNz8R+p0rYk@mail.gmail.com>
References: <AANLkTin4c_zZxQi1rUN8uvDJeB7ET6D-mnNz8R+p0rYk@mail.gmail.com>
Message-ID: <4D73AB60.5080008@iglou.com>

On 03/06/2011 09:03 AM, Elvis Stansvik wrote:
> Hello Scribus folks,
>
> In 2009 I implemented basic support for table layout in the KWord word
> processor as part of Google Summer of Code. This year I'm again
> considering applying for GSoC.
>
> I've always had a soft spot for Scribus, having used it quite a lot
> for doing flyers and ads in the past. Hence I started looking into
> applying with Scribus as a mentoring organization and found out that
> you guys are considering tables support for Scribus as a GSoC.
>
> Even though I'm sure you're very much aware that tables support would
> be a big undertaking for a GSoC, I would first off like to raise a
> warning finger, having been through it once; I think you'll be hard
> pressed to find a student that will finish something that can be
> called feature complete in one summer, unless the student is already a
> core dev. Although my GSoC for KWord in 2009 was considered a success,
> I did not finish all features specified in my original project
> proposal. The reason it was still considered a success was that due to
> the complexity of the task, me and my mentor early on agreed to have
> certain features as optional in the project description. Among the
> features that were not finished was table breaking across pages and
> interactive table editing.
>
> That said, I'd be very much interested in taking on tables support for
> Scribus as a GSoC this summer, provided that we can can conclude which
> parts of the support are to be considered mandatory, which are
> optional and which of them that are out of scope for the project.
>
> I have experience with Qt and C++, naturally, but apart from a small
> feature I added a couple of years ago [1], I have no experience with
> the Scribus code. Especially not with its core layout code.
>
> I did a checkout of Scribus and tried to get an overview of the code,
> and I must say that I'm a little worried; whereas in my KWord project
> in 2009, due to a pretty strict documentation policy in KOffice,
> almost every class and function was documented. In Scribus,
> documentation of the classes seems to be the exception rather than the
> rule.
>
> So I have a few questions:
>
> 1) Am I right in that a table in Scribus would be a new PageItem?
> 2) Would tables leverage Scribus' existing layout mechanisms by having
> each cell in the table be (or contain) a PageItem_TextFrame?
> 3) What about the ideas at [2], are they relevant?
> 4) Is there any "birdseye" developer documentation of how Scribus does
> its layout, from loading to final glyph? Classes involved, patterns
> used et.c.? If not, is this something that any of the core devs would
> be willing to jot down off the top of their head? Wouldn't have to be
> anything ambitious, just some notes. It would really help as a guide
> when reading the source code.
> 5) Are there any refactorings, big or small, that needs to be done in
> order to accommodate tables support? In my KWord project I was able to
> do my work in a plugin, plus some reasonably small and isolated
> changes to core layout code. What's the situation in Scribus?
>
> I realize now that this mail sounds awfully negative :) But don't
> worry, it's just me trying to be down to earth, as I know it's
> important to iron these things out beforehand. Especially important is
> to iron out what will be the scope of the project.
>
> If you're interested I dug out my old patches from GSoC 2009 [3] and
> if you want to read my blog posts regarding the project from back then
> it's at [4].
>
> Looking forward to your input!
>
> Best regards,
> Elvis Stansvik
>
> [1] http://bugs.scribus.net/view.php?id=7126
> [2] http://wiki.scribus.net/canvas/Tables
> [3] http://dose.se/elvis_stansvik_gsoc_2009/
> [4] http://estan.dose.se/tag/gsoc

I like your realistic enthusiasm, Elvis!

Tables may be a place to test the idea advanced by Louis and a.l.e that 
documentation needs to happen before writing code. In this particular 
case, it means considering what features/operability tables surely must 
have, which are highly desirable, which are optional.

Some basic features I envision:

Importation of common spreadsheet and database file formats: Excel, 
OpenOffice, CSV, maybe even some things from postgresql or mysql. 
Ability to import a table from OpenOffice writer, perhaps other word 
processors.

Ability to easily move from one table cell to another with something 
other than mouse clicks.

Ability to do table-wide, individual cell, and a collection of cells the 
formatting of borders (including each individual border (side) of a cell 
and an overall border for the table), fill, font and styles, in-cell 
columns and distances. This may or may not include creation of "table 
styles" which include all of these elements, perhaps others. Certainly, 
copying the features of one table/cell to others is essential.

Ability to easily resize cells, merge cells, change cell content type 
(such as we have now, being able to contain an image in a cell, for 
example).

And needless to say, should be pretty intuitive.

Greg


From cbradney at scribus.info  Sun Mar  6 16:56:08 2011
From: cbradney at scribus.info (Craig Bradney)
Date: Sun, 06 Mar 2011 16:56:08 +0100
Subject: [scribus-dev] Tables as Summer of Code project
In-Reply-To: <4D73AB60.5080008@iglou.com>
References: <AANLkTin4c_zZxQi1rUN8uvDJeB7ET6D-mnNz8R+p0rYk@mail.gmail.com>
	<4D73AB60.5080008@iglou.com>
Message-ID: <4D73AE98.9060108@scribus.info>

> 
> I like your realistic enthusiasm, Elvis!
> 
> Tables may be a place to test the idea advanced by Louis and a.l.e that
> documentation needs to happen before writing code. In this particular
> case, it means considering what features/operability tables surely must
> have, which are highly desirable, which are optional.

I think we can take other working programs as a form of initial
documentation, with a set of points like "Scribus will implement
cell-cell navigation like OO.org 3.x/KWord 1.x" (or whatever)

> Some basic features I envision:
> 
> Importation of common spreadsheet and database file formats: Excel,
> OpenOffice, CSV, maybe even some things from postgresql or mysql.
> Ability to import a table from OpenOffice writer, perhaps other word
> processors.

This would be in no way a basic feature. Getting the tables stored in
memory, in files, and drawn on canvas is where it needs to start. Import
comes later. Being able to create a proper table is the most important step.

> Ability to easily move from one table cell to another with something
> other than mouse clicks.

Yes


> Ability to do table-wide, individual cell, and a collection of cells the
> formatting of borders (including each individual border (side) of a cell
> and an overall border for the table), fill, font and styles, in-cell
> columns and distances. This may or may not include creation of "table
> styles" which include all of these elements, perhaps others. Certainly,
> copying the features of one table/cell to others is essential.

Yes

> Ability to easily resize cells, merge cells, change cell content type
> (such as we have now, being able to contain an image in a cell, for
> example).

Yes

Craig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110306/f4b737a7/attachment.pgp>

From cbradney at scribus.info  Sun Mar  6 17:04:52 2011
From: cbradney at scribus.info (Craig Bradney)
Date: Sun, 06 Mar 2011 17:04:52 +0100
Subject: [scribus-dev] Tables as Summer of Code project
In-Reply-To: <AANLkTin4c_zZxQi1rUN8uvDJeB7ET6D-mnNz8R+p0rYk@mail.gmail.com>
References: <AANLkTin4c_zZxQi1rUN8uvDJeB7ET6D-mnNz8R+p0rYk@mail.gmail.com>
Message-ID: <4D73B0A4.8000904@scribus.info>


> So I have a few questions:
> 
> 1) Am I right in that a table in Scribus would be a new PageItem?

Yes, adding new types of items has become much easier in the last couple
of years (still within the 1.5.0 branch though, time passes slowly these
days)

> 2) Would tables leverage Scribus' existing layout mechanisms by having
> each cell in the table be (or contain) a PageItem_TextFrame?

Yes, however the text side is somewhat separated from the TextFrame
class, given there are text storage and layout classes.


> 3) What about the ideas at [2], are they relevant?

This seems to introduce a lot of unneeded extras or things that could be
done afterwards.

> 4) Is there any "birdseye" developer documentation of how Scribus does
> its layout, from loading to final glyph? Classes involved, patterns
> used et.c.? If not, is this something that any of the core devs would
> be willing to jot down off the top of their head? Wouldn't have to be
> anything ambitious, just some notes. It would really help as a guide
> when reading the source code.

Nope... unfortunately not. IRC works, emails work.. and the wiki works.
The more people collaborate via the wiki, the more gets documented, but
what exists now is very little.

http://docs.scribus.net/devel/ is autogenerated from the classes

> 5) Are there any refactorings, big or small, that needs to be done in
> order to accommodate tables support? In my KWord project I was able to
> do my work in a plugin, plus some reasonably small and isolated
> changes to core layout code. What's the situation in Scribus?

Per the above, new page item types are easier to add so while not a
plugin, it would be quite well isolated for the basics.

> I realize now that this mail sounds awfully negative :) But don't
> worry, it's just me trying to be down to earth, as I know it's
> important to iron these things out beforehand. Especially important is
> to iron out what will be the scope of the project.

Negative is not worth talking about.. realistic is. Reality will also be
more beneficial for a GSoC application.

Another thing.. if GSoC would not work out this year, would you be
interested in this via alternative sponsorship?

Also, per my msg on IRC, we have Jain Basil who was working on something
towards tables, but given nothing public has come of that for various
reasons on his part, however you should contact him and see where things
are at on his side. He might have a lot of design to lean on or take
over from, or be willing to share. Wasting work and stepping on toes is
not something we encourage.

Thanks very much for contacting us

Craig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110306/6e6e0700/attachment-0001.pgp>

From gpittman at iglou.com  Sun Mar  6 17:10:16 2011
From: gpittman at iglou.com (Gregory Pittman)
Date: Sun, 06 Mar 2011 11:10:16 -0500
Subject: [scribus-dev] Tables as Summer of Code project
In-Reply-To: <4D73AE98.9060108@scribus.info>
References: <AANLkTin4c_zZxQi1rUN8uvDJeB7ET6D-mnNz8R+p0rYk@mail.gmail.com>	<4D73AB60.5080008@iglou.com>
	<4D73AE98.9060108@scribus.info>
Message-ID: <4D73B1E8.2080105@iglou.com>

On 03/06/2011 10:56 AM, Craig Bradney wrote:
>>
>> Importation of common spreadsheet and database file formats: Excel,
>> OpenOffice, CSV, maybe even some things from postgresql or mysql.
>> Ability to import a table from OpenOffice writer, perhaps other word
>> processors.
>
> This would be in no way a basic feature. Getting the tables stored in
> memory, in files, and drawn on canvas is where it needs to start. Import
> comes later. Being able to create a proper table is the most important step.

It may not be a basic feature for Scribus, but there is an expectation 
from users that this would happen. I agree it doesn't have to be done as 
a first step, yet the first steps need to anticipate that this will need 
to happen later.

Greg


From cbradney at zip.com.au  Sun Mar  6 17:50:45 2011
From: cbradney at zip.com.au (Craig Bradney)
Date: Sun, 06 Mar 2011 17:50:45 +0100
Subject: [scribus-dev] #9559
Message-ID: <4D73BB65.8070700@zip.com.au>

Hi Greg

Can you please test 9559?

Edit scriptercore.cpp and change:

                cm        += QString("sys.path[0] =
\"%1\"\n").arg(escapedAbsPath);

to

                cm        += QString("sys.path.insert(0,
\"%1\")\n").arg(escapedAbsPath);


Thanks
Craig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110306/d76fca9f/attachment.pgp>

From gpittman at iglou.com  Sun Mar  6 17:57:37 2011
From: gpittman at iglou.com (Gregory Pittman)
Date: Sun, 06 Mar 2011 11:57:37 -0500
Subject: [scribus-dev] #9559
In-Reply-To: <4D73BB65.8070700@zip.com.au>
References: <4D73BB65.8070700@zip.com.au>
Message-ID: <4D73BD01.7080808@iglou.com>

On 03/06/2011 11:50 AM, Craig Bradney wrote:
> Hi Greg
>
> Can you please test 9559?
>
> Edit scriptercore.cpp and change:
>
>                  cm        += QString("sys.path[0] =
> \"%1\"\n").arg(escapedAbsPath);
>
> to
>
>                  cm        += QString("sys.path.insert(0,
> \"%1\")\n").arg(escapedAbsPath);

Ok.
I'll have to resurrect a script that used PIL.

Greg


From gpittman at iglou.com  Sun Mar  6 18:42:20 2011
From: gpittman at iglou.com (Gregory Pittman)
Date: Sun, 06 Mar 2011 12:42:20 -0500
Subject: [scribus-dev] #9559
In-Reply-To: <4D73BD01.7080808@iglou.com>
References: <4D73BB65.8070700@zip.com.au> <4D73BD01.7080808@iglou.com>
Message-ID: <4D73C77C.9090900@iglou.com>

On 03/06/2011 11:57 AM, Gregory Pittman wrote:
> On 03/06/2011 11:50 AM, Craig Bradney wrote:
>> Hi Greg
>>
>> Can you please test 9559?
>>
>> Edit scriptercore.cpp and change:
>>
>> cm += QString("sys.path[0] =
>> \"%1\"\n").arg(escapedAbsPath);
>>
>> to
>>
>> cm += QString("sys.path.insert(0,
>> \"%1\")\n").arg(escapedAbsPath);
>
> Ok.
> I'll have to resurrect a script that used PIL.

Initial testing suggests it still doesn't work. I'll make a smaller 
script that uses PIL to try to make sure.

Greg


From elvstone at gmail.com  Sun Mar  6 19:37:11 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Sun, 6 Mar 2011 19:37:11 +0100
Subject: [scribus-dev] Tables as Summer of Code project
In-Reply-To: <4D73B0A4.8000904@scribus.info>
References: <AANLkTin4c_zZxQi1rUN8uvDJeB7ET6D-mnNz8R+p0rYk@mail.gmail.com>
	<4D73B0A4.8000904@scribus.info>
Message-ID: <AANLkTi=M-8UrqGLj3V_mat2Er7K5_fnWKYXOkUBJj+d2@mail.gmail.com>

2011/3/6 Craig Bradney <cbradney at scribus.info>:
>
>> So I have a few questions:
>>
>> 1) Am I right in that a table in Scribus would be a new PageItem?
>
> Yes, adding new types of items has become much easier in the last couple
> of years (still within the 1.5.0 branch though, time passes slowly these
> days)

Well that's good. Reading the code, I see PageItems are not
responsible for drawing themselves, but drawn in ScPageOutput,
correct?

>
>> 2) Would tables leverage Scribus' existing layout mechanisms by having
>> each cell in the table be (or contain) a PageItem_TextFrame?
>
> Yes, however the text side is somewhat separated from the TextFrame
> class, given there are text storage and layout classes.

Right, I found the StoryText class. But layout, isn't
PageItem_TextFrame::layout() all of it? (that's one massive function
btw!)

>
>
>> 3) What about the ideas at [2], are they relevant?
>
> This seems to introduce a lot of unneeded extras or things that could be
> done afterwards.

Alright.

>
>> 4) Is there any "birdseye" developer documentation of how Scribus does
>> its layout, from loading to final glyph? Classes involved, patterns
>> used et.c.? If not, is this something that any of the core devs would
>> be willing to jot down off the top of their head? Wouldn't have to be
>> anything ambitious, just some notes. It would really help as a guide
>> when reading the source code.
>
> Nope... unfortunately not. IRC works, emails work.. and the wiki works.
> The more people collaborate via the wiki, the more gets documented, but
> what exists now is very little.

I see, well I guess I'll just bug you guys when there's something I
need to know then.

>
> http://docs.scribus.net/devel/ is autogenerated from the classes

Yep, I found that. Also generated a local copy.

>
>> 5) Are there any refactorings, big or small, that needs to be done in
>> order to accommodate tables support? In my KWord project I was able to
>> do my work in a plugin, plus some reasonably small and isolated
>> changes to core layout code. What's the situation in Scribus?
>
> Per the above, new page item types are easier to add so while not a
> plugin, it would be quite well isolated for the basics.

Good.

>
>> I realize now that this mail sounds awfully negative :) But don't
>> worry, it's just me trying to be down to earth, as I know it's
>> important to iron these things out beforehand. Especially important is
>> to iron out what will be the scope of the project.
>
> Negative is not worth talking about.. realistic is. Reality will also be
> more beneficial for a GSoC application.

For sure. I read you had problems with students dropping out back in 2009 :(

>
> Another thing.. if GSoC would not work out this year, would you be
> interested in this via alternative sponsorship?

I would. Though depending on the amount of sponsorship available I
might have to get some kind of small additional summer job as well, to
cover rent and living costs.

>
> Also, per my msg on IRC, we have Jain Basil who was working on something
> towards tables, but given nothing public has come of that for various
> reasons on his part, however you should contact him and see where things
> are at on his side. He might have a lot of design to lean on or take
> over from, or be willing to share. Wasting work and stepping on toes is
> not something we encourage.

Right, I will. Is he on IRC? Guess he's on this list? (Jain; reply
here, or I'll just e-mail you directly).

>
> Thanks very much for contacting us

No problem, I remember you guys as a nice gang, and it's a fine piece
of software.

Elvis

>
> Craig
>
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
>


From gpittman at iglou.com  Mon Mar  7 00:04:06 2011
From: gpittman at iglou.com (Gregory Pittman)
Date: Sun, 06 Mar 2011 18:04:06 -0500
Subject: [scribus-dev] #9559
In-Reply-To: <4D73C77C.9090900@iglou.com>
References: <4D73BB65.8070700@zip.com.au> <4D73BD01.7080808@iglou.com>
	<4D73C77C.9090900@iglou.com>
Message-ID: <4D7412E6.7010409@iglou.com>

On 03/06/2011 12:42 PM, Gregory Pittman wrote:
> On 03/06/2011 11:57 AM, Gregory Pittman wrote:
>> On 03/06/2011 11:50 AM, Craig Bradney wrote:
>>> Hi Greg
>>>
>>> Can you please test 9559?
>>>
>>> Edit scriptercore.cpp and change:
>>>
>>> cm += QString("sys.path[0] =
>>> \"%1\"\n").arg(escapedAbsPath);
>>>
>>> to
>>>
>>> cm += QString("sys.path.insert(0,
>>> \"%1\")\n").arg(escapedAbsPath);
>>
>> Ok.
>> I'll have to resurrect a script that used PIL.
>
> Initial testing suggests it still doesn't work. I'll make a smaller
> script that uses PIL to try to make sure.

Still not getting it to work, but here are couple of scripts that you 
might try to test with.

The first, piltest.py, attempts to simply use PIL::Image to make an 
image frame of the correct size at set coordinates, with a set width. 
This fails and freezes.

The second, piltest2.py, is even simpler, just trying to load an image 
and shows a messageBox of its dimensions. Interestingly, this works to 
this point, yet still freezes. I will see if I can learn something about 
this Image module to try to explain this.

Greg
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: piltest.py
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110306/099b341b/attachment.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: piltest2.py
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110306/099b341b/attachment.txt>

From ale.comp_06 at xox.ch  Mon Mar  7 18:04:30 2011
From: ale.comp_06 at xox.ch (a.l.e)
Date: Mon, 07 Mar 2011 18:04:30 +0100
Subject: [scribus-dev] Tables as Summer of Code project
In-Reply-To: <AANLkTi=M-8UrqGLj3V_mat2Er7K5_fnWKYXOkUBJj+d2@mail.gmail.com>
References: <AANLkTin4c_zZxQi1rUN8uvDJeB7ET6D-mnNz8R+p0rYk@mail.gmail.com>	<4D73B0A4.8000904@scribus.info>
	<AANLkTi=M-8UrqGLj3V_mat2Er7K5_fnWKYXOkUBJj+d2@mail.gmail.com>
Message-ID: <4D75101E.3080801@xox.ch>

hi

after the longer and interesting irc discussion yesterday evening, i'd 
like to summarize my feelings about a GSOC project implementing the 
tables editor:

- it's a good idea to rebuild the table editor and GSOC may be the good 
place to start it.
- i don't think that a GSOC project can lead to a complete (state of the 
art) table editor.
- i'd prefer to just get a basic "modern" table editor (it must at least 
do what the current one can do) with a very solid structure and a clear 
documentation in which directions (and how) it should be extended,
- i'm not so enthusiastic of fitting as many optional features as the 
limited time frame of a GSOC allows.

in one sentence: i'd prefer a GSOC focused on a good design of the table 
editor, coupled with the implementation of its basic features (up to 
being usable).

ciao
a.l.e


From cbradney at zip.com.au  Mon Mar  7 18:15:30 2011
From: cbradney at zip.com.au (Craig Bradney)
Date: Mon, 07 Mar 2011 18:15:30 +0100
Subject: [scribus-dev] Tables as Summer of Code project
In-Reply-To: <4D75101E.3080801@xox.ch>
References: <AANLkTin4c_zZxQi1rUN8uvDJeB7ET6D-mnNz8R+p0rYk@mail.gmail.com>	<4D73B0A4.8000904@scribus.info>	<AANLkTi=M-8UrqGLj3V_mat2Er7K5_fnWKYXOkUBJj+d2@mail.gmail.com>
	<4D75101E.3080801@xox.ch>
Message-ID: <4D7512B2.1090601@zip.com.au>

On 3/7/11 6:04 PM, a.l.e wrote:
> hi
>
> after the longer and interesting irc discussion yesterday evening, i'd
> like to summarize my feelings about a GSOC project implementing the
> tables editor:
>
> - it's a good idea to rebuild the table editor and GSOC may be the
> good place to start it.
> - i don't think that a GSOC project can lead to a complete (state of
> the art) table editor.
> - i'd prefer to just get a basic "modern" table editor (it must at
> least do what the current one can do) with a very solid structure and
> a clear documentation in which directions (and how) it should be
> extended,
> - i'm not so enthusiastic of fitting as many optional features as the
> limited time frame of a GSOC allows.
>
> in one sentence: i'd prefer a GSOC focused on a good design of the
> table editor, coupled with the implementation of its basic features
> (up to being usable).

I'd agree.. however the current implementation of tables is also plain
wrong.. but I think we have a good candidate for this project, with a
proven history of implementing useful tables. From that and a basic
editor or on canvas editing, it could really progress well.

Craig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110307/bf193416/attachment.pgp>

From cbradney at scribus.info  Mon Mar  7 20:17:46 2011
From: cbradney at scribus.info (Craig Bradney)
Date: Mon, 07 Mar 2011 20:17:46 +0100
Subject: [scribus-dev] #9559
In-Reply-To: <4D7412E6.7010409@iglou.com>
References: <4D73BB65.8070700@zip.com.au>
	<4D73BD01.7080808@iglou.com>	<4D73C77C.9090900@iglou.com>
	<4D7412E6.7010409@iglou.com>
Message-ID: <4D752F5A.4070408@scribus.info>

On 3/7/11 12:04 AM, Gregory Pittman wrote:
> On 03/06/2011 12:42 PM, Gregory Pittman wrote:
>> On 03/06/2011 11:57 AM, Gregory Pittman wrote:
>>> On 03/06/2011 11:50 AM, Craig Bradney wrote:
>>>> Hi Greg
>>>>
>>>> Can you please test 9559?
>>>>
>>>> Edit scriptercore.cpp and change:
>>>>
>>>> cm += QString("sys.path[0] =
>>>> \"%1\"\n").arg(escapedAbsPath);
>>>>
>>>> to
>>>>
>>>> cm += QString("sys.path.insert(0,
>>>> \"%1\")\n").arg(escapedAbsPath);
>>>
>>> Ok.
>>> I'll have to resurrect a script that used PIL.
>>
>> Initial testing suggests it still doesn't work. I'll make a smaller
>> script that uses PIL to try to make sure.
> 
> Still not getting it to work, but here are couple of scripts that you
> might try to test with.
> 
> The first, piltest.py, attempts to simply use PIL::Image to make an
> image frame of the correct size at set coordinates, with a set width.
> This fails and freezes.
> 
> The second, piltest2.py, is even simpler, just trying to load an image
> and shows a messageBox of its dimensions. Interestingly, this works to
> this point, yet still freezes. I will see if I can learn something about
> this Image module to try to explain this.
> 

Ale, Greg, Malex, anyone who knows about scripting/python/PIL.. any
further thoughts on this?

RC2 is being tagged tonight.. if we could get this fixed in RC3 or
final, that would be nice!

thanks
Craig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110307/6c833f99/attachment.pgp>

From ale.comp_06 at xox.ch  Mon Mar  7 20:55:23 2011
From: ale.comp_06 at xox.ch (a.l.e)
Date: Mon, 7 Mar 2011 20:55:23 +0100
Subject: [scribus-dev] #9559
In-Reply-To: <4D752F5A.4070408@scribus.info>
References: <4D73BB65.8070700@zip.com.au> <4D73BD01.7080808@iglou.com>
	<4D73C77C.9090900@iglou.com> <4D7412E6.7010409@iglou.com>
	<4D752F5A.4070408@scribus.info>
Message-ID: <20110307205523.7c386d21@eisflach>

buonasera,

> On 3/7/11 12:04 AM, Gregory Pittman wrote:
> > On 03/06/2011 12:42 PM, Gregory Pittman wrote:
> >> On 03/06/2011 11:57 AM, Gregory Pittman wrote:
> >>> On 03/06/2011 11:50 AM, Craig Bradney wrote:
> >>>> Hi Greg
> >>>>
> >>>> Can you please test 9559?
> >>>>
> >>>> Edit scriptercore.cpp and change:
> >>>>
> >>>> cm += QString("sys.path[0] =
> >>>> \"%1\"\n").arg(escapedAbsPath);
> >>>>
> >>>> to
> >>>>
> >>>> cm += QString("sys.path.insert(0,
> >>>> \"%1\")\n").arg(escapedAbsPath);
> >>>
> >>> Ok.
> >>> I'll have to resurrect a script that used PIL.
> >>
> >> Initial testing suggests it still doesn't work. I'll make a smaller
> >> script that uses PIL to try to make sure.
> > 
> > Still not getting it to work, but here are couple of scripts that
> > you might try to test with.
> > 
> > The first, piltest.py, attempts to simply use PIL::Image to make an
> > image frame of the correct size at set coordinates, with a set
> > width. This fails and freezes.
> > 
> > The second, piltest2.py, is even simpler, just trying to load an
> > image and shows a messageBox of its dimensions. Interestingly, this
> > works to this point, yet still freezes. I will see if I can learn
> > something about this Image module to try to explain this.
> > 
> 
> Ale, Greg, Malex, anyone who knows about scripting/python/PIL.. any
> further thoughts on this?
> 
> RC2 is being tagged tonight.. if we could get this fixed in RC3 or
> final, that would be nice!

i don't have any ubuntu box around...

but, if needed, i can have a look at it.

ciao
a.l.e


From elvstone at gmail.com  Tue Mar  8 12:22:46 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Tue, 8 Mar 2011 12:22:46 +0100
Subject: [scribus-dev] Tables as Summer of Code project
In-Reply-To: <4D7512B2.1090601@zip.com.au>
References: <AANLkTin4c_zZxQi1rUN8uvDJeB7ET6D-mnNz8R+p0rYk@mail.gmail.com>
	<4D73B0A4.8000904@scribus.info>
	<AANLkTi=M-8UrqGLj3V_mat2Er7K5_fnWKYXOkUBJj+d2@mail.gmail.com>
	<4D75101E.3080801@xox.ch> <4D7512B2.1090601@zip.com.au>
Message-ID: <AANLkTikVDqEcPrd+czF0ehVX3Xd9_3HLdpUmSWMPKAyr@mail.gmail.com>

2011/3/7 Craig Bradney <cbradney at zip.com.au>:
> On 3/7/11 6:04 PM, a.l.e wrote:
>> hi
>>
>> after the longer and interesting irc discussion yesterday evening, i'd
>> like to summarize my feelings about a GSOC project implementing the
>> tables editor:
>>
>> - it's a good idea to rebuild the table editor and GSOC may be the
>> good place to start it.
>> - i don't think that a GSOC project can lead to a complete (state of
>> the art) table editor.
>> - i'd prefer to just get a basic "modern" table editor (it must at
>> least do what the current one can do) with a very solid structure and
>> a clear documentation in which directions (and how) it should be
>> extended,
>> - i'm not so enthusiastic of fitting as many optional features as the
>> limited time frame of a GSOC allows.
>>
>> in one sentence: i'd prefer a GSOC focused on a good design of the
>> table editor, coupled with the implementation of its basic features
>> (up to being usable).
>
> I'd agree.. however the current implementation of tables is also plain
> wrong.. but I think we have a good candidate for this project, with a
> proven history of implementing useful tables. From that and a basic
> editor or on canvas editing, it could really progress well.

I think so too, as long as things are kept realistic.

What a.l.e. is saying sounds reasonable to me. It is of course
important to keep extendibility and good design in mind when you know
something isn't going to be finished (which in all honesty nothing
ever is, so that last condition could be left out).

I have an exam coming up on Monday that I need to focus on, but after
that I hope to spend some time doing a bit more research and then
write a draft proposal.

Elvis

>
> Craig
>
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
>


From malex at scribus.info  Thu Mar 10 21:32:28 2011
From: malex at scribus.info (O. Moskalenko)
Date: Thu, 10 Mar 2011 14:32:28 -0600
Subject: [scribus-dev] gsoc application review requested
Message-ID: <20110310203228.GA11629@mail.tagancha.org>

Please take a look at
http://wiki.scribus.net/canvas/GSoC_2011_Scribus_Team_Application and post
your comments on the discussion page. The application is due tomorrow, so the
reviews must happen "tonight". I also need link_id data for all mentors
(http://www.google-melange.com/).

Let's get it done.

Cheers,

Alex


From gpittman at iglou.com  Fri Mar 11 18:16:50 2011
From: gpittman at iglou.com (Gregory Pittman)
Date: Fri, 11 Mar 2011 12:16:50 -0500
Subject: [scribus-dev] Scribus viability, longevity, financial stability
Message-ID: <4D7A5902.9040002@iglou.com>

Perhaps in the wind up to LGM 2011 we can begin to formulate a way for 
the masses of people (hehe) wanting to donate to the project to have 
some way of doing this.

It's hard to know if tax-deductibility is a big issue, but we at least 
should be shooting for an eV of some sort to be able to create a 
tax-protected bank account somewhere. It's a shame to be turning away or 
ignoring those who want to throw money our way.

Greg


From alexandre.prokoudine at gmail.com  Fri Mar 11 18:44:35 2011
From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine)
Date: Fri, 11 Mar 2011 20:44:35 +0300
Subject: [scribus-dev] Scribus viability, longevity, financial stability
In-Reply-To: <4D7A5902.9040002@iglou.com>
References: <4D7A5902.9040002@iglou.com>
Message-ID: <AANLkTinA3r2X_caO7AioLO4gJ+=RSKB8BX1Ctzk4rHkY@mail.gmail.com>

On Fri, Mar 11, 2011 at 8:16 PM, Gregory Pittman wrote:

> It's hard to know if tax-deductibility is a big issue, but we at least
> should be shooting for an eV of some sort to be able to create a
> tax-protected bank account somewhere.

Er... You mean the eV still doesn't exist? I was under impression it
was created several years ago.

Alexandre Prokoudine
http://libregraphicsworld.org


From mabri11 at ymail.com  Fri Mar 11 19:59:41 2011
From: mabri11 at ymail.com (Matthew Brincke)
Date: Fri, 11 Mar 2011 18:59:41 +0000 (GMT)
Subject: [scribus-dev] svg plug-in: how to extend with text-as-text
	importing?
Message-ID: <202386.38955.qm@web24920.mail.ird.yahoo.com>

Hello Scribus folks,

currently, the Scribus svg plug-in imports text as polylines. Therefore,
I'd like to extend it to import text as text because I need that functionality.
Firstly, is there someone already working on it (I don't want to duplicate
work)?
Secondly, is there a function available, accessible from plugins, that can
create text frames in the import area (e. g. as "sub-frame")?
Thirdly, is it feasible to do this work based on (and eventually for submission
to) Scribus 1.4(.x) (instead of Scribus 1.5), please? If yes, the preceding
questions are referencing the 1.4 branch, if not, the 1.5 branch.
Thank you very much in advance.

Best regards,

mabri




From ale.comp_06 at xox.ch  Sun Mar 13 16:11:36 2011
From: ale.comp_06 at xox.ch (a.l.e)
Date: Sun, 13 Mar 2011 16:11:36 +0100
Subject: [scribus-dev] svg plug-in: how to extend with text-as-text
 importing?
In-Reply-To: <202386.38955.qm@web24920.mail.ird.yahoo.com>
References: <202386.38955.qm@web24920.mail.ird.yahoo.com>
Message-ID: <20110313161136.16f21a9d@eisflach>

hi mabri,

> currently, the Scribus svg plug-in imports text as polylines.
> Therefore, I'd like to extend it to import text as text because I
> need that functionality. Firstly, is there someone already working on
> it (I don't want to duplicate work)?
> Secondly, is there a function available, accessible from plugins,
> that can create text frames in the import area (e. g. as "sub-frame")?
> Thirdly, is it feasible to do this work based on (and eventually for
> submission to) Scribus 1.4(.x) (instead of Scribus 1.5), please? If
> yes, the preceding questions are referencing the 1.4 branch, if not,
> the 1.5 branch. Thank you very much in advance.

any improvements which needs bigger changes should go into 1.5svn.

personally, if you want to work on this issue, i would suggest you to:
- add a choice to import the text as vector or as text
- start with a simple text frame from inkscape and add more and more features
- propose incremental patches by adding them to the bug tracker to simplify their review.

ciao
a.l.e


From elvstone at gmail.com  Sun Mar 20 16:33:13 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Sun, 20 Mar 2011 16:33:13 +0100
Subject: [scribus-dev] Tables GSoC draft proposal
Message-ID: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>

Hi,

First of all, congratulations on being picked by Google this year!

Below is a first draft of my GSoC proposal. The proposal is perhaps
better read on the wiki, where it's available at

http://wiki.scribus.net/canvas/GSoC_2011_Tables_Proposal

Please respond if you have any comments or if there are things I have missed.

Best regards,
Elvis

= Basic support for tables in Scribus [DRAFT 1] =

== Abstract ==
The Scribus software currently lacks proper support for laying out
content in a tabular arrangement, a feature commonly known as tables.
In the following document I propose to implement a first basic support
for tables in Scribus. The proposal comes in three parts. First, a
problem description is given, where I provide a rationale for the
project. Second, an implementation plan, including project
deliverables and a contingency plan. Third, a tentative timeline for
the project, and last some biographical information and other
practicalities.

== Problem Description ==
Tables provide a compact way of representing tabular information in a
page layout, and is a common design element in books, magazines and
advertisements. Scribus currently has a shortcut for creating an
automatically grouped table-like array of text frames. These are not
proper tables. To stay competitive, Scribus needs better support for
tables. Support that enables the user to create and edit tables as
distinct items with their own set of properties as commonly found in
other table implementations.

== Implementation Plan ==
Having been through Summer of Code once before, I think I have a good
perspective on what's important going into a project of this nature.
One thing that cannot be stressed enough is the importance of having
something tangible and working by the end of the project period. Not
only will this give closure and a sense of accomplishment to me as a
student, it also gives the Scribus core developers a good outlook when
it comes to taking the code in and building further on it. To mitigate
the risk of ending up with an unfinished project, a contingency plan
is included. The contingency plan lists features that can be dropped
from the project, should time start to run out.

=== Basic Idea ===
The implementation will be done by introducing a new page item,
PageItem_Table. This item will be responsible for layout and drawing
of a table. The layout and drawing of table cell content will be
delegated to standard text frames, which might have to be given new
features/modifications to serve this purpose. As content in the table
cells change, the table will be notified of this and perform a
relayout of the table, starting from the row in which the change
occured.

=== Project Deliverables ===
These are features that I believe are realistic to implement during
the course of the project (but see further down for a contingency
plan). For more detailed chronological information, see Timeline.

* Tables
** Insert, select, resize and remove.
** Background color.
** Border color.
** Border style.
** Default cell style.
** Breaking across page boundaries.
** Import from CSV and ODT.

* Table Rows
** Insert, select, resize and remove.
** Background color.
** Default cell style.

* Table Columns
** Insert, select, resize and remove.
** Background color.
** Default cell style.

* Table Cells
** Select and resize.
** Background color.
** Border color.
** Border style.
** Padding and margin.
** Row and column spanning.

For all features, load/save roundtrip to Scribus .sla format will be supported.

=== Contingency Plan ===
If unforeseen difficulties are encountered during the project, one of
more of the following features may be dropped. Hopefully to be
implemented later. Note that should any of these features be dropped,
an effort will still be made keep the feature in mind to avoid
painting ourselves into any corners.

* '''Breaking across page boundaries'''
*: This is a feature which I did not finish completely during my 2009
project for KWord, and one which can be quite hairy to implement. I
think I have a good general idea of how to go about it, but should it
turn out to take too long, it may be dropped.
* '''Row and column spanning'''
*: This I really think I should be able to pull off. But should time
run short, it may be dropped.
* '''Import from CSV and ODT'''
*: While hopefully not too challanging, technically, this feature may
be time consuming and is something which can be added later. Hence it
may be dropped.

== Timeline ==
Below follows a rough tentative timeline for the project. The timeline
is of course subject to change, should some parts of the project turn
out to be more/less time consuming than anticipated.

I have my last exam on May 28, and my first day of school after the
summer is Aug 28. This means my project period will be cut five days
short in the beginning. It was the same thing during my project in
2009, and I believe it's quite common for European students taking
part in Summer of Code. It just means the timeline has to take this
into account.

In the time leading up to the project period, I'll try to acquaint
myself with the Scribus code I'll be touching, and experiment with
data structures and layout algorithms for the tables I'll be
implementing.

* '''Week 1''' May 29-June 5
** Removal of the old "tables" implementation.
** Data structures for tables.
* '''Week 2''' June 6-June 12
** Basic table layout with fixed column widths and mock content in cells.
** Insertion/removal of rows/columns.
** Basic drawing of table.
* '''Week 3''' June 13-June 19
** More advanced layout.
** Variable column widths.
* '''Week 4''' June 20-June 26
** Cell formatting properties such as border and padding.
** Cell content layout; use Scribus' text frames to populate cells.
* '''Week 5''' June 27-July 3
** More integration of text frames. Fixing of issues/road bumps.
** UI: Row/column selection/insertion/removal/resizing.
* '''Week 6''' July 4-July 10
** Wrapping up for mid-term evaluation.
** Fix bugs/finish up what I have so far.
* '''Week 7''' July 11-July 17 '''(Mid-term-evaluation)'''
** Row and column spanning.
* '''Week 8''' July 18-July 24
** Table/row/column/cell styles.
* '''Week 9''' July 25-July 31
** UI: Direct formatting.
** UI: Integration of styles in Style Manager.
* '''Week 10''' August 1-August 7
** Table breaking.
* '''Week 11''' August 8-August 14
** More table breaking.
** CSV and/or ODT import.
* '''Week 12''' August 15-August 21 '''(Suggested pencils down)'''
** Wrapping up for mid-term evaluation.
** Fix bugs/finish up what I have so far.
* '''Deadline''' August 22 '''(Firm pencils down)'''

== Post-Summer of Code Commitment ==
A big part of what makes a successful project is the students level of
involvement after the project period is over. Although the time I will
have available for FOSS hacking will go down drastically after the
summer, I'll of course stick around to answer questions, fix bugs and
help out the best I can. I've stayed in contact with the KWord
developers ever since my project in 2009, and I won't treat you
Scribus folks differently. In short; I won't disappear on you.

== Student Biography ==
Living in Stockholm with my girlfriend Hanna, I'm a 27 year old
freshman at the Computer Science program at KTH Royal Institute of
Technology in Stockholm. I've dabbled with Free Software for about 12
years now. In recent years KDE has been my main focus and in 2009 I
implemented basic support for tables in the KWord word processor as
part of Google Summer of Code. Previous employments include working at
my dads small publishing company Nya Doxa AB and running my own book
shop as well as a book caf?. I should note that Scribus has been a
great help at both these positions. Apart from my studies I enjoy
hiking our small Swedish mountains when I have the opportunity, and
hanging out discussing with my friends over a beer. I have no other
engagements this summer apart from Summer of Code.

== Contact Information ==
'''Name:''' Elvis Stansvik<br>
'''E-mail:''' elvstone at gmail.com<br>
'''IRC:''' estan @ irc.freenode.net<br>
'''Phone:''' +46763091545


From alexandre.prokoudine at gmail.com  Sun Mar 20 20:33:29 2011
From: alexandre.prokoudine at gmail.com (Alexandre Prokoudine)
Date: Sun, 20 Mar 2011 22:33:29 +0300
Subject: [scribus-dev] Tables GSoC draft proposal
In-Reply-To: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>
References: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>
Message-ID: <AANLkTikC5uTh-apf3Y1L6p76N9PBUhN5mN+aMdSGBS0x@mail.gmail.com>

On 3/20/11, Elvis Stansvik wrote:

> ** UI: Integration of styles in Style Manager.

Wasn't there a plan to rewrite Style Manager? Is anybody in the team
expecting to work on it in the same timeframe?

> * '''Breaking across page boundaries'''
> *: This is a feature which I did not finish completely during my 2009
> project for KWord, and one which can be quite hairy to implement. I
> think I have a good general idea of how to go about it, but should it
> turn out to take too long, it may be dropped.

Scribus can already do that for other types of objects. Isn't the same
logic applicable to just another page item? If it isn't, then there is
something wrong with architecture, IMO :)

> == Post-Summer of Code Commitment ==
> A big part of what makes a successful project is the students level of
> involvement after the project period is over. Although the time I will
> have available for FOSS hacking will go down drastically after the
> summer, I'll of course stick around to answer questions, fix bugs and
> help out the best I can. I've stayed in contact with the KWord
> developers ever since my project in 2009, and I won't treat you
> Scribus folks differently. In short; I won't disappear on you.

Well, it's fair. I like it.

Alexandre Prokoudine
http://libregraphicsworld.org


From cbradney at scribus.info  Sun Mar 20 20:37:30 2011
From: cbradney at scribus.info (Craig Bradney)
Date: Sun, 20 Mar 2011 20:37:30 +0100
Subject: [scribus-dev] Tables GSoC draft proposal
In-Reply-To: <AANLkTikC5uTh-apf3Y1L6p76N9PBUhN5mN+aMdSGBS0x@mail.gmail.com>
References: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>
	<AANLkTikC5uTh-apf3Y1L6p76N9PBUhN5mN+aMdSGBS0x@mail.gmail.com>
Message-ID: <4D86577A.9070703@scribus.info>

On 3/20/11 8:33 PM, Alexandre Prokoudine wrote:
> On 3/20/11, Elvis Stansvik wrote:
> 
>> ** UI: Integration of styles in Style Manager.
> 
> Wasn't there a plan to rewrite Style Manager? Is anybody in the team
> expecting to work on it in the same timeframe?

Given the speed with which Estan added the table style support (at least
the start of), I removed this item from the GSoC list. There are more
important things to focus on.

>> * '''Breaking across page boundaries'''
>> *: This is a feature which I did not finish completely during my 2009
>> project for KWord, and one which can be quite hairy to implement. I
>> think I have a good general idea of how to go about it, but should it
>> turn out to take too long, it may be dropped.
> 
> Scribus can already do that for other types of objects. Isn't the same
> logic applicable to just another page item? If it isn't, then there is
> something wrong with architecture, IMO :)

Scribus cannot break a image frame across a page (ok, it can cut it, but
not break it)... nor can it break a text frame across a page, it breaks
the contents.


>> == Post-Summer of Code Commitment ==
>> A big part of what makes a successful project is the students level of
>> involvement after the project period is over. Although the time I will
>> have available for FOSS hacking will go down drastically after the
>> summer, I'll of course stick around to answer questions, fix bugs and
>> help out the best I can. I've stayed in contact with the KWord
>> developers ever since my project in 2009, and I won't treat you
>> Scribus folks differently. In short; I won't disappear on you.
> 
> Well, it's fair. I like it.

Me too.. my first vote goes to this one.

Craig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110320/006bf222/attachment.pgp>

From elvstone at gmail.com  Sun Mar 20 22:41:24 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Sun, 20 Mar 2011 22:41:24 +0100
Subject: [scribus-dev] Tables GSoC draft proposal
In-Reply-To: <AANLkTikC5uTh-apf3Y1L6p76N9PBUhN5mN+aMdSGBS0x@mail.gmail.com>
References: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>
	<AANLkTikC5uTh-apf3Y1L6p76N9PBUhN5mN+aMdSGBS0x@mail.gmail.com>
Message-ID: <AANLkTimV1QA6j6G=Aw4N_yr8jNqviEyEwLg8Uz6W8mLP@mail.gmail.com>

2011/3/20 Alexandre Prokoudine <alexandre.prokoudine at gmail.com>:
> On 3/20/11, Elvis Stansvik wrote:
>
>> ** UI: Integration of styles in Style Manager.
>
> Wasn't there a plan to rewrite Style Manager? Is anybody in the team
> expecting to work on it in the same timeframe?

I was unaware of that, but see Craig's answer.

>
>> * '''Breaking across page boundaries'''
>> *: This is a feature which I did not finish completely during my 2009
>> project for KWord, and one which can be quite hairy to implement. I
>> think I have a good general idea of how to go about it, but should it
>> turn out to take too long, it may be dropped.
>
> Scribus can already do that for other types of objects. Isn't the same
> logic applicable to just another page item? If it isn't, then there is
> something wrong with architecture, IMO :)

Well properly breaking a table is more than just continuing to draw
the table on the next page, it has implications for the layout of the
table. Open up OO.o and place a table across a page boundary and
you'll see what I mean. Throw in some row spanning cells across the
page boundary and it gets even funnier :)

I don't believe Scribus has any code that can be reused for this
purpose directly. It has the ability to properly break content across
linked frames, and that will probably come in handy. I believe I
should be able to use this functionality. A cell that is visible on N
pages will then be represented by N linked text frames.

Regards,
Elvis

>
>> == Post-Summer of Code Commitment ==
>> A big part of what makes a successful project is the students level of
>> involvement after the project period is over. Although the time I will
>> have available for FOSS hacking will go down drastically after the
>> summer, I'll of course stick around to answer questions, fix bugs and
>> help out the best I can. I've stayed in contact with the KWord
>> developers ever since my project in 2009, and I won't treat you
>> Scribus folks differently. In short; I won't disappear on you.
>
> Well, it's fair. I like it.
>
> Alexandre Prokoudine
> http://libregraphicsworld.org
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>


From czarek at oferuje.pl  Mon Mar 21 15:16:08 2011
From: czarek at oferuje.pl (Cezary Grabski)
Date: Mon, 21 Mar 2011 15:16:08 +0100
Subject: [scribus-dev] Case of cursor position after last char of text
Message-ID: <201103211516.08607.czarek@oferuje.pl>

I have problem with text undo in case when cursor is placed after last 
character in story text.

Problem is in that when cursor is in this position any changes related to char 
styles are not applied but undo state is created.
Scribus work in this case in other manner than other text editors.

In other text editors if you have cursor at the end of text any changes of 
text attributes are applied for next upcoming text. In OO when you place 
cursor in middle of the word without any selection changes are applied for 
whole word.

In Scribus in that case changes are applied for one char on the right. If 
cursor is at the of text there is any char on the right, so changes are not 
applied. But they are not applied for upcoming chars either.

Now undo state is created and this cause crashes on undo/redo actions.
I cant avoid creation undo states in such cases, but I think we should change 
Scribus behaviour in this situation.

cezaryece


From czarek at oferuje.pl  Mon Mar 21 15:42:11 2011
From: czarek at oferuje.pl (Cezary Grabski)
Date: Mon, 21 Mar 2011 15:42:11 +0100
Subject: [scribus-dev] Case of cursor position after last char of text
In-Reply-To: <201103211516.08607.czarek@oferuje.pl>
References: <201103211516.08607.czarek@oferuje.pl>
Message-ID: <201103211542.11365.czarek@oferuje.pl>

In fact there is problem either with cursor position after last char of each 
paragraph.
Changes related to char style seems be applied for PARSEP special char and on 
undo/redo strange things happen.

I dont think making undo checking for such exceptions will be solving this 
problem in good manner.

cezaryece


From plinnell at scribus.info  Mon Mar 28 00:09:51 2011
From: plinnell at scribus.info (Peter Linnell)
Date: Mon, 28 Mar 2011 00:09:51 +0200
Subject: [scribus-dev] 1.4.0.rc.3 Release
Message-ID: <4D8FB5AF.9060509@scribus.info>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Tonight we have released Scribus 1.4.0.rc3. It is more stable, faster
and nicer having had lots of TLC applied.

This release candidate is the last one where we will possibly make
string changes, so this is also a call for translators to update their
translations before 1.4.0 final.

This release features:

    Crash bug fixes
    A lot of undo updates (including updates to text undo)
    Usability fixes
    A move to 140 versioned preference files
    A number of older bugs triaged and fixed

The complete change log since 1.4.0.rc1 is here:
http://scribus.net/svn/Scribus/branches/Version135/Scribus/ChangeLogSVN

Users and testers are encouraged to check bugs fixes since rc2 was released.

Source downloads:
http://sourceforge.net/projects/scribus/files/scribus-devel/1.4.0.rc3/

Source sha1sums:

    482aa1e25d36995c1551d4d8ce6667b29f4346c0 scribus-1.4.0.rc3.7z
    353a6a1d0e640c817e609710cc53a40a7b457830 scribus-1.4.0.rc3.7z.sig
    a426a167ffb326125ffa6937c4afb295d01e8d61 scribus-1.4.0.rc3.tar.bz2
    6978403b47635ea4df3e7f3b9b07c143e36d5245 scribus-1.4.0.rc3.tar.bz2.sig
    3b15cb21e4b94155cda0f40fa0ea833149173562
Scribus_1.4.0.rc3_leopard_intel.dmg
    3b15cb21e4b94155cda0f40fa0ea833149173562
Scribus_1.4.0.rc3_leopard_intel.dmg

md5sum : db35ac29e724b7ab98536aa4c54ccafb
scribus-1.4.0.rc3-win32-install.exe

openSUSE, Fedora and Mandriva RPMS:
http://download.opensuse.org/repositories/home:/mrdocs/

Debian/Ubuntu Packages are expected soon in our upstream repositories.

Please see: http://wiki.scribus.net/canvas/Debian for instructions


Windows Installer:
http://sourceforge.net/projects/scribus/files/scribus-devel/1.4.0.rc3/scribus-1.4.0.rc3-win32-install.exe/download

Enjoy!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAk2Pta8ACgkQ73uV5/YBZtpC5QCfenw+TWCQ8EuY2dJzd+DFSTVB
A40Anj9hpL5MZORCBSH9drc8lywGBo7c
=USmq
-----END PGP SIGNATURE-----


From elvstone at gmail.com  Tue Mar 29 08:55:30 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Tue, 29 Mar 2011 08:55:30 +0200
Subject: [scribus-dev] Tables GSoC draft proposal
In-Reply-To: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>
References: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>
Message-ID: <AANLkTi=F96K0GVEJoXaCTdZT5zQiT5ap64XmOCU6Bpvv@mail.gmail.com>

Hello again,

As the student application period is now open, I'm planning on sending
my application to Google soon.

No further comments on my draft proposal below? I've done a couple of
small edits in the version on the wiki [1], but it's essentially the
same version as the one I sent to the list.

Should I give it the "final" stamp and maybe make a typeset version of it?

Cheers,
Elvis

[1] http://wiki.scribus.net/canvas/GSoC_2011_Tables_Proposal

2011/3/20 Elvis Stansvik <elvstone at gmail.com>:
> Hi,
>
> First of all, congratulations on being picked by Google this year!
>
> Below is a first draft of my GSoC proposal. The proposal is perhaps
> better read on the wiki, where it's available at
>
> http://wiki.scribus.net/canvas/GSoC_2011_Tables_Proposal
>
> Please respond if you have any comments or if there are things I have missed.
>
> Best regards,
> Elvis
>
> = Basic support for tables in Scribus [DRAFT 1] =
>
> == Abstract ==
> The Scribus software currently lacks proper support for laying out
> content in a tabular arrangement, a feature commonly known as tables.
> In the following document I propose to implement a first basic support
> for tables in Scribus. The proposal comes in three parts. First, a
> problem description is given, where I provide a rationale for the
> project. Second, an implementation plan, including project
> deliverables and a contingency plan. Third, a tentative timeline for
> the project, and last some biographical information and other
> practicalities.
>
> == Problem Description ==
> Tables provide a compact way of representing tabular information in a
> page layout, and is a common design element in books, magazines and
> advertisements. Scribus currently has a shortcut for creating an
> automatically grouped table-like array of text frames. These are not
> proper tables. To stay competitive, Scribus needs better support for
> tables. Support that enables the user to create and edit tables as
> distinct items with their own set of properties as commonly found in
> other table implementations.
>
> == Implementation Plan ==
> Having been through Summer of Code once before, I think I have a good
> perspective on what's important going into a project of this nature.
> One thing that cannot be stressed enough is the importance of having
> something tangible and working by the end of the project period. Not
> only will this give closure and a sense of accomplishment to me as a
> student, it also gives the Scribus core developers a good outlook when
> it comes to taking the code in and building further on it. To mitigate
> the risk of ending up with an unfinished project, a contingency plan
> is included. The contingency plan lists features that can be dropped
> from the project, should time start to run out.
>
> === Basic Idea ===
> The implementation will be done by introducing a new page item,
> PageItem_Table. This item will be responsible for layout and drawing
> of a table. The layout and drawing of table cell content will be
> delegated to standard text frames, which might have to be given new
> features/modifications to serve this purpose. As content in the table
> cells change, the table will be notified of this and perform a
> relayout of the table, starting from the row in which the change
> occured.
>
> === Project Deliverables ===
> These are features that I believe are realistic to implement during
> the course of the project (but see further down for a contingency
> plan). For more detailed chronological information, see Timeline.
>
> * Tables
> ** Insert, select, resize and remove.
> ** Background color.
> ** Border color.
> ** Border style.
> ** Default cell style.
> ** Breaking across page boundaries.
> ** Import from CSV and ODT.
>
> * Table Rows
> ** Insert, select, resize and remove.
> ** Background color.
> ** Default cell style.
>
> * Table Columns
> ** Insert, select, resize and remove.
> ** Background color.
> ** Default cell style.
>
> * Table Cells
> ** Select and resize.
> ** Background color.
> ** Border color.
> ** Border style.
> ** Padding and margin.
> ** Row and column spanning.
>
> For all features, load/save roundtrip to Scribus .sla format will be supported.
>
> === Contingency Plan ===
> If unforeseen difficulties are encountered during the project, one of
> more of the following features may be dropped. Hopefully to be
> implemented later. Note that should any of these features be dropped,
> an effort will still be made keep the feature in mind to avoid
> painting ourselves into any corners.
>
> * '''Breaking across page boundaries'''
> *: This is a feature which I did not finish completely during my 2009
> project for KWord, and one which can be quite hairy to implement. I
> think I have a good general idea of how to go about it, but should it
> turn out to take too long, it may be dropped.
> * '''Row and column spanning'''
> *: This I really think I should be able to pull off. But should time
> run short, it may be dropped.
> * '''Import from CSV and ODT'''
> *: While hopefully not too challanging, technically, this feature may
> be time consuming and is something which can be added later. Hence it
> may be dropped.
>
> == Timeline ==
> Below follows a rough tentative timeline for the project. The timeline
> is of course subject to change, should some parts of the project turn
> out to be more/less time consuming than anticipated.
>
> I have my last exam on May 28, and my first day of school after the
> summer is Aug 28. This means my project period will be cut five days
> short in the beginning. It was the same thing during my project in
> 2009, and I believe it's quite common for European students taking
> part in Summer of Code. It just means the timeline has to take this
> into account.
>
> In the time leading up to the project period, I'll try to acquaint
> myself with the Scribus code I'll be touching, and experiment with
> data structures and layout algorithms for the tables I'll be
> implementing.
>
> * '''Week 1''' May 29-June 5
> ** Removal of the old "tables" implementation.
> ** Data structures for tables.
> * '''Week 2''' June 6-June 12
> ** Basic table layout with fixed column widths and mock content in cells.
> ** Insertion/removal of rows/columns.
> ** Basic drawing of table.
> * '''Week 3''' June 13-June 19
> ** More advanced layout.
> ** Variable column widths.
> * '''Week 4''' June 20-June 26
> ** Cell formatting properties such as border and padding.
> ** Cell content layout; use Scribus' text frames to populate cells.
> * '''Week 5''' June 27-July 3
> ** More integration of text frames. Fixing of issues/road bumps.
> ** UI: Row/column selection/insertion/removal/resizing.
> * '''Week 6''' July 4-July 10
> ** Wrapping up for mid-term evaluation.
> ** Fix bugs/finish up what I have so far.
> * '''Week 7''' July 11-July 17 '''(Mid-term-evaluation)'''
> ** Row and column spanning.
> * '''Week 8''' July 18-July 24
> ** Table/row/column/cell styles.
> * '''Week 9''' July 25-July 31
> ** UI: Direct formatting.
> ** UI: Integration of styles in Style Manager.
> * '''Week 10''' August 1-August 7
> ** Table breaking.
> * '''Week 11''' August 8-August 14
> ** More table breaking.
> ** CSV and/or ODT import.
> * '''Week 12''' August 15-August 21 '''(Suggested pencils down)'''
> ** Wrapping up for mid-term evaluation.
> ** Fix bugs/finish up what I have so far.
> * '''Deadline''' August 22 '''(Firm pencils down)'''
>
> == Post-Summer of Code Commitment ==
> A big part of what makes a successful project is the students level of
> involvement after the project period is over. Although the time I will
> have available for FOSS hacking will go down drastically after the
> summer, I'll of course stick around to answer questions, fix bugs and
> help out the best I can. I've stayed in contact with the KWord
> developers ever since my project in 2009, and I won't treat you
> Scribus folks differently. In short; I won't disappear on you.
>
> == Student Biography ==
> Living in Stockholm with my girlfriend Hanna, I'm a 27 year old
> freshman at the Computer Science program at KTH Royal Institute of
> Technology in Stockholm. I've dabbled with Free Software for about 12
> years now. In recent years KDE has been my main focus and in 2009 I
> implemented basic support for tables in the KWord word processor as
> part of Google Summer of Code. Previous employments include working at
> my dads small publishing company Nya Doxa AB and running my own book
> shop as well as a book caf?. I should note that Scribus has been a
> great help at both these positions. Apart from my studies I enjoy
> hiking our small Swedish mountains when I have the opportunity, and
> hanging out discussing with my friends over a beer. I have no other
> engagements this summer apart from Summer of Code.
>
> == Contact Information ==
> '''Name:''' Elvis Stansvik<br>
> '''E-mail:''' elvstone at gmail.com<br>
> '''IRC:''' estan @ irc.freenode.net<br>
> '''Phone:''' +46763091545
>


From elvstone at gmail.com  Tue Mar 29 09:33:12 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Tue, 29 Mar 2011 09:33:12 +0200
Subject: [scribus-dev] Tables GSoC draft proposal
In-Reply-To: <AANLkTi=F96K0GVEJoXaCTdZT5zQiT5ap64XmOCU6Bpvv@mail.gmail.com>
References: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>
	<AANLkTi=F96K0GVEJoXaCTdZT5zQiT5ap64XmOCU6Bpvv@mail.gmail.com>
Message-ID: <AANLkTinyL5RyY=BL1Cn+UTuyTqOL0ZenjsC-guqVJff=@mail.gmail.com>

2011/3/29 Elvis Stansvik <elvstone at gmail.com>:
> Hello again,
>
> As the student application period is now open, I'm planning on sending
> my application to Google soon.
>
> No further comments on my draft proposal below? I've done a couple of
> small edits in the version on the wiki [1], but it's essentially the
> same version as the one I sent to the list.
>
> Should I give it the "final" stamp and maybe make a typeset version of it?

I made a quick LaTeX-typeset version of the proposal (attached).

Elvis

>
> Cheers,
> Elvis
>
> [1] http://wiki.scribus.net/canvas/GSoC_2011_Tables_Proposal
>
> 2011/3/20 Elvis Stansvik <elvstone at gmail.com>:
>> Hi,
>>
>> First of all, congratulations on being picked by Google this year!
>>
>> Below is a first draft of my GSoC proposal. The proposal is perhaps
>> better read on the wiki, where it's available at
>>
>> http://wiki.scribus.net/canvas/GSoC_2011_Tables_Proposal
>>
>> Please respond if you have any comments or if there are things I have missed.
>>
>> Best regards,
>> Elvis
>>
>> = Basic support for tables in Scribus [DRAFT 1] =
>>
>> == Abstract ==
>> The Scribus software currently lacks proper support for laying out
>> content in a tabular arrangement, a feature commonly known as tables.
>> In the following document I propose to implement a first basic support
>> for tables in Scribus. The proposal comes in three parts. First, a
>> problem description is given, where I provide a rationale for the
>> project. Second, an implementation plan, including project
>> deliverables and a contingency plan. Third, a tentative timeline for
>> the project, and last some biographical information and other
>> practicalities.
>>
>> == Problem Description ==
>> Tables provide a compact way of representing tabular information in a
>> page layout, and is a common design element in books, magazines and
>> advertisements. Scribus currently has a shortcut for creating an
>> automatically grouped table-like array of text frames. These are not
>> proper tables. To stay competitive, Scribus needs better support for
>> tables. Support that enables the user to create and edit tables as
>> distinct items with their own set of properties as commonly found in
>> other table implementations.
>>
>> == Implementation Plan ==
>> Having been through Summer of Code once before, I think I have a good
>> perspective on what's important going into a project of this nature.
>> One thing that cannot be stressed enough is the importance of having
>> something tangible and working by the end of the project period. Not
>> only will this give closure and a sense of accomplishment to me as a
>> student, it also gives the Scribus core developers a good outlook when
>> it comes to taking the code in and building further on it. To mitigate
>> the risk of ending up with an unfinished project, a contingency plan
>> is included. The contingency plan lists features that can be dropped
>> from the project, should time start to run out.
>>
>> === Basic Idea ===
>> The implementation will be done by introducing a new page item,
>> PageItem_Table. This item will be responsible for layout and drawing
>> of a table. The layout and drawing of table cell content will be
>> delegated to standard text frames, which might have to be given new
>> features/modifications to serve this purpose. As content in the table
>> cells change, the table will be notified of this and perform a
>> relayout of the table, starting from the row in which the change
>> occured.
>>
>> === Project Deliverables ===
>> These are features that I believe are realistic to implement during
>> the course of the project (but see further down for a contingency
>> plan). For more detailed chronological information, see Timeline.
>>
>> * Tables
>> ** Insert, select, resize and remove.
>> ** Background color.
>> ** Border color.
>> ** Border style.
>> ** Default cell style.
>> ** Breaking across page boundaries.
>> ** Import from CSV and ODT.
>>
>> * Table Rows
>> ** Insert, select, resize and remove.
>> ** Background color.
>> ** Default cell style.
>>
>> * Table Columns
>> ** Insert, select, resize and remove.
>> ** Background color.
>> ** Default cell style.
>>
>> * Table Cells
>> ** Select and resize.
>> ** Background color.
>> ** Border color.
>> ** Border style.
>> ** Padding and margin.
>> ** Row and column spanning.
>>
>> For all features, load/save roundtrip to Scribus .sla format will be supported.
>>
>> === Contingency Plan ===
>> If unforeseen difficulties are encountered during the project, one of
>> more of the following features may be dropped. Hopefully to be
>> implemented later. Note that should any of these features be dropped,
>> an effort will still be made keep the feature in mind to avoid
>> painting ourselves into any corners.
>>
>> * '''Breaking across page boundaries'''
>> *: This is a feature which I did not finish completely during my 2009
>> project for KWord, and one which can be quite hairy to implement. I
>> think I have a good general idea of how to go about it, but should it
>> turn out to take too long, it may be dropped.
>> * '''Row and column spanning'''
>> *: This I really think I should be able to pull off. But should time
>> run short, it may be dropped.
>> * '''Import from CSV and ODT'''
>> *: While hopefully not too challanging, technically, this feature may
>> be time consuming and is something which can be added later. Hence it
>> may be dropped.
>>
>> == Timeline ==
>> Below follows a rough tentative timeline for the project. The timeline
>> is of course subject to change, should some parts of the project turn
>> out to be more/less time consuming than anticipated.
>>
>> I have my last exam on May 28, and my first day of school after the
>> summer is Aug 28. This means my project period will be cut five days
>> short in the beginning. It was the same thing during my project in
>> 2009, and I believe it's quite common for European students taking
>> part in Summer of Code. It just means the timeline has to take this
>> into account.
>>
>> In the time leading up to the project period, I'll try to acquaint
>> myself with the Scribus code I'll be touching, and experiment with
>> data structures and layout algorithms for the tables I'll be
>> implementing.
>>
>> * '''Week 1''' May 29-June 5
>> ** Removal of the old "tables" implementation.
>> ** Data structures for tables.
>> * '''Week 2''' June 6-June 12
>> ** Basic table layout with fixed column widths and mock content in cells.
>> ** Insertion/removal of rows/columns.
>> ** Basic drawing of table.
>> * '''Week 3''' June 13-June 19
>> ** More advanced layout.
>> ** Variable column widths.
>> * '''Week 4''' June 20-June 26
>> ** Cell formatting properties such as border and padding.
>> ** Cell content layout; use Scribus' text frames to populate cells.
>> * '''Week 5''' June 27-July 3
>> ** More integration of text frames. Fixing of issues/road bumps.
>> ** UI: Row/column selection/insertion/removal/resizing.
>> * '''Week 6''' July 4-July 10
>> ** Wrapping up for mid-term evaluation.
>> ** Fix bugs/finish up what I have so far.
>> * '''Week 7''' July 11-July 17 '''(Mid-term-evaluation)'''
>> ** Row and column spanning.
>> * '''Week 8''' July 18-July 24
>> ** Table/row/column/cell styles.
>> * '''Week 9''' July 25-July 31
>> ** UI: Direct formatting.
>> ** UI: Integration of styles in Style Manager.
>> * '''Week 10''' August 1-August 7
>> ** Table breaking.
>> * '''Week 11''' August 8-August 14
>> ** More table breaking.
>> ** CSV and/or ODT import.
>> * '''Week 12''' August 15-August 21 '''(Suggested pencils down)'''
>> ** Wrapping up for mid-term evaluation.
>> ** Fix bugs/finish up what I have so far.
>> * '''Deadline''' August 22 '''(Firm pencils down)'''
>>
>> == Post-Summer of Code Commitment ==
>> A big part of what makes a successful project is the students level of
>> involvement after the project period is over. Although the time I will
>> have available for FOSS hacking will go down drastically after the
>> summer, I'll of course stick around to answer questions, fix bugs and
>> help out the best I can. I've stayed in contact with the KWord
>> developers ever since my project in 2009, and I won't treat you
>> Scribus folks differently. In short; I won't disappear on you.
>>
>> == Student Biography ==
>> Living in Stockholm with my girlfriend Hanna, I'm a 27 year old
>> freshman at the Computer Science program at KTH Royal Institute of
>> Technology in Stockholm. I've dabbled with Free Software for about 12
>> years now. In recent years KDE has been my main focus and in 2009 I
>> implemented basic support for tables in the KWord word processor as
>> part of Google Summer of Code. Previous employments include working at
>> my dads small publishing company Nya Doxa AB and running my own book
>> shop as well as a book caf?. I should note that Scribus has been a
>> great help at both these positions. Apart from my studies I enjoy
>> hiking our small Swedish mountains when I have the opportunity, and
>> hanging out discussing with my friends over a beer. I have no other
>> engagements this summer apart from Summer of Code.
>>
>> == Contact Information ==
>> '''Name:''' Elvis Stansvik<br>
>> '''E-mail:''' elvstone at gmail.com<br>
>> '''IRC:''' estan @ irc.freenode.net<br>
>> '''Phone:''' +46763091545
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gsoc_proposal.pdf
Type: application/pdf
Size: 34060 bytes
Desc: not available
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110329/74553783/attachment-0001.pdf>

From elvstone at gmail.com  Tue Mar 29 09:53:51 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Tue, 29 Mar 2011 09:53:51 +0200
Subject: [scribus-dev] Tables GSoC draft proposal
In-Reply-To: <AANLkTinyL5RyY=BL1Cn+UTuyTqOL0ZenjsC-guqVJff=@mail.gmail.com>
References: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>
	<AANLkTi=F96K0GVEJoXaCTdZT5zQiT5ap64XmOCU6Bpvv@mail.gmail.com>
	<AANLkTinyL5RyY=BL1Cn+UTuyTqOL0ZenjsC-guqVJff=@mail.gmail.com>
Message-ID: <AANLkTi=tpHjCLWUiupmcyPB7eCrZRcscfVuLbpEWDdNW@mail.gmail.com>

2011/3/29 Elvis Stansvik <elvstone at gmail.com>:
> 2011/3/29 Elvis Stansvik <elvstone at gmail.com>:
>> Hello again,
>>
>> As the student application period is now open, I'm planning on sending
>> my application to Google soon.
>>
>> No further comments on my draft proposal below? I've done a couple of
>> small edits in the version on the wiki [1], but it's essentially the
>> same version as the one I sent to the list.
>>
>> Should I give it the "final" stamp and maybe make a typeset version of it?
>
> I made a quick LaTeX-typeset version of the proposal (attached).

A few Unicode-related issues crept into that one. I've fixed them and
also put it up on the wiki, where I'll keep it up to date [1].

Elvis

[1] http://wiki.scribus.net/wiki/images/2/2c/Tables_GSoC_Proposal_2011.pdf

>
> Elvis
>
>>
>> Cheers,
>> Elvis
>>
>> [1] http://wiki.scribus.net/canvas/GSoC_2011_Tables_Proposal
>>
>> 2011/3/20 Elvis Stansvik <elvstone at gmail.com>:
>>> Hi,
>>>
>>> First of all, congratulations on being picked by Google this year!
>>>
>>> Below is a first draft of my GSoC proposal. The proposal is perhaps
>>> better read on the wiki, where it's available at
>>>
>>> http://wiki.scribus.net/canvas/GSoC_2011_Tables_Proposal
>>>
>>> Please respond if you have any comments or if there are things I have missed.
>>>
>>> Best regards,
>>> Elvis
>>>
>>> = Basic support for tables in Scribus [DRAFT 1] =
>>>
>>> == Abstract ==
>>> The Scribus software currently lacks proper support for laying out
>>> content in a tabular arrangement, a feature commonly known as tables.
>>> In the following document I propose to implement a first basic support
>>> for tables in Scribus. The proposal comes in three parts. First, a
>>> problem description is given, where I provide a rationale for the
>>> project. Second, an implementation plan, including project
>>> deliverables and a contingency plan. Third, a tentative timeline for
>>> the project, and last some biographical information and other
>>> practicalities.
>>>
>>> == Problem Description ==
>>> Tables provide a compact way of representing tabular information in a
>>> page layout, and is a common design element in books, magazines and
>>> advertisements. Scribus currently has a shortcut for creating an
>>> automatically grouped table-like array of text frames. These are not
>>> proper tables. To stay competitive, Scribus needs better support for
>>> tables. Support that enables the user to create and edit tables as
>>> distinct items with their own set of properties as commonly found in
>>> other table implementations.
>>>
>>> == Implementation Plan ==
>>> Having been through Summer of Code once before, I think I have a good
>>> perspective on what's important going into a project of this nature.
>>> One thing that cannot be stressed enough is the importance of having
>>> something tangible and working by the end of the project period. Not
>>> only will this give closure and a sense of accomplishment to me as a
>>> student, it also gives the Scribus core developers a good outlook when
>>> it comes to taking the code in and building further on it. To mitigate
>>> the risk of ending up with an unfinished project, a contingency plan
>>> is included. The contingency plan lists features that can be dropped
>>> from the project, should time start to run out.
>>>
>>> === Basic Idea ===
>>> The implementation will be done by introducing a new page item,
>>> PageItem_Table. This item will be responsible for layout and drawing
>>> of a table. The layout and drawing of table cell content will be
>>> delegated to standard text frames, which might have to be given new
>>> features/modifications to serve this purpose. As content in the table
>>> cells change, the table will be notified of this and perform a
>>> relayout of the table, starting from the row in which the change
>>> occured.
>>>
>>> === Project Deliverables ===
>>> These are features that I believe are realistic to implement during
>>> the course of the project (but see further down for a contingency
>>> plan). For more detailed chronological information, see Timeline.
>>>
>>> * Tables
>>> ** Insert, select, resize and remove.
>>> ** Background color.
>>> ** Border color.
>>> ** Border style.
>>> ** Default cell style.
>>> ** Breaking across page boundaries.
>>> ** Import from CSV and ODT.
>>>
>>> * Table Rows
>>> ** Insert, select, resize and remove.
>>> ** Background color.
>>> ** Default cell style.
>>>
>>> * Table Columns
>>> ** Insert, select, resize and remove.
>>> ** Background color.
>>> ** Default cell style.
>>>
>>> * Table Cells
>>> ** Select and resize.
>>> ** Background color.
>>> ** Border color.
>>> ** Border style.
>>> ** Padding and margin.
>>> ** Row and column spanning.
>>>
>>> For all features, load/save roundtrip to Scribus .sla format will be supported.
>>>
>>> === Contingency Plan ===
>>> If unforeseen difficulties are encountered during the project, one of
>>> more of the following features may be dropped. Hopefully to be
>>> implemented later. Note that should any of these features be dropped,
>>> an effort will still be made keep the feature in mind to avoid
>>> painting ourselves into any corners.
>>>
>>> * '''Breaking across page boundaries'''
>>> *: This is a feature which I did not finish completely during my 2009
>>> project for KWord, and one which can be quite hairy to implement. I
>>> think I have a good general idea of how to go about it, but should it
>>> turn out to take too long, it may be dropped.
>>> * '''Row and column spanning'''
>>> *: This I really think I should be able to pull off. But should time
>>> run short, it may be dropped.
>>> * '''Import from CSV and ODT'''
>>> *: While hopefully not too challanging, technically, this feature may
>>> be time consuming and is something which can be added later. Hence it
>>> may be dropped.
>>>
>>> == Timeline ==
>>> Below follows a rough tentative timeline for the project. The timeline
>>> is of course subject to change, should some parts of the project turn
>>> out to be more/less time consuming than anticipated.
>>>
>>> I have my last exam on May 28, and my first day of school after the
>>> summer is Aug 28. This means my project period will be cut five days
>>> short in the beginning. It was the same thing during my project in
>>> 2009, and I believe it's quite common for European students taking
>>> part in Summer of Code. It just means the timeline has to take this
>>> into account.
>>>
>>> In the time leading up to the project period, I'll try to acquaint
>>> myself with the Scribus code I'll be touching, and experiment with
>>> data structures and layout algorithms for the tables I'll be
>>> implementing.
>>>
>>> * '''Week 1''' May 29-June 5
>>> ** Removal of the old "tables" implementation.
>>> ** Data structures for tables.
>>> * '''Week 2''' June 6-June 12
>>> ** Basic table layout with fixed column widths and mock content in cells.
>>> ** Insertion/removal of rows/columns.
>>> ** Basic drawing of table.
>>> * '''Week 3''' June 13-June 19
>>> ** More advanced layout.
>>> ** Variable column widths.
>>> * '''Week 4''' June 20-June 26
>>> ** Cell formatting properties such as border and padding.
>>> ** Cell content layout; use Scribus' text frames to populate cells.
>>> * '''Week 5''' June 27-July 3
>>> ** More integration of text frames. Fixing of issues/road bumps.
>>> ** UI: Row/column selection/insertion/removal/resizing.
>>> * '''Week 6''' July 4-July 10
>>> ** Wrapping up for mid-term evaluation.
>>> ** Fix bugs/finish up what I have so far.
>>> * '''Week 7''' July 11-July 17 '''(Mid-term-evaluation)'''
>>> ** Row and column spanning.
>>> * '''Week 8''' July 18-July 24
>>> ** Table/row/column/cell styles.
>>> * '''Week 9''' July 25-July 31
>>> ** UI: Direct formatting.
>>> ** UI: Integration of styles in Style Manager.
>>> * '''Week 10''' August 1-August 7
>>> ** Table breaking.
>>> * '''Week 11''' August 8-August 14
>>> ** More table breaking.
>>> ** CSV and/or ODT import.
>>> * '''Week 12''' August 15-August 21 '''(Suggested pencils down)'''
>>> ** Wrapping up for mid-term evaluation.
>>> ** Fix bugs/finish up what I have so far.
>>> * '''Deadline''' August 22 '''(Firm pencils down)'''
>>>
>>> == Post-Summer of Code Commitment ==
>>> A big part of what makes a successful project is the students level of
>>> involvement after the project period is over. Although the time I will
>>> have available for FOSS hacking will go down drastically after the
>>> summer, I'll of course stick around to answer questions, fix bugs and
>>> help out the best I can. I've stayed in contact with the KWord
>>> developers ever since my project in 2009, and I won't treat you
>>> Scribus folks differently. In short; I won't disappear on you.
>>>
>>> == Student Biography ==
>>> Living in Stockholm with my girlfriend Hanna, I'm a 27 year old
>>> freshman at the Computer Science program at KTH Royal Institute of
>>> Technology in Stockholm. I've dabbled with Free Software for about 12
>>> years now. In recent years KDE has been my main focus and in 2009 I
>>> implemented basic support for tables in the KWord word processor as
>>> part of Google Summer of Code. Previous employments include working at
>>> my dads small publishing company Nya Doxa AB and running my own book
>>> shop as well as a book caf?. I should note that Scribus has been a
>>> great help at both these positions. Apart from my studies I enjoy
>>> hiking our small Swedish mountains when I have the opportunity, and
>>> hanging out discussing with my friends over a beer. I have no other
>>> engagements this summer apart from Summer of Code.
>>>
>>> == Contact Information ==
>>> '''Name:''' Elvis Stansvik<br>
>>> '''E-mail:''' elvstone at gmail.com<br>
>>> '''IRC:''' estan @ irc.freenode.net<br>
>>> '''Phone:''' +46763091545
>>>
>>
>


From cbradney at scribus.info  Tue Mar 29 10:23:55 2011
From: cbradney at scribus.info (Craig Bradney)
Date: Tue, 29 Mar 2011 10:23:55 +0200
Subject: [scribus-dev] Tables GSoC draft proposal
In-Reply-To: <AANLkTi=tpHjCLWUiupmcyPB7eCrZRcscfVuLbpEWDdNW@mail.gmail.com>
References: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>
	<AANLkTi=F96K0GVEJoXaCTdZT5zQiT5ap64XmOCU6Bpvv@mail.gmail.com>
	<AANLkTinyL5RyY=BL1Cn+UTuyTqOL0ZenjsC-guqVJff=@mail.gmail.com>
	<AANLkTi=tpHjCLWUiupmcyPB7eCrZRcscfVuLbpEWDdNW@mail.gmail.com>
Message-ID: <52823691-EB9E-4BA1-8A4D-F15CA8E79DAF@scribus.info>


Sorry, top posting on iPhone ugh.

Looks good, latex.. Shudder... Scribus! :)

Only thing I see I that with the pageitem split, you don't need to remove the old table implementation until the end. Just add a new mode and actions. Pretty easy.

Craig 


On 29/03/2011, at 9:53 AM, Elvis Stansvik <elvstone at gmail.com> wrote:

> 2011/3/29 Elvis Stansvik <elvstone at gmail.com>:
>> 2011/3/29 Elvis Stansvik <elvstone at gmail.com>:
>>> Hello again,
>>> 
>>> As the student application period is now open, I'm planning on sending
>>> my application to Google soon.
>>> 
>>> No further comments on my draft proposal below? I've done a couple of
>>> small edits in the version on the wiki [1], but it's essentially the
>>> same version as the one I sent to the list.
>>> 
>>> Should I give it the "final" stamp and maybe make a typeset version of it?
>> 
>> I made a quick LaTeX-typeset version of the proposal (attached).
> 
> A few Unicode-related issues crept into that one. I've fixed them and
> also put it up on the wiki, where I'll keep it up to date [1].
> 
> Elvis
> 
> [1] http://wiki.scribus.net/wiki/images/2/2c/Tables_GSoC_Proposal_2011.pdf
> 
>> 
>> Elvis
>> 
>>> 
>>> Cheers,
>>> Elvis
>>> 
>>> [1] http://wiki.scribus.net/canvas/GSoC_2011_Tables_Proposal
>>> 
>>> 2011/3/20 Elvis Stansvik <elvstone at gmail.com>:
>>>> Hi,
>>>> 
>>>> First of all, congratulations on being picked by Google this year!
>>>> 
>>>> Below is a first draft of my GSoC proposal. The proposal is perhaps
>>>> better read on the wiki, where it's available at
>>>> 
>>>> http://wiki.scribus.net/canvas/GSoC_2011_Tables_Proposal
>>>> 
>>>> Please respond if you have any comments or if there are things I have missed.
>>>> 
>>>> Best regards,
>>>> Elvis
>>>> 
>>>> = Basic support for tables in Scribus [DRAFT 1] =
>>>> 
>>>> == Abstract ==
>>>> The Scribus software currently lacks proper support for laying out
>>>> content in a tabular arrangement, a feature commonly known as tables.
>>>> In the following document I propose to implement a first basic support
>>>> for tables in Scribus. The proposal comes in three parts. First, a
>>>> problem description is given, where I provide a rationale for the
>>>> project. Second, an implementation plan, including project
>>>> deliverables and a contingency plan. Third, a tentative timeline for
>>>> the project, and last some biographical information and other
>>>> practicalities.
>>>> 
>>>> == Problem Description ==
>>>> Tables provide a compact way of representing tabular information in a
>>>> page layout, and is a common design element in books, magazines and
>>>> advertisements. Scribus currently has a shortcut for creating an
>>>> automatically grouped table-like array of text frames. These are not
>>>> proper tables. To stay competitive, Scribus needs better support for
>>>> tables. Support that enables the user to create and edit tables as
>>>> distinct items with their own set of properties as commonly found in
>>>> other table implementations.
>>>> 
>>>> == Implementation Plan ==
>>>> Having been through Summer of Code once before, I think I have a good
>>>> perspective on what's important going into a project of this nature.
>>>> One thing that cannot be stressed enough is the importance of having
>>>> something tangible and working by the end of the project period. Not
>>>> only will this give closure and a sense of accomplishment to me as a
>>>> student, it also gives the Scribus core developers a good outlook when
>>>> it comes to taking the code in and building further on it. To mitigate
>>>> the risk of ending up with an unfinished project, a contingency plan
>>>> is included. The contingency plan lists features that can be dropped
>>>> from the project, should time start to run out.
>>>> 
>>>> === Basic Idea ===
>>>> The implementation will be done by introducing a new page item,
>>>> PageItem_Table. This item will be responsible for layout and drawing
>>>> of a table. The layout and drawing of table cell content will be
>>>> delegated to standard text frames, which might have to be given new
>>>> features/modifications to serve this purpose. As content in the table
>>>> cells change, the table will be notified of this and perform a
>>>> relayout of the table, starting from the row in which the change
>>>> occured.
>>>> 
>>>> === Project Deliverables ===
>>>> These are features that I believe are realistic to implement during
>>>> the course of the project (but see further down for a contingency
>>>> plan). For more detailed chronological information, see Timeline.
>>>> 
>>>> * Tables
>>>> ** Insert, select, resize and remove.
>>>> ** Background color.
>>>> ** Border color.
>>>> ** Border style.
>>>> ** Default cell style.
>>>> ** Breaking across page boundaries.
>>>> ** Import from CSV and ODT.
>>>> 
>>>> * Table Rows
>>>> ** Insert, select, resize and remove.
>>>> ** Background color.
>>>> ** Default cell style.
>>>> 
>>>> * Table Columns
>>>> ** Insert, select, resize and remove.
>>>> ** Background color.
>>>> ** Default cell style.
>>>> 
>>>> * Table Cells
>>>> ** Select and resize.
>>>> ** Background color.
>>>> ** Border color.
>>>> ** Border style.
>>>> ** Padding and margin.
>>>> ** Row and column spanning.
>>>> 
>>>> For all features, load/save roundtrip to Scribus .sla format will be supported.
>>>> 
>>>> === Contingency Plan ===
>>>> If unforeseen difficulties are encountered during the project, one of
>>>> more of the following features may be dropped. Hopefully to be
>>>> implemented later. Note that should any of these features be dropped,
>>>> an effort will still be made keep the feature in mind to avoid
>>>> painting ourselves into any corners.
>>>> 
>>>> * '''Breaking across page boundaries'''
>>>> *: This is a feature which I did not finish completely during my 2009
>>>> project for KWord, and one which can be quite hairy to implement. I
>>>> think I have a good general idea of how to go about it, but should it
>>>> turn out to take too long, it may be dropped.
>>>> * '''Row and column spanning'''
>>>> *: This I really think I should be able to pull off. But should time
>>>> run short, it may be dropped.
>>>> * '''Import from CSV and ODT'''
>>>> *: While hopefully not too challanging, technically, this feature may
>>>> be time consuming and is something which can be added later. Hence it
>>>> may be dropped.
>>>> 
>>>> == Timeline ==
>>>> Below follows a rough tentative timeline for the project. The timeline
>>>> is of course subject to change, should some parts of the project turn
>>>> out to be more/less time consuming than anticipated.
>>>> 
>>>> I have my last exam on May 28, and my first day of school after the
>>>> summer is Aug 28. This means my project period will be cut five days
>>>> short in the beginning. It was the same thing during my project in
>>>> 2009, and I believe it's quite common for European students taking
>>>> part in Summer of Code. It just means the timeline has to take this
>>>> into account.
>>>> 
>>>> In the time leading up to the project period, I'll try to acquaint
>>>> myself with the Scribus code I'll be touching, and experiment with
>>>> data structures and layout algorithms for the tables I'll be
>>>> implementing.
>>>> 
>>>> * '''Week 1''' May 29-June 5
>>>> ** Removal of the old "tables" implementation.
>>>> ** Data structures for tables.
>>>> * '''Week 2''' June 6-June 12
>>>> ** Basic table layout with fixed column widths and mock content in cells.
>>>> ** Insertion/removal of rows/columns.
>>>> ** Basic drawing of table.
>>>> * '''Week 3''' June 13-June 19
>>>> ** More advanced layout.
>>>> ** Variable column widths.
>>>> * '''Week 4''' June 20-June 26
>>>> ** Cell formatting properties such as border and padding.
>>>> ** Cell content layout; use Scribus' text frames to populate cells.
>>>> * '''Week 5''' June 27-July 3
>>>> ** More integration of text frames. Fixing of issues/road bumps.
>>>> ** UI: Row/column selection/insertion/removal/resizing.
>>>> * '''Week 6''' July 4-July 10
>>>> ** Wrapping up for mid-term evaluation.
>>>> ** Fix bugs/finish up what I have so far.
>>>> * '''Week 7''' July 11-July 17 '''(Mid-term-evaluation)'''
>>>> ** Row and column spanning.
>>>> * '''Week 8''' July 18-July 24
>>>> ** Table/row/column/cell styles.
>>>> * '''Week 9''' July 25-July 31
>>>> ** UI: Direct formatting.
>>>> ** UI: Integration of styles in Style Manager.
>>>> * '''Week 10''' August 1-August 7
>>>> ** Table breaking.
>>>> * '''Week 11''' August 8-August 14
>>>> ** More table breaking.
>>>> ** CSV and/or ODT import.
>>>> * '''Week 12''' August 15-August 21 '''(Suggested pencils down)'''
>>>> ** Wrapping up for mid-term evaluation.
>>>> ** Fix bugs/finish up what I have so far.
>>>> * '''Deadline''' August 22 '''(Firm pencils down)'''
>>>> 
>>>> == Post-Summer of Code Commitment ==
>>>> A big part of what makes a successful project is the students level of
>>>> involvement after the project period is over. Although the time I will
>>>> have available for FOSS hacking will go down drastically after the
>>>> summer, I'll of course stick around to answer questions, fix bugs and
>>>> help out the best I can. I've stayed in contact with the KWord
>>>> developers ever since my project in 2009, and I won't treat you
>>>> Scribus folks differently. In short; I won't disappear on you.
>>>> 
>>>> == Student Biography ==
>>>> Living in Stockholm with my girlfriend Hanna, I'm a 27 year old
>>>> freshman at the Computer Science program at KTH Royal Institute of
>>>> Technology in Stockholm. I've dabbled with Free Software for about 12
>>>> years now. In recent years KDE has been my main focus and in 2009 I
>>>> implemented basic support for tables in the KWord word processor as
>>>> part of Google Summer of Code. Previous employments include working at
>>>> my dads small publishing company Nya Doxa AB and running my own book
>>>> shop as well as a book caf?. I should note that Scribus has been a
>>>> great help at both these positions. Apart from my studies I enjoy
>>>> hiking our small Swedish mountains when I have the opportunity, and
>>>> hanging out discussing with my friends over a beer. I have no other
>>>> engagements this summer apart from Summer of Code.
>>>> 
>>>> == Contact Information ==
>>>> '''Name:''' Elvis Stansvik<br>
>>>> '''E-mail:''' elvstone at gmail.com<br>
>>>> '''IRC:''' estan @ irc.freenode.net<br>
>>>> '''Phone:''' +46763091545
>>>> 
>>> 
>> 
> 
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev


From elvstone at gmail.com  Tue Mar 29 10:34:49 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Tue, 29 Mar 2011 10:34:49 +0200
Subject: [scribus-dev] Tables GSoC draft proposal
In-Reply-To: <52823691-EB9E-4BA1-8A4D-F15CA8E79DAF@scribus.info>
References: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>
	<AANLkTi=F96K0GVEJoXaCTdZT5zQiT5ap64XmOCU6Bpvv@mail.gmail.com>
	<AANLkTinyL5RyY=BL1Cn+UTuyTqOL0ZenjsC-guqVJff=@mail.gmail.com>
	<AANLkTi=tpHjCLWUiupmcyPB7eCrZRcscfVuLbpEWDdNW@mail.gmail.com>
	<52823691-EB9E-4BA1-8A4D-F15CA8E79DAF@scribus.info>
Message-ID: <AANLkTinJXLmhXhvL9DixXKqiG48Oc7eMBdF7U8ujqbuu@mail.gmail.com>

2011/3/29 Craig Bradney <cbradney at scribus.info>:
>
> Sorry, top posting on iPhone ugh.
>
> Looks good, latex.. Shudder... Scribus! :)

Heh, yea sorry. Of course I should have used Scribus, I did that for
my proposal in 2009 actually, even though the project then was for
KWord :) It's just I've gotten so used to LaTeX from school.

>
> Only thing I see I that with the pageitem split, you don't need to remove the old table implementation until the end. Just add a new mode and actions. Pretty easy.

Yup. I guess so. It's just that PageItem currently has a
isTableItem()/setIsTableItem() (it means a textframe that is part of a
"fake" table), which are function names I guess I might be using for
my implementation. But I can just refactor that out of the way and
keep the current stuff in until the very end.

I've removed that point from the timeline and updated the proposal on
the wiki and the PDF.

Elvis

>
> Craig
>
>
> On 29/03/2011, at 9:53 AM, Elvis Stansvik <elvstone at gmail.com> wrote:
>
>> 2011/3/29 Elvis Stansvik <elvstone at gmail.com>:
>>> 2011/3/29 Elvis Stansvik <elvstone at gmail.com>:
>>>> Hello again,
>>>>
>>>> As the student application period is now open, I'm planning on sending
>>>> my application to Google soon.
>>>>
>>>> No further comments on my draft proposal below? I've done a couple of
>>>> small edits in the version on the wiki [1], but it's essentially the
>>>> same version as the one I sent to the list.
>>>>
>>>> Should I give it the "final" stamp and maybe make a typeset version of it?
>>>
>>> I made a quick LaTeX-typeset version of the proposal (attached).
>>
>> A few Unicode-related issues crept into that one. I've fixed them and
>> also put it up on the wiki, where I'll keep it up to date [1].
>>
>> Elvis
>>
>> [1] http://wiki.scribus.net/wiki/images/2/2c/Tables_GSoC_Proposal_2011.pdf
>>
>>>
>>> Elvis
>>>
>>>>
>>>> Cheers,
>>>> Elvis
>>>>
>>>> [1] http://wiki.scribus.net/canvas/GSoC_2011_Tables_Proposal
>>>>
>>>> 2011/3/20 Elvis Stansvik <elvstone at gmail.com>:
>>>>> Hi,
>>>>>
>>>>> First of all, congratulations on being picked by Google this year!
>>>>>
>>>>> Below is a first draft of my GSoC proposal. The proposal is perhaps
>>>>> better read on the wiki, where it's available at
>>>>>
>>>>> http://wiki.scribus.net/canvas/GSoC_2011_Tables_Proposal
>>>>>
>>>>> Please respond if you have any comments or if there are things I have missed.
>>>>>
>>>>> Best regards,
>>>>> Elvis
>>>>>
>>>>> = Basic support for tables in Scribus [DRAFT 1] =
>>>>>
>>>>> == Abstract ==
>>>>> The Scribus software currently lacks proper support for laying out
>>>>> content in a tabular arrangement, a feature commonly known as tables.
>>>>> In the following document I propose to implement a first basic support
>>>>> for tables in Scribus. The proposal comes in three parts. First, a
>>>>> problem description is given, where I provide a rationale for the
>>>>> project. Second, an implementation plan, including project
>>>>> deliverables and a contingency plan. Third, a tentative timeline for
>>>>> the project, and last some biographical information and other
>>>>> practicalities.
>>>>>
>>>>> == Problem Description ==
>>>>> Tables provide a compact way of representing tabular information in a
>>>>> page layout, and is a common design element in books, magazines and
>>>>> advertisements. Scribus currently has a shortcut for creating an
>>>>> automatically grouped table-like array of text frames. These are not
>>>>> proper tables. To stay competitive, Scribus needs better support for
>>>>> tables. Support that enables the user to create and edit tables as
>>>>> distinct items with their own set of properties as commonly found in
>>>>> other table implementations.
>>>>>
>>>>> == Implementation Plan ==
>>>>> Having been through Summer of Code once before, I think I have a good
>>>>> perspective on what's important going into a project of this nature.
>>>>> One thing that cannot be stressed enough is the importance of having
>>>>> something tangible and working by the end of the project period. Not
>>>>> only will this give closure and a sense of accomplishment to me as a
>>>>> student, it also gives the Scribus core developers a good outlook when
>>>>> it comes to taking the code in and building further on it. To mitigate
>>>>> the risk of ending up with an unfinished project, a contingency plan
>>>>> is included. The contingency plan lists features that can be dropped
>>>>> from the project, should time start to run out.
>>>>>
>>>>> === Basic Idea ===
>>>>> The implementation will be done by introducing a new page item,
>>>>> PageItem_Table. This item will be responsible for layout and drawing
>>>>> of a table. The layout and drawing of table cell content will be
>>>>> delegated to standard text frames, which might have to be given new
>>>>> features/modifications to serve this purpose. As content in the table
>>>>> cells change, the table will be notified of this and perform a
>>>>> relayout of the table, starting from the row in which the change
>>>>> occured.
>>>>>
>>>>> === Project Deliverables ===
>>>>> These are features that I believe are realistic to implement during
>>>>> the course of the project (but see further down for a contingency
>>>>> plan). For more detailed chronological information, see Timeline.
>>>>>
>>>>> * Tables
>>>>> ** Insert, select, resize and remove.
>>>>> ** Background color.
>>>>> ** Border color.
>>>>> ** Border style.
>>>>> ** Default cell style.
>>>>> ** Breaking across page boundaries.
>>>>> ** Import from CSV and ODT.
>>>>>
>>>>> * Table Rows
>>>>> ** Insert, select, resize and remove.
>>>>> ** Background color.
>>>>> ** Default cell style.
>>>>>
>>>>> * Table Columns
>>>>> ** Insert, select, resize and remove.
>>>>> ** Background color.
>>>>> ** Default cell style.
>>>>>
>>>>> * Table Cells
>>>>> ** Select and resize.
>>>>> ** Background color.
>>>>> ** Border color.
>>>>> ** Border style.
>>>>> ** Padding and margin.
>>>>> ** Row and column spanning.
>>>>>
>>>>> For all features, load/save roundtrip to Scribus .sla format will be supported.
>>>>>
>>>>> === Contingency Plan ===
>>>>> If unforeseen difficulties are encountered during the project, one of
>>>>> more of the following features may be dropped. Hopefully to be
>>>>> implemented later. Note that should any of these features be dropped,
>>>>> an effort will still be made keep the feature in mind to avoid
>>>>> painting ourselves into any corners.
>>>>>
>>>>> * '''Breaking across page boundaries'''
>>>>> *: This is a feature which I did not finish completely during my 2009
>>>>> project for KWord, and one which can be quite hairy to implement. I
>>>>> think I have a good general idea of how to go about it, but should it
>>>>> turn out to take too long, it may be dropped.
>>>>> * '''Row and column spanning'''
>>>>> *: This I really think I should be able to pull off. But should time
>>>>> run short, it may be dropped.
>>>>> * '''Import from CSV and ODT'''
>>>>> *: While hopefully not too challanging, technically, this feature may
>>>>> be time consuming and is something which can be added later. Hence it
>>>>> may be dropped.
>>>>>
>>>>> == Timeline ==
>>>>> Below follows a rough tentative timeline for the project. The timeline
>>>>> is of course subject to change, should some parts of the project turn
>>>>> out to be more/less time consuming than anticipated.
>>>>>
>>>>> I have my last exam on May 28, and my first day of school after the
>>>>> summer is Aug 28. This means my project period will be cut five days
>>>>> short in the beginning. It was the same thing during my project in
>>>>> 2009, and I believe it's quite common for European students taking
>>>>> part in Summer of Code. It just means the timeline has to take this
>>>>> into account.
>>>>>
>>>>> In the time leading up to the project period, I'll try to acquaint
>>>>> myself with the Scribus code I'll be touching, and experiment with
>>>>> data structures and layout algorithms for the tables I'll be
>>>>> implementing.
>>>>>
>>>>> * '''Week 1''' May 29-June 5
>>>>> ** Removal of the old "tables" implementation.
>>>>> ** Data structures for tables.
>>>>> * '''Week 2''' June 6-June 12
>>>>> ** Basic table layout with fixed column widths and mock content in cells.
>>>>> ** Insertion/removal of rows/columns.
>>>>> ** Basic drawing of table.
>>>>> * '''Week 3''' June 13-June 19
>>>>> ** More advanced layout.
>>>>> ** Variable column widths.
>>>>> * '''Week 4''' June 20-June 26
>>>>> ** Cell formatting properties such as border and padding.
>>>>> ** Cell content layout; use Scribus' text frames to populate cells.
>>>>> * '''Week 5''' June 27-July 3
>>>>> ** More integration of text frames. Fixing of issues/road bumps.
>>>>> ** UI: Row/column selection/insertion/removal/resizing.
>>>>> * '''Week 6''' July 4-July 10
>>>>> ** Wrapping up for mid-term evaluation.
>>>>> ** Fix bugs/finish up what I have so far.
>>>>> * '''Week 7''' July 11-July 17 '''(Mid-term-evaluation)'''
>>>>> ** Row and column spanning.
>>>>> * '''Week 8''' July 18-July 24
>>>>> ** Table/row/column/cell styles.
>>>>> * '''Week 9''' July 25-July 31
>>>>> ** UI: Direct formatting.
>>>>> ** UI: Integration of styles in Style Manager.
>>>>> * '''Week 10''' August 1-August 7
>>>>> ** Table breaking.
>>>>> * '''Week 11''' August 8-August 14
>>>>> ** More table breaking.
>>>>> ** CSV and/or ODT import.
>>>>> * '''Week 12''' August 15-August 21 '''(Suggested pencils down)'''
>>>>> ** Wrapping up for mid-term evaluation.
>>>>> ** Fix bugs/finish up what I have so far.
>>>>> * '''Deadline''' August 22 '''(Firm pencils down)'''
>>>>>
>>>>> == Post-Summer of Code Commitment ==
>>>>> A big part of what makes a successful project is the students level of
>>>>> involvement after the project period is over. Although the time I will
>>>>> have available for FOSS hacking will go down drastically after the
>>>>> summer, I'll of course stick around to answer questions, fix bugs and
>>>>> help out the best I can. I've stayed in contact with the KWord
>>>>> developers ever since my project in 2009, and I won't treat you
>>>>> Scribus folks differently. In short; I won't disappear on you.
>>>>>
>>>>> == Student Biography ==
>>>>> Living in Stockholm with my girlfriend Hanna, I'm a 27 year old
>>>>> freshman at the Computer Science program at KTH Royal Institute of
>>>>> Technology in Stockholm. I've dabbled with Free Software for about 12
>>>>> years now. In recent years KDE has been my main focus and in 2009 I
>>>>> implemented basic support for tables in the KWord word processor as
>>>>> part of Google Summer of Code. Previous employments include working at
>>>>> my dads small publishing company Nya Doxa AB and running my own book
>>>>> shop as well as a book caf?. I should note that Scribus has been a
>>>>> great help at both these positions. Apart from my studies I enjoy
>>>>> hiking our small Swedish mountains when I have the opportunity, and
>>>>> hanging out discussing with my friends over a beer. I have no other
>>>>> engagements this summer apart from Summer of Code.
>>>>>
>>>>> == Contact Information ==
>>>>> '''Name:''' Elvis Stansvik<br>
>>>>> '''E-mail:''' elvstone at gmail.com<br>
>>>>> '''IRC:''' estan @ irc.freenode.net<br>
>>>>> '''Phone:''' +46763091545
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> scribus-dev mailing list
>> scribus-dev at lists.scribus.net
>> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>


From ale.comp_06 at xox.ch  Tue Mar 29 11:29:38 2011
From: ale.comp_06 at xox.ch (a.l.e)
Date: Tue, 29 Mar 2011 11:29:38 +0200
Subject: [scribus-dev] Tables GSoC draft proposal
In-Reply-To: <AANLkTi=tpHjCLWUiupmcyPB7eCrZRcscfVuLbpEWDdNW@mail.gmail.com>
References: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>	<AANLkTi=F96K0GVEJoXaCTdZT5zQiT5ap64XmOCU6Bpvv@mail.gmail.com>	<AANLkTinyL5RyY=BL1Cn+UTuyTqOL0ZenjsC-guqVJff=@mail.gmail.com>
	<AANLkTi=tpHjCLWUiupmcyPB7eCrZRcscfVuLbpEWDdNW@mail.gmail.com>
Message-ID: <4D91A682.4020201@xox.ch>

hi elvis,

looks like a solid proposal!

looking at the past GSOC projects and considering how important table 
editing is,  i'd like to suggest:

- integrating the code into the trunk should be part of the GSOC (and 
not happen at some later time; the answer from craig to your mail may 
suggest that this may happen...)
- you may define the extensions to your implementation which are 
important but you could / may not fit into the time frame of the GSOC 
(having an idea about the future direction may help people interested in 
single features to implement them as an "independent" project in the 
near future)

some more specific ideas:
- i'd rather to have some binding to the scripter API than "native" CSV 
import (and i'm not sure how badly i want to have them imported from 
.odt... going through CSV may be enough...)
- column / rows spanning is imo more important than page breaking (and i 
wonder whether it's also easier to implement)
- as craig wrote, it would be better to have both table implementations 
in parallel in trunk (and remove the old one when its features are 
matched by the ng one: this has been done for the preferences, the 
scripter and the PP...)

voil?, i wish you good luck with your proposal and -- hopefully -- with 
your GSOC project!

ciao
a.l.e


From elvstone at gmail.com  Tue Mar 29 12:35:28 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Tue, 29 Mar 2011 12:35:28 +0200
Subject: [scribus-dev] Tables GSoC draft proposal
In-Reply-To: <4D91A682.4020201@xox.ch>
References: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>
	<AANLkTi=F96K0GVEJoXaCTdZT5zQiT5ap64XmOCU6Bpvv@mail.gmail.com>
	<AANLkTinyL5RyY=BL1Cn+UTuyTqOL0ZenjsC-guqVJff=@mail.gmail.com>
	<AANLkTi=tpHjCLWUiupmcyPB7eCrZRcscfVuLbpEWDdNW@mail.gmail.com>
	<4D91A682.4020201@xox.ch>
Message-ID: <AANLkTinTY4-zuJ5UM0rsSzCRcCuoSOQ=3oR60KZatUzV@mail.gmail.com>

2011/3/29 a.l.e <ale.comp_06 at xox.ch>:
> hi elvis,
>
> looks like a solid proposal!
>
> looking at the past GSOC projects and considering how important table
> editing is, ?i'd like to suggest:
>
> - integrating the code into the trunk should be part of the GSOC (and not
> happen at some later time; the answer from craig to your mail may suggest
> that this may happen...)

right. i guess the idea is i'll be working in a branch and regularly
keep in sync with trunk? i don't know how much time i'll have to
schedule for the integration into trunk, but hopefully it won't be
that much work. as you can see i also have five days after the
official "pencils down" date until school starts again. i have no
problem with using these days for further work on the project, maybe
the integration could be scheduled on those days.

anyway, i'll put the trunk integration into the proposal somehow.

> - you may define the extensions to your implementation which are important
> but you could / may not fit into the time frame of the GSOC (having an idea
> about the future direction may help people interested in single features to
> implement them as an "independent" project in the near future)

good idea, i'll add an "outlook" section. although this section will
of course be of tentative nature. a more correct one will come in my
final report.

>
> some more specific ideas:
> - i'd rather to have some binding to the scripter API than "native" CSV
> import (and i'm not sure how badly i want to have them imported from .odt...
> going through CSV may be enough...)

alright, i'll keep that in mind. the importing features are also
features that i decided to put in my contingency plan as features that
may be dropped if time is short. but it's good to know that CSV > ODT.

> - column / rows spanning is imo more important than page breaking (and i
> wonder whether it's also easier to implement)

although they are both non-trivial, i would say row/column spanning is
easier than breaking without a doubt.

> - as craig wrote, it would be better to have both table implementations in
> parallel in trunk (and remove the old one when its features are matched by
> the ng one: this has been done for the preferences, the scripter and the
> PP...)

yea, i'll make sure to keep them both in there.

>
> voil?, i wish you good luck with your proposal and -- hopefully -- with your
> GSOC project!

thanks! and thanks for the good review. i gotto go to school soon, but
will come up with a new draft later tonight i think.

Elvis

>
> ciao
> a.l.e
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>


From gpittman at iglou.com  Tue Mar 29 18:01:30 2011
From: gpittman at iglou.com (Gregory Pittman)
Date: Tue, 29 Mar 2011 12:01:30 -0400
Subject: [scribus-dev] Tables GSoC draft proposal
In-Reply-To: <AANLkTi=tpHjCLWUiupmcyPB7eCrZRcscfVuLbpEWDdNW@mail.gmail.com>
References: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>	<AANLkTi=F96K0GVEJoXaCTdZT5zQiT5ap64XmOCU6Bpvv@mail.gmail.com>	<AANLkTinyL5RyY=BL1Cn+UTuyTqOL0ZenjsC-guqVJff=@mail.gmail.com>
	<AANLkTi=tpHjCLWUiupmcyPB7eCrZRcscfVuLbpEWDdNW@mail.gmail.com>
Message-ID: <4D92025A.9040509@iglou.com>

On 03/29/2011 03:53 AM, Elvis Stansvik wrote:
> 2011/3/29 Elvis Stansvik<elvstone at gmail.com>:
>> 2011/3/29 Elvis Stansvik<elvstone at gmail.com>:
>>> Hello again,
>>>
>>> As the student application period is now open, I'm planning on sending
>>> my application to Google soon.
>>>
>>> No further comments on my draft proposal below? I've done a couple of
>>> small edits in the version on the wiki [1], but it's essentially the
>>> same version as the one I sent to the list.
>>>
>>> Should I give it the "final" stamp and maybe make a typeset version of it?
>>
>> I made a quick LaTeX-typeset version of the proposal (attached).
>
> A few Unicode-related issues crept into that one. I've fixed them and
> also put it up on the wiki, where I'll keep it up to date [1].

Hi Elvis!

First suggestion: Clean the garbage from your emails. You could/should 
have trimmed down your post to the above. We have the archive to find 
old posts if we need them. This is a simple personal discipline issue.

Secondly: Try to get inside the head of a layout design user. While we 
want tables to interact with spreadsheet files and in some respects 
mimic the operation of a spreadsheet program, in layout design one is 
looking for things that you can't get from Excel/Calc or even 
Word/oowriter. We may want to make a table whose contents are links to a 
number of images, or you may start out with data/text, yet replace 
selected cells with images or replace a block of 2 or 4 or more cells 
with one image frame. Do all these need to be implemented for GSoC? No, 
but you need to anticipate these modifications later.

It actually puzzles me as to why, but for whatever reason, in word 
processor programs you can specify different characteristics for the 
different borders of a cell. Again, maybe something to anticipate rather 
than include in your project. What if someone wants a cell to be 
something other than a rectangle? Is this feasible?

Can a cell be a container for other Scribus content, such as render 
frames, polygons, arcs, spirals, even PDF form elements? Maybe container 
is a good paradigm to think about.

Lastly: Consider my position in the Scribus community as someone 
primarily involved with documentation. Don't take too seriously what I'm 
saying for one thing, but see if you can generate some information that 
can be used to generate user documentation for your implementations.

In summary: I think you have a solid proposal.

Greg


From ale.comp_06 at xox.ch  Tue Mar 29 18:28:17 2011
From: ale.comp_06 at xox.ch (a.l.e)
Date: Tue, 29 Mar 2011 18:28:17 +0200
Subject: [scribus-dev] Tables GSoC draft proposal
In-Reply-To: <4D92025A.9040509@iglou.com>
References: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>	<AANLkTi=F96K0GVEJoXaCTdZT5zQiT5ap64XmOCU6Bpvv@mail.gmail.com>	<AANLkTinyL5RyY=BL1Cn+UTuyTqOL0ZenjsC-guqVJff=@mail.gmail.com>	<AANLkTi=tpHjCLWUiupmcyPB7eCrZRcscfVuLbpEWDdNW@mail.gmail.com>
	<4D92025A.9040509@iglou.com>
Message-ID: <4D9208A1.3020004@xox.ch>

hi

> Secondly: Try to get inside the head of a layout design user. While we 
> want tables to interact with spreadsheet files and in some respects 
> mimic the operation of a spreadsheet program, in layout design one is 
> looking for things that you can't get from Excel/Calc or even 
> Word/oowriter. We may want to make a table whose contents are links to 
> a number of images, or you may start out with data/text, yet replace 
> selected cells with images or replace a block of 2 or 4 or more cells 
> with one image frame. Do all these need to be implemented for GSoC? 
> No, but you need to anticipate these modifications later.
>
> It actually puzzles me as to why, but for whatever reason, in word 
> processor programs you can specify different characteristics for the 
> different borders of a cell. Again, maybe something to anticipate 
> rather than include in your project. What if someone wants a cell to 
> be something other than a rectangle? Is this feasible?
>
> Can a cell be a container for other Scribus content, such as render 
> frames, polygons, arcs, spirals, even PDF form elements? Maybe 
> container is a good paradigm to think about.
>
> Lastly: Consider my position in the Scribus community as someone 
> primarily involved with documentation. Don't take too seriously what 
> I'm saying for one thing, but see if you can generate some information 
> that can be used to generate user documentation for your implementations.
>
> In summary: I think you have a solid proposal.

i guess we now know who was proposing the hexagonal cells...

:-)

ciao
a.l.e


From elvstone at gmail.com  Wed Mar 30 09:50:28 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Wed, 30 Mar 2011 09:50:28 +0200
Subject: [scribus-dev] Tables GSoC draft proposal
In-Reply-To: <4D92025A.9040509@iglou.com>
References: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>
	<AANLkTi=F96K0GVEJoXaCTdZT5zQiT5ap64XmOCU6Bpvv@mail.gmail.com>
	<AANLkTinyL5RyY=BL1Cn+UTuyTqOL0ZenjsC-guqVJff=@mail.gmail.com>
	<AANLkTi=tpHjCLWUiupmcyPB7eCrZRcscfVuLbpEWDdNW@mail.gmail.com>
	<4D92025A.9040509@iglou.com>
Message-ID: <AANLkTinUkRRw85yPkkPxjVQARNUMuRDPO37APy1vuAqA@mail.gmail.com>

Hi Gregory,

2011/3/29 Gregory Pittman <gpittman at iglou.com>:
> [...]
> Hi Elvis!
>
> First suggestion: Clean the garbage from your emails. You could/should have
> trimmed down your post to the above. We have the archive to find old posts
> if we need them. This is a simple personal discipline issue.

Really sorry about that. Different lists have different policies, or
maybe people have just been too shy to tell me. Thanks for pointing it
out. Won't happen again, promise! ;)

>
> Secondly: Try to get inside the head of a layout design user. While we want
> tables to interact with spreadsheet files and in some respects mimic the
> operation of a spreadsheet program, in layout design one is looking for
> things that you can't get from Excel/Calc or even Word/oowriter. We may want
> to make a table whose contents are links to a number of images, or you may
> start out with data/text, yet replace selected cells with images or replace
> a block of 2 or 4 or more cells with one image frame. Do all these need to
> be implemented for GSoC? No, but you need to anticipate these modifications
> later.

I guess my background in implementing tables for a word processor in
the past might shine through a bit in my proposal :) It's good that
you bring this up. For the use case you bring up, having images as
cells (possibly spanning several cells), I believe this should be
possible using "traditional" tables by using cell background images
combined with row/column spanning.

>
> It actually puzzles me as to why, but for whatever reason, in word processor
> programs you can specify different characteristics for the different borders
> of a cell. Again, maybe something to anticipate rather than include in your
> project. What if someone wants a cell to be something other than a
> rectangle? Is this feasible?

I'll answer the question of different cell border characteristics for
the different sides of cells first (I believe this is what you
meant?); I think this might have a use case even in graphical design.
See e.g.

http://www.creativepro.com/article/master-indesign-s-tabs-and-tables

for an example where I believe this feature has been used.

As for non-rectangular cells; it is true that a user might want to
layout e.g. hexagonal cells in a "beehive formation", or use other
types of non-rectangular "cells". My Summer of Code project is only
concerned with tables in the traditional sense though. Of course I'll
do my best to make these as intuitive and useful as possible for
graphic designers.

>
> Can a cell be a container for other Scribus content, such as render frames,
> polygons, arcs, spirals, even PDF form elements? Maybe container is a good
> paradigm to think about.

It is a good paradigm. And I can keep that in mind when writing the
code so that it will be feasible for my table layout code to lay out
other items apart from text frames in the future.

>
> Lastly: Consider my position in the Scribus community as someone primarily
> involved with documentation. Don't take too seriously what I'm saying for
> one thing, but see if you can generate some information that can be used to
> generate user documentation for your implementations.

I take all advice seriously! And your input is very valuable. Just
like you say, at the highest level of abstraction, tables are just a
collection of containers layed out according to certain rules. And
it's always good to keep abstraction in mind when writing new code.
But my project is by its nature limited, and I've decided to stick to
the traditional definition of tables. That is, a rectangular array of
rectangular cells. Baby steps you know ;)

But I'll keep in mind that one day we might want something more
abstract, maybe something called a "Collection", which could have
different strategies for layout, and of which my table layout code
would be one strategy. Although I can't see into the future, I'll try
to write clean and modular code with this in mind.

Finally, I'll make sure to at least jot something down that can be
used as a basis for user documentation during the project. Perhaps
I'll also have time to help out with writing it after the project
period is over.

>
> In summary: I think you have a solid proposal.

Great. And thanks again for your input.

Elvis

>
> Greg
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>


From elvstone at gmail.com  Wed Mar 30 10:02:21 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Wed, 30 Mar 2011 10:02:21 +0200
Subject: [scribus-dev] Tables GSoC draft proposal
In-Reply-To: <4D91A682.4020201@xox.ch>
References: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>
	<AANLkTi=F96K0GVEJoXaCTdZT5zQiT5ap64XmOCU6Bpvv@mail.gmail.com>
	<AANLkTinyL5RyY=BL1Cn+UTuyTqOL0ZenjsC-guqVJff=@mail.gmail.com>
	<AANLkTi=tpHjCLWUiupmcyPB7eCrZRcscfVuLbpEWDdNW@mail.gmail.com>
	<4D91A682.4020201@xox.ch>
Message-ID: <AANLkTik7DxP_tSn=O6+YV6wdRqpkXB2nDV4Hjj=Luo8H@mail.gmail.com>

Hi a.l.e,

2011/3/29 a.l.e <ale.comp_06 at xox.ch>:
> hi elvis,
>
> looks like a solid proposal!
>
> looking at the past GSOC projects and considering how important table
> editing is, ?i'd like to suggest:

Following your suggestions, I've updated the proposal with the
following changes:

* Cell/column spanning has been made mandatory (removed from contingency plan).
* Scribus trunk integration added to project deliverables/timeline. To
compensate, breaking across pages was removed from the project.
* The "Post-Summer of Code Commitment" section has been folded into a
new section "The Future" where I also list a few possible future
table-related projects.
* Scripting API added to project deliverables/timeline/contingency plan.
* Suggest importing features be implemented as scripts, and give CSV a
higher priority than ODT.

I believe that is it.

The updated version is on the wiki (and in the PDF, which is now
linked from the wiki page under "Printable Version").

Tell me if there's anything more you'd like changed/clarified (that
goes for anyone and everyone).

Otherwise I'll submit the proposal to you guys through Google Melange
as soon as I get an "OK".

Thanks for the input!

Elvis

>
> - integrating the code into the trunk should be part of the GSOC (and not
> happen at some later time; the answer from craig to your mail may suggest
> that this may happen...)
> - you may define the extensions to your implementation which are important
> but you could / may not fit into the time frame of the GSOC (having an idea
> about the future direction may help people interested in single features to
> implement them as an "independent" project in the near future)
>
> some more specific ideas:
> - i'd rather to have some binding to the scripter API than "native" CSV
> import (and i'm not sure how badly i want to have them imported from .odt...
> going through CSV may be enough...)
> - column / rows spanning is imo more important than page breaking (and i
> wonder whether it's also easier to implement)
> - as craig wrote, it would be better to have both table implementations in
> parallel in trunk (and remove the old one when its features are matched by
> the ng one: this has been done for the preferences, the scripter and the
> PP...)
>
> voil?, i wish you good luck with your proposal and -- hopefully -- with your
> GSOC project!
>
> ciao
> a.l.e
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>


From ale.comp_06 at xox.ch  Wed Mar 30 10:21:18 2011
From: ale.comp_06 at xox.ch (a.l.e)
Date: Wed, 30 Mar 2011 10:21:18 +0200
Subject: [scribus-dev] release checklist
Message-ID: <20110330102118.428567a6@eisflach>

dear scribmakers,


i guess that the team has a checklist for things to do before and after a release... but there is more to do :-) from time to time, i notice that there are things which are not up to date.

to track all those things than can be done by people external to the team, i dared to create a wiki page:

http://wiki.scribus.net/canvas/Release_management

if you think this can be helpful, please fill it with the things you notice that are out of sync!


btw, i've tried to find a checklist extension for mediawiki but could not find any... so, for now, let's go for a simple wiki page!

ciao
a.l.e


From elvstone at gmail.com  Wed Mar 30 10:24:56 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Wed, 30 Mar 2011 10:24:56 +0200
Subject: [scribus-dev] Some small good news regarding tables GSoC
Message-ID: <AANLkTikHHEvnAAEr73Bc+vrdkyqXJwhm4dCaSw4AiFd0@mail.gmail.com>

Good morning all,

I have some small good news.

This first year at my uni we've been having an introductory
programming/computer science course where they've been teaching us
basic OOP (and some simple algorithms) using Java. For my part, the
course has mostly been mundane excercises as I have some programming
background already and the exercises have been more of a chore than a
challenge. But to finish the course off, we're supposed to do a small
(few weeks) project on a subject of our choice.

I just got word yesterday that my teaching assistant will let me do my
project on table layout. It's kind of an awkward choice since the
project is supposed to be a finished program with a GUI, so I wasn't
sure she'd let me. Especially not since we're supposed to do the
project in pairs. But she will let me do the project on my own.

What this means is that I will have some in-school time to experiment
with table layout in Java, and maybe learn a thing or two that I can
bring with me into a possible future GSoC project this summer.

The project is of limited scope, only a few weeks (3-4 i think). And
of course it includes a lot of formal stuff in addition to the actual
coding. But I still consider it good news.

Just thought I'd let you guys know.

Elvis


From gpittman at iglou.com  Wed Mar 30 15:03:16 2011
From: gpittman at iglou.com (Gregory Pittman)
Date: Wed, 30 Mar 2011 09:03:16 -0400
Subject: [scribus-dev] Some small good news regarding tables GSoC
In-Reply-To: <AANLkTikHHEvnAAEr73Bc+vrdkyqXJwhm4dCaSw4AiFd0@mail.gmail.com>
References: <AANLkTikHHEvnAAEr73Bc+vrdkyqXJwhm4dCaSw4AiFd0@mail.gmail.com>
Message-ID: <4D932A14.2070207@iglou.com>

On 03/30/2011 04:24 AM, Elvis Stansvik wrote:
> Good morning all,
>
> I have some small good news.
>
> This first year at my uni we've been having an introductory
> programming/computer science course where they've been teaching us
> basic OOP (and some simple algorithms) using Java. For my part, the
> course has mostly been mundane excercises as I have some programming
> background already and the exercises have been more of a chore than a
> challenge. But to finish the course off, we're supposed to do a small
> (few weeks) project on a subject of our choice.
>
> I just got word yesterday that my teaching assistant will let me do my
> project on table layout. It's kind of an awkward choice since the
> project is supposed to be a finished program with a GUI, so I wasn't
> sure she'd let me. Especially not since we're supposed to do the
> project in pairs. But she will let me do the project on my own.
>
> What this means is that I will have some in-school time to experiment
> with table layout in Java, and maybe learn a thing or two that I can
> bring with me into a possible future GSoC project this summer.
>
> The project is of limited scope, only a few weeks (3-4 i think). And
> of course it includes a lot of formal stuff in addition to the actual
> coding. But I still consider it good news.
>
> Just thought I'd let you guys know.

Superb! This actually very much fits in with what we'd like to see -- 
students not waiting until GSoC begins to start to feel their way around 
their own project.

Greg


From cbradney at scribus.info  Wed Mar 30 16:11:17 2011
From: cbradney at scribus.info (Craig Bradney)
Date: Wed, 30 Mar 2011 16:11:17 +0200
Subject: [scribus-dev] Some small good news regarding tables GSoC
In-Reply-To: <4D932A14.2070207@iglou.com>
References: <AANLkTikHHEvnAAEr73Bc+vrdkyqXJwhm4dCaSw4AiFd0@mail.gmail.com>
	<4D932A14.2070207@iglou.com>
Message-ID: <91E5454C-F357-40EB-AC31-B740DA93F3D8@scribus.info>

Thanks for not cutting unnecessary info in your reply Greg ;)

Lol
Craig



On 30/03/2011, at 3:03 PM, Gregory Pittman <gpittman at iglou.com> wrote:

> On 03/30/2011 04:24 AM, Elvis Stansvik wrote:
>> Good morning all,
>> 
>> I have some small good news.
>> 
>> This first year at my uni we've been having an introductory
>> programming/computer science course where they've been teaching us
>> basic OOP (and some simple algorithms) using Java. For my part, the
>> course has mostly been mundane excercises as I have some programming
>> background already and the exercises have been more of a chore than a
>> challenge. But to finish the course off, we're supposed to do a small
>> (few weeks) project on a subject of our choice.
>> 
>> I just got word yesterday that my teaching assistant will let me do my
>> project on table layout. It's kind of an awkward choice since the
>> project is supposed to be a finished program with a GUI, so I wasn't
>> sure she'd let me. Especially not since we're supposed to do the
>> project in pairs. But she will let me do the project on my own.
>> 
>> What this means is that I will have some in-school time to experiment
>> with table layout in Java, and maybe learn a thing or two that I can
>> bring with me into a possible future GSoC project this summer.
>> 
>> The project is of limited scope, only a few weeks (3-4 i think). And
>> of course it includes a lot of formal stuff in addition to the actual
>> coding. But I still consider it good news.
>> 
>> Just thought I'd let you guys know.
> 
> Superb! This actually very much fits in with what we'd like to see -- students not waiting until GSoC begins to start to feel their way around their own project.
> 
> Greg
> 
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev


From gpittman at iglou.com  Wed Mar 30 17:13:01 2011
From: gpittman at iglou.com (Gregory Pittman)
Date: Wed, 30 Mar 2011 11:13:01 -0400
Subject: [scribus-dev] Some small good news regarding tables GSoC
In-Reply-To: <91E5454C-F357-40EB-AC31-B740DA93F3D8@scribus.info>
References: <AANLkTikHHEvnAAEr73Bc+vrdkyqXJwhm4dCaSw4AiFd0@mail.gmail.com>	<4D932A14.2070207@iglou.com>
	<91E5454C-F357-40EB-AC31-B740DA93F3D8@scribus.info>
Message-ID: <4D93487D.30008@iglou.com>

On 03/30/2011 10:11 AM, Craig Bradney wrote:
> Thanks for not cutting unnecessary info in your reply Greg ;)

au contraire, everything I left was needed. :-)
Perhaps you didn't scroll down Elvis's post to see what all was there...

It's what happens when you top-post. :D

Greg


From elvstone at gmail.com  Wed Mar 30 17:31:21 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Wed, 30 Mar 2011 17:31:21 +0200
Subject: [scribus-dev] Some small good news regarding tables GSoC
In-Reply-To: <4D93487D.30008@iglou.com>
References: <AANLkTikHHEvnAAEr73Bc+vrdkyqXJwhm4dCaSw4AiFd0@mail.gmail.com>
	<4D932A14.2070207@iglou.com>
	<91E5454C-F357-40EB-AC31-B740DA93F3D8@scribus.info>
	<4D93487D.30008@iglou.com>
Message-ID: <AANLkTimf+pMoGXFaoaO0qakANaAOmZnLEWFH+Bc2Kztp@mail.gmail.com>

Den onsdagen den 30:e mars 2011 skrev Gregory Pittman<gpittman at iglou.com>:
> On 03/30/2011 10:11 AM, Craig Bradney wrote:
>
> Thanks for not cutting unnecessary info in your reply Greg ;)
>
>
> au contraire, everything I left was needed. :-)
> Perhaps you didn't scroll down Elvis's post to see what all was there...
>
> It's what happens when you top-post. :D

*ducks in the fire* ;)

>
> Greg
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>


From cbradney at scribus.info  Wed Mar 30 17:47:16 2011
From: cbradney at scribus.info (Craig Bradney)
Date: Wed, 30 Mar 2011 17:47:16 +0200
Subject: [scribus-dev] Some small good news regarding tables GSoC
In-Reply-To: <AANLkTimf+pMoGXFaoaO0qakANaAOmZnLEWFH+Bc2Kztp@mail.gmail.com>
References: <AANLkTikHHEvnAAEr73Bc+vrdkyqXJwhm4dCaSw4AiFd0@mail.gmail.com>	<4D932A14.2070207@iglou.com>	<91E5454C-F357-40EB-AC31-B740DA93F3D8@scribus.info>	<4D93487D.30008@iglou.com>
	<AANLkTimf+pMoGXFaoaO0qakANaAOmZnLEWFH+Bc2Kztp@mail.gmail.com>
Message-ID: <4D935084.5090308@scribus.info>

On 3/30/11 5:31 PM, Elvis Stansvik wrote:
> Den onsdagen den 30:e mars 2011 skrev Gregory Pittman<gpittman at iglou.com>:
>> On 03/30/2011 10:11 AM, Craig Bradney wrote:
>>
>> Thanks for not cutting unnecessary info in your reply Greg ;)
>>
>>
>> au contraire, everything I left was needed. :-)
>> Perhaps you didn't scroll down Elvis's post to see what all was there...
>>
>> It's what happens when you top-post. :D
> 
> *ducks in the fire* ;)
> 

smartphone posting.. PITA. :)

Craig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110330/fc94b359/attachment.pgp>

From elvstone at gmail.com  Wed Mar 30 18:09:14 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Wed, 30 Mar 2011 18:09:14 +0200
Subject: [scribus-dev] Some small good news regarding tables GSoC
In-Reply-To: <4D935084.5090308@scribus.info>
References: <AANLkTikHHEvnAAEr73Bc+vrdkyqXJwhm4dCaSw4AiFd0@mail.gmail.com>
	<4D932A14.2070207@iglou.com>
	<91E5454C-F357-40EB-AC31-B740DA93F3D8@scribus.info>
	<4D93487D.30008@iglou.com>
	<AANLkTimf+pMoGXFaoaO0qakANaAOmZnLEWFH+Bc2Kztp@mail.gmail.com>
	<4D935084.5090308@scribus.info>
Message-ID: <AANLkTinHzPasbemXTn6Dgry3TOCsxv3ZNgwOhYaSnGgr@mail.gmail.com>

2011/3/30 Craig Bradney <cbradney at scribus.info>:
> On 3/30/11 5:31 PM, Elvis Stansvik wrote:
>> Den onsdagen den 30:e mars 2011 skrev Gregory Pittman<gpittman at iglou.com>:
>>> On 03/30/2011 10:11 AM, Craig Bradney wrote:
>>>
>>> Thanks for not cutting unnecessary info in your reply Greg ;)
>>>
>>>
>>> au contraire, everything I left was needed. :-)
>>> Perhaps you didn't scroll down Elvis's post to see what all was there...
>>>
>>> It's what happens when you top-post. :D
>>
>> *ducks in the fire* ;)
>>

smartphone posting ^

>
> smartphone posting.. PITA. :)

agreed.

>
> Craig
>
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
>


From elvstone at gmail.com  Wed Mar 30 20:09:31 2011
From: elvstone at gmail.com (Elvis Stansvik)
Date: Wed, 30 Mar 2011 20:09:31 +0200
Subject: [scribus-dev] Tables GSoC draft proposal
In-Reply-To: <AANLkTik7DxP_tSn=O6+YV6wdRqpkXB2nDV4Hjj=Luo8H@mail.gmail.com>
References: <AANLkTi=vhN9cZHPonkk0xLzSFenDMBLnShJFORUXSJ8t@mail.gmail.com>
	<AANLkTi=F96K0GVEJoXaCTdZT5zQiT5ap64XmOCU6Bpvv@mail.gmail.com>
	<AANLkTinyL5RyY=BL1Cn+UTuyTqOL0ZenjsC-guqVJff=@mail.gmail.com>
	<AANLkTi=tpHjCLWUiupmcyPB7eCrZRcscfVuLbpEWDdNW@mail.gmail.com>
	<4D91A682.4020201@xox.ch>
	<AANLkTik7DxP_tSn=O6+YV6wdRqpkXB2nDV4Hjj=Luo8H@mail.gmail.com>
Message-ID: <AANLkTikpE1XX+OpPScvJ8SSwWcwBex5=bFPnLGxhPO95@mail.gmail.com>

2011/3/30 Elvis Stansvik <elvstone at gmail.com>:
> Hi a.l.e,
>
> [...]
> Tell me if there's anything more you'd like changed/clarified (that
> goes for anyone and everyone).
>
> Otherwise I'll submit the proposal to you guys through Google Melange
> as soon as I get an "OK".

The proposal is now submitted and available at:

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/estan/1

Regards,
Elvis


From naveen.agarwal011 at gmail.com  Thu Mar 31 12:03:31 2011
From: naveen.agarwal011 at gmail.com (Naveen Agarwal)
Date: Thu, 31 Mar 2011 15:33:31 +0530
Subject: [scribus-dev] GSOC Application Submitted
Message-ID: <AANLkTim15DkDy_b0zEcfKCZCSWmZDwoprJNGpRbg3+m4@mail.gmail.com>

Hello Scribus Team,

After discussing with Scribus-dev team, I have submitted my proposal for
"Improvement of the undo/redo framework" project. The project will also
cover
creating of Unit Test suite for undo/redo framework and if time permits will
be
extended for the other parts as well.

Looking Forward for your input on the proposal!

Regards,
Naveen Agarwal
wolfpack(IRC nick)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110331/bb3615f8/attachment.htm>

