<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 28, 2014 at 10:18 AM, Martin Klapetek <span dir="ltr"><<a href="mailto:martin.klapetek@gmail.com" target="_blank">martin.klapetek@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Tue, Oct 28, 2014 at 12:50 AM, Aleix Pol <span dir="ltr"><<a href="mailto:aleixpol@kde.org" target="_blank">aleixpol@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div>I think we are all eager to see KTp working awesomely working on our Plasma 5 systems. I've started to push some of the ports in my BlueSystems time then I saw some of you were starting to push in that direction, so I decided to come up with a little kanboard so that we can make sure everything happens properly. [1]</div><div><br></div><div>I recommend some of you to decide to take some of the modules to port. We should decide what we take for a good port, you'll see I added 2 subtasks to any task:</div><div>- Builds with Qt5: that means that it can be built and somewhat used on the Qt5 version. I recommend to make naïve ports in the first run, so that things doesn't break. By naïve I mean using KDELibs4Support, then we can go stripping those down little by little. Maybe even as GCI tasks.</div><div>- Qt5 in master: there we should decide when we're going to do the move and if we want any kind of quality standard to follow, such as dropping KDELibs4Support or similar. From my experience, things seem to work quite smoothly anyway (I've been using the ported KTp chat plasmoid since around May without much trouble).</div><div><br></div><div>Also some release release under the KDE Frameworks umbrella would be very interesting soon, I'd like to hear from the maintainers about that.</div></div></blockquote><div><br></div></div></div><div>Let's aim for as much kdelibs4support-free ports as possible for any release/merge in master. It's not that hard and we don't have that much code that would use it extensively (auth-handler and accounts-kcm's internal libs are all fully ported already).</div></div><div><br></div></div></div></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">In general I agree, it's slow work though, especially considering that KIcon is massively over-used in ktp codebase. Anyway, if somebody wants to spend some nice time helping KTp, it's a very good way to do so. :D</div><div class="gmail_extra"><br></div><div class="gmail_extra">Aleix</div></div>