GSoC 2015 Status Update

Wed Jul 1 11:45:25 UTC 2015

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/20150701/9272590c/attachment.html>