[kde-edu]: KVTML

[Joshua Keel]

> >On Saturday 02 July 2005 7:08 pm, Joshua Keel wrote:
> > Hi Peter,
> >
> > I've been developing a KDE Edu app (playground/edu/kanagram) lately
> > which uses KVTML. However, I've run into some problems using KVTML. I
> > need to develop an editor for it (and I've seen some code which does
> > that in KWordQuiz), but this code is not in libkdeedu. Also, my app
> > needs descriptions for its vocabulary files. Is there a file
> > description tag in KVTML? If so, there's no way to access that data in
> > libkdeedu. IMO, there needs to be a way to access such data. I propose
> > the following:
> >
> > 1. Move the KVTMLWriter class from KWordQuiz into libkdeedu
> > 2. If there isn't already a way to describe a file, add one to the format
> > 3. Add ways to access commonly used data such as a file description in
> > libkdeedu 4. Consider renaming the KEduVocData class to KVTMLReader, or
> > something more appropriate
> 
> What you are asking for is actually somewhat in progress. There is currently
> 
> development under way for a kvtml data class. Presently this is done within
> a 
> branch of KWordQuiz located in branches/work/kwordquiz. The ambition however
> 
> is to move the new classes (KEduVocExpression and KEduVocDocument) to 
> libkdeedu when they are more mature. They can then be shared among 
> applications. You are welcome to participate in this work. Current lead 
> developer for this is Eric Pignet (see CC).

I've checked out the latest KWordQuiz, and the work being done looks
good. I need something working right now, though, and my needs are
fairly simple. If I could, I'd like to add a couple of features to the
current kvtml libs. These features would be:

1. parse the header (get the remark attribute and the title, store
them as members?)
2. allow getting and settings of the word and its associated
translation in a KEduVocDataItem

I think that's about all I need. I had basically decided to come up
with my own plaintext format when annma and pinotree stopped me and
let me know all the reasons that wasn't a good idea. ;) If no one has
any problems with making the mentioned modifications, I'll start
working on it. Should I submit a patch to the list after I get it
working? Are there any design considerations I should be aware of? I'm
especially wondering about parsing the header. Should we go ahead and
create another parse() method, named parseHeader() (or something more
relevant) instead? And should the KEduVocDataItem store its word and
translation in QStrings, or in the currently used QDomElement?

I may also want to import the KVTMLWriter class from the stable
KWordQuiz. What do you think of that?

Thanks,
Joshua Keel