Gerald Bauer
2005-01-19 05:13:40 UTC
Hello,
allow me to highlight the Xamlon forum post titled "How far will you
go to support Flash".
Tomas writes:
I've been following Xamlon and cs2swf for some time now and had a
few questions regarding UI controls and C# events/properties.
1) As I recall, the event and UI control classes in cs2swf were
modeled after the native as2 "class" objects. Since the windows forms
and compact version of XAML run against the .NET Windows.Forms control
objects, how will Xamlon eventually bring these two worlds together?
2) Will XAML built w/ the Pro Windows.Forms edition be interchangable
with the Flash XAML compiler? (including the UI object's methods,
properties, and events)
3) Will the Xamlon compiler enable coding of Flash Applications via a
"flash compact" .NET Framework? This would imply that a limited subset
of .NET Framework namespaces/API beyond UI (such as: sockets,
reflection, data structures, and XML classes) could be brought in from
existing C# source and executed in the Flash Player VM.
Look forward to your thoughts.
And Robin Debreuil from team Xamlon responds:
Those are certainly the hard questions : ).
1) We have started on two sets of controls, modeled after Avalon and
WinForms controls. While I think the Avalon controls will eventually
be the better ones, there are pretty big reason to go winform right
now. We also have the compact framework for Xamlon, so I think the
logical first target will be for that (in that the Flash player can't
really support the fuller set of Winform components, just due to sheer
size as well as some things that just can't be mapped, like threading
etc). Down the road though, the Avalon 'thinking' works better for
markup imo... that would also need to be a subset of course, but a
very functional one.
2) It should be interchangeable with at least the compact version,
though there will probably be some 'notes' people should read : ).
There are some things with swf that don't map 100% and they become
very difficult to support bit for bit. One example, even lower than
the component level, is Enumerate doesn't guarantee the order in swf.
Generally the objects are backwards so we reverse them, but there are
cases when things are deleted or added out of order, resulting in an
order that isn't the same as in C#. We can build our own sets here to
get the 1% case, but sometimes you will take a pretty big hit on speed
and size everywhere (going away from swf' native array implementation
for example) only to solve a really uncommon case. There are other
things that just don't map at all, so while there should be
'interchangeability', that would require using a defined subset. We
are thinking of marking assemblies like you do with [ClsCompliant]
now, so [SwfCompliant] would at least let you know what isn't going to
work. That isn't going to happen in time for the beta though..
3) We do have all the swf api mapped with a SwfNative library, so
everything programmatic you can do in Flash you can do in this. Then
there are mapping routines for things like the BCL -- delegates,
IEnumerator, string.Concat etc, which use SwfNative to build helper
routines. So once we (or others) get deeper into components, we have
all the tools needed to map things. But -- there will of course always
be a trade offs when the mapping isn't so clean. As an example, we
have swf XmlScokets available, the jist of them is the same, but the
implementation is fairly different. So we can either map the simple
things easily, map everything and end up with code that is larger and
slower, or people could just use the XmlSockets, maybe with #if defs,
for more exact control over the swf. Regex is an example of a class
where this becomes even more torturous, where the purpose of regex
(fast and small) kind of gets lost in the translation. So our goal is
to map things, but there are places where this will run up against
reality too...
Source:
http://www.xamlon.com/forums/shwmessage.aspx?ForumID=14&MessageID=816
What's your take? Do you think Team Xamlon is onto something with
the XAML to Flash conversion?
- Gerald
_________________________________________
United XAML | http://unitedxaml.org
XAML Forum & News | http://xamlnews.com
allow me to highlight the Xamlon forum post titled "How far will you
go to support Flash".
Tomas writes:
I've been following Xamlon and cs2swf for some time now and had a
few questions regarding UI controls and C# events/properties.
1) As I recall, the event and UI control classes in cs2swf were
modeled after the native as2 "class" objects. Since the windows forms
and compact version of XAML run against the .NET Windows.Forms control
objects, how will Xamlon eventually bring these two worlds together?
2) Will XAML built w/ the Pro Windows.Forms edition be interchangable
with the Flash XAML compiler? (including the UI object's methods,
properties, and events)
3) Will the Xamlon compiler enable coding of Flash Applications via a
"flash compact" .NET Framework? This would imply that a limited subset
of .NET Framework namespaces/API beyond UI (such as: sockets,
reflection, data structures, and XML classes) could be brought in from
existing C# source and executed in the Flash Player VM.
Look forward to your thoughts.
And Robin Debreuil from team Xamlon responds:
Those are certainly the hard questions : ).
1) We have started on two sets of controls, modeled after Avalon and
WinForms controls. While I think the Avalon controls will eventually
be the better ones, there are pretty big reason to go winform right
now. We also have the compact framework for Xamlon, so I think the
logical first target will be for that (in that the Flash player can't
really support the fuller set of Winform components, just due to sheer
size as well as some things that just can't be mapped, like threading
etc). Down the road though, the Avalon 'thinking' works better for
markup imo... that would also need to be a subset of course, but a
very functional one.
2) It should be interchangeable with at least the compact version,
though there will probably be some 'notes' people should read : ).
There are some things with swf that don't map 100% and they become
very difficult to support bit for bit. One example, even lower than
the component level, is Enumerate doesn't guarantee the order in swf.
Generally the objects are backwards so we reverse them, but there are
cases when things are deleted or added out of order, resulting in an
order that isn't the same as in C#. We can build our own sets here to
get the 1% case, but sometimes you will take a pretty big hit on speed
and size everywhere (going away from swf' native array implementation
for example) only to solve a really uncommon case. There are other
things that just don't map at all, so while there should be
'interchangeability', that would require using a defined subset. We
are thinking of marking assemblies like you do with [ClsCompliant]
now, so [SwfCompliant] would at least let you know what isn't going to
work. That isn't going to happen in time for the beta though..
3) We do have all the swf api mapped with a SwfNative library, so
everything programmatic you can do in Flash you can do in this. Then
there are mapping routines for things like the BCL -- delegates,
IEnumerator, string.Concat etc, which use SwfNative to build helper
routines. So once we (or others) get deeper into components, we have
all the tools needed to map things. But -- there will of course always
be a trade offs when the mapping isn't so clean. As an example, we
have swf XmlScokets available, the jist of them is the same, but the
implementation is fairly different. So we can either map the simple
things easily, map everything and end up with code that is larger and
slower, or people could just use the XmlSockets, maybe with #if defs,
for more exact control over the swf. Regex is an example of a class
where this becomes even more torturous, where the purpose of regex
(fast and small) kind of gets lost in the translation. So our goal is
to map things, but there are places where this will run up against
reality too...
Source:
http://www.xamlon.com/forums/shwmessage.aspx?ForumID=14&MessageID=816
What's your take? Do you think Team Xamlon is onto something with
the XAML to Flash conversion?
- Gerald
_________________________________________
United XAML | http://unitedxaml.org
XAML Forum & News | http://xamlnews.com