moving KNotification in kdelibs.

[Olivier Goffart]

Hi Aaron,
thanks for your remarks. 

Le Mardi 15 Novembre 2005 00:46, Aaron J. Seigo a écrit :
> 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?


not yet
I more see that as an evolution rather than a strict replacement.

> 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

This part comes from the old KNotifyClient.
But this is true it's duplicated with desktop file, and should be merged.

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

It has to be in a config file, because the user may configure it.

> what is the memory usage of an event?

Few small strings.  and the life time of an event should be small.

> 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 ;)

The deamon is just used to display the popup.
i've tried to implement this specs, which is already used in some gtk 
application:  http://www.galago-project.org/specs/notification

> 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 =)

Yes,  i plan to be able to do user event,  and use dirrectly notifyBy*
But it's private for now, because the API is not fixed yet.

> in knotificaton.cpp there is this:
>
> //this is temporary code
> class ConfigHelper
> {
>
> how temporary is this?

Good question.  
Should be cleaned before the release.
This is implementation details anyway.

> 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

oops

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

yes

>
> > 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 =)

ok