Well for a start its an ARM chip so LinuxMCE would need to be ported to it.
There is some ongoing work getting qOrbiter operational on it.
It should technically be possible to get other MD related binaries cross-compiled for it.
So to answer your question - nope, no installs of LinuxMCE.

-Coley.

yeah I had my fair share of swearing at that version check macro, since it seemed to be the way Qt code itself checked versions I used it. Including <QtGlobal> #defines the macro. The IDE was able to adjust the syntax highlighting, so why the compiler couldn't kept me confused.
As for the 1.0 vs 2.0 in qml I can't seem to find a satisfactory answer, I'm playing around with a few ideas and will see if any bear fruit.

-Coley.

I know the rule around here is normally "he who writes the code writes the rules" but I don't see any need for two codebases. If I did I would have done that from the start and not #ifdef'd the codebase to work on both versions of Qt. Qt have forced our hand with the changes, maybe its too early to try and work with Qt5.0, its barely alpha at this point, potentially still a moving target  I know the documentation certainly is!
As qOrbiter matures having two bases with bug fixes and having to patch either stream with new features becomes a nightmare.
golgoj4 if you still want to split Qt4 and Qt5 verions apart, an svn branch might be a middle ground, at least then a merge could bring either branch up to date.
I agree with possy here but as I consider this golgoj4's baby I will work with whatever is chosen.
Discussion welcome.
-Coley.

Glad to see there's more than me looking at the Pi and lmce.
What dev environment have you set up? is it a scratchbox type setup?
I started cross compiling some of the pluto libs as their code is currently compiled into qOrbiter, and they'll be needed as libs if any DCE devices are to run on the Pi. But I was messing with too many makefiles and parked it. Then you chimed in
I was thinking of the media stuff and probably the best route, correct me if I'm wrong, would be to create an omxplayer device for the Pi as that is specifically built for the Pi and can  make use of the h/w acceleration.

Wheezy seems to be a bit faster according to some reports and also there is a hardfp image of wheezy out there.

-Coley.

golgoj4 do your .pro file changes work for you switching between Qt targets?
what steps do you run?
I cannot get it to successfully compile when I rely on the .pro file to switch.
Do you need to do a make clean and re-run qmake after a switch?

thanks,
-Coley.

Coley,

whatever suits you best. I personally would probably create two tickets. 4.8->5.0 and one for rPi. But I am hopelessly anal about these kind of things.

#1497 created to handle Qt version transition, will try to keep it rPi agnostic.
-Coley.

Ok the threading thing seems to be an issue with the new QML engine - will need to find a work around for this.
I've been trying to get my chopped-up code into a reasonable state for svn checkin - to achieve this I have set-up side by side Qt4.8.1 and Qt5.0 for linux plus Qt5.0 cross for Raspberry Pi so I can select any target easily.

There are a boatload of trac# associated with this according to the README - will I create a new one for Qt4.xx -> Qt5.0 port? rather than being specific to the RPi?

-Coley.

Just a quick video taken this morning before work.
http://youtu.be/BewGFJJXZ2A qOrbiter loading to home screen complete with gaussian blurring logo in the background.

Had to move the CPU/GPU memory split to half'n'half to get the screen saver operational.

Now to find out why threading ain't working ...

-Coley.

Thanks possy - hopefully I'll get there

A bit more progress - Screensaver doesn't segfault any more, but the pics don't display. Effects get loaded and all that side is ok but I'm getting an OpenGL error:

Code:

QOpenGLFramebufferObject: Framebuffer incomplete attachment.

Haven't figured out yet who/what is emitting the error but it results in no pics appearing, backdrop of qOrbiter has changed from blank to black.
Must fire up my qt4.x qOrbiter on my core and do a like for like comparison.
 - Floorplan screens switch in and out - don't know of their functionality
 - security pad screen loads - again haven't tried out functionality.

golgoj4 - is your Readme in qOrbiter up to date in terms of what I should expect to work?

-Coley.

A quick update:-
 - mouse support on latest Qt snap
 - home screen operates as expected, scenario rows populated as expected.
 - Lighting, I have one zwave switch - light on, light off as expected
 - User selection operates
 - Room selection operates and scenarios re-populate
 - Security, link to camera switches screen but AFAIK this screen isn't complete yet.
And the not so good news
 - Tried media selection - screen won't switch, I get an error trying to switch out of the QML engine thread, specifically:

Code:

QQmlEngine: Illegal attempt to connect to ListModel(0x14231e8) that is in a different thread than the QML engine

More digging required ...
-Coley.

I see there was an initial commit from the dev yesterday.
Anyone with a kinect care to have a play?

-Coley.

Right! after a fight ...
 - qt5 cross-compiled for debian wheezy distro from git
 - rPi sys-root from git
 - qOrbiter compiled against freshly baked qt5 and sys-root
 - rPi running debian wheezy
 - More edits to change header files as Qt changed a lot between qt4.x and qt5.0 with their modularisation.

No symbol size mismatches

Will report later on how this operates as I'm ssh'd into dev box and rPi so cannot actually test.

-Coley.

could also apply for one of the 400 vouchers from nokia, if they still have them

I thought they were already allocated.

-C.

locutus - did you get an env set up yet? I saw on another thread you are expecting your own raspberry Pi soon, did you receive it yet?

Meanwhile I've been trying to get qOrbiter running on a more up to date image. I can go with a debian squeeze or wheezy image on the Pi and get them up and running. But the qOrbiter I build with the cross compiler supplied via QtonPi wiki doesn't run on the image - complaints about size differences in objects. I can apt-get update my qt50-snapshot, wheezy is newer than squeeze, so either should have the mouse support I am looking for.
I've installed a second cross compiler - the linaro toolchain seems to be recommended - that is operational via Qtcreator.
I don't have a cross qt5 sysroot set up yet to match the qt50-snapshot on the image. I have't been able to find a pre-rolled one on the interwebs so am in the process of building a suitable qt5 sysroot from git.

Grr.. some isp issue is preventing me ssh'ing into my setup atm, may have to do some work  

-Coley.

so like, if someone wants to send me one, now is the time. coley has been kickin ass and the time is upon us!

-golgoj4

Can you not get your new employer to sponsor you one? 

-Coley.