On Sunday 26 June 2016 21:26:39 4ernov wrote: > 2016-06-22 14:41 GMT+03:00 Pali Rohár <pali.ro...@gmail.com>: > > Hi! > > > > On Sunday 19 June 2016 19:02:30 4ernov wrote: > > > Hello, > > > > > > I continue to step by step porting plugins and protocols to KF5 > > > and have several suggestions on the process. I think, most of > > > things should be discussed with Pali, but anyone interested is > > > welcomed to this > > > > discussion. > > > > Great! > > > > > 1. I found quite useful to port plugins in separate branches. > > > This allows to separate changes belong to different plugins, > > > review the necessary changes for a concrete plugin and simply > > > concentrate better on the plugin under construction. So, the > > > question is whether this approach is desired, given that I'll > > > commit these branches to main repository (or maybe it should > > > have as few branches as possible). > > > > I have no problem with this. If other people will be able to find > > changes... > > Yes, thank you. So I've just uploaded three branches I already have, > for bonjour, jabber protocols and history plugin. I think, the idea > is to have them available for reviewing/looking through for now and > then merge, when all the rest is ready (e.g., when turning master to > KF5 version, but also may be earlier).
Ok. > > 2. If (1) is fine, Pali, may I ask to synchronize Jabber protocol > > branch as > > > > > soon as I create it (I'll post on this, again, if 1 would be > > > decided OK) > > > > to > > > > > get Jabber protocol compiled against KF5/Qt5? > > > > Ok, I will look at it. > > Yes, I've just pushed this branch for jabber protocol, it's called > "kf5-jabber-iris" and it actually contains all the necessary changes > to have Jabber protocol be compiled and used but the change in > libiris. So, Pali, could you please sync the clone of master branch > of > https://github.com/psi-im/iris with the necessary change included? Done, Kopete master branch now contains version from top commit iris master. > > 3. This approach is also make it handy to review the changes > > necessary for > > > > > certain plugin to be ported. In my opinion, this review won't > > > take much time, as typically most of changes are > > > kde-dev-scripts-guided or some > > > > usual > > > > > things. Unfortunately, I don't know, how to push a whole branch > > > to KDE reviewboard easily, but anyway, one could just look at > > > the branch > > > > changes. > > > > Reviewboard supports reviewing just one patch/diff/commit. So you > > can create either one bug patch or hundreds small. I would prefer > > to send that big one with link to smaller git commits or git > > branch. > > Yes, I'll think of it and yes, maybe one big patch per branch. > > > > Here's also my list of plugins and protocols yet to be ported: > > > - groupwise > > > > No idea if there is any user of groupwise protocol. I have also no > > idea if it is still working or not. > > Yes, I also didn't noticed it use, too. But what is the scenario for > this unsupported plugins? Can we just drop this code in the branch > (looks good for keeping the whole project smaller, I still not too > comfortable with it due to the amount of code, to be honest) or keep > it as-is (unported) or something else? We can disable that plugin (like IRC for whole KDE4 series) and if nobody complain we can drop it. Or wait if somebody is willing to port it and test if still is working... Kopete is already in git, so source code even after dropping will not be lost. > > > - qq > > > > IIRC current qq protocol is not working anymore, so do not spend > > time on it. > > Ok. > > > > - winpopup > > > > Depends on samba and smbclient and should still works (after > > correct installation). But do not know if it is useful today. > > > > It is implementation of Windows 2000 comamnd "net send" and is > > compatible (via Samba) with those Windows systems. > > I hope, I can test it with Windows machine, but yes, I see these > arguments. Testing is possible also with Linux machine... In any case samba server is needed. > > > - webpresence > > > - skype > > > > No idea if skype is still working... As it was designed for Skype > > 2.x versions. So I would suggest you to first check and then > > decide if porting or not. > > Well, as for Skype, I would prefer to drop it, since as far, as I > know (and have experienced) the original Skype itself doesn't work > properly on Linux, such as no support for conferences Conference calls were very funny part on Linux. Linux Skype client have not supported it (at times when I used it), but Skype API supported it! So via API you was able to create conference call also on Linux, but not via Skype GUI... In that time I was planning to add support for conference Skype calls in Kopete (as it was possible), but have not time for that... Same was with contact group support. On Windows Skype client you could move contact into some group. On Linux again not, but group management was exported via API. And this is implemented in Kopete, so groups between Skype contacts in Kopete and contacts in Windows client were in sync. > or some call > types. Since it appears to be a wrapper around, perhaps, it would > require even more efforts to debug... Skype protocol in Kopete uses DBUS API which Skype Linux client exports. So if old version of Skype client still works or if new version of Skype client still exports that DBUS API it should works. But I have no idea, have not started it for more years. So somebody needs to test what is Skype doing now... > > > - statistics > > > - history2 > > > > I would drop History2 from Kopete. So if it is not ported yet, > > maybe it make sense to not port it... > > Yes, I'll look at it, but I personally use Kopete history quite > intensively and an option to just look at XML log in any text editor > mean very much for me, and a dialog with chat log was also very > useful. As I've ported history plugin, I've got my log files > appending back, but no dialogs. What is the difference between > history and history2? Are all these additional history-aware dialogs > in history2? History2 is fork of history, but uses SQLite storage instead XML. History2 do not support rich (html) text message. So history2 is just replacement for history. > > Also history plugin and bonjour protocol is already ported, but I'd > > like to > > > > > see the decision on (1) to know, how to push the code properly. > > > > History plugin is nor now needed, we do not have any better > > replacement yet. > > Maybe, but I like it very much, and while it was quite easy to port > and now just works (branch "kf5-history"), maybe we can keep it... History plugin is needed, history2 not. -- 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
