moving KNotification in kdelibs.

[Aaron J. Seigo]

On Monday 14 November 2005 09:04, Olivier Goffart wrote:
> I have developed KNotiofy, a replacement for KNotifyClient

is there a rational for replacing KNotify that we could read somewhere?
is there some design reference somewhere that one could look at to understand 
how the client and the server work?

in the [Global] section of the config file, i see it has an icon name and 
(seemingly?) the name of the app (though it's in the Comment field). is this 
duplicated from the app's .desktop file, and if so would it make sense to 
just reference that .desktop file (though that would be even more overhead) 
or even just use the icon/app name for the application that it is running 
within? the latter would at least prevent kconfig usage for the simple case 

and speaking of overhead, what is the overhead of using an external config 
file in this fashion? in the class docu it mentions "This allows us to play 
sounds when a dialog appears.", and this should happen pretty much instantly 
otherwise the system feels slow and clunky.

what is the memory usage of an event?

looking at the code, it seems all the notification actually happens in the 
client. what is the purpose of the daemon in this case? (i haven't looked at 
that code at all, ergo the silly question ;)

it also seems that all the notification logic (which type of notification, 
etc) is contained in the static KNotification::event(...) method for the 
mapping between the Action type and the actual method calls and the methods 
that cause actual actions to be takens are all private ... this makes 
KNotification a fairly well-sealed black box. is there any use case where one 
might wish to use a KNotification object and call notifyBy* methods 
themselves? it just seems very non-extensible (though whether it needs to be 
is the big question i suppose =)

in knotificaton.cpp there is this:

//this is temporary code
class ConfigHelper
{

how temporary is this?

the class docu needs some proofing, e.g.:

 * \section file The global config file
 * On installation, there should be a file called
 *
 * <p>On installation, there should be a file called

some code examples would also be nice, as would some higher level 
documentation ("this is how you use knotification")

> 2) UnitTest
> I currently didn't made unit test yet,  but i don't really know what to
> test. The current KNotifyClient.

i'd test things like "ensure that given a defined set of contexts, the correct 
one is chosen", that various Action= entries get translated to the right 
bitmasks, "given an event ID, it selects all the correct information for that 
ID", etc.. essentially, test the code in the class =)

> 3) Location
> KNotifyClient is in kdecore for now,  but KNotification use QWidget, so it
> make sens to put it in kdeui

lots of clases in kdecore use QWidget.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051114/853388d4/attachment.sig>