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

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

On Thursday 30 May 2002 08:37 am, Ewald Arnold wrote:

> I already mentioned that I don't like the idea of walking through a domtree 
> too much. Of course this is a very personal opinion. I will start an event 
> driven approach the next days so we can compare the two.

I can understand why.  As you know my original implementation was SAX based 
and I have it working in lib format if you would like for me to send it to 
you.  Yesterday I first just copied in the code from FlashKard, made it work 
in the lib, but then sometime around 20:00 last night I started playing with 
QDom and decided to use that instead.

I too would like to see some real tests on how this performs comparatively.  
I'll also look around through the other KDE sources to see what is used in 
different places.

The advantage to using the QDom approach is that it is much easier to 
reconstruct a document.  This was my main concern with a SAX based approach 
and the chief shortcoming of FlashKard's implementation.  For a static 
parse() function like I implemented yesterday, it really doesn't matter, 
because the assumption there is that you're using it in a read only fashion.  

If we decide to use a SAX based approach, we will have to redo much of the 
work that QDom does.  We will have to keep track of the parsed elements in 
such a way that they can be easily reconstructed.  In a heterogenous 
environment like keeedu, where a lot of apps will potentially be doing things 
to the data, this might be a bit tricky.  

> I think we should have at least two: an io and data related one and a second 
> for gui things. If no one objects I will set up the cvs environment for two 
> libs: libkdeedudata and libkdeedugui. This supports seperating data and 
> representation and also enables people to use the data access api without 
> kde 
> around (edudata should then be able use qt libs only).

Yep, I was thinking about that on the way over here (~25 minute train ride to 
work).  I could imagine a situation (though uncommon) where a command line 
utility might want to make use of the "data" lib.  I think rather than this 
being just data that all non gui classes should go there.  We will however 
need to link to kdecore and not just Qt for things like kdDebug() and i18n().

I would suggest, to follow the main KDE libs naming convention, that they be 
libkdeeducore and libkdeeduui.  And if we ever get things going with KParts 
that might merrit another lib, but we can make that decision when we get to 
it.

Also what do you think about the prefix KEdu for the classes?  I know these 
things may seem trivial at the moment, but a lot of the reason for putting a 
little code in CVS was to start some of these debates so that we can 
establish conventions before this thing starts to get big.

Something that was a bit arbitrary yesterday was calling these things 
KEduData[...].  Can/should we assume that this will be _the_ data format that 
we use or should we treat these specifically as "vocabulary" data?  I 
obviously chose the former, but if anyone thinks otherwise I'd like comments.

Now, moving on to what you have in your "successor" directory.  In kvtml are 
<o> and <t> identical in all of the attributes that they accept (and if so 
will this always be true)?  If so, I think it makes sense to make them our 
"items" and rename what I called KEduDataItem to KEduDataElement where there 
would be something like:

KEduDataElement foo;
KEduDataItem original = foo.original();
QString originalText = original.text();

If they are not the same I think keeping the "element" as our smallest item 
makes the most sense.  

Again, I know I coded this without really talking to others and I don't want 
to make that my policy for the future.  This was mostly a "I'll see what I 
can get done before I fall asleep at my keyboard" type of thing.  And as this 
discussion proves, it seems to have started some more concrete discussion of 
how the lib will be implemented.  Even if everything that I wrote yesterday 
eventually gets thrown out, that's a fine cost for getting this going!

Cheers!

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