<div dir="ltr"><div><div>Hello,<br><br>This week I focused on the following changes:<br><br> * I added the KF5::TextEditor component.<br> * I removed setCodecForCStrings for setting UTF-8 encoding in QString. In Qt5 QString automatically calls the fromUtf8 instead of fromAscii function and as Mark pointed out we won't need to call setCodecForCStrings to set the UTF-8 encoding anymore.<br> * I have removed the calls to KDialog::makeStandardCaption as the application name is automatically added to the titlebar in desktop platforms <a href="https://mail.kde.org/pipermail/kde-frameworks-devel/2014-August/018143.html">now</a>.<br> * Add ViewPrivate class to the ContextView class and other functions, signals to restore its functionality to when it derived from Plasma::View. The functions in question are few and just as a reminder, the inheritance structure had been changed to derive it from QGraphicsView in a previous commit.<br> * CodeCompletionModelControllerInterface3 is now contained in CodeCompletionModelControllerInterface and so the inheritance structure of the AmarokScriptCodeCompletionModel class has been changed to reflect this. More details are <a href="http://api.kde.org/frameworks-api/frameworks5-apidocs/ktexteditor/html/kte_port_to_5.html">here</a>.<br> * KIO::upUrl is used to up the directory now instead of KUrl::upUrl().<br> * Also KTextEditor::SmartInterface is no longer present and <code>KTextEditor::Editor::instance()</code> is used instead of KTextEditor::EditorChooser::editor().<br> * I have removed the ScriptEditorDocument::clearHighlights() code in ScriptEditorDocument.cpp . I hope it's okay as I couldn't find an implementation of the pure virtual clearDocumentHighlights in the codebase.<br> * I have ported the threadweaver code for all of the remaining classes and added defaultBegin, defaultEnd functions to the classes that inherit from ThreadWeaver::Job. I repeated other changes made in previous week's commit(with ID:914b8cc) for the rest of the codebase and also added default parameters for the reimplemented run() function. In doing so the entire functionality of the QObjectDecorator class is present in these classes itself and we can link the signals of these classes to the slots like we did before.<br><br></div>Cheers<br></div>Aroonav<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 1 July 2015 at 17:15, Aroonav Mishra <span dir="ltr"><<a href="mailto:aroonav11@gmail.com" target="_blank">aroonav11@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">Hello<br><br>My work this week mainly revolved around the ThreadWeaver
API. As I had mentioned before KF5::TheadWeaver lacks detailed
documentation and the API has changed a LOT. So some of these changes
might be incorrect or incomplete as of now.<br><br>* The calls to
Weaver::instance() has been changed to Queue::instance() as this seems
to be the only function to access the global application's queue.<br>*
The pure virtual function ThreadWeaver::Job::run() prototype has changed
and hence new formal parameters have been added in the derived classes.<br>* ThreadWeaver::JobPointer is used in place of ThreadWeaver::Job*.<br>*
I have changed the inheritance of classes that previously inherited
from ThreadWeaver::Job to inherit from QObject too. I have additionally
defined the signals previously defined in Job in these classes itself.<br><br>These
signals have actually been moved into the class QObjectDecorator but I
am facing difficulties in thinking of ways on how to use it. The main
problem is that previously in kdelibs's
ThreadWeaver::Job, signals were automatically generated in it's
execute() function to indicate whether the job has started, done or
failed which is a very important functionality but as the signals are no
longer defined in Job, this functionality seems to be no longer in
ThreadWeaver::Job. Although it seems that this feature has been moved
into QObjectDecorator defaultBegin() and defaultEnd() but I am not sure
about it yet.<br>It will require some time to work out the details on
how to use the new API completely and solve the above problem and any
other problem(if any) that might arise.<br><br>I believe that it will be
better to experment with different approaches to solve the problems of
using ThreadWeaver properly once we reach the next stage of port where
we will be able to run the tests. I will continue to make the changes
indicated above and continue the port of the rest of the codebase unless
I get a solution which looks more promising than this. All help,
comments and ideas will be highly appreciated :)<br><br>Cheers,<br>Aroonav<br><br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 23 June 2015 at 16:22, Aroonav Mishra <span dir="ltr"><<a href="mailto:aroonav11@gmail.com" target="_blank">aroonav11@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>
<div dir="ltr" style="text-align:left">
Hello,<br>I would have sent this yesterday but I was in the middle of a commit which I wanted to include here. So sorry for the delay.<br>I had to take the third week off but it didn't affect my project much as I had started working before 25 May.<br>
Some of the changes that I have made over the last few days are as follows:<br>
<ul style="text-align:left"><li>I have added KF5::KCMUtils and KF5NewStuff components.</li><li>Most of the KDialog code has been moved to QDialog which included
changes like replacement of setButtons with QDialogButtonBox. Although
KDialog is deprecated and this conversion seems unnecessary at this
stage of porting, I encountered dependencies on classes in KF5 that now
inherits from QDialog instead of KDialog. Due to this some KDialog code
in Amarok had to be ported now rather than later. In my last commit (id 3102d83) I have removed some extra instances of QWidget which I had made in the previous commit (id 343a203<em></em>) and which don't seem necessary while I was porting away from setButtons in KDialog.<br></li><li>I made a few classes in Amarok to inherit from KPageDialog instead
of KDialog to let us use the buttonBox() function in the former which is
pretty useful.</li><li>I removed the definition of slotButtonClicked() slot in
deviceconfiguredialog.cpp as there were not any signals connecting to
it. The rest of the slotButtonClicked() calls were replaced with either
QDialog::accept() or QDialog::reject().</li><li>I discovered a function QDir::toNativeSeparators which is really
useful. On moving from KUrl to QUrl, I had to replace the calls to
KUrl::addPath(const QString& txt) with u.setPath(u.path() + '/' +
txt) [Copied straight from the docs ;)]. Now you can see that we have a
'/' in setPath which may or may not be the native separator of the
platform. So here the static function QDir::toNativeSeparators comes
into use and it will make the separators appropriate (if needed) for the
underlying operating system.<br></li><li>On moving from KIcon to QIcon, it is suggested in the docs that QIcon::fromTheme be used but when the parameter is a QPixMap object, the constructor of QIcon seems more appropriate.</li><li>I have removed an overloaded constructor in TrackLoader.cpp which is no longer required due to the current usage of QUrl.</li><li>Some of the minor changes include the fixing of the header files, correcting conversions between QUrl and QString, replacement of KUrl::AdjustPathOption with QUrl equivalents, <br></li></ul>
Please comment if any of the above changes made by me seem erroneous.<br><br>Cheers<span><font color="#888888"><br></font></span></div><span><font color="#888888"><div style="text-align:left">Aroonav<br></div><div dir="ltr" style="text-align:left">
<div>
</div>
</div>
</font></span></div>
<span></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 9 June 2015 at 00:22, Aroonav Mishra <span dir="ltr"><<a href="mailto:aroonav11@gmail.com" target="_blank">aroonav11@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"><br><div class="gmail_extra"><div class="gmail_quote"><span>On 8 June 2015 at 23:58, Myriam Schweingruber <span dir="ltr"><<a href="mailto:myriam@kde.org" target="_blank">myriam@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Aroonav,<br>
<span><br>
On Mon, Jun 8, 2015 at 7:59 PM, Aroonav Mishra <<a href="mailto:aroonav11@gmail.com" target="_blank">aroonav11@gmail.com</a>> wrote:<br>
> The second week of GSoC coding period has come to an end. I didn't want to<br>
> create another thread for my weekly updates hence I have emailed in this<br>
> thread itself.<br>
<br>
</span>That's OK, actually a good idea :)<br>
<span>><br>
> So this week some of the changes that I made are as follows:<br>
><br>
</span><span>> Though KDialog is in KDELibs4Support but the classes that previously<br>
> inherited from this have changed their base class. As the usage of<br>
> functions(ex setButtons of KDialog) from these inherited classes cause<br>
> errors now so I am currently porting away from KDialog. I have to review<br>
> (many)changes made by the porting script for which I have to understand<br>
> their API first. So I believe this is going to take some time.<br>
<br>
</span>By "away from KDialog" you mean porting to QDialog, right?<br></blockquote></span><div>Yes I meant that.<br>And I was referring to the class Amarok2ConfigDialog which inherits from KConfigDialog which inherits from KPageDialog. Previously KPageDialog inherited from KDialog but in KF5 now it inherits directly from QDialog and skips KDialog. So the usage of functions(like setButtons which were part of KDialog) which were used in Amarok2ConfigDialog now cause errors.<br><br></div><div>So for this I am porting from KDialog to QDialog completely.<br><br></div><div>I hope this clears up everything.<br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span>><br>
> I will be pushing the commits that concern the above changes soon.<br>
><br>
> Cheers!!<br>
><br>
> P.S Happy Birthday Mamarok!<br>
<br>
</span>Thank you :)<br>
<br>
And thanks for the update, very appreciated!<br></blockquote></span><div>You are welcome :) <br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards, Myriam<br>
<span><font color="#888888">--<br>
Proud member of the Amarok and KDE Community<br>
Protect your freedom and join the Fellowship of FSFE:<br>
<a href="http://www.fsfe.org" target="_blank">http://www.fsfe.org</a><br>
Please don't send me proprietary file formats,<br>
use ISO standard ODF instead (ISO/IEC 26300)<br>
_______________________________________________<br>
Amarok-devel mailing list<br>
<a href="mailto:Amarok-devel@kde.org" target="_blank">Amarok-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/amarok-devel" target="_blank">https://mail.kde.org/mailman/listinfo/amarok-devel</a><br>
</font></span></blockquote></span></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>