TouchOrbiter - Auto-configuring new orbiter

[wierdbeard65]

Reading this thread has filled me with a combination of joy that I am not alone in some of my views and sadness that the team seems to be falling apart.

nothing falls apart but I do not accept profanity here.

I am glad to hear it! Although, you are not the only one to have commented on the postings of others....

[hari]

back on topic please or I need to abuse my forum super powers..

br Hari

[totallymaxed]

What I want most is for people to stop adding 'features'.  Maybe an RC; maybe a release would be conceivable.  There is a 'Do as I say and not as I do!' attitude from the core team and that's really unfortunate and counter-productive.  Challenges for adding new features have been posted regularly since Beta was announced.

Regarding feature freeze: Yes, we had it for a long time. Unfortunately people do not abide. I am strongly against adding any new features, just like you are, and if you listen-in in the dev channel you probably have noticed.

I mean it fellas, am I the only one smart enough to actually work on the Pluto bits of the code? Are you all totally chicken shit? It certainly seems that way.

not the best attempt to attract new developers... I'm getting sick of your attitude..

Reading this thread has filled me with a combination of joy that I am not alone in some of my views and sadness that the team seems to be falling apart.

There are 2 things here, both of which are related, in my opinion, to the attitude of some of the core devs.

Firstly, MCE is a hugely complex system. "Breaking in" is not for the faint-hearted as it seems to me that unless you are capable of digging through mountains of code, you don't stand a chance. There is virtually no documentation on how it works "under the covers". I'm sorry, guys, but the programmer's guide is woefully pitiful. A rough outline of DCE. A lot of times we see comments from people with little or no Linux experience, but who wish to become involved. Time and again people manage to add features, using general resources to guide them, only to be told that their solution is "Duct Tape" and to "integrate it properly". For example, where is the detailed explanation of where settings are held and how they get applied? How many folks have complained about settings they change to get an addition working being overwritten on reboot? Further probing revals it's all by design and part of the "plug and play" philisophy. Great, but please can someone document it? Some of the core devs complain they don't have time to do this. Maybe, but the investment would pay off as there would be more people getting involved and helping!

Which brings me to my second point. Features. We are in Beta, as has been said already, so it really should be "NO NEW FEATURES". It seems to me that (see comment above) the valuable time of the core devs would be better spent documenting what we have and making it work, rather than adding new stuff (which may actually also break the system further). We are entering into a vicious cycle where a lot of the projects that MCE relies on are being updated themselves. If we don't go RC soon, we run the risk of NEVER doing so! We are already basing it on a version of Linux that is 2 years old. Regularly I see issues coming up due to Samba, Myth, Asterix or whatever now being updated. Hardware changes, new stuff requires new drivers which oftentimes only work with updated kernel / os / subsystem.

Guys, I know it's cool to be able to anounce "hey, look what I just added", but at this point reliability is what matters. FWIW, I'd rather have fewer features, but a system thus "just works" than a system that promises much, but fails to deliver. We're not Micro$oft after all! As to why I haven't dug in yet? Well I think Hari's response to Thom says it all.

Just my 10cents.

This whole 'Off topic' discussion that Thom's comments have triggered should be taken to another thread...its not what we are discussing in this specific thread. So please start a new thread rather than adding any more comment here (I'm not disagreeing with you or agreeing with you...but commenting here is not helpful).

Thanks


Andrew

[totallymaxed]

I've been learning some c++ and I've spent the weekend hacking away playing with online sdl tutorials and the touch_orbiter_1.0 in svn and I have managed to create a linux touch orbiter that is working well for me using sdl.  Great learning experience.

What I would like to do now is add configuration setup like the padorbiter has.  From the I've tracked down it looks like there is a 'createorbiter' DCE command that padorbiter uses to create a new orbiter device on the core.

1) I'm assuming a new DCE command will be necessary to create the proxy_orbiter (and associated orbiter). 
2) It seems to me that if a new DCE command is required to create the proxy_orbiter then any device using touch_orbiter could utilize the same command for the proxy_orbiter creation and setup.  Anyone care to comment on whether I am right or wrong here?

