Cool! How did you find the experience? Was it difficult creating a backend that could be used by both? Any tips for others trying to do the same?

Actually, I found it very simple :) That’s way I did it, to make people aware of the fact that supporting both widget and quick is not that hard.

The most important thing to think of is to try, as hard as possible, to not scatter the business logic all over the code. Keep all logic in the domain. Also don’t poison the view with domain objects, in my case for example the Station object. This makes it hard to do changes on the model because the view has a strong dependency to the model.

During the development I changed the domain several times but I didn’t have to change the view, I only changed the controller-part but my GUI code could remain untouched, which was really neat.

When it comes to the Quick-part I took a slightly different approach. I chose not to create controllers in the C++ world. I could have emitted signals from Quick to C++ but instead I let the main quick file act controller. There can be one or two places where I don’t follow this rule in the qml because of laziness :)

So, each GUI component does know nothing about the domain. For example, the stop button doesn’t invoke the Streaming::stop() method directly, this is handled via the PlaybackController. The same goes for NowPlaying, updating the UI is done by the NowPlayingController. By doing this you have a set of UI components that can be re-usable in different contexts, they don’t depend on a particular domain. In the Quick app this apply too since I use the main qml file as controller and the rest of the qml components are (except for me being lazy in some place) not aware of the domain.

I have to admit, I must do some more toying with Quick to try out the different paths one can choose to expose functionality. I could, as I mentioned above, emit signals from quick to c++, I could also create new qml types for example:

One thing that you can think of when doing the qml-part is to have as much as possible as properties. The property bindings makes the qml much easier to work with, than having to invoke methods, set up connections, etc.

If anything is unclear just ask.

Yes really cool staff, but from git now not compiling. Qt 4.7.0 rc and mingw

I’m not sure if mingw supports compiling phonon-stuff. I’ve also noticed that the phonon headers have different locations depending on qt-version.

What kind of error do you get when compiling?

First error out of the box was : mingw32-make²: *** No rule to make target `../model/libicecastmodel.a’, needed by `debug\qtcast.exe’. Stop.

Then i remove project qtcast from main pro

and in quickcast make some changes, about include and this compiled. quickcast working ok. but url and tags doesn’t displays in app.

I am using mingw from qtcreator latest ….

The url and tag problem can be due to the phonon back-end. The gstreamer back-end for Linux actually sets a special http-header so that the icecast server appends some additional meta data to the stream. The windows back-end might not do this.

Mmmm ok i will try to find why and how to fix this … Will post my result, if ….

Nice work buddy. Keep up the good woek!

@maxvanceffer: try adding following to the main pro file

CONFIG += ordered

It could be that qtcast is compiled before model, with the ordered config option the subdirs will be compiled in the order they are written.

No problem doesn’t disappear. I made a new git clone, and add this configure parameter. And steel problem is here.

mingw32-make²: *** No rule to make target `../model/libicecastmodel.a’, needed by `debug\qtcast.exe’. Stop.
mingw32-make¹: *** [debug] Error 2
mingw32-make: *** [sub-qtcast-make_default-ordered] Error 2

Mingw compile first model, then qtcast.

Bwt when start play radio station. It will be wonderful to display something like a progress. Because some radio streams take a little bit more time to start play.