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

List:       koffice-devel
Subject:    [GSoC Proposal] KWord Plugins: MediaWiki translation, Auto-Correction,
From:       Nicholas Sinlock <isolatedincident () gmail ! com>
Date:       2009-03-27 17:34:09
Message-ID: 49CD0E11.3010901 () gmail ! com
[Download RAW message or body]

Hello everyone, I'm submitting a new proposal for comments.  This is 
still a partially rough draft, but I
feel like I've gotten most of the details nailed down.  Some of it may 
be partially incomplete because of
that and the time constraints I wrote this under.

["GSoC-KWord-Plugins-txt.txt" (text/plain)]

Name:
Nicholas Sinlock
 
Email Address:
IsolatedIncident@Gmail.com
 
Freenode IRC Nick:
nsinlock
 
Location (City, Country and/or Time Zone):
Ellicott City, Maryland, U.S.A. (Eastern Standard Time)
 
Proposal Name:
KWord Plugins: (media)wiki markup translation, auto-correction, and source code colorization 

Motivation for Proposal / Goal:
	This collection of plugins will introduce new, useful functionality into the KWord application \
of KOffice. Wikias, especially media wiki's, are becoming more popular over time, yet KWord is \
unable to recognize or translate those markups into the native KWord format. Implementing this \
plugin will enable the conversion of wikia pages into printable text documents. But even beyond \
that, it will also create the necessary background code to work off of when implementing KWord \
to (media)wiki markup translation.  Auto-correction in KWord 2.x is currently only partially \
implemented. Fully implementing this functionality will return KWord to the previous level of \
functionality enjoyed in 1.x. It will also allow for me to more easily implement the third \
plugin, the source code colorization plugin. KWord isn't necessarily the best choice for \
editing source code, but this plugin will be useful for users who want to compose documents \
which feature source code within their texts. The colorization allows for the source code to \
stand out within the document.  

Implementation Details:
	All of these plugins will be extending the kotextplugin class, which will allow them to modify \
the text only after a modification has been made to a word or paragraph within the document.  \
If possible I will use some existing code which converts (media)wiki to xml and modify it to \
convert the (media)wiki markup fully to the KWord standard. There are several options, \
including a python library, mwlib, which can parse mediawiki to a variety of formats. If I am \
unable to use any existing code, then I will have to write the specific code to parse and \
convert the (media)wiki markup into the KWord xml. The goal would be to run the plugin whenever \
a change is made to a paragraph, on that specific text. Either way, this would mean that when a \
person inserts a wikia page into KWord, the plugin will automatically translate those markups \
into markups understandable by KWord. Finally, since the plugin would only look at newly edited \
code, it could also react to a user typing in those markups, and shouldn't take up too many \
resources.  The auto-correction plugin will be superficially similar to the above plugin. It \
will implement the features not yet implemented within KWord 2.x. Currently, that includes the \
ability to use list formatting for bulleted paragraphs and autonumbering for numbered \
paragraphs. I can most likely borrow part of this code from kdelibs and kwrite/kate or even \
some of the code from KOffice 1.x for any functionality previously implemented.  The source \
code colorization plugin should be the easiest as I can borrow code from the previous plugins, \
and from Kate/KWrite. Kate/KWrite currently offer source code colorization for a number of \
languages. I can use the code, found in kdelibs under Kate/Syntax, and either borrow that code \
or write up new code based upon that code. Under kdelibs, there are also the xml definitions \
used in the syntax/source code colorization. I can simply access those from kdelibs or create a \
separate copy within the plugin structure. The plugin will detect a change in the document, and \
then use the Kate/KWrite code to detect and color and source code input into the document. The \
plugin will have to be selectively turned on, however, since otherwise the plugin would have to \
check the change against all of the possible source code types. Kate seems to implement this \
intelligently either setting it based upon the file type, or allowing a user to select the code \
type to be checked against.

Tentative Timeline:
My goal would be to start on the (media)wiki plugin in first, as it seems to be the most \
difficult. I would expect to finish the plugin within several weeks. I would then work on the \
auto-correction plugin, then the source code colorization. Since these ideas can reuse code \
from the previous plugins, I would expect them to take progressively less time. By the half way \
point, I plan on being done with the (media)wiki plugin, and be in the process of coding the \
auto-correction plugin. I'm confident that all three plugins can be successfully implemented \
within the allotted time.  

Do you have other obligations from late May to early August (school, work, etc.)?:
No.
 

About Me (let us know who you are!):
	I'm a freshman/sophmore Computer Science major in the University of Maryland: College \
Park(www.umd.edu and www.cs.umd.edu). I have experience programming in C++, Java, and Python. \
I've worked a little with both KDE and Qt, but I am still very new to Free Software. This would \
be my first major Free Software commit.    love KDE and KOffice, I run a KDE distro on both of \
my machines and am using KWord to write this document.(Not that this necessarily matters)



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


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