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