[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]