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 <aroona...@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 <aroona...@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 <aroona...@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 <aroona...@gmail.com> wrote: >>> >>>> >>>> On 8 June 2015 at 23:58, Myriam Schweingruber <myr...@kde.org> wrote: >>>> >>>>> Hi Aroonav, >>>>> >>>>> On Mon, Jun 8, 2015 at 7:59 PM, Aroonav Mishra <aroona...@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@kde.org >>>>> https://mail.kde.org/mailman/listinfo/amarok-devel >>>>> >>>> >>>> >>> >> >
_______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
