Approach for port to KF5

[Stefan Burnicki]

Hi all,

I would like to start the discussion about how we actually approach the
port to KF5.
There are two important points that should be clarified:


1. The usage of QML/QtQuick and C++.

For me, an application using QML/QtQuick and C++ is unknown territory.
The documentation at [1], [2], [3], and [4] turned out to be very
informative for me, I don't know how experienced you are. At the moment
I'm trying to get into it, but it will take some time, I guess. As far
as I can tell by now, many things, especially from the /app, could be
realized in both QtQuick and C++, especially everything that is based on
the Model/View/Delegate concept. Therefore we should carefully think
about what we want to implement in which language. And probably we
should also carefully redesign some classes, instead of "simply" port them.

Let's take for example one key element, the MediaItemModel/ -View/
-Delegate. I think it's pretty clear that The MediaItemView and
MediaItemDelegate will eventually be replaced by QtQuick, as they are
more or less only responsible for visual things and contain no advanced
logic (but currently much ugly code instead). The MediaItemModel,
however, could still be written in C++ or realized in new ways, as for
example with some kind of extension plugin, also take a look at [4].
Unfortunately, that's where my knowledge ends by now, as I need to learn
more things first. By all means we should communicate what we are
designing and how things are meant to work together. If you already have
some ideas about this, I'd be happy if you share them.


2. The development approach

As said, many things need to be rewritten or are getting replaced by
QML/QtQuick. In general, I think we should start off by porting the
build system, removing all components from it and then start from inside
out: Port main.cpp, then bangarangapplication.cpp, and so on. Once one
component is ported, it could be added to the build system again.

However, I'm a little in doubt if we miss the opportunity to "clean up"
with this approach. Maybe a good alternative approach could be to start
off with a new directory. Then we can start from scratch with a new
cmake project, before we port and move all components file by file,
extending the build system step by step. Doing it this way would end up
in a completely new project with all mess and unneeded components left
behind. Features we ignore for now, as the video related stuff, can rest
in the old directory and be ported when time has come.

Another issue I'm having in mind is the ability to test the ported
things. When it comes to porting the /platform, we won't have a GUI,
yet, so testing will be hard.  Porting the existing GUI for first tests
is a bad idea, I think, as it will restrict us in new and clean code
design and introduce old mess that I'm willing to avoid as much as possible.
Instead, we could start off with some unit tests, which is a good thing
in general, but this will result in some effort.
We will also need to be careful to only port stuff that we will really
need in the end, which could be a little tricky, as we might don't know
it at the point of porting.


Alright, these are my ideas for the port. What do you guys think?

Stefan
------
[1] http://qt-project.org/doc/qt-4.8/qdeclarativemodels.html
[2]
http://qt-project.org/doc/qt-5/qtqml-cppintegration-interactqmlfromcpp.html
[3]
http://qt-project.org/doc/qt-5/qtqml-cppintegration-exposecppattributes.html
[4] http://qt-project.org/doc/qt-5/qml-extending-tutorial-index.html