<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 25, 2014 at 3:35 PM, Giorgos Tsiapaliokas <span dir="ltr"><<a href="mailto:giorgos.tsiapaliokas@kde.org" target="_blank">giorgos.tsiapaliokas@kde.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
my name is Giorgos and I am contributing to KDE since 2011.<br>
Most of my contributions are on plasmate [1]. Most of my patches<br>
are based on plasmate and these days I am the main contributor of plasmate.<br>
Plasmate focuses on making it easier for people to create, test and publish<br>
plasma packages, like plasmoids and themes.<br>
<br>
<br>
Also this year I have been accepted in GSOC and my project is<br>
to port plasmate to KDevPlatform. Here [2] is a blog post explaining<br>
the reasoning behind the port of plasmate to KDevPlatform.<br>
<br>
Here is a small summary of my blog post.<br>
For me the goal of plasmate isn't to make plasmate the next big IDE,<br>
the goal is to give people the option of using the great tools that it<br>
provides. In the plasmate repository expect from plasmate we also provide most<br>
of its functionality as standalone applications. This desicion has been taken<br>
by the success that tools like plasmoidviewer and engine explorer had. Even in<br>
the new tools that we added we kept offering them as standalone applications.<br>
<br>
<br>
*But* until now plasmate wasn't using anything from KDevPlatform<br>
which led to a big maintainance burden. So we ended up at spending more<br>
time ¬†fixing stuff in plasmate rather than impoving the tools that it provides.<br>
Which for me isn't ideal.<br>
<br>
So which is the plan? As it regards plasmate, the plan is to make it focus on<br>
plasma packages only and to be as simple as possible, for instance plasmate<br>
shouldn't have a gdb debugger. As it regards the tools that<br>
plasmate(repository) offers the plan is to make them usable within from<br>
KDevelop because they will be plugins.<br>
<br>
What I would like to see is us(the people working on KDevelop and plasmate)<br>
working closer. How could the plasmate contributors help KDevelop more?<br>
What would you like to see from plasmate? In general how can we collaborate<br>
more? Do we all want to work together?<br>
<br>
<br>
[1] <a href="https://projects.kde.org/projects/extragear/sdk/plasmate" target="_blank">https://projects.kde.org/projects/extragear/sdk/plasmate</a><br>
[2] <a href="http://terietor.wordpress.com/2014/06/24/porting-plasmate-to-kdevplatform/" target="_blank">http://terietor.wordpress.com/2014/06/24/porting-plasmate-to-kdevplatform/</a><br>
<br>
thanks,<br>
Giorgos<br><span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Hi Giorgos,</div><div>First, thanks for the e-mail, it will be very interesting to see how this goes forward.</div>

<div>¬†</div></div>I think that a good exercise will be to know what API's from kdevplatform are you leveraging and which</div><div class="gmail_extra">interfaces you are planning to implement yourself. But for the moment, I think you should try to use</div>

<div class="gmail_extra">as much as possible from KDevelop and see what is that you don't like.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers!</div><div class="gmail_extra">Aleix</div><div class="gmail_extra">

<br></div></div>