Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - los93sol

Pages: 1 [2] 3 4 ... 27
Developers / Re: Los93soL Android Touch Orbiter
« on: December 03, 2010, 02:24:12 pm »
Some user testing has been discussed here:

That thread is for the other Android Touch Orbiter, not the one mentioned in this thread

Developers / Re: Los93soL Android Touch Orbiter
« on: December 02, 2010, 04:17:36 pm »
los93sol - which latest changes do we need?  pluto-website admin?  Or do we also need the latest orbiter plugin, or even more?

pluto-website admin is all that is required currently, per your heads up last night, I'm aware of the crash when installing on 1.6, I don't know why it's happening yet, it only happens when installed from URL though, if I install through USB using ADB the app installs and runs without issues on 1.6.  I'm all ears if anyone may know why it's happening, the errors don't point me in any kind of direction

Developers / Los93soL Android Touch Orbiter
« on: November 29, 2010, 03:36:18 pm »
I've been working on a touch orbiter for Android devices for awhile now and think it's time to start a development thread for it.  This is posted in the development thread because it is not ready for the masses yet, and is undergoing constant development.  I'm posting about it here for those that want to help test and follow the development progress.  Anyone testing needs to be sure you're core is up to date.

There are several key differences between this orbiter and the one from DarrenMason, details are below.  We're all experimenting with these devices and trying to find the right combination to really move forward...

Updated 12/5/10
  • Supports Android 1.5 to current
  • All strings localized (Need assistance with translations, volunteers please reach out to me)
  • HTTPS support, must manually apply patch:
  • 3g Support (Requires that you have outside access to the web admin)
  • Orbiter can be created and generated straight from the device
  • Update and/or use an existing Orbiter
  • Device resolution is detected automatically and added to database if it does not exist
  • View orbiter generation status from within the app OR in the status bar
  • Touch Orbiter communications utilize HTTP instead of the conventional socket approach
  • Keyboard support
  • Optional username/password logon
  • Configurable refresh rate

Updated 12/1/10
Partially Implemented
  • Wifi preference settings

Updated 12/1/10
Known Issues
  • Orbiter status bar generation progress can sometimes report complete, but not be reflected when launching the app until manually relaunched
  • If your orbiter is deleted, the orbiter app will appear to do nothing on launch

Updated 12/5/10
Planned Features
  • Pass phone events back to the core for more advanced mobile orbiter scenarios, for security concerns these should be options and the user should be able to turn off reporting (ie. Wifi On, Wifi Off, Wifi Connected (SSID), Bluetooth On, Bluetooth Off, Bluetooth Paired (Device), GPS On, GPS Off Last Known Location, maybe even as granular as text messages and phone calls from specific people containing a specific message)
  • Profile support (ie. Home, Away, Wifi, 3G)
  • Shake to refresh
  • Widgets (ie: House mode, Scenario Execution from home screen)
  • Follow-me support using Bluetooth (Initial tests are promising, server side development required)
  • Media browsing/playback on device
  • Use device as phone extension in the home

As you can see, I'm already doing some things that haven't been accomplished/tried before with the touch orbiters.  I'm also actively looking to enhance the functionality available to these devices.  I've done some preliminary testing for Follow-me Bluetooth on these devices and proved that it is possible, but there is quite a bit of server-side work that needs to be done to pull it off cleanly.  Merkur2k and I worked on a script in the web admin to do some custom lookups and poll the core for information, this script can continue to be enhanced, or we may use the same method in additional scripts to achieve things like Widgets.  I'm very interested to hear back from the community about your ideas to achieve some of the planned features, and any additional ideas you may have to make this orbiter even better.

You can follow the development of this application in SVN here:

Latest alpha/beta version will be temporarily hosted on my server until published on the Android Market for debut release


To Get Web Admin Changes (On your core)

To Get Required Changes For Keyboard Support (Continued from above instructions)
  • cp /home/lmce-admin/operations/myDevices/orbiters/proxySocket.php /var/www/lmce-admin/operations/myDevices/orbiters/proxySocket.php

Updated 12/14/10

Users / Re: New UI1 Orbiter skin
« on: November 20, 2010, 12:50:01 am »
Yes, but we still need to get a functional proof of concept.  Personally I don't think it's even going to happen, not enough people understand our current system, and there's not been any tangible progress on that front in almost a year already.  It's just such a massive undertaking, I don't see it ever happening and see more value in slowly migrating off of what we have already instead of trying to to a full blown overhaul, we really just need a few people do take ownership of it and continue to hammer it out.

Users / Re: New UI1 Orbiter skin
« on: November 19, 2010, 09:18:17 pm »
Thom...if I ask very nicely, can you overhaul the media views so we can eliminate having a list and a datagrid and just have a navigable grid of coverart?  If no art is present just display the name in the space?  :)  That would be sooooooooooooooooooo much nicer than how it is now!

Media on our systems can change regularly, even daily, doesn't it make sense to be able to scan foe updates from the UI so we can start moving closer to a system that tags media for us?

