[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [kopete-devel] use external libgadu patch
From:       Matt Rogers <mattr () kde ! org>
Date:       2009-01-11 4:43:49
Message-ID: 200901102244.01151.mattr () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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" (application/pgp-signature)]

_______________________________________________
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel


[prev in list] [next in list] [prev in thread] [next in thread]