The discussion is certainly interesting, and using a SWF renderer would be exciting if technically possible, from a "outcome" perspective if nothing else. But as far as arguing the detailed specifics of what is possible (both Kir and Matthew have declared they are no experts in SWF/Flash/Gnash) it seems to me that Aaron has already taken the most appropriate next step. In a couple of days time we can get an expert opinion on what the technologies are capable of, from the head of the Gnash development team. Surely he is in an ideal position to take one look at the LMCE interface, and basic design deliverables we are looking for and telling us with some authority as to whether they are capable of doing the stuff we are looking for, and with how much development to integrate it all?
I agree that getting the GNASH expert will settle much of this on the practical points. Though it's important to have goals and requirements ready. So I reply to some relevant points:
- I don't think that Flash is a good choice for the UI3 basis: it is based on different ideas, it is used for different purposes and it is not open. In fact, the biggest common thing with UI3 in Flash is that it is sometimes used for building user interfaces 
In fact very often, it is not: I've seen much more sites based with UI based on pure HTML, HTML+JavaScript, etc. etc. than based purely on Flash. I.e. even for the UI-building task, Flash is not the 'best' tool. Web 2.0 sites for example, are based on AJAX and other similar approaches, not on the Flash itself, although they can embed Flash into them. For the desktop applications (i.e. running outside of the browser), I even cannot remember any _big_ application with Flash-based interface. So - selecting Flash is like selecting an old somebody's else SUV car and trying to use it on races: it was designed for different purpose, it is old and you cannot heavy-tune it.
- The same applies to the Gnash - with addition that Gnash (in the sense of development direction) is a tail of Flash pony: Gnash has to follow the Flash features and evolution. It will never be the separate.
Maybe that's true for "Flash", but Adobe's Flash is just their branded instance of the open standard SWF. GNASH is an open SWF player (and FLV server) that doesn't actually have to follow Flash, just SWF. It does, however, follow Flash without LMCE doing anything, so that's not a problem. However, SWF does indeed reflect quite a lot of what UI3, and LMCE in general, need to do, and the ways to do it. As I've posted in this thread, Sun has included OpenLaszlo in its new Java platforms that are already parts of the Blu-Ray, DVB and mobile phone specs. So lots of devices already work according to its design, and even include support for features that OpenLaszlo scripts.
OK, the SWF is said to be open (IIRC, with exclusion that GNASH developers have to reverse-engineer SWF files to build SWF player, because they cannot look into SWF standard itself, right?). The Flash itself is very popular (in certain places) and there is even OpenLaszlo utilizing SWF (or DHTML) which is pushed to some devices. But imho, we are discussing different things - I am not attacking the Flash itself, I am in doubt if it has enough flexibility to implement the UI with all the required features. For example, consider video+UI blending, when video is played by Xine_Player and menu overlays video - can Flash/Laslo do it, taking into account that Xine window is a separate window itself? I don't know. Next example: the current version of Linux Flash plugin is 32-bit only, I have not heard about 64-bit version (and even about plans releasing it). Gnash sometimes fails for me even on "not very complex" SWFs - does this mean there will be no 64-bit version of UI3 until some_not_defined_time_point? What about heavy 3D animation / OpenGL-like effects - will SWF be able to handle it and will it give a good frame rate when rendering?
SWF is open enough, given what GNASH (and other developers) have produced. As I've said, neither SWF nor GNASH (nor, to the point, the SWF supported by GNASH) might be sufficient to support all of UI3's requirements. But SWF/GNASH seems to complete many, if not most, of UI3's requirements, without introducing much of anything extra that conflicts with UI3 or LMCE's requirements. Starting with SWF/GNASH and adding development to improve it where specifically UI3 needs help seems a lot more productive than starting from scratch (or just from the TrollTech libraries). That also brings the SWF/GNASH communities. And the OpenLaszlo and other SWF development tools bring the same kinds of benefits.
Plus the Adobe support. The same goes for a 64bit version of either way: upgrade 32bit GNASH vs 64bit scratch. FWIW, GNASH also already supports OpenGL (and Cairo and AGG when OpenGL isn't available). Multiply the efforts in either track by the different GUI platforms, some with severe resource constraints (eg. mobile & IP phones), and just getting the GNASH headstart is a big boost, because GNASH does already do so much of what's planned for UI3.
FWIW, just because HTML is used for a lot more GUIs than is Flash doesn't mean Flash isn't good for a GUI, or for specifically UI3. Just because most cars on the road are sedans doesn't mean that pickup trucks are inappropriate for working construction sites. LMCE is much more complex than most software, especially the Web software that's pretty crippled in its UI paradigm and widgets (and which has to get downloaded with every new page).
Seems we interpreted this "cars" analogy differently: when talking about SUVs, I mean the use of "inappropriate tool for reaching some goal", not "win by popularity" logic which is of course stupid. I still not see why the SWF is the best framework for building the UI3.
I don't know SWF is the best way to do UI3. But it seems the best alternative we're currently discussing, and quite a good one. It seems SWF's features are highly complementary to UI3, especially since UI3 is to operate a media center, which SWF is highly suited to in its many multimedia features.
1) if you want to design it from scratch, you will most probably have to hack all and every piece in whole LinuxMCE system, to propagate new ideas/design approaches - or you will restrict your "open mind" to some subset of things (say, "UI3 has to coexist nicely with applications A,B,C") thus losing half of "from scratch" benefits
Certainly not. LMCE is a very properly tiered architecture. Only the GUI needs to be touched for UI3 to take over. We're talking about the Orbiter, in various platforms (standard Orbiter, Web Orbiter, mobile Orbiter, IP phone Orbiter, etc).
There are definitely some nuances and I am not completely aware about all of them, but for example - the standard Orbiter also does "windows" handling, e.g. when Xine_Player or Pluto_Screen_Server needs to be displayed, the proper window is brought on top, including all required positioning, resizing, etc. When creating the UI3 itself, this functionality will be probably separated into another tool, say magic_windows_manager. This means that either this magic_window_manager should be started only when UI3 is selected, or the same should happen for the UI2 and UI1 Orbiters. This what I mean "design changes propagation".
Now we're talking about backporting new features from UI3 to UI1/2. Seems not just a different discussion entirely, but also that it doesn't matter whether it's backported from SWF/GNASH or from anything else. Or that it's required at all. Why shouldn't the old UIs work the same way they always did?
Within the scope of just making a new, more featureful UI3, there shouldn't be any revisions propagated through the rest of the code. Unless perhaps there are new events etc supported/generated by UI3, which the DCErouter must support. But of course delivering required new features will be worth upgrading the DCErouter to accommodate them. Though the generic nature of DCE seems to make even that unlikely. AppServer upgrade, maybe, if there are new apps, but that's the architecture's way of handling such new features, which indeed minimizes the scope of the revisions. And besides, any approach to a UI3 that supports new features like that will require such propagation, not just if it's delivered in SWF. If anything, SWF is mature enough that developing such new features, and extending them to any new coding in scopes outside the Orbiter's code, will probably have existing techniques that will make development easier than "blue sky" development of UI3 from scratch.
- Regarding the IDE: don't care too much about the big and powerful IDE at the beginning of journey: if the development be successful, the IDE will appear. Of course, certain ideas should be taken into account, such as - it is always easier to modify human-readable file that to issue SQL queries. Like with websites - webdesigners doesn't use IDE 100% of time - they spend a lot of time in notepad-like text editors, tweaking the HTML,CSS,JS,etc.
It's irresponsible to replace a GUI with a new system without including a GUI designer (or allowing use of an existing one). Especially when one major limit of LMCE is that its old GUI designer is acknowledged totally unusable by both its users and its authors. This requirement is a driving force in producing a UI3. "It'll come" is no way to plan a project, especially when it'll have to come from us. We have to pick the framework that will most reliably include a GUI design/composition system, like a data format that already has one, or plan to write one ourselves.
If you design the GUI system well (including the data structures, elements layout formats, etc.) it will be not hard to write a custom IDE for it (when rendering of sample UIs is already present and data format is selected carefully). But I certainly wouldn't recommend to select the UI framework putting the availability of IDE for it. 99% of time people will see the UI3, not the framework for UI3 development, that's the logic.
In addition - yep, Adobe does have an SWF editors, etc. but is all this stuff free? Is it easily extensible/customizable so we can modify it? As in file formats, the XML is better than a binary blob - with editors/creating tools it is easy when you can use free tools to make a modification. If Joe needs to buy an IDE for $300 just to change color of 1 button, what will he say?
There are free tools for generating SWF, not limited to OpenLaszlo, and tools for generating other formats from SWF. I expect there will be some development necessary by LMCE to bundle them into an environment best suited to LMCE. Especially if we incorporate something like sqlCVS with templates for target Orbiter devices. But that would be faster than developing a whole new GUI studio environment, especially if on a whole new GUI format, and most especially while doing both at the same time with the same developers only from the LMCE community, rather than bundle SWF tools perhaps with help from the SWF community.
- Description of objects properties inheritance and conditional properties evaluation, reminds me about HTML+CSS style of UI implementation - does anybody else see this analogy? Maybe we could utilize it and define the engine layouts in kind of XML-ish format. And use CSS-analogue approach for defining stylesheets, too.
Whatever we decide to do to produce the UI improvements, it will probably include runtime configs that style the GUI. HTML+CSS is one example of that model, but is very limited (owing mostly to the limits of HTML).
We are not restricted by the HTML standard, I was talking about "analogy", not direct use of this technology. But it is a bit funny to hear about restriction of HTML+CSS from you at the same time when you speak about the OpenLaszlo which can be also compiled into DHTML.
Well, I was agreeing with your analogy. Though pointing out that one instance, HTML+CSS, is limited. Which is one reason why I have not been pushing the DHTML generation of OpenLaszlo. Those limitations of DHTML are why SWF itself is a better target for OpenLaszlo than is DHTML, except when SWF can't be supported in a device, but SWF can. FWIW, I've also mentioned the even more limited SVG, which could be suitable in even more constrained environments (or when the GUI doesn't need more than SVG).
I'm not really sure that you really understand GUI development, or LMCE's architecture. You also seem to be wrong about SWF and how it actually does relate to UI3 (or to Flash) on LMCE. Where are you getting these perspectives from?
As far as I know, the SWF and Flash are not related to LMCE (at least yet ;-). If you are aware about some freshly developed code - please update me on this.
Well, we are relating them now in this discussion (and elsewhere on that subject). You were claiming that SWF is really different from what UI3 needs, though Aaron.b disagreed with that claim (though he'd made it too, in the original wiki UI3 article) in replies in this post.
Regarding GUI, LMCE and perspectives - good question. I never developed full-scale GUI framework, but used different kinds of them: VCL, MFC, QT, so I know what it is and what are components of. LMCE - it's a fork of Pluto, right? I am familiar with Pluto system and even submitted some code to them. Of course I don't know _full_ details architecture as it is too large to fit in my head 
, but DCE is for Devices,Commands,Events - right?
Well, our disagreements about the scopes necessarily touched by UI3 development indicated that you didn't understand how LMCE's UI architecture worked. Evidently you do, so I'm still not sure why you said what you did about LMCE's UI architecture, claiming cross-tier dependency problems. I personally don't know how LMCE's architecture changed after it forked from Pluto, and whether perhaps there were some Pluto dependency problems like that that are now fixed in LMCE.
But I've been designing and implementing GUIs for a long time. Since the early 1980s. I helped clone a Photoshop beta into a "digital prepress" (pro desktop publishing) system for extremely hirez cameras (crossplatform Mac/Windows, pre-3.0). I was part of the team that helped Apple port the MacOS Toolkit from Pascal to C++ (for Apple Developer University), specifically in a code development tool with a hypermedia API. I've been part of so many evolutions (and revolutions) that I know how easy it is to
talk about GUI architectures and requirements, vs how hard it is to be right. Conversely, I know how quickly GUI experts can pick up new ones, and the importance of reusing them. I'm not just trying to brag about my resume. I'm trying to point out how I know what I know about these issues, even though my expertise in specifically LMCE is still limited, my SWF/OpenLaszlo/GNASH experience is largely from reading webpages (though I've used some free SWF tools before). A good deal of getting this kind of thing right is both predicting how GUI techniques will evolve over a few years for developers and consumers, and how the various community lifecycles both enable and constrain that evolution. YMMV.
