--===============0584504679==
Content-Type: multipart/signed;
  boundary="nextPart2397318.nUNoG5ULL7";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart2397318.nUNoG5ULL7
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 17 March 2009 19:18:18 Nicholas Sinlock wrote:
> Thomas Zander wrote:
> > On Tuesday 17. March 2009 17:36:17 Nicholas Sinlock wrote:
> >> But Thomas, I am not sure if I understand you
> >> about one thing.   Are you saying that you
> >>  don't want GSoC students to deal with any of the core apps code at al=
l?
> >
> > I will limit my input on this matter to KWord and the textshape related
> > classes here, as that is where my experience and my invested time lies.
> > There is still a lot of work in the core that I think is useful to do,
> > but as I mentioned the shared vision on this is essential as well as go=
od
> > communication.  Those things that grow over time as people work togethe=
r.
> >
> > A GSoC student is per definition someone that is new to the project (as
> > that is our main goal for accepting students) and since the student wor=
ks
> > full time and the mentor typically has a day job or even holidays its
> > very hard to share this common vision of code structures and intentions
> > while the GSoC runs.
> > So if you want to have a good chance of your contributions ending up in=
 a
> > future KOffice release it will be a good idea to avoid working on the
> > core parts for your GSoC.
> >
> > And it doesn't have to be an issue, really. There are really a million
> > cool projects you can do as plugins in KOffice.
> > Be creative :)
>
> Alright, let me just ask straight out then.   Do you feel that this
> proposal is too big for a GSoC period?
> If so, could you give me an idea of what size is more appropriate?   I'd
> really rather like to be able to
> work on KOffice for the GSoC, and if my proposal is too big to begin
> with, I'd rather drop it an move
> on to a potentially more successful one.  Thanks!
I don't think that this proposal is too big for a GSoC : versionning has no=
=20
relation with any change tracking system : it's just about being able to st=
ore=20
and retrieve "snapshots" of the document to/from a single ODF file.
That behaviour is not standardized so far, OpenOffice.org implements it usi=
ng=20
a new Versions.xml file in the document root folder, and with a versions=20
subfolder containing each version as a simple OpenDocument file.
So I don't think that this would be too hard to implement in KOffice for a=
=20
GSoC. Moreover, this would benefit every KOffice application supporting ODF.


--nextPart2397318.nUNoG5ULL7
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAknAJqUACgkQZA1EFZCdHVvumACfQWn8r5JVYm/dBn16RPn06aCM
Z2sAoKB3LaIWHZLDzYFfTTANwb7jGasM
=NNZT
-----END PGP SIGNATURE-----

--nextPart2397318.nUNoG5ULL7--

--===============0584504679==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0584504679==--