From kde-edu-devel Thu May 30 00:15:05 2002 From: Scott Wheeler Date: Thu, 30 May 2002 00:15:05 +0000 To: kde-edu-devel Subject: [kde-edu-devel] And so it begins (libkdeedu) X-MARC-Message: https://marc.info/?l=kde-edu-devel&m=102271788626227 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" 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