TouchOrbiter - Auto-configuring new orbiter

[phenigma]

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.

[tschak909]

I do understand this is a learning experience, but...

I think making touch orbiters for native clients is a waste of time. Actually spend some time with Orbiter, and figure it out... Otherwise, all of you making touch orbiters are going to run the risk of reinventing what we already have. I'm growing very irritated by the whole thing.

-Thom

[phenigma]

I do understand this is a learning experience, but...

I think making touch orbiters for native clients is a waste of time. Actually spend some time with Orbiter, and figure it out... Otherwise, all of you making touch orbiters are going to run the risk of reinventing what we already have. I'm growing very irritated by the whole thing.

-Thom

There seems to be a divergence between how you 'want' things done and how everyone else is moving and implementing things. 

Do you have a native linux orbiter that works standalone of an MD or other MID device that you would like to share?  I think that would be nice with Orbiter but some work needs to be done to enable it to easily run standalone of an MD on linux (I did try) but I certainly didn't have the knowledge before this past weekend.  I've looked at the Orbiter code and I shake my head... why should I touch it when you are continually saying it's being re-written from scratch?  Orbiter is bloated and consumes a lot of resources.  Native orbiters for each and every possible device do not make sense to me, it's a nightmare of maintenance of multiple devices that all do the same thing.  And there are a dozen new devices to support every month. 

It also seems to me that touch orbiter circumvents having to pay a licence fee (PPL) to sell a device with orbiter (no I am not a dealer and I do not intend to sell anything) and so a licencing fee is not required for those that resell, probably one reason why CHT is going this route.

