Approach for port to KF5

[Andrew Lake]

Here's my thought. I think we go with the start-off-clean approach you
suggest Stefan - with a new directory/branch and new cmake project. That
way we don't have to deal trying to understand legacy code and re-use only
what makes sense.

Start with the platform stuff and write unit tests as we go. Stefan would
you be willing to take the KF5 branch and set it up to start clean like you
described? After this start-clean set up is ready we can start tackling
which classes to begin working on. If anyone has suggestions on which
classes they would like to tackle first, speak up. MediaItemModel is
probably near the top of the list.

Eshton, do you have ideas here?

Regarding the UI layer, yes all of the old views and delegates will be
replaced with QtQuick/QML, so don't waste any time trying to port those.
I'll create a separate directory for the UI stuff, copy over Mathieu's
initial QML code and work with Mathieu and develop that in parallel. Don't
worry about GUI testing for now. As the UI design settles down we'll start
looking for how to connect to the various models implemented in the
platform layer. Then we can start worrying about UI tests.
The various *managers in /app will likely still be C++, but none of them
need be a priority right now. In fact, we can completely rewrite those if
it makes sense.

How does that sound?

Andrew


On Fri Oct 31 2014 at 5:58:03 AM Stefan Burnicki <
stefan.burnicki at burnicki.net> wrote:

> 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
>
> _______________________________________________
> Bangarang mailing list
> Bangarang at kde.org
> https://mail.kde.org/mailman/listinfo/bangarang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/bangarang/attachments/20141031/e0cbfe9d/attachment.html>