(typical Dave sized email below. Sorry)
- Libkpeople is getting a rewrite that won't have any of the current problems. Summary is: - Instead of storing all data in Nepomuk, we store a simple mapping and sources provide data at runtime - PIM seem happy with this. Right now this is 90% feature compatiable with libkpeople0.1, Martin and I have ported all the KTp stuff. Branch name is kpeople2 everywhere. I don't want this to be a thing that Martin and Dave work on independant of the rest of the project and I would like more of you involved. - Call UI detrout is working on QtGstreamer1.0. This is amazing work, I'd like everyone who wants to see an open KDE video service to help step up to work on that. - Encryption. We want to support this so we can become the default IM client in KDE SC from 5.0. The best approach I think will be to use libOTR4. In Kopete this is a plugin, whilst we have a plugin system in KTp, ours has to be flexible enough to support the plasmoid and active - which can't do the low level widget interaction needed for OTR. The Kopete code is basically: - some KActions in the chat kpart (see below!) - A singleton - some dialogs - message handling. The message handling can fit quite well into our plugin system, the rest not so much. I think we may have to compile it linked in to the main chat-widget code, but I don't want to see spaghetti code spread over everywhere. - KParts TextUI There is some ongoing work to move the text-ui to use KParts. It means we can embed chat in other apps, we can make that library private, as well as simplify the code a lot as each tab can keep track of it's own actions. I /think/ this is close to merging, but has a crash without a patched kdelibs.. it would be good if we can avoid that. - QML Text UI Please see here: http://community.kde.org/KTp/Tasks/TextUIQML The auto-scroll in the chat plasmoid (and therefore this) is the biggest blocker. Also please read my review and approve it.. :) - Singleton AccountManager/Factories This A big API change, which will tidy everything up. I always used to say we can't use a singleton AM because: 1) we don't want to fetch data for all contacts for all services 2) we don't want the same features for all channelFactories doing so would result in /massive/ dbus overhead [1] is fixed in GlobalContactManager which upgrades connections [2] we can fix by using different channel factories in the different client registrars. If none of that means anything to you; just ignore this sentence. :) --- Timelines I am currently thinking of merging kpeople2 code now-ish, entering a beta freeze, and releasing 0.8 soon after (i.e mid December). I know that doesn't leave a lot of time for other new features, but I think it's worth fixing this metacontact stuff ASAP. We can always release 0.9 soon after. I want your input on this; I don't want to dictate the project. David _______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
