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

List:       kopete-devel
Subject:    [Kopete-devel] Re: kdenonbeta/kopete/kopete/contactlist
From:       Richard Smith <kde () metafoo ! co ! uk>
Date:       2003-04-14 12:00:22
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 14 April 2003 8:35 am, Olivier Goffart wrote:
> >> If Oliver G is in "Friends" group
> >> and also in "Kopete" group, and i have notifications on for both these
> >> groups (as it stands notifications are on for all groups), then a
> >> notification should not fire twice just because he is in both groups. He
> >> is only one person, he is only coming online once. A notification should
> >> only fire once per person.
>
> yes that's true

how does your proposal below solve this problem?

> > Agreed. It makes much more sense to me to have a list of rules for
> > sending a per-KMC notification, and one should be sent for the first rule
> > that matches the contact. This doesn't even have to be a complicated
> > UI... see the message filter rules in MS Outlook Express for an example
> > of a very usable way of doing this.
>
> mh no no too complicated.

Too complicated for the Kopete binary, certainly. But I think maybe not too 
complicated for a plugin.

> my opinions is:  you can set params for metacontact or for groups.
> kopete look first at the metacontact. if a spetial param is found i take
> it. if not, it look at the group.

But which group does it look at? We can't even take the 'most significant' 
notification, because we can't judge whether a user is more likely to notice 
a passive popup or a sound file, or which of two sound files is more 
significant.

If we really want to go this way, it seems to me that the only logical way of 
doing it would be to just have notification params per metacontact, and a 
group command called 'set notification for all group members' or something. 
But that seems overly complicated.

> >> Also, for the other point.... Notifications are not part of the UI..
> >> this is why theyre in kdecore and not kdeui. It is not the
> >> KopeteMetaContactLVI that is coming online, it is the KopeteMetaContact
> >> itself. The way this is set up now a metacontact without an LVI can have
> >> no notifications, and these contacts do exist. This is aside from the
> >> point that its wrong OO design to have the notifications for the MC in
> >> the LVI when it is the MC itself causing the event, not the LVI.
>
> wrong!
> I already planed to make a notification on the list (i.e. a blinking icon)
> when a contact change his status.
> this notification is a LVI one.
> that make sense for me to regroup all notifications.

The LVI should certainly know about notifications (as you point out, it needs 
to), but it doesn't follow that it should have anything to do with 
KNotify-style notifications (though I'm not sure if that's what you're 
suggesting).

> > IMO the metacontact itself should not deal with the notifications; I
> > consider that fairly bad OO design too. The KMC ought to already notify
> > other code of these events via signals; it makes more sense to me to
> > create a notification handler object which deals with notifications in
> > whatever way is desired.
>
> i think i like this idea... but!
> isn't KNotifyClient already this object?

No... my notification handler object would be the code that has knowledge 
about how to convert a MetaContact, Event pair into a notification. My 
proposal would be a singleton object which talks to KNotifyClient.

Deciding which notification to give doesn't need to be done from within the 
metacontact, and in fact when you think about what a metacontact *is*, it 
doesn't make a great deal of sense to do it there.

> > It could use KCL::metaContactAdded,
> > and in fact could go in a plugin.
>
> I don't think notifications is a plugin (not for now)
>
> > But like many other features, it might be better to
> > have a simple form of notification in the kopete core.
>
> what do you mean? i don't understand this last sentence.

What I mean is, my proposal is too complicated to be part of the kopete 
binary, and I think that there should be some very simple notification in the 
binary (ie notification for specific events, independent of the metacontact), 
with the advanced functionality I've suggested in a plugin.

Richard
-- 
My old signature
Was dull and is now replaced
By this, a haiku
[Attachment #5 (application/pgp-signature)]

_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel


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