While I generally avoid polluting this blog with verifiable facts of any sort, Paul has no such standards it seems. Here is a great snapshot of the sparks flying between that teeming mass of MS developers on .Net, and that the-most-ubiquitouS-platform-in-the-World-that-doesn't-suck-like-Frickin-TV. They have been locked in a near embrace without actually being able to touch for all of the most recent eternity, which started in about 1997. I think the Greeks or the Brothers Grimm even wrote a legend about it once, but I couldn't find anything on google. Hmm, maybe they called it Win32 back in those days..?

posted on Sunday, March 13, 2005 4:44 AM
Feedback
  • # RE: Flash for the rest of them...
    Aral Balkan
    Posted @ 3/13/2005 4:45 PM
    Grrr, that post got me so angry I posted a rather harsh reply.

    Really, what is Xamlon? From their preview pages it looks like a toy (http://www.xamlon.com/software/xamlonpro/flash/preview.aspx).

    Have these people not seen Flex?

  • # RE: Flash for the rest of them...
    Paul Colton
    Posted @ 3/13/2005 5:42 PM
    Aral,

    We've had our heads down in development, and are now resurfacing to share our vision with the world. We'll be updating the site to make things more clear, but in short:

    Xamlon Flash Edition allows you to use C# and/or VB.NET along with XML (for UI layout, resources, etc.) to create SWFs. No ActionScript, no server, no Flash MX required.

    It's a simple concept with huge implications. Here are just some of those implications:

    - use one language and one XML syntax for application deployment, whether it's native Windows or Flash
    - use compiled third party libraries written in C# or VB.NET in your Windows apps or Flash apps
    - leverage the powerful IDEs that are out there for software development, but target Flash (Microsoft's Visual Studio for example)

    The bottom line is that we're opening up the world of Flash to all developers, not just those who have learned Flash MX and ActionScript.

  • # RE: Flash for the rest of them...
    Aral Balkan
    Posted @ 3/13/2005 5:50 PM
    Hi Paul,

    I definitely like your vision but, having been developing RIAs in the Flash world for quite a few years now, I am hesitant mostly of the components. That's a *huge* part of this and, as I understand it, work on it has not even begun. As I noted on the other blog, if the components can match the ones in Flex and the workflow match that provided by Flex Builder (live preview, etc.) and the tool is client-side, well, wow!

    I just can't see myself even touching it before it gets to this point though -- it would be too much of a step backwards.

  • # RE: Flash for the rest of them...
    Bertrand Le Roy
    Posted @ 3/14/2005 5:50 PM
    I don't understand this talk about widgets. Xamlon is not Flex, it does not in principle need a special widget library, it's just "scripting" Flash objects differently: any existing Flash clip should be usable in Xamlon, right? So Xamlon should already be able to use a library orders of magnitude larger than Flex, correct?

  • # RE: Flash for the rest of them...
    Robin Debreuil
    Posted @ 3/14/2005 7:00 PM
    There are a few approaches, and they go both ways (within limits), so it is a bit complicated to present everything simply... but I'll try. And fail no doubt.

    You can use it just like you use Flash now, except you use C# instead of actionscript. All the Flash API (things like movieclips) are mapped with stub libraries, as are a lot of base class libraries from .Net (things like Hashtable). This is so things compile, and because of this (and all the ndoc comments on it) you get intellisense etc. For graphics you can load swfs in, or embed them as library items, and reference them from code. Like this it is basically a standalone swf compiler. Code like this won't run in Avalon though, at least not until we map things like Movieclip to avalon objects (which we are thinking of doing at one point).

    The second 'level' is the components. The components we build are similar to (a subset of) Avalon as far as api, though of course underneath it is all movieclips and swf. These api's don't expose any of the swf specific parts. If you use these components via their api, then the code is portable. At this point new Button() looks the same in both, and of course you can say <Button> in Xaml as well, which is probably even more portable. Also, not everyone wants to create their own component set, and there isn't one built into swf, so we felt we needed to add one.

    Another thing you 'can' do, but isn't always practical, is take exisiting dll's and just dump them in to swf. So in theory you could take the whole .Net framework and run it in swf, but of course that doesn't actually work. It is too big, and some things aren't supported, like threading etc. The other thing is swf bytecode is orders of magnitude slower than .Net. so porting something like Unreal (gpu issues aside), isn't going to happen soon. However if you have what MS calls 'business logic' separated out, that can probably be reused without too much fuss.

    One of the really neat things we are finding though, is it is super easy to reuse code libaries with this (like it is in .Net), so I think people will start making/porting libraries. That works both ways too - if you create an easing library to give menu's spring (or port one from actionscript), then all of the sudden you can use these in .Net programs too. That is when things start to get super cool to me : ).


  • # A Moment of Clarification
    Robin Debreuil's Blog
    Posted @ 3/15/2005 7:05 AM


  • # A Moment of Clarification
    Robin Debreuil's Blog
    Posted @ 3/15/2005 7:08 AM


Blog Stats

  • Posts - 121
  • Stories - 1
  • Comments - 1441
  • Trackbacks - 47

.Net Blogs

01101 Blogs

Flash Blogs

Graphics

People