Users / Re: n00b Q's - HD partitions/mounts & racks
« on: November 19, 2010, 07:37:29 pm »
In my experience it's only intimidating if it's not properly planned, documented, and implemented.  I have defined standards for wiring, terminations, and labeling to streamline the wiring in my home.  I have also laid everything out on a floorplan that contains both a hardcopy in a notebook with accompanying documentation and a USB stick with the digital copy in the binder as well.  I've also put together some quick help documents for performing basic changes to the home wiring.

For example, in my rack I have 2 RJ45 24 port patch panels, and a 24 port switch.  I punch everything to the B punch pattern so that I can do the following with my 3 patch panels.  The top patch panel is prewired all 24 ports hot with traditional analog POTS line.  The second patch panel is the CAT5 lines going out to different rooms around the home.  Then the switch is below that.  This lets me simply move a single jumper to switch and outlet in the home from network to phone with no punchwork necessary, it's very quick, and very easy for ANYONE to do.  The fact that I label all outlets in each room, and on the patch panel side, as well as provide a floorplan in my binder makes it incredibly efficient to make changes.

That's just one example of what I've done in my environment to make things easier on me, I also did similar with coax in the house as well since I have both cable and satellite service, it is very quick to switch between service types without having to monkey around with routing cables through my rack, just move a single 12" jumper and I'm done.  This configuration also keeps your rack wiring INCREDIBLY clean and tidy.

Hopefully this gets you thinking about the things you can do to make avoid an intimidating situation, in my case, all my existing wiring was a rats nest of undocumented cable runs which required toning and fumbling around to make even basic changes, I took those past experiences into consideration when laying out my rack setup and used the opportunity to rectify those problems.

Users / Re: New UI1 Orbiter skin
« on: November 19, 2010, 01:36:07 pm »
The play/pause, etc. buttons wouldn't necessarily have to be on each screen, I didn't explain my thinking very well before, what I meant was, for instance, when you have media playing, or are on a phone call, etc.  If you're navigating screens outside of the control screen for the current 'audible activity' (ie. watching tv, listening to music, on a phone call), that space could be useful to place relevant controls for that 'audible activity' so that you could do things like drop the call, play/pause, maybe place light/volume controls in that space, just trying to think outside of how we currently do things in the UI to update the functionality while you're working through this.  Personally, I think this would make the experience much nicer.  I was thinking about the popup dialog too, that area could be a general information area of the screen so that when you have media playing, etc. that information could be shown there, and when a popup dialog needs to display, swap out the information...just a thought.  I'm one of those people that likes for things in the UI to be extremely fluid and symmetrical, I also like for things to be sensibly placed with pre-defined standards so the user can anticipate where certain controls will be on the screen without having to hunt around each time they see a new screen.

Again, you're doing great work, keep it up!

Users / Re: New UI1 Orbiter skin
« on: November 19, 2010, 09:31:13 am »

Sorry for my pitiful PS skills, but this is sort of what I had in mind, your last mockups were pretty close to this.  The area to the right of the LinuxMCE logo would make a perfect area of reserved screen real estate for popup dialogs...

And for the button arrays something akin to the blackberry style would probably look really's an example

Users / Re: New UI1 Orbiter skin
« on: November 17, 2010, 10:52:03 pm »
Good call on that popup dialog space being reserved, fully agree that it's quite annoying when it pops up and covers things up, it's also a bit annoying that we can't review past dialog messages, but that's another subject altogether...

Re: getting the look right with removing the rectangle, have you tried just going straight across it and doing like a roll effect on the edge so it transitions down to your content canvas nicely, and the same thing back up across the bottom.  I like the symmetrical look/design you've got going, what about slimming the LinuxMCE logo down to the size of the round buttons you have up top and centering it along the bottom edge so you still have room for the popup dialog on either side of it.  That should leave you with ample space for additional buttons at the bottom as well...just a thought, I'll try to photoshop my thoughts when I get home from work tonight.

Users / Re: New UI1 Orbiter skin
« on: November 17, 2010, 08:25:17 pm »
You're really making some progress now!  Looking good, I don't think it's too dark at all.  Have you played with the idea of...where you have the 'content' area of the screen in a rectangle, maybe stripping off the rectangle to use the full width of the screen and have your default buttons across the top how you have them now and using a similar layout for custom screen buttons across the bottom like a play, stop, ff, rw, etc?  Just a suggestion, it's looking good, keep it going!

Feature requests & roadmap / Re: Project Natal
« on: November 11, 2010, 03:59:43 pm »
Bongowongo: I think it's just you...consider what a nice mic that does true noise cancellation costs, then add the cost of a nice 480p camera with pan/tilt to it.  You might come out to about the same pricepoint of $150USD, but definitely not any cheaper than $150 for nice hardware.  Now think about the other things that you can do with it, you get RGB+d and can scan the room, right now it means nothing to us, but think outside the box, what could you do with a scan of the room?  This thing reads accurately enough that gesture control could mean you sit on your couch with no conventional remotes anymore.  These are readily available to us at any local shack that sells video games, I couldn't go just anywhere and buy a nice noise cancelling mic before.  Also, it only takes up a single USB port and is all in one 'box' so you don't have a bunch of stuff cluttering up your entertainment area.  Just a few benefits of this device that come to mind over the traditional approach.

