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