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

List:       kde-edu-devel
Subject:    [kde-edu-devel] And so it begins (libkdeedu)
From:       Scott Wheeler <wheeler () kde ! org>
Date:       2002-05-30 0:15:05
[Download RAW message or body]

Ok, I wrote all of this offline prior to Ewald's mention of issues with QDom,  
but those can be looked at shortly.  Here's what I've got for now: 
 
=== 
 
Per public and private discussion with Annma today, I've committed the first  
part of libkdeedu.  With all of the hype around the use of Ewald's kvtml,  
Anma has been the first besides Ewald and myself to take the initiative to  
begin using it.  Rather than having her copy and paste my poor implementation  
it seemed to be a good time to start to Do Things The Right Way (tm). 
 
First, I made a lib based on my bad implementation of kvtml, but then my  
conscience got the better of me and I started tinkering with QDom.  What  
you'll find in libkdeedu is a QDom based, very basic, parser for kvtml.   
Right now it just parses "e" (entry), "o" (original) and "t" (tranlation)  
tags, but it's done in such a way that it should be easy to extend (unlike my  
previous implementation).  I've also made changes to FlashKard to do it's  
input using this. 
 
So now, if you include "kedudata.h", you'll have access to two classes and a  
typedef.  They are as follows: 
 
KEduDataItem -- a class to store vocabulary items 
KEduDataItemList -- a "typedef QValueList<KEduDataItem>" 
KEduData -- a class that will later be used for kvtml documents but at the  
moment just has one static member "parse(const QString fileName)". 
 
The use is basically what I laid out in my earlier email: 
 
KEduDataItemList list = KEduData::parse("foo.kvtml"); 
QString original = list[0].originalText(); 
QString translated = list[0].translatedText(); 
 
Also you'll need something like: 
 
#include "../../libkdeedu/kedudata.h" 
 
and in your Makefile.am: 
 
flashkard_LDADD = $(LIB_KFILE) ../../libkdeedu/libkdeedu.la 
 
So now some disclaimers: 
 
This is very basic.  There isn't much there, but that will change.  Right now  
this is to suit Annma's needs (and FlashKard while I'm at it).  Many gaps  
need to be filled in. 
 
This is all *very* subject to change.  In fact I guarantee it.  If you're  
lucky, I'll only break your app a few times.  Things will be moved, renamed,  
rewritten and the API will change. 
 
This also means that it's open for suggestions.  For the name of the lib, I  
followed the libkdenetwork pattern, but that can change.  I arbitrarily  
picked the prefix "KEdu" for all of the classes and decided on the name  
"KEduData" for the vocabulary data.  Ewald had suggested some other things  
but mainly based on having several KDE-Edu libs, which of course begs the  
question, should there be several?  Looking around at other KDE things it  
seems pretty common to pack a lot of logically connected material into one  
lib. 
 
Also propper (in-header) documentation will follow, but I want to get a little  
better idea of what the API will be before I spend the time to document it. 
 
I'm really not trying to comandere this thing, I was just feeling productive,  
so I started coding. 
 
I may start looking into writing something to write kvtml, but that will  
probably happen after a brainstorming session at LinuxTag. 
 
Cheers and good luck! 
 
-Scott 
_______________________________________________
kde-edu-devel mailing list
kde-edu-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-edu-devel
[prev in list] [next in list] [prev in thread] [next in thread]