- Jabber data processing needs a loop and/or an event handler (depending on architecture). Most graphical systems will also need one, this can cause problems. In this example, we used QT's idle processing feature, which called a single cycle of Gloox's message processing. A kgloox wrapper class was written for this.
- In case writing a client application (not a bot or likesome), we need to connect conversations to windows. Most users feel comfortable that they have one window for each contact (or at least, each resource). Because of incoming messages, we'll need a mapping of contact -> window, and also a window->contact mapping. Although the second one could be stored in the window class itself in some environments, the first one will definitely need some window manager object. Some would argue that it's just a matter of observer pattern, but I'd say that it's easier to implement this way, because of contact we haven't opened a window for yet.
- In most of the time, we need to subscribe to specific kind of messages, like messages of specific type (message/presence), of specific origin (given user), or specific namespace (feature query). It's a good idea to have some general handling pattern of such - like, observer pattern, signal-slot mechanisms, or packet catchers/interceptors. It's also a good idea to make it either hierarchical or precisely catcheable (like a PresenceProcessor class catches all <Presence/> stanzas coming from a JabberConnection class, then individual viewports could catch for a specific user, ie. when a window is open with a given contact, it's a good feature that you could see when the contact goes away.)
- It's good to have separate layers of application: not all the components would be responsible, for example, processing of Jabber XML streams, nor all the layers have a hardwired reference of UI.
You can download the KDE source here.
Requirements for build: