On Wednesday 26 November 2008 00:09:32 Maciej Mrozowski wrote: > On Wednesday 26 of November 2008 03:35:25 Matt Rogers wrote: > > Hi > > > Thanks for your patch. Is there something wrong with our bundled libgadu > > that using an external libgadu fixes? (just curious). > > Nothing I would know about, features I tested worked with both versions. > Well, not necessarily, I couldn't verify public dir lookup feature as its > dialog window is not complete - looks like whole plug-in was translated > using qt3to4 and not everything has been fixed since then (it looks > incomplete in both protocol versions anyway - I guess I'll try to send some > patch for it, it may not be easy anyway as I've never written any serious > app in Qt4, but we'll see). > > The issue with libgadu is - the whole Gadu-Gadu protocol is proprietary, > and it has been reverse engineered by Wojtek Kamiński (an author of > libgadu) several years ago - it's continuously developer by some people > (maybe by Kamiński as well) as this library is widely used in other > Gadu-Gadu *nix clients (kadu,ekg and other). Protocol itself, as being > proprietary is being slightly modified sometimes (as protocol vendor cares > only about its own Windows client) and it's better to let someone else > follow the changes (library API is frozen but there were some changes few > years ago in public directory handling and I'm sure you have noticed). > > From svn logs I see you're using at least 2 years old libgadu and KDE team > was even patching it for themselves (some memory leaks fixed according to > svn log). Version I put in cmake as requirement is dated 2008.02 and should > be available in every distro. Of course the most important is to rely on > library upstream when comes to updates and bugfixes (there's some security > update - released 24.10.2008 as 1.8.2 - maybe it should be set in cmake > instead of 1.8.0 just in any case). > > Even if there's nearly everything done for this protocol in kopete - there > are still some things missing - and I guess I would help here more if this > darn Qt4/KDE4 programming weren't that hard to learn. It's ridiculous that > you need to be an expert to write simple click & go program. It's of course > thanks to lack of tools or poor quality of tools, so that being seasoned > C/C++/POSIX developer I can't write simple KDE program just right away and > 10 years ago I could do everything in C++ Builder while learning > programming language. Of course it's just an off-topic but I guess it's > valuable to rise as it's major show-stopper for Qt/KDE (hint - kdevelop > guys need more help - and qtdesigner should be integrated far beyond just > docking it there). > > I haven't managed to read all topics yet, so maybe my questions are > irrelevant: > - why kopete history (XML-one) doesn't store UTC timestamps (just some > localtime, hard to compare separated dates) - don't get me wrong but kopete > history format looks not-well thought or maybe I'm missing something > - are there any plans to migrate kopete backend to akonadi? (yeah, there's > fuss about akonadi everywhere but I guess it's worth to have everything > stored in one location - and it would obsolete any ideas for > sqlite/mysql/postgresql history backend - which have the big advantage of > easy history > migration/transfer/merging)
I committed your patch. Thanks! -- Matt
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
