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

List:       kde-edu-devel
Subject:    Re: [kde-edu-devel] possible design math app
From:       Dominique Devriese <fritmebufstek () pandora ! be>
Date:       2002-08-11 12:50:17
[Download RAW message or body]

Eva Brucherseifer <eva@kde.org> writes:

> Hi,
> 
> your discussion about a common math app was quite interesting and I
> would like  
> to come up with a design proposal. I have some holiday soon and I'd
> also like  
> to put some coding work into it.

Hi, i'm currently working hard on kig, i have a borying summer job,
and have other stuff to do too, so i prolly won't be able to help
coding, but i do have some remarks about your design..
The general idea behind it seems to be very good, but
implementation-wise, i would do some things differently...

> 
> First of all: I am not for one large math app in one piece, but I am also 
> against masses of small apps. What I favour is a plugin design, where you 
> have shells which embed edu plugins. These plugins would have a common 
> interface and they should be easily reproducable so that a lot of excercises 
> can be implemented (I got my old algebra school book from my parents 
> yesterday, and there are a lot of exercises to implement ;-)
> 
> So how does my design look like? It is very much inspired by the 'KDE way to 
> do things' which are kparts-plugins  (if you are not familiar with kparts, 
> you should definitly have a look at the very good tutorials at 
> developer.kde.org. if you are german, I can also send you a german article 
> from iX magazine).

This is my major problem with your design.  KParts are not meant for
this kind of thing.  They are idd a plugin architecture, but for _one_
specific sort of plugins: kparts are for viewing and editing
documents.  Their design and implementation reflect this goal.  Many
people seem to have misunderstood this, as we also have KonsolePart,
which is being used in ways that KParts were not designed for.  It
causes many problems, and weird workarounds for problems like what to
do with KPart methods like openURL etc.

What we need here aren't KParts, but normal plugins.  I would propose
you look at some stuff in kdelibs/interfaces/kregexpeditor together
with kdeutils/kregexpeditor.  I'll try to explain briefly how it
works:
1 you define an abstract class containing the interface you want all
plugins to have.  This most of the time is rather easy, here's what i
think it should look like:

class KEduPlugin
{
        QWidget* widget();
        KActionCollection& actionCollection();
        const QString uiRcFile();
};

All plugins export ( using KGenericFactory and friends ) their own
subclass of this class, and install a Desktop file at an appropriate
place.  The shell finds plugins using KTrader, casts it to
KEduPlugin* and then uses it in some way..

That's about it.  If you want to see a real-life implementation of
this, look at the kregexpeditor sources in
kdelibs/interfaces/kregexpeditor

> Here is the design:
> 
> You have a shell, which implements educational concepts. 
> This can be:
> learning something, with imidiate feedback if an answer is correct or not.
> training: do the excercises as fast as possible
> feedback at the end of a set of excercises
> some flashcard approach, where excercises with incorrect answers come up 
> again
> exercises embedded in games
> statistics
> .... (whatever teachers come up with)

this would work the same way...

> 
> This shell embeds widgets which each implement an excercise, like
> timestables,  
> fractions, calculation of percentage, addition, substruction, etc. Each 
> widget is a plugin. Its capabilites are configured in desktop files,
> as they  
> exist for kparts:

or other things for that matter ( e.g. kregexpeditor ;)

> -----------------------------
> [Desktop Entry]
> Name=TimestablesEduPlugin
> Type=Service
> ServiceTypes=KEduParts/MathLearning,KEduParts/MathTraining
> X-KDE-Library=libktimestables
> Icon=ktimestables
> -----------------------------

this would stay entirely the same (except that i would change
KEduParts to KEduPlugins :)

> The large difference to kparts is here, that kparts are based on
> mimetypes and  
> that they always have an attached document. Kparts-plugins also exist, but 
> they don't have widgets. So we need something new here.

like an Interface together with KTrader stuff... ;)

> 
> So how does the shell know which edu-plugins there are to embed? For that 
> kparts has the KTrader. KTrader uses the sycoca-database which scans all 
> desktop files and builds a cache. You can use the KTrader class to ask for 
> plugins which fulfill certain capabilites. 
> But of course you can also have a shell which only embeds a special plugin 
> (that way you still have the setup you have at the moment with a lot
> of small  
> apps). You basically can use the same plugins in a lot of different
> ways.

stays the same too..

> 
> But we are not finished yet. What we also need (and we also don't have it in 
> kparts) is a communication between the shell and the plugin. The shell needs 
> to be notified about the result of an exercise and the shell needs to tell 
> the plugin to create a new excercise.
> I see 2 ways to do this:
> signals and slots
> 	the interface for the plugin contains predefined signals and
> slots for the 
> 	communication, so the shell can connect them after loading the plugin
> 	and both shell and plugin can use these connections.
> DCOP (desktop communication protocol)
> 	the desktop communication protocol lets you send messages which are not
> 	defined in the interface. Each member of the communication can get a list
> 	of available dcop commands. 
> The advantage of DCOP is, that you have reduced compile time dependencies. 
> Still signals and slots might be easier in the beginning, so am in favour of 
> that and if we need a more complex communication, we can still use DCOP 
> later.

This is the second thing i would like to react to:
1 DCOP is for _interprocess_communication_.  Communication between
different processes.  It is _totally_unsuitable_ here.
2 even signals/slots are unnecessary here.  You can just simply use
plain old function calls on the Interface object.
3 I don't really see what you mean with "reduced compile time
dependencies".  Anyway, the Interface stuff is good here too, since
plugins only need the Interface header file to compile, and the same
goes for the shell app.

> 
> In order to have several excercise widgets in one shell we might use a 
> QWidgetStack to hide the inactive excercises.

hm... didn't know that one, but it seems appropriate, indeed.  Or
perhaps we could use a KTabCtl, to show things in different tab
pages...  But i am very bad at ui design... :)
> 
> The great advantage I see in such a design is the following:
> plugins can be reused

idd

> educational concepts don't need to be implemented over and over
> again

hm.. could you give an example of that, cause i don't quite understand
what you mean, here...

> common look&feel

err.. no: only the shell is always the same, as your plugins have
their own QWidget's, they can look any way they want.  Btw. the
KEduPlugin presents a KActionCollection and a rc file, so that
the shell's ui is adaptable by the plugins in the same way that it
works for KParts...

> we can reuse the KDE knowledge of the kparts/ktrader implementation, maybe 
> we even don't need to reimplement it but extend existing code

I would personally not use kparts, since they serve another goal, the
Interface stuff, as you see it in e.g. kregexpeditor seems more
appropriate... 

> 
> So how would I proceed.... 
> first I'd take ktt (or any other little math app) into a kpart. 
> implement a new interface class for kedupart (which would go into a
> new lib:  
> libeduparts), inspired by the kparts code
> check with other KDE people if ktrader can be extended or reimplement 
> something similar

KTrader is not solely for KParts as it is now.  KTrader does not need
any additions..

> 
> How does that sound? Any comments/help/critizism is welcome!
> 

well, those were it :)
i hope you understand what i'm trying to explain, if not, please ask
me...

cheers
domi

-- 
I still miss Windows, but my aim is getting better.

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