The existing linux/mini2440 touch_orbiter in svn has not recieved any love since inception and it has a memory leak making it unusable after a brief time and uses almost as much cpu as the native orbiter (this I can resolve now that I've been through the process and have figured out why/where).  I'd like to create a single device to support multiple linux distributions and windows/mac that can easily configure itself. 

The touch orbiter allows me to use my webdt's with squeezeslaves installed - audio zones everywhere I have a webdt!  Padorbiter uses too many resources for this to be possible.  I can even do *other* things, like browse the web, with my webdt & touch_orbiter running, not possible with Padorbiter.  You have said yourself that you can't 'shoehorn' it all in.

And to top it off this was even something you had suggested implementing.  My feeling pretty much mimics this:

Thom, I'm quite in a mood of slashing my wrists right now, for no good reason, and I get this mood each time I want to do something for this system, not sure why. I did this Touch Orbiter thing on a whim, for quick and dirty way of getting more devices with Orbiters on them in a snap, and get other people to write similar code for other platforms, for an instant explosion of supported devices.

Your response was this:

Dude, I wasn't trying to make you depressed, or anyone else for that matter.

I am trying to get people to try and make the process of using these proxy orbiters plug and play process.

we have:
is entirely text
* the ability to detect screen resolution
* the ability to select a skin
* the ability to select users to use this orbiter
* the ability to detect whether PNG or JPEG is supported

This can be funneled into a New Orbiter DCE command to the Orbiter PlugIn, which, when coupled with two new device templates:

* Proxy Orbiter - PNG Images
* Proxy Orbiter - JPEG Images

with the ImageQuality device data set appropriately,

This can all be made plug and play.

-Thom

A recent conversation in irc with los93sol and you were praising him for trying to do just this.  So, I did this to find and fix a memory leak that was preventing touch_orbiter from being a viable option and to learn more so I may be able to contribute more in the future. 

I started this thread so that I wouldn't be re-inventing what has already been done, as you say.  I wanted to find others who are building touch orbiters for devices so that a common solution could be found for automagically configuring all these devices, not just mine.  I suppose I'll not bother, leave it alone, and continue to manually configure my system and not try to make things plug and play.  Thanks for the support!

J.

[tschak909]

Why don't you actually try to look at and understand what we have, before spouting off?

Shake your head? Do you understand what Orbiter actually does?

I don't think you do.

and circumventing the PPL? That's funny. You still have to run Proxy Orbiter on the core.. Guess what? That's a subclass of Orbiter. PPL code.

Compiling Orbiter with at least -DMAEMO_NOKIA770 and -DPADORBITER will get you a native orbiter that can run on Linux. You can also do -DUSE_GTK to use the GTK Progress bar and prompt code. Just be sure to copy GTKGlade.orbiter in the src/Linux directory to /usr/pluto/bin...

And yes, Orbiter will be rewritten at some point. This does bring up my other point. I'd like people to make UI toys in Clutter, so we can have something to mash between our fingers, something we can use and interact with to define the features we need in a new orbiter..But I've already gone over this repeatedly, with just about everybody missing the point...

The Touch Orbiter is at best an interim solution for the problem of moving orbiter to other systems where the C++ DCE library isn't available.

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. No. Let's not actually understand what we have, let's just put our fingers in our ears LA LA LA LA LA and work around it! Stop it. Roll up your sleeves, grow a sack, and actually dig in and understand what we have..Then, and only then, can we move forward.

-Thom

[coley]

<snip>
Compiling Orbiter with at least -DMAEMO_NOKIA770 and -DPADORBITER will get you a native orbiter that can run on Linux. You can also do -DUSE_GTK to use the GTK Progress bar and prompt code. Just be sure to copy GTKGlade.orbiter in the src/Linux directory to /usr/pluto/bin...
<snip>
-Thom

Just to pick up on this point - had done exactly this previously for the n900 and it works and creates an orbiter that can be just run on the n900, no pre-config needed. I got stuck creating a viable .deb for it and haven't been back to it since but will try and get it installable, once I figure out the packaging stuff.

-Coley

[Murdock]

Thom - I understand your point, but posts like this will not grow developer interest in the project. I don't think it's what your saying but the way it's being said.

[totallymaxed]

Why don't you actually try to look at and understand what we have, before spouting off?

Shake your head? Do you understand what Orbiter actually does?

I don't think you do.

and circumventing the PPL? That's funny. You still have to run Proxy Orbiter on the core.. Guess what? That's a subclass of Orbiter. PPL code.

Compiling Orbiter with at least -DMAEMO_NOKIA770 and -DPADORBITER will get you a native orbiter that can run on Linux. You can also do -DUSE_GTK to use the GTK Progress bar and prompt code. Just be sure to copy GTKGlade.orbiter in the src/Linux directory to /usr/pluto/bin...

And yes, Orbiter will be rewritten at some point. This does bring up my other point. I'd like people to make UI toys in Clutter, so we can have something to mash between our fingers, something we can use and interact with to define the features we need in a new orbiter..But I've already gone over this repeatedly, with just about everybody missing the point...

The Touch Orbiter is at best an interim solution for the problem of moving orbiter to other systems where the C++ DCE library isn't available.

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. No. Let's not actually understand what we have, let's just put our fingers in our ears LA LA LA LA LA and work around it! Stop it. Roll up your sleeves, grow a sack, and actually dig in and understand what we have..Then, and only then, can we move forward.

-Thom

Thom - I really think you should go and create another thread where you can 'evangelise' your preferred approach to Orbiter instead of continuing to criticise people here in the forum for getting involved in developing versions of Touch Orbiter for devices they want to add to their systems. As Uplink said we developed the reference code for Touch Orbiter and published it under the GPL to help people get involved in this project by leveraging their existing development skill sets and to encourage others like phenigma who wanted to use the code as a way of learning new skills. Touch Orbiter achieves both of these goals admirably as witnessed by the number of people here in the forum who are doing just that!

I know you feel this whole approach is not right...but please respect that others here dont always agree with you. Your attitude here in this thread and numerous others is bombastic and un-helpful in the extreme. Please create a separate thread here and expound your views and your approach in that thread rather than negatively attacking people for doing something you dont agree with.

I think there is room here for a whole range of views and opinions and I for one would never attack you or anyone else for taking a different approach to the one i might believe is right - please do us all a service and do likewise.

All the best


Andrew

[phenigma]

First and foremost, thank you all for speaking your minds.  Ongoing intelligent discussion must continue to occur on this project.

Why don't you actually try to look at and understand what we have, before spouting off?

I really am Thom, I really am.  It's not easy when this system is so large.  I understand everything very well in my head; it's the implementation that is lacking right now.

Shake your head? Do you understand what Orbiter actually does?

I don't think you do.

I do understand what it does (mostly).  I don't understand all of the intricacies of the C++ language but I can read it and tell what it is doing.  I have spent hundreds of hours reading the code in svn.  I've been following svn changes daily for about two years and I'm investigating many aspects of the system and improving my knowledge every day.

and circumventing the PPL? That's funny. You still have to run Proxy Orbiter on the core.. Guess what? That's a subclass of Orbiter. PPL code.

Okay, circumventing was a bad choice of words.  My understanding of the licences that commercial installers have undertaken (and yes this may vary) is that they pay a fee when the sell a device that is 'intended to run orbiter', so if they sell a hybrid that runs orbiter they will pay a licencing fee for that device, but not a fee for each instance of orbiter the hybrid runs.  Then they can supply as many additional devices that run a 'touch orbiter' or 'web orbiter' without having to pay any additional licencing fees for those devices.  Example: If I am a re-seller and sell a device with 'Orbiter' installed or intended to run 'Orbiter' then I must pay a fee to pluto when I sell this device.  But... if I sell a device installed or intended to run 'Touch Orbiter' then I will not have to pay the fee when I sell this device, no PPL code or applications.  This is my understanding.

Compiling Orbiter with at least -DMAEMO_NOKIA770 and -DPADORBITER will get you a native orbiter that can run on Linux. You can also do -DUSE_GTK to use the GTK Progress bar and prompt code. Just be sure to copy GTKGlade.orbiter in the src/Linux directory to /usr/pluto/bin...

I don't believe I've tried the options together I will, thank you.  I tried -DPADORBITER but without any the other options.

And yes, Orbiter will be rewritten at some point. This does bring up my other point. I'd like people to make UI toys in Clutter, so we can have something to mash between our fingers, something we can use and interact with to define the features we need in a new orbiter..But I've already gone over this repeatedly, with just about everybody missing the point...

I have been looking at clutter and I am amazed at how abstracted it is and seemingly easy to use, at least the basic stuff.

The Touch Orbiter is at best an interim solution for the problem of moving orbiter to other systems where the C++ DCE library isn't available.

I agree with you.  But until Orbiter is re-written without PPL constraints it is a solution that will be persued by many.  But I also see that the touch orbiter interface looks like it could be extensible to permit a wide range of data transfer capabilities and provide orbiter like functionality rather that simple image display and x,y return.  dce through http?  or could hari's rpc code essentially enable that type of functionality?  never mind, this is another topic and more code for me to read.

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. No. Let's not actually understand what we have, let's just put our fingers in our ears LA LA LA LA LA and work around it! Stop it. Roll up your sleeves, grow a sack, and actually dig in and understand what we have..Then, and only then, can we move forward.

-Thom

Thom you are not the only one smart enough.  But this brings me to my previous post.  While I dream nightly about dce messages firing between devices and envision more devices interfacing with greater ease...  We are not all as experienced as you are with development or with the many facets of this system.  I have a lot of respect for you and your understanding of this system, and your commitment to the project, but you are aggressive, appear arrogant, act dictatorial, and belittle people too often for me to really want to commit to doing anything you ask or demand.  I want you to be a leader not an bully.  Just because I don't understand Orbiter as well as you do does not make me less worthy of an intelligent response.  Thom I don't agree with what you do here all the time and you don't have to agree with what I do either but I'm trying to help make this system better.  I put more time into learning this system then I really should and I didn't think constructive help and a push in the right direction was too much to ask towards helping to make auto-configuring more of a reality.

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.  Beta is about a year old and new features are still be added, an RC doesn't appear on the horizon.  If the core devs won't abide by the declarations then open the damn thing up so others can put their features in too!@

My rant ends now.  I will continue to do what I am able when I am able to.

With respect,

Jason.

[phenigma]

<snip>
Compiling Orbiter with at least -DMAEMO_NOKIA770 and -DPADORBITER will get you a native orbiter that can run on Linux. You can also do -DUSE_GTK to use the GTK Progress bar and prompt code. Just be sure to copy GTKGlade.orbiter in the src/Linux directory to /usr/pluto/bin...
<snip>
-Thom

Just to pick up on this point - had done exactly this previously for the n900 and it works and creates an orbiter that can be just run on the n900, no pre-config needed. I got stuck creating a viable .deb for it and haven't been back to it since but will try and get it installable, once I figure out the packaging stuff.

-Coley

Coley are your code changes available anywhere?  No one seems to be maintaining the maemo builds right now, I've never set up a maemo build env but I would take a crack at figuring it out and packaging it. 

Unrelated: There is also currently a bug installing the existing orbiter on the lastest PR1.2 because of the '.install' file for n900 pointed to in the wiki.  I know what needs to be done to fix it but niteman hasn't responded to me e-mails so I'm not sure if he's around to fix the file.

J.

[Marie.O]

Hello Jason,

there ain't much that I would add to your statements, on the contrary. Very well put.

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.  Beta is about a year old and new features are still be added, an RC doesn't appear on the horizon.  If the core devs won't abide by the declarations then open the damn thing up so others can put their features in too!@

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.

Regarding going RC: We have many bugs that effect the system as is, and which need to go away before going RC. The minority of bugs is related to our base distribution. The minute I declare RC, people will jump off fixing bugs, and whole shit load of features will creep up upon us. This will not help make lmce installation a better experience.

This is the reason, why I won't declare a release candidate unless ALL known bugs, which are marked Priority normal or higher have been fixed. Even if this means, we will go down in computing history as the project with the longest beta period of all times.

[los93sol]

Regarding auto-configuring new orbiter's, Merkur2K and I are working through this at the moment for the Android Orbiter I have been working on.  The implementation is quite simple, there is a PHP script that you post to using your variant of httpclient and it returns JSON back which can be easily parsed to retrieve the database results for rooms, users, skins, ui's, and languages.  You can then monitor the progress of the generation process and display that to your user by whatever means is convenient.  We are still working through creating the device and adding resolutions to the database on demand, but the previously mentioned features are already tested and working in the Android Orbiter.  Note that before using these features you will have to perform a logon to the web admin using appropriate credentials from the user to access the PHP script.  This will all be documented in the wiki when the details are firmed up and it has been fully tested.  Until then, hopefully this is a nice teaser....

http://img180.imageshack.us/img180/2812/deviceo.png

[hari]

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

Hari

[coley]

Coley are your code changes available anywhere?  No one seems to be maintaining the maemo builds right now, I've never set up a maemo build env but I would take a crack at figuring it out and packaging it. 

Unrelated: There is also currently a bug installing the existing orbiter on the lastest PR1.2 because of the '.install' file for n900 pointed to in the wiki.  I know what needs to be done to fix it but niteman hasn't responded to me e-mails so I'm not sure if he's around to fix the file.

J.

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 http://maemovmware.garage.maemo.org/2nd_edition/ which has cross compiler and rootstraps all set up. Or you can get the scratchbox install http://www.forum.nokia.com/Library/Tools_and_downloads/Other/Maemo/ which you can setup on your core to do the cross compiling.
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.
I don't recall many code changes - maybe an #ifdef or two, I'll chk later anyway.

I noticed the error too with the current .install and I think I posted changes in the forum on how to proceed. If nite_man isn't responding and you have fixes maybe post them here and ask totallymaxed nicely if he could get someone to upload the updates to the site - it is hosted on one of their servers. I'm happy to test any changes you have.

-Coley.

p.s. Oops, just noticed this is under Touch Orbiter - if this discussion continues maybe we should break it out under a PadOrbiter topic?

[wierdbeard65]

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.

[hari]

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.