Has anyone looked at this yet or begun any work towards this in any of the touch orbiter platforms?

J.

Hi Phenigma,

To help us all re-orientate ourselves and get this thread back on-track again... could you summarise where your at or what your planning for Auto configuring new Touch Orbiters? As step by step description what should happen would be useful. This will also help anyone developing a Touch Orbiter variant to get their head around what needs to be added (if anything) to their Apps.

All the best


Andrew

[los93sol]

Anyone interested in touch orbiter auto-configuration should really follow along with http://svn.linuxmce.org/trac.cgi/ticket/857  That's the ticket documenting the development/changes Merkur and I are working to implement which makes it relatively quick and painless to incorporate this feature.

More details to come as things progress, but right now you can get rooms, users, skins, languages, and ui's available to populate selections in your touch orbiter implementation.  You can also poll for the status of orbiter generation with full progress and feedback just like a conventional orbiter would display.

Hopefully others will start jumping on board to help test and develop this.

[phenigma]

Anyone interested in touch orbiter auto-configuration should really follow along with http://svn.linuxmce.org/trac.cgi/ticket/857  That's the ticket documenting the development/changes Merkur and I are working to implement which makes it relatively quick and painless to incorporate this feature.

I've been following along, great stuff so far.  I plan to try it.  I have heard from others working on a touch orbiter and they will likely try to use this as well.  Thank you so much for all the work you and Merkur have been doing.

To help us all re-orientate ourselves and get this thread back on-track again... could you summarise where your at or what your planning for Auto configuring new Touch Orbiters? As step by step description what should happen would be useful. This will also help anyone developing a Touch Orbiter variant to get their head around what needs to be added (if anything) to their Apps.

Well my initial thoughts of the process went a little like this:

1) check if device exists/is defined in database, based on say a .conf file (like maemo) or a MAC (like padorbiter or windows orbiter)
2) if device exists in database then connect to it's defined port #, if it fails proceed to 3) else proceed to 9)
3) detect the native display resolution of the device
4) ask the user if this is a new orbiter and therefor if a new device should be created (a la padorbiter)
5) create the new device -> proxy_orbiter, perhaps an orbiter to go with it if creating proxy_orbiter doesn't do this
6) query the user and set orbiter template attributes for: Language, Room, User, available Skin, etc...
7) query user for display resolutions that are <= native resolution of device and set template attributes
regenerate
9) use...   if selected resolution == native resolution would trigger a fullscreen display (no window dressing)

and then 10) should be 'profit' or something like that but I havn't figured out the origin of this little inside joke yet to know why....  <:-P

I may have missed something there but that was the general idea of it.  I'm hoping for something fairly generic that runs (or at least compiles) easily on multiple systems: mini2440, maemo(s), debian.  The functionality exists in Orbiter and I wanted to mimic the behaviour/code in Orbiter that padorbiter uses to auto-configure.  My issue was, more or less, with the backend code required to implement the auto-creation of proxy_orbiter as I havn't really had a chance to explore the dce commands that Orbiter uses to do this.  los93sol seems to have documented these commands somewhat in the code referenced in the ticket above (thanks!).  I'm am really busy right now but I am going to try to use them.

Jason,
The maemo build env isn't too difficult to setup. I don't know if you are happier on a windows or linux box. There is a VM image available ...
Then from the scratchbox env you can either symlink to your existing LinuxMCE src or do an svn co from within. I have a script that builds the other necessary libs for the orbiter, I'll attach it here once I get home.
...
p.s. Oops, just noticed this is under Touch Orbiter - if this discussion continues maybe we should break it out under a PadOrbiter topic?

Thanks coley.  Yes we should start a new thread for this.  I'll try to set up a build-env and see what happens.  I'd love to access any scripts/changes you already have.  You could PM or e-mail me what you have (phenigma at hotmail dot you know) and I'll post a new thread with my progress.

J.