Some more thoughts about refactorisation of Protocol and GaduProtocol classes. When I was extracting contact list export-import functionality from GaduProtocol, I've got an excellent idea about how-to-split the whole big class into smaller ones. It is very simple and widelly used in other projects (so why did't I thought about it before?).
We will have services: ContactListService, ChatService, FileTransferService, VoiceService and many others. Each of these will be an abstract class (call it an interface). Protocol class will implement methods like ChatService * chatService() - it will return 0 (no service implementation) by default. GaduProtocol for example will return GaduChatService object created in GaduProtocol's contructor.
Advantages? Smaller classes, possibility to query protocols for capabilities (if chatService() == 0 we cannot chat by this protocol, fileTransferService() == 0 - we cannot send/receive files).