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

List:       kopete-devel
Subject:    Re: libiris update for kf5 branch
From:       4ernov <4ernov () gmail ! com>
Date:       2016-03-30 16:22:02
Message-ID: CAL8gro3mq2_z-SDNbka7y7QpqxARZYdRt-Z0r+q=L3q7jKNS5w () mail ! gmail ! com
[Download RAW message or body]

2016-03-30 19:14 GMT+03:00 Pali Rohár <pali.rohar@gmail.com>:
> On Wednesday 30 March 2016 17:47:58 4ernov wrote:
>> > > Apart from that, how do you think, is it worth trying to still
>> > > detach the library as an external dependency or we're better off
>> > > sticking with current internal one? That's just in order to take
>> > > a moment and make most major changes during this transfer now
>> > > and not soon after the port is stabilized.
>> >
>> > Reason why kopete repository contains copy of libiris is historic.
>> > First is that kopete had own patches to libiris (now all are
>> > upstreamed) and second because libiris upstream project itself
>> > does not have stable API/ABI and does not provide system/shared
>> > library. So projects copy its own copy (either via git submodule
>> > or as kopete, full subtree copy).
>> >
>> > So if we need some modification to libiris, we can do that in
>> > kopete tree, no problem... But I would like to have master branch
>> > synced. In working branches, feel free what you need/want.
>>
>> Thank you so much for detailed clarification, Pali! Yes, I see the
>> reasons for that now. I also checked out vanilla libiris from its
>> repository and it also failed to compile against Qt5 out of the box.
>> So, the one way is to fix it, send changes upstream and then check
>> out the updated version to internal copy.
>>
>> But I also would like to come up with an idea that crossed my mind
>> yesterday after I failed to compile libiris. Would it be bad or
>> undesired to switch to another backend for Jabber connectivity?
>> Please don't consider it as "I'm here, let's now change everything"
>> newcomer's suggestion, just want to discuss all the approaches
>> before using one. I've looked at Qxmpp project
>> (https://github.com/qxmpp-project/qxmpp). At first glance, it's being
>> actively developed, supports a bunch of features, even has Jingle
>> support, contains documentation, is included into distros and already
>> Qt5-friendly, compiled for me with no issues. The key important
>> feature is that we could just use it as external dependency and don't
>> care too much about supporting its tree internally. If you wouldn't
>> be against this idea, I could play with this change in separate
>> branch and return with some results on that. But anyway, I think,
>> after all the remaining parts are ported to not postpone or delay
>> this.
>
> Because libiris is used by other projects I would think that Qt5 support
> will be there... It would be better to discuss about those compile
> errors with libiris people...
>
> But if you think that another xmpp library better fit for Kopete, feel
> free to do experiments and show test results. Some comparison of
> features of both libraries can be useful too...
>
> Replacing libiris for another library would take lot of time which I do
> not have. And because libiris is working I did not have any reason to
> replace it.

OK, I'll experiment with trying to get libiris work with Qt5 (at least
with Kopete internal configuration) and will play with trying the
alternative in a side activity. Though Jabber is key functionality at
least for me, I think I'll port the remaining protocols first, at
least to 'get it compiled' state, as there seem to be less problems.

Pali, thanks for your suggestions and guidance.

> --
> Pali Rohár
> pali.rohar@gmail.com
>
> _______________________________________________
> kopete-devel mailing list
> kopete-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kopete-devel
>
_______________________________________________
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]