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

List:       kde-edu-devel
Subject:    Re: [kde-edu-devel] math app - design version 0.1
From:       Dominique Devriese <fritmebufstek () pandora ! be>
Date:       2002-08-19 21:50:15
[Download RAW message or body]

Eva Brucherseifer <eva@kde.org> writes:

> Hi all,
> 
> after spending the weekend in front of my laptop, here are the
> results. You  
> can download the code (early design state!) from 
> http://www.rtr.tu-darmstadt.de/~eva/download/kmath-0.1.tar.gz
> I used kbruch as an example. 

Hi, i've only just found the time to look at your code, and i must say
i'm impressed...  Seems to be rather usable already..
Here are some comments ( and a small patch i made to get it to
compile, and to fix a crash when you forget to put the plugin in a
KTrader search path...)
first the patch ( i edited it, to get rid of differences in
Makefile.in's and such, so i don't know if patch(1) wil still accept
it.. )

diff -ur kmath-0.1/keduparts/Makefile.am kmath-0.1.nw/keduparts/Makefile.am
--- kmath-0.1/keduparts/Makefile.am	Sun Aug 18 21:09:04 2002
+++ kmath-0.1.nw/keduparts/Makefile.am	Mon Aug 19 22:51:00 2002
@@ -1,7 +1,7 @@
 ####### General stuff
 
 INCLUDES= -I$(srcdir)/../   $(all_includes)
-libkeduparts_la_LDFLAGS = $(KDE_MT_LDFLAGS) -version-info 3:0:1 -no-undefined
+# you need $(all_libraries here or else it will not link on systems
+# where kdelibs are not installed in /usr/lib (like mine ;)
+libkeduparts_la_LDFLAGS = $(KDE_MT_LDFLAGS) -version-info 3:0:1 -no-undefined $(all_libraries)
 libkeduparts_la_LIBADD  = $(LIB_KIO) $(LIB_KPARTS)
 
 check-local:

diff -ur kmath-0.1/kmath/kmath/kmath.cpp kmath-0.1.nw/kmath/kmath/kmath.cpp
--- kmath-0.1/kmath/kmath/kmath.cpp	Sun Aug 18 21:09:04 2002
+++ kmath-0.1.nw/kmath/kmath/kmath.cpp	Mon Aug 19 23:01:57 2002
@@ -152,6 +152,7 @@
         // itself can't do anything useful
         KMessageBox::error(this, "Could not find our Part!");
         kapp->quit();
+       // kapp->quit() means "quit on the next time we come in the
+       // event loop.." without this return you end up executing the
+       // rest of this function any way, which leads to a crash...
+	return;
     }

> 
> Right now working is:
> a lib with the interface of edu parts
> the part (kbruch, I did change the design of kbruch only where I had to)
> the communication between the part and the shell
> the shell has some small functionality (statistics class is taken from 
> kbruch)
> 

looked at this only briefly... could you document the EduPart
interface a bit, cause i don't really get what some of the functions
are for... :( 

> Missing (or only very quick&dirty implemented) is:
> configuration of the part (and thus the exercises)
> configuration of test suites
> correct loading and management of different parts (at the moment
> kbruch is hard coded)
> command line option to load a specific part (that can be used to create
> desktop files for each part, so that it can be used as standalone
> app)
> 
> The source has the following directories:
> keduparts - interface of the edupart
> kmath - shell
> plugins - place of the parts (rename to "parts"?)
> plugins/kbruch - kbruch edu part
> 
> Last weekend we had a diskussion about the class, the edupart
> interface should  
> inherit from. After reading kparts code and the documentation, I
> think, I can  
> say, that we definitly have parts in our application and no plugins. Plugins 
> originally don't have widgets, parts do have. Parts also don't need
> to handle  
> files, this only applies to the two specialisations of Kparts::Part
> which are  
> Kparts::KReadOnlyPart and KParts::KReadWritePart.
> So far it's not yet clear in my code, but I think, I'll rename all
> "plugins"
> into "parts".

/me agrees completely
btw, i was kidding when i said that about the names "plugin"
vs. "part" ;)

> 
> Still, I got the idea, that we indeed might want to deal with files
> along with  
> the edu parts. Right now, most math apps create random exercises (or
> is task
> the better word?), which the user has to do. The user has no chance,
> to save  
> a set of exercises and repeat it later. The user also cannot save
> test  
> parameters like, the number of tasks, the level of difficulty, the
> special
> type. 
> Now imagine, we want to enable this... here comes the
> KParts::ReadWritePart  
> in. All edu apps would work on the same mimetype (.edu?) and these
> files  
> describe tests consisting of a number of tasks, which are maybe
> implemented 
> in several edu part libraries. 

How about we have the kmath app itself take care of the edu files (
mimetype application/x-kdeedu and extension .kdeedu seem best to
me ... ) which have some xml format, containing information on what
part to open it with, and information specific to the part in
question...
Having all eduparts be responsible for the same mimetype would be
difficult, since you would have no way of knowing what edupart should
take care of a given file... ( unless i'm missing something here... )

> 
> So far for today... time to enjoy the rest of the weekend without a
> computer  
> :-)
> 
> Greetings,
> eva

cheers
domi
-- 
What's good for Standard Oil is good for Microsoft.
_______________________________________________
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]