Thursday 6 August 2015

GSoC 2015 Week #7-10 with Amarok

I haven't posted here for quite some time and a lot has happened over the last few weeks. Blame my habit of procrastination for not posting more frequently ;)

  • 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.

Now after all this, I was getting linking errors during the linking of amaroklib and hence I decided that it was high time to port the code in src/context but during the port of the code in src/context, I realized that it is going to take a LOT of time to complete. We may have to move to QML as Plasma 5 only supports QML for the widgets. So Mark suggested to leave it aside for the moment. To get around it, I tried to disable the compilation of src/context and the files that depend on the stuff in src/context. Well I should have guessed that it won't work (The effect was similar to the fall of dominoes; for each file that was disabled, I had to disable one or more file that depended on it) and later I had to comment out the code that was causing the linking errors. I have appropriately marked out each commented piece of code (with "FIXME: disabled temporarily for KF5 porting") so that it can be re-enabled later and we won't have to deal with obscure bugs due to their absence.

Apart from this, I had to remove the second argument of the KPluginInfo constructor ( KPluginInfo( const QString & filename, const char* resource = 0 ) has changed to KPluginInfo (const QString &filename) ). I am still unsure whether this change is correct or not.

Sadly, over the last week I messed up my system and I had to repeat quite a bit of the work but that didn't take much of my time. The port seems to be proceeding nicely and I am now reading about QNetworkAccessManager to replace QHttp that is no longer present in Qt5 API.

Cheers !!!

8 comments:

  1. Great work :) Any idea when the KF5-port will be usable?

    ReplyDelete
    Replies
    1. I fear that it will be quite some time before the KF5-port is usable. But let's hope that it is usable as soon as possible :)

      Delete
  2. Replies
    1. Yes yes, your comment has been posted. :)

      Delete
  3. Keep it up. Do share the link on your blog when you update the wiki.

    ReplyDelete
    Replies
    1. Thanks :)
      Expect a post next week around the firm 'pencils down' date.

      Delete