qOrbiter gets some Pi

[phenigma]

Is the hope to have the pi as a media director, or qorbiter-only type setup (so it can be connected to an in-wall touch panel). Or both?

Havn't been hangin' out online much lately but for kicks I've been playing a bit.  This is a little off topic as it is not qOrbiter related but it is Pi related.

I have 95% of the system built for armel on debian squeeze and one of my Pi's is booting as a disked MD in a test system I have here.  UI1 is functional and working but without accelerated X drivers screen draws are slow.  Audio works great!  Havn't tested video yet but again there is no acceleration as of yet so it may play SD divx files but I don't expect much more than that at this point.  XBMC is achieving half-decent screen updates using the OpenGL ES acceleration on the GPU, they also benefit from accelerated x264 decodes (and a couple others) which play 1080P material very well.  Xine has no current way of hooking into this (not that I've noticed anyways).  I plan to keep experimenting and keep an eye on accelerated X driver development for RPi and Xine.

My experience so far is suggesting that coupling the typical MD software (LM, app_server, etc) with qOrbiter would yeild a great system.  Especially if QT can accelerate video playback.

J.

[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.

[tschak909]

Yup, that would be the best approach. I can provide the technical support needed to create a player/plugin pair for anyone working on this.

-Thom

[golgoj4]

FYI as of this morning i

1) reverted my changes to reflect the current svn checkout
2) created a qorbiter-qt5 dir for qt5 work

Ive done this because the changes are just too dramatic between versions. I appreciate the help people are contributing and I feel like it will make it easier to just work as opposed to having a billion ifdefs and entire classes changing in the same build depending on target. I just feel like this will be cleaner and lend itself to a smoother workflow.

also, normally i dont make unilateral decisions, but its been something thats been bothering me, and it doesnt force anyone to do it this very moment. But please consider checking out the Qt5 dir and moving you changes there if they are qt5 specific as I think  it will be a more enjoyable, less soupy experience.

-langston

[Marie.O]

golgoj4 and coley,

you two are the ones mainly working on qOrbiter and as such are setting the rules. However, I really like to point out, that MOST of the stuff in qOrbiter will be library independent. By creating two different codebases you will introduce a lot of overhead, where bugfixes and feature enhancements which deal with DCE communication and LinuxMCE-specific object creation will need to be done in two places. I doubt, that you will like that very much.

Please reconsider your decision to split trees.

Puh, now I have at least written something down, so IF you find out in two month time, that things do not work out with two codebases, I am able to say: 'I told you so'. IF things DO work out, in our next argument, YOU are able to say: 'Just look at Qt4 vs Qt5 in July 2012, and how it did work out'.

I'd say: win-win situation

[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.

[golgoj4]

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.

well the whole moving target is partially why i wanted to move qt5 to its own build sandbox so we could experiment with it cleanly. But i seem to have been outvoted so i guess things go on. But as it stands right now, Im having issues getting the stupid Qt_version_check to work on a consistent basis. Its very odd as it evaluates some blocks right, and others wrong. Leaving me to scratch my head. But what about the qml. All the qml has to be changed to 2.0 or we need to add the old 1.1 into the mix. Hows that gonna work? I spose we can set a flag or something. Im just trying to not get to a place where qOrbiter has more crap to support various versions of qt than actual functionality for the user. However, you did all the work on Qt5 so im willing to follow your lead on this one. 

-golgoj4

[golgoj4]

also, just to give some insight into my crazy mind.

Even though qOrbiter is 'released' on android, i consider it pre-alpha software.
This 1st pass is entirely to find out what I CAN do.
The second pass is making it clean.
The compilation of everything into the binary will change. at some point, if its a class, it will become a plugin. meaning libwhatever and used via 'import Dcerouter 1.0'
i really need to read more books on software development!

I am gruff. i bitch. i moan. i complain. and I thank everyone who has patience to deal with all of this when they ask me hard questions about qOrbiter because in the end, it will make it better, even if it requires more thought and patience than a twitter client.

-golgoj4

[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.

[golgoj4]

So did it just magically start working? Environment setting? this is just now working for me at all and i split it up so i could actually compile it. Not finding anything on this in the wild either. can we get a description of the env, because this is really starting to drive me insane.

golgoj4

[coley]

nope - no magic about it.
It worked in some instances and not in others, but once I included the <QtGlobal> header where the macro wasn't behaving all worked fine.
I'll try compilation on diff versions of qtcreator, but don't see how that will impact this macro.

-Coley.

[coley]

make clean and re-run qmake between builds
qt 4.8.1 - for_desktop gcc(x86) qOrbiter compiled successfully.
qt 5.0 - for_desktop gcc(ARM) bcm cross-compiler, qOrbiter compiled successfully.

any more info you need from my env?

-Coley.

[golgoj4]

make clean and re-run qmake between builds
qt 4.8.1 - for_desktop gcc(x86) qOrbiter compiled successfully.
qt 5.0 - for_desktop gcc(ARM) bcm cross-compiler, qOrbiter compiled successfully.

any more info you need from my env?

-Coley.

Nope, but I did find something very interesting

(QT_VERSION >= 0x050000) works

(QT_VERSION >= QT_VERSION_CHECK(5,0,0)) - doesnt in some cases.

Very curious behavior! I will keep experimenting to see what the deal is. Thanks for the feedback

golgoj4

[coley]

Yep, that's going to work okay. That's the end result of the macro.
That check was what I was using before discovering the other macro in Qt sources.
Magic numbers never good - have been steered away from them from an early age

-Coley.

[golgoj4]

Yep, that's going to work okay. That's the end result of the macro.
That check was what I was using before discovering the other macro in Qt sources.
Magic numbers never good - have been steered away from them from an early age

-Coley.

Possy pointed me to a regex based example, so I should be able to shift it to a range rather than a selected specific version

-golgoj4