• Introduction
• contactlistLoaded
• contactDataChange (user_login)
• groupAdded (Group_ID)
• groupDeleted (Group_ID)
• groupRenamed (Group_ID, Group_Name)
• contactAdded (user_login, New_Group_ID)
• loggedOut ()
• myNickChange ()
• contactNickChange (user_login)
• contactBlocked (user_login)
• contactUnBlocked (user_login)
• contactMoved (user_login, Old_Group_ID?, New_Group_ID)
• contactRemoved (user_login, Group_ID)
• contactChangeState ( ...)
• contactPSMChange (user_login)
• messageReceived
• loggedIn
• groupAddFailed
• groupDeleteFailed
• groupRenameFailed
• contactDeleted
• contactDeleteFailed
• contactAddFailed
• contactBlocked
• contactBlockFailed
• contactCopiedTo
• contactCopyFailed
• contactMovedTo
• contactMoveFailed
• contactChangeState
• contactChangeNick
• contactChangePSM
• contactChangeMusic

Introduction

To seperate gui and protocol, and to abstract things it is necessary that the model(protocol) has no knowledge of the gui. But if this is so, how can the model notify the gui of things that happened? This is where events come in. When something happens (a contact comes online) the model handles everything, and it fires an event (contactChangeState for example). That is all it does, it never has to call a proc in the gui namespace. This way, it is fairly easy to change the whole gui without changing a single bit in the model.
Now the gui, who has registered itself to listen to certain events from certain sources, has in this case registered itself to listen to contactChangeState events from all sources. So when the event is fired, the contactChangeState proc of the gui will be called with the appropriate arguments. It can then use it to update the display.
The GUI on the other hand does have to know the model, but this is not a problem. There just has to be a good API, that we won't change too much.
Also, you can create another model (like lets say a jabber one, wich has the same api, so it can be used by the gui.

contactlistLoaded

This event is called when the initial contact list is loaded. It can happen that is finished downloading from the server or that it is loaded from the hard-disk.

contactDataChange (user_login)

When a visual data has changed. We should redraw the contact list.

groupAdded (Group_ID)

A group is succesfully added.

groupDeleted (Group_ID)

A group is successfully deleted

groupRenamed (Group_ID, Group_Name)

A group is successfuly renamed

contactAdded (user_login, New_Group_ID)

A contact is succesfully added.

loggedOut ()

We're successfully logged out.

myNickChange ()

Our nickname has changed

contactNickChange (user_login)

The nick of a contact has changed

contactBlocked (user_login)

A contact is blocked

contactUnBlocked (user_login)

A contact is unblocked

contactMoved (user_login, Old_Group_ID?, New_Group_ID)

A contact is moved from an Old_Group_ID? to New_Group)

contactRemoved (user_login, Group_ID)

A contact is removed from Group_ID

contactChangeState ( ...)

contactPSMChange (user_login)

messageReceived

loggedIn

Those following events are not yet coded:

groupAddFailed

A group failed to be added

groupDeleteFailed

A group failed to be deleted (eg group isnt empty)

groupRenameFailed

A group failde to be renamed

contactDeleted

A contact was successfully deleted

contactDeleteFailed

A contact failed to be deleted (eg it doesn't exist anyway)

contactAddFailed

A contact failed to be added (eg it's already in the group)

contactBlocked

A contact was successfully added to the BL

contactBlockFailed

A contact failed to be added to the BL (eg it doesn't exist)

contactCopiedTo

contactCopyFailed

contactMovedTo

contactMoveFailed

contactChangeState

contactChangeNick

contactChangePSM

contactChangeMusic