This used to keep an internal Tp::Message and delegated all it's getters to that. But that means it can't be constructed without one, and thus can't be used with the LogManager. So, it needs to ditch the Tp::Message and store the relevant properties itself. And be able to be constructed from an AdiumThemeContentInto.
>And be able to be constructed from an AdiumThemeContentInto. Don't do this. AdiumThemeContentInfo needs to be constructed from a KTp::Message. Not the other way round.
(In reply to comment #1) > >And be able to be constructed from an AdiumThemeContentInto. > > Don't do this. AdiumThemeContentInfo needs to be constructed from a > KTp::Message. Not the other way round. Uh oh, the reason I did this is because LogManger only gave AdiumThemeContentInfos. I needed to be able to create a Message from it so I can process it. Or did you mean a long term change to make LogManager create/return Message's instead?
Or did you mean a long term change to make LogManager create/return Message's instead? Yeah, that sounds a lot cleaner.
So, this actually amounts to restructuring Message so that within ktpchatlib, it can be used instead of a Tpl::Message, Tp::Message, Tp::RecievedMessage, AdiumThemeContentInfo, and whatever class MessagesModel uses. Right? I had a go at doing this and realized there's a lot of big and important decisions to be made, so I'm putting this on the backburner till Tuesday (our next mentor meeting). PS: The release plan for 0.4 has changed so much that I don't know what the dates are now. But if BUG 298731 needs to be fixed urgently, I can do a temporary hack for now.
Fixed by me. (my commit->bugzilla integration is broke) http://quickgit.kde.org/index.php?p=ktp-text-ui.git&a=commit&h=f60356c98ee44f820711c8161844ae24933e8619