Feature requests & roadmap / Re: Commercial Use
« on: November 11, 2010, 03:51:04 pm »
Those expectations are quite lofty at this thoroughly understand why you need to have some background of the projects history.  You can start by looking at pluto home's ailing website.

Read through the PPL on their website and consider that we are still focusing on freeing ourselves from that license.  As a businessman I'm sure you can see how, as long as we're operating under that license, we're basically limping around on one leg, no chance to run until we're free of those shackles.  Then go look at our codebase and see just how large and complex it is, you can imagine that with only a handful of us here working to accomplish these things, it takes a considerable amount of time.

Now consider that none of us are paid to do development on this system, I think I can speak for all the developers here when I say we do it because we enjoy it and understand the potential of the system.  We all have lives we live outside of this particular hobby, and most of us are also working 40+ hours a week, have families, etc.  We're only humans, we can only put in so much time programming, studying, researching, and designing.

That said, I would love to see your expectations of the system met, those are the goals we're all working towards, but your post does not come across as constructive, more like telling us to get our shit together and get busy so that you can profit off of it.  I'm going to suggest a few alternative approaches that would be more well received by the community here.

1) Contribute to the codebase and help us help you reach your goals, the few of us here that are actively working on the system are willing to help, you can find that time and time again on the forum, in the IRC channel(s), in TRAC, and on the wiki.

2) Make a donation to a developer who has already made significant contributions toward your goals, a nice gesture to say thanks for the work you've put in so far.

3) Test the system, if you have problems, open a TRAC ticket, yes there are some that have sat stagnant for quite some time, but we do look at them, and we are actively resolving those issues.

4) Help us get better documentation in the wiki.  If you solve a problem, search the wiki and add to our existing documentation.  If you find something incorrect in the wiki, correct the information.

5) Jump on the #linuxMCE channel on freenode IRC and help users solve problems they may be having and encourage them to provide feedback.

@Everyone who helps us
There's several ways you can help the project achieve those goals without relying solely on us.  I want to take a time out and thank everyone in this community who is actively helping, helping doesn't have to be in the form of programming, the short list above are also ways that people help us every day.

With that all out of the way, the software is not perfect, far from it in fact, I think we've all been frustrated with it at one time or another.  We find mistakes, we make mistakes, but mistakes are okay because mistakes provide feedback and feedback is how we learn.  Without making mistakes along the way, we'll never reach the goal and vision we all have of what this system can be.

@Anyone who wants to see an improvement
I hope this helps explain the reality of the project, and encourages at least one person to grab a shovel and start digging.


Feature requests & roadmap / Re: Project Natal
« on: November 10, 2010, 08:15:24 pm »
Yep, there are several projects going on currently, most really hit the ground running last night after adafruit released the USB dumps from their analyzer.  There are drivers being developed under several different licenses, and should be firming up soon, there's already several people successfully getting the RGB+D data out of the camera and controlling the motorized base.  Only a matter of time now really.  First thing I'll be doing with it in LinuxMCE is leveraging the noise canceling mics for an MD phone, then onto using the camera as a security sensor.  Jump in, get acquinted with the LinuxMCE codebase, and help out.  I've got several projects going at the moment and this one is not high on my priority list.  We still have a shortage of developers and really appreciate when people pitch in.

Users / Re: Don't ring any phones during sleeping mode?
« on: November 10, 2010, 05:20:57 pm »
Create a ticket and I'll take a look at it, from what I had found in there several months ago I doubt the logic was ever in place to handle it.

Users / Re: Android Touch Orbiter
« on: November 10, 2010, 05:14:04 pm »
We've got 2 touch orbiters source code checked into SVN now.  I'm exploring more advanced features like implementing bluetooth support, etc. (Preliminary code for this is in svn already)  Anyways, had a brainstorm and wanted to get some discussion going.  With Android devices we are able to retrieve the last known location, and have several options for location detection, bluetooth, gps, cell triangulation, and wifi come to mind.  With a little effort we can probably do some cool things with location based scenarios (like the mobile orbiter scenarios when away from home).  I'm thinking it would be cool to levarage something like Google Maps so we can make the home aware of where we are/have been.  I wanted to plant the seed and get some feedback, do you guys think something like this could be useful, what ideas do you have for something like this, etc?

Keep in mind that the original mobile orbiter code was written when phones were not nearly as capable as they are today, we need to do some thorough research and assess what we currently have before making any final development decisions.  I feel that the touch orbiter is a definite step in the right direction, but let's not forget there are lots of other features of the mobile orbiters too, and we have the source code so we can be innovative in this area.

Pages: 1 [2] 3 4 ... 27