GSoC 2015 Status Update

Aroonav Mishra aroonav11 at gmail.com
Fri Jul 17 09:46:37 UTC 2015 

Hello,

I have mainly focussed this week on introducing changes that I have
mentioned in my previous reports & commits to the rest of the files. Apart
from this, I have done the following:

* Ported from KAction to QAction, KMenu to QMenu with the help of the
porting scripts.
* Added KF5::GlobalAccel, KF5::KIO components, Qt5::Sql, Qt5::Quick,
Qt5::ScriptTools, KF5::PlasmaQuick, KF5::NotifyConfig and KF5::Archive
components.
* KGlobal::mainComponent().aboutData() is replaced with
KAboutData::applicationData() which contains information such as authors,
license, etc.
* KGlobalAccel::setGlobalShortcut is used instead of setGlobalShortcut to
set global shortcuts.
* QApplication::type() no longer exists and hence the macro
QApplication::qApp is used by casting in src/PluginManager.cpp and
other files.
* In TrayIcon.cpp a QMap has been created mapping each QString to its
corresponding QAction which is done in KActionCollection and hence the
calls to actionCollection()->action is replaced by calls to a function
defined in the class itself.
* KGlobalSettings::CompletionPopup is replaced with
KCompletion::CompletionPopup.

I had mentioned before that I will porting the code in the src/context
later. I will be doing this now and I believe that this should take some
time.

Cheers
Aroonav


On 8 July 2015 at 19:16, Aroonav Mishra <aroonav11 at gmail.com> wrote:

> Hello,
>
> This week I focused on the following changes:
>
>     * I added the KF5::TextEditor component.
>     * 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.
>     * I have removed the calls to KDialog::makeStandardCaption as the
> application name is automatically added to the titlebar in desktop
> platforms now
> <https://mail.kde.org/pipermail/kde-frameworks-devel/2014-August/018143.html>
> .
>     * 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.
>     * CodeCompletionModelControllerInterface3 is now contained in
> CodeCompletionModelControllerInterface and so the inheritance structure of
> the AmarokScriptCodeCompletionModel class has been changed to reflect this.
> More details are here
> <http://api.kde.org/frameworks-api/frameworks5-apidocs/ktexteditor/html/kte_port_to_5.html>
> .
>     * KIO::upUrl is used to up the directory now instead of KUrl::upUrl().
>     * Also KTextEditor::SmartInterface is no longer present and
> KTextEditor::Editor::instance() is used instead of
> KTextEditor::EditorChooser::editor().
>     * 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.
>     * 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.
>
> Cheers
> Aroonav
>
> On 1 July 2015 at 17:15, Aroonav Mishra <aroonav11 at gmail.com> wrote:
>
>> Hello
>>
>> 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.
>>
>> * 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.
>> * The pure virtual function ThreadWeaver::Job::run() prototype has
>> changed and hence new formal parameters have been added in the derived
>> classes.
>> * ThreadWeaver::JobPointer is used in place of ThreadWeaver::Job*.
>> * 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.
>>
>> 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.
>> 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.
>>
>> 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 :)
>>
>> Cheers,
>> Aroonav
>>
>>
>> On 23 June 2015 at 16:22, Aroonav Mishra <aroonav11 at gmail.com> wrote:
>>
>>>  Hello,
>>> 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.
>>> I had to take the third week off but it didn't affect my project much as
>>> I had started working before 25 May.
>>> Some of the changes that I have made over the last few days are as
>>> follows:
>>>
>>>    - I have added KF5::KCMUtils and KF5NewStuff components.
>>>    - 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) and which don't seem necessary while I
>>>    was porting away from setButtons in KDialog.
>>>    - 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.
>>>    - 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().
>>>    - 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.
>>>    - 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.
>>>    - I have removed an overloaded constructor in TrackLoader.cpp which
>>>    is no longer required due to the current usage of QUrl.
>>>    - 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,
>>>
>>> Please comment if any of the above changes made by me seem erroneous.
>>>
>>> Cheers
>>> Aroonav
>>>
>>> On 9 June 2015 at 00:22, Aroonav Mishra <aroonav11 at gmail.com> wrote:
>>>
>>>>
>>>> On 8 June 2015 at 23:58, Myriam Schweingruber <myriam at kde.org> wrote:
>>>>
>>>>> Hi Aroonav,
>>>>>
>>>>> On Mon, Jun 8, 2015 at 7:59 PM, Aroonav Mishra <aroonav11 at gmail.com>
>>>>> wrote:
>>>>> > The second week of GSoC coding period has come to an end. I didn't
>>>>> want to
>>>>> > create another thread for my weekly updates hence I have emailed in
>>>>> this
>>>>> > thread itself.
>>>>>
>>>>> That's OK, actually a good idea :)
>>>>> >
>>>>> > So this week some of the changes that I made are as follows:
>>>>> >
>>>>> > Though KDialog is in KDELibs4Support but the classes that previously
>>>>> > inherited from this have changed their base class. As the usage of
>>>>> > functions(ex setButtons of KDialog) from these inherited classes
>>>>> cause
>>>>> > errors now so I am currently porting away from KDialog. I have to
>>>>> review
>>>>> > (many)changes made by the porting script for which I have to
>>>>> understand
>>>>> > their API first. So I believe this is going to take some time.
>>>>>
>>>>> By "away from KDialog" you mean porting to QDialog, right?
>>>>>
>>>> Yes I meant that.
>>>> 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.
>>>>
>>>> So for this I am porting from KDialog to QDialog completely.
>>>>
>>>> I hope this clears up everything.
>>>>
>>>>> >
>>>>> > I will be pushing the commits that concern the above changes soon.
>>>>> >
>>>>> > Cheers!!
>>>>> >
>>>>> > P.S Happy Birthday Mamarok!
>>>>>
>>>>> Thank you :)
>>>>>
>>>>> And thanks for the update, very appreciated!
>>>>>
>>>> You are welcome :)
>>>>
>>>>>
>>>>> Regards, Myriam
>>>>> --
>>>>> Proud member of the Amarok and KDE Community
>>>>> Protect your freedom and join the Fellowship of FSFE:
>>>>> http://www.fsfe.org
>>>>> Please don't send me proprietary file formats,
>>>>> use ISO standard ODF instead (ISO/IEC 26300)
>>>>> _______________________________________________
>>>>> Amarok-devel mailing list
>>>>> Amarok-devel at kde.org
>>>>> https://mail.kde.org/mailman/listinfo/amarok-devel
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20150717/0fbd531c/attachment.html>

More information about the Amarok-devel mailing list