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

List:       kopete-devel
Subject:    Re: [kopete-devel] use external libgadu patch
From:       Maciej Mrozowski <reavertm () poczta ! fm>
Date:       2008-11-26 6:09:32
Message-ID: 200811260709.32312.reavertm () poczta ! fm
[Download RAW message or body]

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)

-- 
regards
MM

Dzwon tanio do wszystkich!
Sprawdz >> http://link.interia.pl/f1fa7

_______________________________________________
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]