Ok, so I'll just write this off the cuff:
There are two proposals:
A) If Pluto is going to use UI3 for their own commercial stuff
B) If Pluto is not going to use UI3 for their own stuff
For the core of the backend rendering engine it doesn't matter which is the case. The idea is to leverage libplasma. It will be getting hooks for SWF (aka Flash) applets and already has a rich applet architecture. All it needs is some hooks and color conversion functions so it can be used efficiently with applications such as Xine, MythTV & VDR.
Where A or B starts to matter is with the API for creating the UI on top of libplasma. In scenario A, Pluto would need to write it's own XML reader/writer, in scenario B we would appropriate the MythTV XML reading code.
Where A or B really matters is in the UI creation tool. If Pluto uses UI3 for their own stuff, they can justify donating the labor of a half dozen programmers, the tool itself would not be GPL, but would probably be a web page + plugin that could handle the libplasma rendering. With some kind of agreement between Pluto + the LinuxMCE Foundation so that if Pluto or it's corporate heirs stop providing the web page the foundation could take over that duty and release the code so that others could as well. If Pluto does not use UI3 for their own stuff, they can not justify putting a number of full time programmers on the task but could provide some limited assistance.
I can't speak for Pluto here, so I can't tell you yet which option they want to pursue. My understanding is that they are in negotiations with some 3rd parties and how those turn out will determine how on board they will be.
As for the other issues, I've been talking to Pluto about their level of openness for years. And much more so since I've taken on a significant role with LinuxMCE. I think they are moving in the right direction now, but mostly because they're now convinced that LinuxMCE can be a greater benefit to them than a liability. But make no mistake they are a for-profit and they will help us only so far as it helps them as well. Don't expect them to be handing out any candy. If you want something done you need to do it yourself.
Anyway for the minutes, I didn't keep the best notes since they were only for my own use:
Riccardo -- KDE libplasma
Daniel K -- LinuxMCE/MythTV
Isaac R -- MythTV
Aaron -- Pluto
Demian(1audio) -- LinuxMCE/?Pluto connection?
Rob Savoy -- GNASH
Matthew -- LinuxMCE by webchat
D. Damron -- LinuxMCE by webchat
Tschak -- LinuxMCE by webchat
There were more, but I just wrote down someone's name if they said something I wanted to follow up on, I wasn't making notes of the meeting for anyone but myself.
Brainstorming:
Scripting Languages:
qtscript -- interpreted
This was suggested by Riccardo, it is very similar to ECMAscript, but has hooks for C++ programs
javascript -- interpreted
This was suggested before the meeting by Jason Tackaberry of freevo and brought up by Daniel
"eclipse" javasript
This was suggested for the C++ bindings
KDE Kross
This was suggested by Riccardo
ECMAscript -- interpreted
Brought up by Riccardo and Rob Savoy as a better (more standard) alternative to javascript
C++ -- compiled
Suggested by Aaron since it would allow you to write things like colour conversions in the UI.
But Rob Savoy (who did compiler work in the past as Cygwin) brought up how much work it would
be to make gcc work in an interactive environment. Aaron later dropped this as unworkable.
Issac said it didn't matter which scripting language was chosen, most designers would just cut-n-paste other people's code snippets. And the few that actually wrote bits of code would hammer away at whichever scripting language was chosen until they got it working. All the proposed scripting languages have about the same learning curve and if not javascript are almost identical to it for someone with a web scripting background or no programming experience at all.
After some discussion it was agreed that this didn't matter so much it mattered that the UI was scriptable; whichever of these near identical scripting languages are easiest to fit into the rest of the whole should be used.
GUI definition language:
XML was suggested by both Daniel, Issac and Aaron. This is the basis of the the new UI being written for MythTV (MythUI).
SWF was suggested by Rob Savoy. This is the basis of GNASH UIs
Raw libplasma programming was suggested by Riccardo
C++ binary was suggested by Aaron
There was much discussion on this, which mostly went in circles. The C++ binary suggestion was made by Aaron and thought of as a way to enforce GPL licensing in addition to producing faster code. However, after some thought he felt this wouldn't produce a stronger GPL tie-in than simply linking to GPL libraries; and he was convinced by the other participants that this code didn't have to be fast as it would mostly just be calling libplasma to do all the heavy lifting. Matthew and Aaron had a bit of an argument on the licensing aspect but we all decided to lay that aside after about an hour and move on to other issues.
SWF was not liked by anyone other than Rob and Matthew because it would require a whole new GUI creator that wrote out in a GNASH only format and used a number of tricks to prevent Adobe's Flash tool from destroying the files. Both Rob and Matthew felt these issues could be overcome. Ajax Animator and other tools were suggested as a starting point. However the rest of the meeting participants felt that it would be almost as difficult to turn these tools into full featured design tools as starting from scratch. Before a complete impasse was reached, Riccardo brought up surprisingly good news. The libplasma were already planning an integrated GNASH player as plasmoid (plasma applet) so gadgets could be designed in SWF and incorporated into any libplasma based UI.
Raw libplasma programming was suggested by Riccardo, but roundly rejected by everyone else. His contention was that designers would either program like him and not fear C++ or not program at all. He also felt that a UI designer was not needed, but instead a programmer should be paired with each designer and work in tandem. The argument against this was basically summed up by, "This is what we're all already doing, we want something better."
XML was in the end the container format to please all, it can contain SVG and PNG graphics. It can contain scripts that work on nodes in the XML tree, and it can contain plasmoids including whole SWF ones. Basing it on the MythTV one might be appropriate, but this wasn't decided on.
Graphics formats:
Not much contention on this issue, SVG as primary format, followed by PNG.
Design Tool:
Inkscape for SVGs
Eclipse
qtdesigner was brought up but considered inappropriate without much discussion
None of these are by themselves usable as a UI3 user interface designer. Except for Riccardo, all thought that this was the big missing component that would allow the rest to work. Aaron said that if Pluto could make a business case for it they could fund the development of this component. With Pluto development funding Inkscape would still be used for creating SVG's but the rest would all be handled in the design tool. A suggestion made by a few people was that if Pluto couldn't fund the UI3 design tool for any reason, it might be possible to either hack Eclipse or Inkscape to add on the missing components. Inkscape is a better starting point wrt to UI3, but Eclipse has a powerful plug-in architecture, that might even allow Inkscape to be treated as a plug-in.
TODOs:
After the brainstorming session. We moved on to what needed to be done to get this implemented.
The backend was considered something that just needed a point man -- but the expertise for this was contained in the room.
None of the people in the room were knew how to design a tool for UI designers, but Thomas and Matthew on web chat had some ideas.
What is needed is
a mock-up of screens
click count for common actions
pick target platforms (Ubuntu Linux, Fedora Linux, Windows Vista, OSX Leopard, etc)
pick lead platform from among target platforms (Ubuntu Linux?)
Mock-ups of the UIs to be generated (just document the following):
TiVo, FrontRow, PS3, LinuxMCE, WindowsMCE, MythTV
Navigation Mockup (in Flash or something like it)
We need a flash designer to generate this type of requirements document.
Thomas + Matthew will contact their UI experts, Pluto willing to pay for mock-up work.
