2016-07-02 20:24 GMT+03:00 Pali Rohár <pali.ro...@gmail.com>: > > 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.
Thank you very much! Will cherry-pick it to Jabber plugin branch. > > > 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. Yes, I meant it, too — the code is there anyway, so if someone would like to continue some of the parts, some base for this would already be there. > > > > - 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... Unfortunately, don't have Skype on the development machine to test (don't have Pulseaudio and 32-bit libs installed, which it apparently requires), but I can just make it to 'get it compiled' stage, so again, anyone interested could debug and use it. > > > > - 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. Thank you for clarification on this, yes, I've read somewhere of this efforts, but apparently used only history plugin. > > > 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. Ok, now it's clear, I agree. Thank you! > -- > Pali Rohár > pali.ro...@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
