GSoC 2015 Status Update

Aroonav Mishra aroonav11 at gmail.com
Wed Jul 8 13:46:26 UTC 2015 

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/20150708/3c7da538/attachment.html>

More information about the Amarok-devel mailing list