An introduction

[Tim Newsom]

Plus, since moonlight is technically language agnostic, those who want 
to write in c# could, those who like c or c++ could.. With IronPython or 
IronRuby or even Javascript there are a number of options for scripting 
and having user interfaces that work seamlessly together.. Regardless of 
the technology used to build the application code underneath.  From my 
understanding.. We could even mix with different UI elements interacting 
with different types of applications ... By that I mean portions of the 
same UI could be sending events to scripts or C# or c/c++ code. Is that 
right?

And XAML can be created dynamically giving the ability to not just 
theme/skin but completely alter the UI at runtime.  By that I mean you 
don't have to have a static interface with a skin file and theme but the 
interface could be radically changed as new code is added and new xaml 
nodes are created.. Does that make any sense?
--Tim

On Wed, 27 Jun 2007 5:49, Vladimir Giszpenc wrote:
> On 6/27/07, Tim Newsom wrote:
>> This could provide the xaml parser for use in an interface design some
>> of us have spoken about.
>> Separating the interface from the actual code that processes the
>> events... Or that's how I understand it.
>> Its a truely awesome development.
>
> Yes it certainly could and would provide a XAML parser.  Read this
> http://jacksonito.blogspot.com/2007/06/mono-developers-guide-to-writing-xaml.html
> for some more details.  They are planning for tools written in
> MoonLight so that you could develop on Linux or even a Mac (though I
> sense no love lost on Apple products on this list :).
>
> On 6/27/07, Hans De Croix wrote:
>> Under what license exactly is silverlight/moonlight?
>
> The Mono part of Moonlight uses the DLR. So...
>
> "Microsoft's DLR is a layer on top of their Common Language Runtime
> (CLR), which provides support for dynamically typed languages such as
> Python, Ruby and JavaScript. The great news is that the DLR is
> released under Microsoft's Permissive License—their way of saying 
> open
> source. Microsoft's .NET/DLR implementations of Python and Ruby, named
> IronPython and IronRuby respectively, are both covered by the same
> Permissive License as DLR."
>
> Mono as a whole has this answer to the license question:
> " What license or licenses are you using for the Mono Project?
>
> We use three open source licenses:
>
>    * The C# Compiler and tools are released under the terms of the
> GNU General Public License
> (http://www.opensource.org/licenses/gpl-license.html) (GPL).
>
>    * The runtime libraries are under the GNU Library GPL 2.0
> (http://www.gnu.org/copyleft/library.html#TOC1) (LGPL 2.0).
>
>    * The class libraries are released under the terms of the MIT X11
> (http://www.opensource.org/licenses/mit-license.html) license.
>
> Both the Mono runtime and the Mono C# Compiler are also available
> under a proprietary license for those who can not use the LGPL and the
> GPL in their code.
>
> For licensing details, contact mono-licensing at novell.com"
>
>
> Specifically Moonlight...
>
> "Novell will be requiring copyright assignments or contributions to be
> made under the MIT X11 license to Moonlight to ensure that we can ship
> this plugin with proprietary drivers if necessary (and also to
> relicense Moonlight for embedded system users)."
>
> I imagine the OpenMoko embedded system is a special case since it is
> open but the license is definitely open source.
>
>
> On 6/27/07, Florent THIERY wrote:
>> I'd be surprised if no hardware acceleration was needed...
>
> It is not needed though it is used if available.  They got help from
> their Xgl+Compiz+Glitz guy David Reveman.
>
> Here is Miguel de Icaza describing the development decisions some 
> more...
>
> "The other consideration to move away from C# to C at the time had to
> do with the early conversations with David Reveman who wanted to
> hardware accelerate this. The idea was to turn the Silverlight
> high-level operations into a scene description that we could transfer
> from the client applications directly onto the compositing manager (On
> modern X installations this is what actually puts the bits on the
> screen and what has enabled all those spicy effects like the rotating
> cube).
>
> The idea here is that the Silverlight client could detect if it was
> running under a compositing manager that offered rendering on the
> server and it would off-load all the rendering to the layer that can
> talk directly to the OpenGL hardware. "
>
> Vlad