16
Installation issues / Re: Broken call routing under 710b4- known issue- has anyone fixed it ?
« on: April 03, 2008, 04:28:17 pm »
the bug was present feb 26, but was fixed shortly thereafter in the svn.linuxmce.org
News:
Rule #1 - Be Patient - Rule #2 - Don't ask when, if you don't contribute - Rule #3 - You have coding skills - LinuxMCE's small brother is available: http://www.agocontrol.com
LinuxMCE sponsor
open.home.automation
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.
17
Developers / Re: Trying to understand audio/video pipes concept (have problem with Marantz A/
« on: March 28, 2008, 03:59:45 pm »
I think you're using this in a different way than it was intended. The intent was that you can have a few source devices connected to a multi-zone receiver, like, say a CD player, and then you can use those source devices in ANY place where you have an output zone. The idea was to have each source device go to multiple output zones. I always tested it using only generic source devices (cable boxes, cd players, etc.) not with a media director, because I media director was always put in a single entertainment area.
Now it sounds like what you're doing is you want 2 media directors connected to the same multi-zone receiver, where 1 md goes to, say the living room (zone 1), and the other md goes to say, the bedroom (zone 2).
I'm not sure how to do this because I the multi-zone receiver I have, a Yamaha, doesn't work like this. You can have multiple md's connected to multiple inputs, of course, but any md can go to any output. In other words, if md 1 is on input 'video 1', and md 2 is on input 'video 2', then you can have zone 1 play video 1, or zone 1 can play video 2, or zone 2 can play video 1, etc. At least with the Yamaha implementation of multi-zone the concept of having one source that is for zone 1 and another source for zone 2 doesn't exist. Any source goes to any zone. That's why I implemented the multi-zone the way I did where the purpose of the multiple output zones is to share input source devices.
The database schema and framework could easily handle both types of scenarios without any changes, but it would probably require a change in the media plugin code that handles a/v pipes to be aware of both types of usage.
Now it sounds like what you're doing is you want 2 media directors connected to the same multi-zone receiver, where 1 md goes to, say the living room (zone 1), and the other md goes to say, the bedroom (zone 2).
I'm not sure how to do this because I the multi-zone receiver I have, a Yamaha, doesn't work like this. You can have multiple md's connected to multiple inputs, of course, but any md can go to any output. In other words, if md 1 is on input 'video 1', and md 2 is on input 'video 2', then you can have zone 1 play video 1, or zone 1 can play video 2, or zone 2 can play video 1, etc. At least with the Yamaha implementation of multi-zone the concept of having one source that is for zone 1 and another source for zone 2 doesn't exist. Any source goes to any zone. That's why I implemented the multi-zone the way I did where the purpose of the multiple output zones is to share input source devices.
The database schema and framework could easily handle both types of scenarios without any changes, but it would probably require a change in the media plugin code that handles a/v pipes to be aware of both types of usage.
18
Developers / Re: Trying to understand audio/video pipes concept (have problem with Marantz A/
« on: March 27, 2008, 12:51:07 am »
The pipes determine how commands get handed along the chain. Volume commands, for example, follow the audio pipe, so you can send the volume up command to the media director, and it may follow the audio pipe to a receiver, then a/v pre-amp, then an a/v amp. All those devices along the 'audio pipe' get the command.
99% of the time the output pipe isn't used since most devices can only output one thing at a time. However in the case of multi-zone receivers, the output pipe is used since it can output two things as once. Each media stream will cause a certain path along the pipes to be 'active' so the audio/video commands follow the pipes.
99% of the time the output pipe isn't used since most devices can only output one thing at a time. However in the case of multi-zone receivers, the output pipe is used since it can output two things as once. Each media stream will cause a certain path along the pipes to be 'active' so the audio/video commands follow the pipes.
19
Developers / Re: Are Java geeks welcome here?
« on: March 24, 2008, 04:51:12 pm »
I vaguely remember a Java DCE a while ago to allow Java devices. We're trying to see if we can find where that code went.
I agree that Java could make a huge difference in LinuxMCE with the mobile phone apps. I designed the original 'mobile orbiter' circa 2003 on the Symbian Series 60 platform. It was considered a great killer app. Everybody loved being able to control the system both at home and while away on the mobile phone. And it's become even more important now as oil prices rise and people are thinking more about the need to be 'green', remote control of the home is a really hot topic right now. Instead of leaving the a/c on all day so you return to a cool home, just turn it on 30 minutes prior to your return, etc...
The problem is Symbian Series 60 is dead, and there is no ubiquitous o/s for mobile phones. So if members of the FOSS community want to work on a Java orbiter that runs on a variety of mobile phones, Pluto will provide direct access to our devs and a lot of support since it's very important to us as well.
I agree that Java could make a huge difference in LinuxMCE with the mobile phone apps. I designed the original 'mobile orbiter' circa 2003 on the Symbian Series 60 platform. It was considered a great killer app. Everybody loved being able to control the system both at home and while away on the mobile phone. And it's become even more important now as oil prices rise and people are thinking more about the need to be 'green', remote control of the home is a really hot topic right now. Instead of leaving the a/c on all day so you return to a cool home, just turn it on 30 minutes prior to your return, etc...
The problem is Symbian Series 60 is dead, and there is no ubiquitous o/s for mobile phones. So if members of the FOSS community want to work on a Java orbiter that runs on a variety of mobile phones, Pluto will provide direct access to our devs and a lot of support since it's very important to us as well.
20
Developers / Re: Developer Conference - April 5th
« on: March 24, 2008, 06:05:43 am »
I can join, and so can Chris and Razvan, also from Pluto. I created the database schema, sqlcvs, sql2cpp, dce, dcerouter, HADesigner, the plugins, the packaging system and the earliest Orbiter. Chris is our most senior C++ developer, working on it for 4 years, and he has been responsible for Orbiter since the early days, did the OpenGL, Symbian, Cisco ports, the screen saver, and most of the fixes to the framework over the past couple years. Neither Chris nor I know that much about Linux internals, bash, etc. Razvan does all that Linux work, including kernel patches, scripts, the installation and setup process, configuration, etc. I am in GMT-8, Chris and Razvan are in GMT+2. It seems that meetings around 16:00 GMT work well since that way it's close to normal working hours for the Americas and Europe.
21
Developers / Re: March 29 - 12:00N EDT - HADesigner Workshop
« on: March 15, 2008, 09:38:02 pm »
That's great news. Pluto will donate $100 to cover the cost so you don't need to solicit donations.
HADesigner is a bit of an embarrassment. I wrote it in 2002. The code is scarce and simple; it only took 2 weeks to develop. It was the only time I ever tried to use C#, so it had a bunch of bugs and irregular code. It was written in a rush just to get some quick UI running on a touch-screen web pad so we could start coding the 'meat' of Pluto. We expected that once the devs got going on Pluto, we'd develop a real design tool and throw away HADesigner. So, it was just a quick temporary 'hack' that nobody expected to be used for more than a couple months. It's been 5 years and nobody's touched Designer or fixed any of the bugs; since it somehow sort of fit the need, there were always other tasks that took on a higher priority, and we never wanted to invest time fixing Designer since it's always been perceived as a temporary hack.
One of the other big reasons for not rewriting HADesigner was that when we did develop the 'real' design tool, we wanted to be sure to do it right, and despite all our brainstorming, we've never quite decided what is the 'right' way. We always thought the right solution would be something like Macromedia's Flash design suite that allows the designer to create virtually any type of UI with all the eye candy he wants to include and any type of interaction model. The problem is, last time we looked, Flash and all similar tools didn't support the fundamental concepts of embedding, inheritance, and variations like designer.
Case in point: There may be 100 screens that embed a standard navigation cluster (play, pause, stop). You don't want to recreate that cluster on all 100 screens; you want embedding: create it once, and then on every remote embed that cluster on each of the 100 screens. Next the cluster and the buttons in it all need to behave differently on different target platforms or with different skins. If you just want to change the look of the 'play' button for a certain skin, you don't want to have recreate all the commands and the other stuff on the play button; just change what needs to change the other properties are inherited. And there are different variations for different target platforms. Maybe on the Cisco UI we have dedicated one of the physical buttons to be 'play', so the "navigation cluster" should only have stop and pause. On a mobile phone, they may be shortcuts for soft keys. On a touchscreen, big buttons to touch. On an OSD, invisible elements bound to buttons on the remote control. On a PDA, they may be a vertical cluster and not horizontal. This is fundamentally different from Flash and the other tools which have the goal of making a given UI look identical on each platform; it's easier to create a design tool since what you see in the design tool is what you get no matter the platform. In our case, we want the opposite; the UI should look and behave completely differently on different platforms with totally different interaction methods, but while still inheriting and reusing the existing objects so each time you create a new platform you don't need to recreate all 5,000 elements in the UI from scratch.
We had a mini UI3 conference in January to brainstorm solutions. But, we spent a lot of time discussing licensing and other issues. Also, none of the participants knew HADesigner. Although the implementation in HADesigner is awful, it sort of does what we need it to for this type of app; it has embedding, inheritance and variations. What will be helpful with this Workshop is that if more people know how Designer works who also know how 'real' design tools work, then maybe we can find the right solution for next gen UI3 which includes the elements of HADesigner we need to preserve, but does it right. Pluto will sponsor this.
Aaron
HADesigner is a bit of an embarrassment. I wrote it in 2002. The code is scarce and simple; it only took 2 weeks to develop. It was the only time I ever tried to use C#, so it had a bunch of bugs and irregular code. It was written in a rush just to get some quick UI running on a touch-screen web pad so we could start coding the 'meat' of Pluto. We expected that once the devs got going on Pluto, we'd develop a real design tool and throw away HADesigner. So, it was just a quick temporary 'hack' that nobody expected to be used for more than a couple months. It's been 5 years and nobody's touched Designer or fixed any of the bugs; since it somehow sort of fit the need, there were always other tasks that took on a higher priority, and we never wanted to invest time fixing Designer since it's always been perceived as a temporary hack.
One of the other big reasons for not rewriting HADesigner was that when we did develop the 'real' design tool, we wanted to be sure to do it right, and despite all our brainstorming, we've never quite decided what is the 'right' way. We always thought the right solution would be something like Macromedia's Flash design suite that allows the designer to create virtually any type of UI with all the eye candy he wants to include and any type of interaction model. The problem is, last time we looked, Flash and all similar tools didn't support the fundamental concepts of embedding, inheritance, and variations like designer.
Case in point: There may be 100 screens that embed a standard navigation cluster (play, pause, stop). You don't want to recreate that cluster on all 100 screens; you want embedding: create it once, and then on every remote embed that cluster on each of the 100 screens. Next the cluster and the buttons in it all need to behave differently on different target platforms or with different skins. If you just want to change the look of the 'play' button for a certain skin, you don't want to have recreate all the commands and the other stuff on the play button; just change what needs to change the other properties are inherited. And there are different variations for different target platforms. Maybe on the Cisco UI we have dedicated one of the physical buttons to be 'play', so the "navigation cluster" should only have stop and pause. On a mobile phone, they may be shortcuts for soft keys. On a touchscreen, big buttons to touch. On an OSD, invisible elements bound to buttons on the remote control. On a PDA, they may be a vertical cluster and not horizontal. This is fundamentally different from Flash and the other tools which have the goal of making a given UI look identical on each platform; it's easier to create a design tool since what you see in the design tool is what you get no matter the platform. In our case, we want the opposite; the UI should look and behave completely differently on different platforms with totally different interaction methods, but while still inheriting and reusing the existing objects so each time you create a new platform you don't need to recreate all 5,000 elements in the UI from scratch.
We had a mini UI3 conference in January to brainstorm solutions. But, we spent a lot of time discussing licensing and other issues. Also, none of the participants knew HADesigner. Although the implementation in HADesigner is awful, it sort of does what we need it to for this type of app; it has embedding, inheritance and variations. What will be helpful with this Workshop is that if more people know how Designer works who also know how 'real' design tools work, then maybe we can find the right solution for next gen UI3 which includes the elements of HADesigner we need to preserve, but does it right. Pluto will sponsor this.
Aaron
22
Developers / Re: How to make proper template for multichannel audio receivers (MArantz as exa
« on: March 12, 2008, 07:03:45 am »
How is this different from the Yamaha (device template for a/v receiver with rs232 control)? I have a Yamaha receiver, which also has multiple output zones, and the template worked ok last time I tried it; admittedly a while ago since I don't use the Zone 2 outputs regularly. But it did show up as a separate entertainment area/zone as I recall. As I remember, I did something like put the main zone in the living room, and the 2nd zone in the kitchen. Then in the kitchen if I choose 'cable/sat', it turned on the cable/sat box and fed it out zone 2, and in the living room if I choose to play media on my md, or listen to fm, it would come out zone 1.
23
Developers / Re: ZWave API
« on: February 13, 2008, 07:50:23 pm »
>> sent commands to the device with his own software and the new driver
I had been making the assumption that the 'new driver/software' was basically just for the usb->rs232 chip, so the kernel would see the dongle and add it as a ttyUSB
My logs show this (this has the new kernel module for ttyUSB, but uses the existing ZWave software)
35 02/13/08 7:09:48.826 ++++++++++++ ZWave is connected <0x2b66ed2f1b40>
36 02/13/08 7:09:48.826 ### Run Current Job <0x41802950>
36 02/13/08 7:09:48.882 SerialConnection::send lock serial mutex <0x41802950>
35 02/13/08 7:09:48.882 SerialConnection::send len = 2 buf = 0x00 0x15 <0x41802950>
36 02/13/08 7:09:48.882 SerialConnection::send unlock serial mutex <0x41802950>
05 02/13/08 7:09:53.026 ### Go to timeout queue <0x41802950>
05 02/13/08 7:09:53.026 ### execute the next job from timeout queue <0x41802950>
05 02/13/08 7:09:53.026 ZWJobInitialize::timeoutHandler <0x41802950>
36 02/13/08 7:09:53.082 SerialConnection::send lock serial mutex <0x41802950>
35 02/13/08 7:09:53.082 SerialConnection::send len = 2 buf = 0x00 0x15 <0x41802950>
36 02/13/08 7:09:53.082 SerialConnection::send unlock serial mutex <0x41802950>
05 02/13/08 7:09:58.010 ### Go to timeout queue <0x41802950>
05 02/13/08 7:09:58.010 ### execute the next job from timeout queue <0x41802950>
05 02/13/08 7:09:58.010 ZWJobInitialize::timeoutHandler <0x41802950>
36 02/13/08 7:09:58.066 SerialConnection::send lock serial mutex <0x41802950>
35 02/13/08 7:09:58.066 SerialConnection::send len = 2 buf = 0x00 0x15 <0x41802950>
36 02/13/08 7:09:58.066 SerialConnection::send unlock serial mutex <0x41802950>
35 02/13/08 7:09:58.290 size too small 1 <0x41802950>
.... repeats ....
35 02/13/08 7:10:03.050 size too small 1 <0x41802950>
05 02/13/08 7:10:03.050 ### Go to timeout queue <0x41802950>
05 02/13/08 7:10:03.050 ### skip the next job from timeout queue <0x41802950>
35 02/13/08 7:10:03.050 ----- INIT ---- 1 <0x41802950>
35 02/13/08 7:10:03.050 ----- INIT ---- 2 <0x41802950>
35 02/13/08 7:10:03.050 -------- 3 <0x2b66ed2f1b40>
35 02/13/08 7:10:03.050 SerialConnection ------------- asa 1 <0x2b66ed2f1b40>
35 02/13/08 7:10:03.154 SerialConnection ------------- asa 2 <0x2b66ed2f1b40>
36 02/13/08 7:10:03.154 waiting for thread to finish <0x2b66ed2f1b40>
35 02/13/08 7:10:03.154 exit receiveFunction : nr. of reads 47 <0x41001950>
36 02/13/08 7:10:03.167 thread finished <0x2b66ed2f1b40>
35 02/13/08 7:10:03.167 SerialConnection ------------- asa 3 <0x2b66ed2f1b40>
35 02/13/08 7:10:03.167 SerialConnection ------------- asa 4 <0x2b66ed2f1b40>
35 02/13/08 7:10:03.167 -------- 4 <0x2b66ed2f1b40>
10 02/13/08 7:10:03.168 Socket::SendMessage type 5 id 37 from 63 to -1000 <0x2b66ed2f1b40>
10 02/13/08 7:10:03.196 TranslateSerialUSB found /sys/devices/pci0000:00/0000:00:04.0/usb2/2-1/2-1:1.0/ttyUSB1/ttyUSB1, returning /dev/ttyUSB1 <0x2b66ed2f1b40>
36 02/13/08 7:10:03.196 Using serial port: ttyUSB1. <0x2b66ed2f1b40>
36 02/13/08 7:10:03.207 SerialConnection::connect init serial mutex <0x2b66ed2f1b40>
I had been making the assumption that the 'new driver/software' was basically just for the usb->rs232 chip, so the kernel would see the dongle and add it as a ttyUSB
- entry, but that once that happened, the serial protocol to talk to the device was the same and the existing ZWave binary would be used. Is that a misunderstanding? Have you and cyr been developing your own replacement for the existing ZWave binary? Maybe the 3 of us (4 if we get Daniel in) could talk about this on Skype or something. This is relevant for us since the programmer at Pluto who wrote the ZWave module originally is not with us anymore, and there's some new ZWave features we need implemented, and maybe we can get you guys some equipment if you're working on ZWave drivers.
My logs show this (this has the new kernel module for ttyUSB, but uses the existing ZWave software)
35 02/13/08 7:09:48.826 ++++++++++++ ZWave is connected <0x2b66ed2f1b40>
36 02/13/08 7:09:48.826 ### Run Current Job <0x41802950>
36 02/13/08 7:09:48.882 SerialConnection::send lock serial mutex <0x41802950>
35 02/13/08 7:09:48.882 SerialConnection::send len = 2 buf = 0x00 0x15 <0x41802950>
36 02/13/08 7:09:48.882 SerialConnection::send unlock serial mutex <0x41802950>
05 02/13/08 7:09:53.026 ### Go to timeout queue <0x41802950>
05 02/13/08 7:09:53.026 ### execute the next job from timeout queue <0x41802950>
05 02/13/08 7:09:53.026 ZWJobInitialize::timeoutHandler <0x41802950>
36 02/13/08 7:09:53.082 SerialConnection::send lock serial mutex <0x41802950>
35 02/13/08 7:09:53.082 SerialConnection::send len = 2 buf = 0x00 0x15 <0x41802950>
36 02/13/08 7:09:53.082 SerialConnection::send unlock serial mutex <0x41802950>
05 02/13/08 7:09:58.010 ### Go to timeout queue <0x41802950>
05 02/13/08 7:09:58.010 ### execute the next job from timeout queue <0x41802950>
05 02/13/08 7:09:58.010 ZWJobInitialize::timeoutHandler <0x41802950>
36 02/13/08 7:09:58.066 SerialConnection::send lock serial mutex <0x41802950>
35 02/13/08 7:09:58.066 SerialConnection::send len = 2 buf = 0x00 0x15 <0x41802950>
36 02/13/08 7:09:58.066 SerialConnection::send unlock serial mutex <0x41802950>
35 02/13/08 7:09:58.290 size too small 1 <0x41802950>
.... repeats ....
35 02/13/08 7:10:03.050 size too small 1 <0x41802950>
05 02/13/08 7:10:03.050 ### Go to timeout queue <0x41802950>
05 02/13/08 7:10:03.050 ### skip the next job from timeout queue <0x41802950>
35 02/13/08 7:10:03.050 ----- INIT ---- 1 <0x41802950>
35 02/13/08 7:10:03.050 ----- INIT ---- 2 <0x41802950>
35 02/13/08 7:10:03.050 -------- 3 <0x2b66ed2f1b40>
35 02/13/08 7:10:03.050 SerialConnection ------------- asa 1 <0x2b66ed2f1b40>
35 02/13/08 7:10:03.154 SerialConnection ------------- asa 2 <0x2b66ed2f1b40>
36 02/13/08 7:10:03.154 waiting for thread to finish <0x2b66ed2f1b40>
35 02/13/08 7:10:03.154 exit receiveFunction : nr. of reads 47 <0x41001950>
36 02/13/08 7:10:03.167 thread finished <0x2b66ed2f1b40>
35 02/13/08 7:10:03.167 SerialConnection ------------- asa 3 <0x2b66ed2f1b40>
35 02/13/08 7:10:03.167 SerialConnection ------------- asa 4 <0x2b66ed2f1b40>
35 02/13/08 7:10:03.167 -------- 4 <0x2b66ed2f1b40>
10 02/13/08 7:10:03.168 Socket::SendMessage type 5 id 37 from 63 to -1000 <0x2b66ed2f1b40>
10 02/13/08 7:10:03.196 TranslateSerialUSB found /sys/devices/pci0000:00/0000:00:04.0/usb2/2-1/2-1:1.0/ttyUSB1/ttyUSB1, returning /dev/ttyUSB1 <0x2b66ed2f1b40>
36 02/13/08 7:10:03.196 Using serial port: ttyUSB1. <0x2b66ed2f1b40>
36 02/13/08 7:10:03.207 SerialConnection::connect init serial mutex <0x2b66ed2f1b40>
24
Developers / Re: ZWave API
« on: February 13, 2008, 06:37:36 pm »
We're doing testing for the 0710 release and trying to be sure it works with the ACT ZCU101 (the pyramid shaped zwave usb) because this is the model currently sold, and the only zwave dongle in 0704 doesn't work. I know some new kernel modules were added by Hari, I believe, and now the ZCU101 is detected, and gets a ttyUSB interface. However the ZWave software still can't talk to it. Has anybody had any success with it?
25
Developers / Re: Supporting the ACT Solutions ZCU201 USB Z-wave Interface
« on: January 31, 2008, 10:57:38 pm »
Thanks a lot, Hari! Since those old ACT ZWave controllers aren't sold anymore, this is pretty important. I just got one of the controllers and we're going to test it and try to make it work for the 0710 release.
26
Developers / Re: Current Status of Insteon PLM Integration
« on: January 22, 2008, 11:07:26 pm »
Regarding: GSD is ignoring command because it's useless...
Unfortunately this code inside GSD is kind of hard to get to and follow. But basically what it's for is if you send the same on or off command repeatedly it only does it once. This was supposed to be done for i/r devices with toggle power (ie if you send 2 off's, and they're toggle power, the 2nd one will actually turn it on, so gsd needs to ignore it). There's a parameter you can add to the on or off command to force it to send it again. I think it's "retransmit" or something. I'd need to look in the code again. You can see it if you use the orbiter and when media is playing choose the option to resend i/r codes. You'll see when you hit the device name, the on command is sent with a retransmit, since presumably the first one didn't go through.
GSD should probably check for a device data and not ignore repeat on/off's if some device data is set.
As far as the events, look in the Lighting_Plugin.cpp code (it runs on the DCERouter as a plugin). You'll see it intercepts some commands and events. I don't recall how it works: I think it intercepts on/off/set level commands going to lights, and that the 'device on/off' events aren't used.
Unfortunately this code inside GSD is kind of hard to get to and follow. But basically what it's for is if you send the same on or off command repeatedly it only does it once. This was supposed to be done for i/r devices with toggle power (ie if you send 2 off's, and they're toggle power, the 2nd one will actually turn it on, so gsd needs to ignore it). There's a parameter you can add to the on or off command to force it to send it again. I think it's "retransmit" or something. I'd need to look in the code again. You can see it if you use the orbiter and when media is playing choose the option to resend i/r codes. You'll see when you hit the device name, the on command is sent with a retransmit, since presumably the first one didn't go through.
GSD should probably check for a device data and not ignore repeat on/off's if some device data is set.
As far as the events, look in the Lighting_Plugin.cpp code (it runs on the DCERouter as a plugin). You'll see it intercepts some commands and events. I don't recall how it works: I think it intercepts on/off/set level commands going to lights, and that the 'device on/off' events aren't used.
27
Developers / Re: UI3 Discussion
« on: January 17, 2008, 07:45:49 am »
I had a nice chat with Matthew. One thing that's clear is perhaps I didn't correctly state what I meant by needing a UI with object oriented properties, like inheritance. Here's a real world example...
1. Someone is creating a new screen in the design tool. In the tool, there exists style sheets with all the font styles. The style "Mid-size button" is defined as Times Roman 10 point. I create a button called 'play'. It has a blue background that pulsates with an animated effect 3 times per second, and has the text "PLAY" on top of it in that "Mid-size button" style. I cluster this together with a "pause" and "stop" button in a container called "Media Controls".
2. A different designer doesn't like the blue background, and instead wants something with wood grain. He doesn't want to recreate the screen, or change the layout or have to duplicate the commands associated with the buttons. Just change the background. So, he creates a new skin called 'wood' in the design tool, and creates a wood grain bitmap, and in the design tool associates this new bitmap with the skin. Now, when the user selects the 'wood' skin he sees the same button with 'play' in Times Roman 10 point, but the background is wood grain. The only thing is the pulsating animated effect doesn't look good on top of the wood, so he chooses another effect called "scroll" which makes the background wood grain image scroll a bit. There may be 100 buttons the original designer created with the blue background and the pulsating effect. This designer shouldn't have to open the properties for each button one at a time, he should be able to make a global change that says for this new skin, use this wood grain bitmap and scroll effect instead.
3. Now there's a user running the UI on a PDA. He finds that with the original blue skin it looks ok except that the pulsating effect is using all the cpu, and with the wood skin, the scrolling is just too much for the pda. So he opens the 'play' button in the design tool, clicks on the 'effects' tab, chooses the 'blue' skin and sees the 'pulsate' effect, he clicks 'criteria' and under "target device" selects "PDA", and then moves to the property field "times per second" and changes it from 3 to 1 so it goes slower on the pda. Then he chooses the 'wood' skin, again sets the criteria to 'target device=pda', and this time sets 'effect' to 'none'. This doesn't effect either user #1 or #2 since they don't use a pda.
4. Now there's another guy using a Cisco VOIP phone. He sees that on his phone all the effects are too much for the phone and need to be disabled. And although the 'Times Roman 10 point' text is legible with the 'blue' skin, when he choose the 'wood' skin which has more contrast, the text is unreadable because the Cisco phone's lcd display isn't that sharp. So, he opens the design tool, selects 'platform = cisco voip phone' and checks off "turn off all effects". Then he opens the style sheet tool and selects the "mid-size button" style, and clicks on "criteria" and sets "skin" = "wood", and changes the font size from 10 point to 12 point. Except, he notices, when the language is German. Then the words are just too big for 12 point font so the user has to live with 10 point, so he edits his criteria and adds to "skin=wood" a "and language<>german".
5. Another user decides he wants to create a new variation called "sideways" that aligns the clusters vertically rather than horizontally. He doesn't want to change any of the other stuff. He just wants to open "Media Controls" cluster, which contains the play/pause/stop buttons in a horizontal group, and he re-arranges them so they are vertical. They retain all their current properties; the play button still pulsates when it's the blue skin, except on the Cisco phone, and the font size is still 12 point instead of 10 with the wood skin on a cisco phone. It's just arranged differently.
Note that whatever file format this master stuff is stored in must be something that supports collaborative development, so different users can make changes to the same object, and then those changes are merged back into the 'master'.
This is how Pluto's current HADesigner works (or at least how it was designed to work). This is what I mean by it's object oriented and objects inherit properties, which you can override based on criteria. There's a criteria builder (it's not very functional, but it's there), so you can build a criteria "skin=wood, device=cisco phone, resolution=less than 640x480". And then you can change the properties of a button for that particular criteria. You can also build a criteria for a text style, so that when 'device=cisco and skin=wood' the font size is 12 point and not 10. The file format for this 'master' definition is an sql database. And sqlcvs was created with HADesigner in mind so that the 5 users described above could all be changing the properties of the 'PLAY' button at the same time and have their changes get merged together. Then, the program OrbiterGen runs which reads the 'master' definition from the sql database, and outputs a .info file which is the native format that Orbiter reads. Orbiter doesn't read the master definition. If you are running Orbiter on a cisco phone with the 'wood' skin, when it reads in the 'play' object, it just sees an object that has no pulsate/scroll effects, and is already scaled for the cisco phone, with the wood background and the word PLAY in 12 point text. OrbiterGen had the responsibility for each object of evaluating the "criteria" to pull out the properties for that object given the target platform, resolution, skin, operating system, ui version, etc.
From a conceptual standpoint, I don't think HADesigner was bad. The idea that everybody could edit the same objects and, without re-creating those objects, just change certain properties for specific situations made sense.
The challenge is that (a) HADesigner just awful to use, and (b) really limited in it's eye candy. All the images are bitmap based (not vector based). You can make them animated by using the MNG format (an animated bitmap, like animated gif), but this hasn't really been used at all. There's a bunch of other ways that it's totally lacking. The only thing I like about it is the concept behind the object properties and the collaboration possibilities.
Now let's say we want to let graphics designers use Adobe's Flash Design tools. It has lots of great widgets for creating pretty objects that are animated, etc. But, if it didn't support the concept of overriding object properties like I described in those 5 examples (which I don't think it does) it would be nearly impossible to create the kind of UI's that we do that target all those platforms. Sure, the objects may have properties and the user could attach action script code which changed them. But having a huge cluster of if statements in action script is not maintainable. If skin=wood and platform=cisco and <blah blah> then object.text.style.pointsize=12; else if skin=blue and <blah> <blah>.. Just for those 5 steps I described above, you'd have dozens and dozens of nested if statements in a mangle of spaghetti code. It would be a nightmare for the flash developers to have to attach hundreds of line of 'if' statements to each of the objects in the UI (there are many thousands). And the developer would go crazy if, for example, every time he wanted to change something for the 'wood' skin he had to edit the action script of 1,000 buttons and add an 'else if skin=wood' to it. And if collaboration would be impossible since you couldn't merge all that action script code; if 5 developers were each working on 5 skins, and all 5 were changing this huge block of nested else if statements, they'd have conflicts for each of the 1,000 buttons. So rather than the design tool giving the user action script for each object, or button, the design tool has to support concepts of styles and properties which are inherited across all objects, with global criteria that you can change properties in one place and it propagates across all objects. And to allow designers to work freely, they shouldn't have to edit code to do this; it should be done wysiwyg in the design tool. I don't know Adobe's Flash designer, but I think that it doesn't work like this.
Also, I'm even sure the SWF file format is by itself sufficient. I'm not sure that the swf format supports the ability to have that criteria/object properties. After all, this isn't what flash and swf were designed for. And, even if the swf format did support this, you probably can't pass that directly to the target render device (ie the Cisco phone). As stated in my example with the 5 steps, to determine what the 'play' button should look like on a cisco phone with the 'wood' skin you have to evaluate a bunch of criteria factors; what the skin is, what the platform is, etc. You don't want the player in the Cisco phone (which has a weak cpu), to have to go through that whole evaluation process to determine what the properties are to display the 'play' button. It would be way too slow. Rather there needs to be some other intermediary process that takes the master file that defines how a play button should work on all the various skins/platforms/languages/etc., and pre-processes the play button for the Cisco UI, pre-scaling any bitmaps, pre-rendering any fonts, etc., so that the player in the Cisco phone just gets the finished 'play' button and doesn't need to do a bunch of complex calculation. This intermediary process is what OrbiterGen currently does. So there would likely still need to be an intermediary program which reads in the master file, evaluates everything, and outputs a pre-rendered/scaled UI for a specific box.
If we wanted to use the swf format, and if the swf format is, as I suspect it is, really targeted for a certain platform/skin, then likely the 'master' format which defines all the objects and which the design tool uses would need to use another format, and this intermediary program that replaces OrbiterGen is what would need to read this master format, evaluate all the criteria for whatever UI it's targeting, and output a generated swf that could be played on it. I think this is similar to what Laszlo does.
So this raises a bunch of issues and questions. What is the design tool? Adobe's Flash Designer is closed source. So unless it did everything we need it to do out of the box we couldn't extend it to suit our needs. Is there another design tool that's really polished and could be extended? Does swf support all the object inheritence we need so that it can be the master format? If so, should we feed that 'master' swf to each UI, even though that master swf defines every criteria for each object, or should we do some pre-processing so each UI just gets an swf that's pre-rendered for it?
Does anybody know if there exists a UI design tool that works like HADesigner does with object criteria/properties/inheritance to target multiple platforms and skins like Pluto does? Is there another way to target all those platforms that doesn't require this approach? If there's no way to get flash to do what we want with the multiple platform stuff, but if flash will let us create an eye-candy rich UI, maybe we need to consider scrapping the idea of having one unified UI/design tool that targets all those platforms and just use flash for the 10' UI on the TV, but leave HADesigner/OrbiterGen/Orbiter as-is for the other platforms like the Cisco phones...
1. Someone is creating a new screen in the design tool. In the tool, there exists style sheets with all the font styles. The style "Mid-size button" is defined as Times Roman 10 point. I create a button called 'play'. It has a blue background that pulsates with an animated effect 3 times per second, and has the text "PLAY" on top of it in that "Mid-size button" style. I cluster this together with a "pause" and "stop" button in a container called "Media Controls".
2. A different designer doesn't like the blue background, and instead wants something with wood grain. He doesn't want to recreate the screen, or change the layout or have to duplicate the commands associated with the buttons. Just change the background. So, he creates a new skin called 'wood' in the design tool, and creates a wood grain bitmap, and in the design tool associates this new bitmap with the skin. Now, when the user selects the 'wood' skin he sees the same button with 'play' in Times Roman 10 point, but the background is wood grain. The only thing is the pulsating animated effect doesn't look good on top of the wood, so he chooses another effect called "scroll" which makes the background wood grain image scroll a bit. There may be 100 buttons the original designer created with the blue background and the pulsating effect. This designer shouldn't have to open the properties for each button one at a time, he should be able to make a global change that says for this new skin, use this wood grain bitmap and scroll effect instead.
3. Now there's a user running the UI on a PDA. He finds that with the original blue skin it looks ok except that the pulsating effect is using all the cpu, and with the wood skin, the scrolling is just too much for the pda. So he opens the 'play' button in the design tool, clicks on the 'effects' tab, chooses the 'blue' skin and sees the 'pulsate' effect, he clicks 'criteria' and under "target device" selects "PDA", and then moves to the property field "times per second" and changes it from 3 to 1 so it goes slower on the pda. Then he chooses the 'wood' skin, again sets the criteria to 'target device=pda', and this time sets 'effect' to 'none'. This doesn't effect either user #1 or #2 since they don't use a pda.
4. Now there's another guy using a Cisco VOIP phone. He sees that on his phone all the effects are too much for the phone and need to be disabled. And although the 'Times Roman 10 point' text is legible with the 'blue' skin, when he choose the 'wood' skin which has more contrast, the text is unreadable because the Cisco phone's lcd display isn't that sharp. So, he opens the design tool, selects 'platform = cisco voip phone' and checks off "turn off all effects". Then he opens the style sheet tool and selects the "mid-size button" style, and clicks on "criteria" and sets "skin" = "wood", and changes the font size from 10 point to 12 point. Except, he notices, when the language is German. Then the words are just too big for 12 point font so the user has to live with 10 point, so he edits his criteria and adds to "skin=wood" a "and language<>german".
5. Another user decides he wants to create a new variation called "sideways" that aligns the clusters vertically rather than horizontally. He doesn't want to change any of the other stuff. He just wants to open "Media Controls" cluster, which contains the play/pause/stop buttons in a horizontal group, and he re-arranges them so they are vertical. They retain all their current properties; the play button still pulsates when it's the blue skin, except on the Cisco phone, and the font size is still 12 point instead of 10 with the wood skin on a cisco phone. It's just arranged differently.
Note that whatever file format this master stuff is stored in must be something that supports collaborative development, so different users can make changes to the same object, and then those changes are merged back into the 'master'.
This is how Pluto's current HADesigner works (or at least how it was designed to work). This is what I mean by it's object oriented and objects inherit properties, which you can override based on criteria. There's a criteria builder (it's not very functional, but it's there), so you can build a criteria "skin=wood, device=cisco phone, resolution=less than 640x480". And then you can change the properties of a button for that particular criteria. You can also build a criteria for a text style, so that when 'device=cisco and skin=wood' the font size is 12 point and not 10. The file format for this 'master' definition is an sql database. And sqlcvs was created with HADesigner in mind so that the 5 users described above could all be changing the properties of the 'PLAY' button at the same time and have their changes get merged together. Then, the program OrbiterGen runs which reads the 'master' definition from the sql database, and outputs a .info file which is the native format that Orbiter reads. Orbiter doesn't read the master definition. If you are running Orbiter on a cisco phone with the 'wood' skin, when it reads in the 'play' object, it just sees an object that has no pulsate/scroll effects, and is already scaled for the cisco phone, with the wood background and the word PLAY in 12 point text. OrbiterGen had the responsibility for each object of evaluating the "criteria" to pull out the properties for that object given the target platform, resolution, skin, operating system, ui version, etc.
From a conceptual standpoint, I don't think HADesigner was bad. The idea that everybody could edit the same objects and, without re-creating those objects, just change certain properties for specific situations made sense.
The challenge is that (a) HADesigner just awful to use, and (b) really limited in it's eye candy. All the images are bitmap based (not vector based). You can make them animated by using the MNG format (an animated bitmap, like animated gif), but this hasn't really been used at all. There's a bunch of other ways that it's totally lacking. The only thing I like about it is the concept behind the object properties and the collaboration possibilities.
Now let's say we want to let graphics designers use Adobe's Flash Design tools. It has lots of great widgets for creating pretty objects that are animated, etc. But, if it didn't support the concept of overriding object properties like I described in those 5 examples (which I don't think it does) it would be nearly impossible to create the kind of UI's that we do that target all those platforms. Sure, the objects may have properties and the user could attach action script code which changed them. But having a huge cluster of if statements in action script is not maintainable. If skin=wood and platform=cisco and <blah blah> then object.text.style.pointsize=12; else if skin=blue and <blah> <blah>.. Just for those 5 steps I described above, you'd have dozens and dozens of nested if statements in a mangle of spaghetti code. It would be a nightmare for the flash developers to have to attach hundreds of line of 'if' statements to each of the objects in the UI (there are many thousands). And the developer would go crazy if, for example, every time he wanted to change something for the 'wood' skin he had to edit the action script of 1,000 buttons and add an 'else if skin=wood' to it. And if collaboration would be impossible since you couldn't merge all that action script code; if 5 developers were each working on 5 skins, and all 5 were changing this huge block of nested else if statements, they'd have conflicts for each of the 1,000 buttons. So rather than the design tool giving the user action script for each object, or button, the design tool has to support concepts of styles and properties which are inherited across all objects, with global criteria that you can change properties in one place and it propagates across all objects. And to allow designers to work freely, they shouldn't have to edit code to do this; it should be done wysiwyg in the design tool. I don't know Adobe's Flash designer, but I think that it doesn't work like this.
Also, I'm even sure the SWF file format is by itself sufficient. I'm not sure that the swf format supports the ability to have that criteria/object properties. After all, this isn't what flash and swf were designed for. And, even if the swf format did support this, you probably can't pass that directly to the target render device (ie the Cisco phone). As stated in my example with the 5 steps, to determine what the 'play' button should look like on a cisco phone with the 'wood' skin you have to evaluate a bunch of criteria factors; what the skin is, what the platform is, etc. You don't want the player in the Cisco phone (which has a weak cpu), to have to go through that whole evaluation process to determine what the properties are to display the 'play' button. It would be way too slow. Rather there needs to be some other intermediary process that takes the master file that defines how a play button should work on all the various skins/platforms/languages/etc., and pre-processes the play button for the Cisco UI, pre-scaling any bitmaps, pre-rendering any fonts, etc., so that the player in the Cisco phone just gets the finished 'play' button and doesn't need to do a bunch of complex calculation. This intermediary process is what OrbiterGen currently does. So there would likely still need to be an intermediary program which reads in the master file, evaluates everything, and outputs a pre-rendered/scaled UI for a specific box.
If we wanted to use the swf format, and if the swf format is, as I suspect it is, really targeted for a certain platform/skin, then likely the 'master' format which defines all the objects and which the design tool uses would need to use another format, and this intermediary program that replaces OrbiterGen is what would need to read this master format, evaluate all the criteria for whatever UI it's targeting, and output a generated swf that could be played on it. I think this is similar to what Laszlo does.
So this raises a bunch of issues and questions. What is the design tool? Adobe's Flash Designer is closed source. So unless it did everything we need it to do out of the box we couldn't extend it to suit our needs. Is there another design tool that's really polished and could be extended? Does swf support all the object inheritence we need so that it can be the master format? If so, should we feed that 'master' swf to each UI, even though that master swf defines every criteria for each object, or should we do some pre-processing so each UI just gets an swf that's pre-rendered for it?
Does anybody know if there exists a UI design tool that works like HADesigner does with object criteria/properties/inheritance to target multiple platforms and skins like Pluto does? Is there another way to target all those platforms that doesn't require this approach? If there's no way to get flash to do what we want with the multiple platform stuff, but if flash will let us create an eye-candy rich UI, maybe we need to consider scrapping the idea of having one unified UI/design tool that targets all those platforms and just use flash for the 10' UI on the TV, but leave HADesigner/OrbiterGen/Orbiter as-is for the other platforms like the Cisco phones...
28
Developers / Re: UI3 Discussion
« on: January 17, 2008, 02:49:03 am »
Matthew, That's great. I sent a private email to you about joining the meeting. My email is aaron.b [at] plutohome (dot) com
I also contacted Rob Savoy, lead dev of Gnash, and have invited him. We already exchanged emails and he sounds interested. We might be able to get him to work with us on this.
I also contacted Rob Savoy, lead dev of Gnash, and have invited him. We already exchanged emails and he sounds interested. We might be able to get him to work with us on this.
29
Developers / Re: UI3 Discussion
« on: January 16, 2008, 09:12:38 pm »
I'll divide my comments in 3 parts: 1) the design tool, 2) the player, 3) financial issues. Both the design tool and the player are *almost* what we need, but, lacking in a couple areas.
--Design tool--
I really would like to find a way to somehow base this on Flash because it will be impossible to reinvent Flash's design suite. I have never used it, but just from looking at the demo video on Adobe.com, it is clearly a very rich, robust, polished design suite that allows the designer to create gorgeous UI's that do almost anything with sophisticated illustration and 3d tools. The thought of us saying "Let's rebuild something that's as good as Adobe's flash designer" is daunting; that software was 10 years in the making with hundreds of full time developers. We just can't make something as elegant as it. And we'll never be able to reproduce having tens of thousands of developers who know it intimately so they can create cool eye candy effects in our UI.
The one area that Adobe's design tools may be lacking in (I don't know for sure) is the cross-platform stuff. Pluto's HADesigner is crude as can be, but, it was designed to target lots of platforms. For example, the 'play' button in UI1 on windows ce pda, and the 'play' button in UI2 on the TV, as well as on the Cisco phone and mobile phone, are actually all the same object. You just assign different attributes for each of the variations (like object oriented inheritance), so you can make it be animated and round on a more powerful box, and a small static square on a mobile phone. You can also cluster the 'play/pause/stop' buttons into a 'media playback group', and say that the group itself is also different on a tv vs. a mobile phone (ie object containers). Then, when you're creating a media remote control, you just drop the 'media playback group' on the screen and whether you're using a mobile phone or a tv it still works. I'm not sure if Adobe's flash designer is object oriented like that, supporting inheritance and overrides, so you can create, say, a button that looks and behaves differently on various platforms. I've never seen Flash used like this; the general goal of flash is the opposite: to have a player that renders the flash file exactly the same on all platforms, rather than having one UI that behaves differently on the different platforms.
While this may be a weakness, it's not necessarily a deal breaker since, after all, if Flash designer is not object oriented with inheritence, the person designing the UI could work around this by just creating separate flash files for the mobile phone, the pda, the cisco phone, the TV, etc. Most designers would probably prefer to create 5 UI's using Adobe's flash designer vs. 1 UI with Pluto's HADesigner because our HADesigner is that bad and it's unlikely we'd have the manpower to create something that rivaled Adobe's flash designer.
The other thing I'm not sure of is how well flash scales. In general all the flash files I've seen are created for a target resolution (say 800x600). With Pluto's HADesigner, OrbiterGen scales the UI to any resolution, rotates it (ie some devices are vertical not horizontal), and stretches it (16:9 vs. 3:4). This would be a big deal breaker if Flash couldn't do this because, although we could tell designers they need to create 5 different UI's for all the target platforms, telling them to create each of those 50 times (5 UI's at 10 different resolutions) would be ridiculous. If they wanted to change the command the 'play' button sent, rather than doing it in 1 place like you do with HADesigner, you'd have to make the same change to 50 UI's if Flash didn't support scaling/rotating/stretching and didn't support object oriented inheritance with overrides.
--Player--
Here what's basically lacking is the ability to blend 2 different applications together. Flash is designed to work stand alone, not bolt on top of and blend into something else. We're looking for a UI that can bolt on top of MythTV, or Xine, or MPlayer, or Firefox (for a 10' web browser), etc. If, however, we commit to using Adobe's flash designer as a back end, then that means we've committed to the flash file format and we're better off to put resources into adding the alpha blending capabilty to something that already plays back flash files, like Gnash, than to start from scratch reinventing a flash player.
--Financial Model--
Here is where it gets tricky. Pluto has investors, and when we put in the budget expenses for development, we have to show that there's some way that we can at least make enough revenue to cover the expenses, and ideally make a profit, otherwise it's considered throwing money away.
Normally the way companies do this with FOSS is to offer software under the GPL that, in order to be used commercially, needs to link with non-GPL code, and the company then licenses it outside the GPL for this commercial use. For example, with MySQL, the client libraries were originally LGPL, but that meant commercial companies could use them in non-GPL apps without paying a license fee. So, in order to generate revenue, MySQL changed the client libraries to GPL. Trolltech did the same thing with QT. Except for cases where the software is offered b2b as part of support contracts (think SuSe, Asterisk, etc.), which doesn't apply to us, licensing the software outside the GPL for commercial use seems to be the standard way that a company can offer software that is open source for the FOSS community, but that they can still make money for with commercial use.
That was our intention with UI3. We want all the FOSS projects to be able to use it for free under the GPL, since they will release their UI's under the GPL too. But, since we will be hiring a lot of developers for this, and probably sponsoring several more, our justification to our investors for spending that money is to be able to license the same software outside the GPL, like MySql and Trolltech do.
So if the back end design tool is Adobe Flash Designer, and the front end player is either Adobe or Gnash, we have no way to explain why we should invest a lot of money on development. If the approach of using Flash Designer + Gnash was close enough to being a workable solution, or if there were enough volunteers to do the work, then it's not an issue; we don't need a revenue model because we won't need to invest a lot of money in it anyway. However, my gut feeling is that this likely will require a substantial investment because, as an example, MythTV's devs would obviously like to have a UI as pretty as TiVo or Apple or Vista, and if it really was that easy to create a beautiful UI in Flash Designer and bolt it on top of Myth, Xine, MPlayer, etc., then they all would have been doing it already. Since all the media center apps need pretty eye candy UI's, and it seems nobody has figured out how to do it with Flash or some other off the shelf toolset, it would seem to indicate that it's really not so simple and therefore a significant investment will be required to make it happen. If that's the case, then perhaps the only way we could get approval on the investment is to develop everything from scratch so we could hold the licensing rights. But as a developer myself, the last thing I want to do is rewrite code or reinvent something that's already done and working, and I'd much rather start with something that exists.
What would be great is if we could get some people involved in the discussion on the 19th who know Flash, Gnash and the other existing software really well so they can let us know what exists already and how much work would be required to make it work for UI3. If these devs are free on the 19th and, ideally, not too far from California, Pluto will cover the cost of bringing them over. If not, we plan to setup a web cam conference anyway.
--Design tool--
I really would like to find a way to somehow base this on Flash because it will be impossible to reinvent Flash's design suite. I have never used it, but just from looking at the demo video on Adobe.com, it is clearly a very rich, robust, polished design suite that allows the designer to create gorgeous UI's that do almost anything with sophisticated illustration and 3d tools. The thought of us saying "Let's rebuild something that's as good as Adobe's flash designer" is daunting; that software was 10 years in the making with hundreds of full time developers. We just can't make something as elegant as it. And we'll never be able to reproduce having tens of thousands of developers who know it intimately so they can create cool eye candy effects in our UI.
The one area that Adobe's design tools may be lacking in (I don't know for sure) is the cross-platform stuff. Pluto's HADesigner is crude as can be, but, it was designed to target lots of platforms. For example, the 'play' button in UI1 on windows ce pda, and the 'play' button in UI2 on the TV, as well as on the Cisco phone and mobile phone, are actually all the same object. You just assign different attributes for each of the variations (like object oriented inheritance), so you can make it be animated and round on a more powerful box, and a small static square on a mobile phone. You can also cluster the 'play/pause/stop' buttons into a 'media playback group', and say that the group itself is also different on a tv vs. a mobile phone (ie object containers). Then, when you're creating a media remote control, you just drop the 'media playback group' on the screen and whether you're using a mobile phone or a tv it still works. I'm not sure if Adobe's flash designer is object oriented like that, supporting inheritance and overrides, so you can create, say, a button that looks and behaves differently on various platforms. I've never seen Flash used like this; the general goal of flash is the opposite: to have a player that renders the flash file exactly the same on all platforms, rather than having one UI that behaves differently on the different platforms.
While this may be a weakness, it's not necessarily a deal breaker since, after all, if Flash designer is not object oriented with inheritence, the person designing the UI could work around this by just creating separate flash files for the mobile phone, the pda, the cisco phone, the TV, etc. Most designers would probably prefer to create 5 UI's using Adobe's flash designer vs. 1 UI with Pluto's HADesigner because our HADesigner is that bad and it's unlikely we'd have the manpower to create something that rivaled Adobe's flash designer.
The other thing I'm not sure of is how well flash scales. In general all the flash files I've seen are created for a target resolution (say 800x600). With Pluto's HADesigner, OrbiterGen scales the UI to any resolution, rotates it (ie some devices are vertical not horizontal), and stretches it (16:9 vs. 3:4). This would be a big deal breaker if Flash couldn't do this because, although we could tell designers they need to create 5 different UI's for all the target platforms, telling them to create each of those 50 times (5 UI's at 10 different resolutions) would be ridiculous. If they wanted to change the command the 'play' button sent, rather than doing it in 1 place like you do with HADesigner, you'd have to make the same change to 50 UI's if Flash didn't support scaling/rotating/stretching and didn't support object oriented inheritance with overrides.
--Player--
Here what's basically lacking is the ability to blend 2 different applications together. Flash is designed to work stand alone, not bolt on top of and blend into something else. We're looking for a UI that can bolt on top of MythTV, or Xine, or MPlayer, or Firefox (for a 10' web browser), etc. If, however, we commit to using Adobe's flash designer as a back end, then that means we've committed to the flash file format and we're better off to put resources into adding the alpha blending capabilty to something that already plays back flash files, like Gnash, than to start from scratch reinventing a flash player.
--Financial Model--
Here is where it gets tricky. Pluto has investors, and when we put in the budget expenses for development, we have to show that there's some way that we can at least make enough revenue to cover the expenses, and ideally make a profit, otherwise it's considered throwing money away.
Normally the way companies do this with FOSS is to offer software under the GPL that, in order to be used commercially, needs to link with non-GPL code, and the company then licenses it outside the GPL for this commercial use. For example, with MySQL, the client libraries were originally LGPL, but that meant commercial companies could use them in non-GPL apps without paying a license fee. So, in order to generate revenue, MySQL changed the client libraries to GPL. Trolltech did the same thing with QT. Except for cases where the software is offered b2b as part of support contracts (think SuSe, Asterisk, etc.), which doesn't apply to us, licensing the software outside the GPL for commercial use seems to be the standard way that a company can offer software that is open source for the FOSS community, but that they can still make money for with commercial use.
That was our intention with UI3. We want all the FOSS projects to be able to use it for free under the GPL, since they will release their UI's under the GPL too. But, since we will be hiring a lot of developers for this, and probably sponsoring several more, our justification to our investors for spending that money is to be able to license the same software outside the GPL, like MySql and Trolltech do.
So if the back end design tool is Adobe Flash Designer, and the front end player is either Adobe or Gnash, we have no way to explain why we should invest a lot of money on development. If the approach of using Flash Designer + Gnash was close enough to being a workable solution, or if there were enough volunteers to do the work, then it's not an issue; we don't need a revenue model because we won't need to invest a lot of money in it anyway. However, my gut feeling is that this likely will require a substantial investment because, as an example, MythTV's devs would obviously like to have a UI as pretty as TiVo or Apple or Vista, and if it really was that easy to create a beautiful UI in Flash Designer and bolt it on top of Myth, Xine, MPlayer, etc., then they all would have been doing it already. Since all the media center apps need pretty eye candy UI's, and it seems nobody has figured out how to do it with Flash or some other off the shelf toolset, it would seem to indicate that it's really not so simple and therefore a significant investment will be required to make it happen. If that's the case, then perhaps the only way we could get approval on the investment is to develop everything from scratch so we could hold the licensing rights. But as a developer myself, the last thing I want to do is rewrite code or reinvent something that's already done and working, and I'd much rather start with something that exists.
What would be great is if we could get some people involved in the discussion on the 19th who know Flash, Gnash and the other existing software really well so they can let us know what exists already and how much work would be required to make it work for UI3. If these devs are free on the 19th and, ideally, not too far from California, Pluto will cover the cost of bringing them over. If not, we plan to setup a web cam conference anyway.
30
Developers / Re: MAME Plugin Progress Thread
« on: December 19, 2007, 04:14:56 pm »
Get this file: http://plutohome.com/gsdcode.tar.gz
Untar it, and add it to your database: mysql pluto_main < gsdcode
This contains all the Ruby code for all our GSD devices. Look in InfraredGroup table, and see also Manufacturer table, to see the infrared groups. I know the GSD for EIB and for Bang & Olufsen use some of the Ruby objects which interface back to LinuxMCE and retrieve device lists, send messages, etc.
Untar it, and add it to your database: mysql pluto_main < gsdcode
This contains all the Ruby code for all our GSD devices. Look in InfraredGroup table, and see also Manufacturer table, to see the infrared groups. I know the GSD for EIB and for Bang & Olufsen use some of the Ruby objects which interface back to LinuxMCE and retrieve device lists, send messages, etc.