Aaron.B was going to write it up. But I'll write something up from my notes if he doesn't get to it soon. :)

Yes, there was quite a lot of info flying around. And some issues that we still have to resolve through community discussion. I'd like to see some notes, especially from someone who wasn't dependent on the flaky Web audio.

Just a quick reminder... It's been a week now, and I guess those that could not attend would love to get an insight into the discussion...At least I do... ;)

I've asked Aaron about getting notes/minutes or even just a recording (if one exists), but I haven't heard back. I myself had the same (or worse) audio problems that many on the conf stream had, so I know I missed stuff, some of it essential. I'd rather start a discussion that continues from that conference from the notes of the conference.

However, despite that, I'll mention here that a lot of the discussion was about whether and how to use SWF and TrollTech's Qt (or just one or the other) as the UI3 framework. The reason I mention that now is that Nokia bought TrollTech (http://trolltech.com/company/newsroom/announcements/press.2008-01-28.4605718236) this week. Which almost certainly affects plans for using Qt in UI3, probably for the better (ie. mobile Orbiter not necessarily limited by Symbian OS' UIKON GUI framework).

This is newsworthy. And probably has Aaron dealing with more complex issues underlying UI3 now. So at the risk of moving the discussion forward without a consistent transition from the last event, the actual UI3 brainstorming conference, maybe we should talk about at least what it would take to create a UI3 along the lines we've already talked about.

One conference point that we raised but didn't fulfill was a requirements list of UI3. If we could get even Aaron's UI3 wiki article (http://wiki.linuxmce.org/index.php/UI3) reduced to bulleted requirements as something to kick around, we'd be more productive. There are requirements of the final UI itself at runtime. There are separate requirements of the process to create that UI (eg. requirements of the UI composer tool that include supporting requirements of the UI it generates), which include collaboration and probably cross-compiling (eg. Linux dev env targeting mobile phones). And there are requirements of both to support transition from the current UI1/2/2-blend to UI3. If we can start such a list, even if the requirements aren't nearly finalized (ie. proposed requirements), by the time we complete the initial version just from Aaron's article, maybe we'll also have the notes from the next artifact, the UI3 brainstorm conference, ready to take it a step further.

Sorry for being a pain in the ass, but I'm actually interessted in what happened there.Communication in FOSS-projects is always a problem, therefor this kind of carelessness should not find there way into the project at all, and especially in this stage getting community processes started.

After all it feels kind of discouraging... And I guess not only for me...

And it just fits into the line of issues-no public source available in the beginning-a mantis-bugtracker with ghosts-users fixing issues on ghost-repository, nobody knows about...-no information about the future of the project-then the attempts to understand the source from charonmedia-svn-then a surprising new development-tree from pluto for 0710-now this is stalled on beta 3 which usually indicate being close to a release, but no information available again

If you really want this project to proceed and attrackt more developers, you should rethink these approaches.

Notice that I use the term "you" instead of "we" by now, as I do not really see, where the control and responsibilities are right now, which is one of the reasons, why I'm so interessted in the minutes.What happend to all the proposals for OSS-development ? What about the community control of LinuxMCE ? What about pluto's control of LMCE ?

From what I've read in the past, these issues seemed to be the reason why OSS-development of Pluto-Home stalled in the first place. Please learn from that...

There are two proposals:A) If Pluto is going to use UI3 for their own commercial stuffB) 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:

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.