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. -- Pali Rohár pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
