Approach for port to KF5

Sat Nov 1 01:50:50 UTC 2014

I'm on board with the new directory/branch approach. Although I don't have much experience with QML, I prefer the idea of exporting MediaItemModel (and any other needed models)  as a extension, it would allow a more dynamic approach to be taken in the UI designs.
In terms of porting classes, it makes better sense to start from the lowest level of the architecture (i.e the listengine hierarchy) before porting other classes. This would allow us to see how much of the above architecture needs serious redesign or rewriting.  Logically, next would be MediaItemModel and any other models, followed by the playlist class; the infofetchers, search infrastructure and storage are details that cannot be tackled until a minimal port is in place.

------------------ Original ------------------
From:  "Andrew Lake";<jamboarder at gmail.com>;
Send time: Saturday, Nov 1, 2014 0:57 AM
To: "Stefan Burnicki"<stefan.burnicki at burnicki.net>; "bangarang"<bangarang at kde.org>; 

Subject:  Re: Approach for port to KF5

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/20141101/bc983689/attachment-0001.html>