2007 May | Lazycoder

29May/070

Grady Booch on Software

Saw a video of Grady Booch over at the YUI blog titled “The Promise, the Limits, the Beauty of Software”.

Just the thing to get the old brain working on a Tuesday morning.

Filed under: Languages, Tutorials No Comments

10May/070

Regarding the possible availability of Silverlight on the Linux platforms

if you can’t make your mind up,
we’ll never get started.
and i don’t wanna wind up
being parted, broken-hearted.
so if you really love me,
say yes.
but if you don’t, dear, confess.
and please don’t tell me
perhaps, perhaps, perhaps.

(I’m sure some British Linux fans are getting a chuckle at that one. Or maybe their caught in the Giggle loop?)

Filed under: Linux, Silverlight No Comments

10May/070

Giving up on Silverlight

I’m giving up on Silverlight development, at least 1.0 development. It’s pretty obvious that NO ONE is going to ship anything based on Silverlight 1.0. Personally, since Silverlight 1.1 won’t work on Apples PowerPC machines, that means that any Silverlight 1.1 code I write won’t work on my main laptop (G4 iBook).

Why write code that I can’t run?

I’ve got a pretty good handle on the object model, enough that I think I may take it back up when I get an Intel based Apple computer.

Filed under: Silverlight, Technology No Comments

10May/0712

Why use XAML?

I'm looking at the SilverlightPad example for the 1.1 alpha version of the plugin. Has anyone else noticed that pretty much all XAML code exhibits the arrow anti-pattern?

PLAIN TEXT

XML:

<!---
///////////////////////////////////////////////////////////////////////////////
//
// blocks.xaml
//
//
// 2007 Microsoft Corporation. All Rights Reserved.
//
// This file is licensed as part of the Silverlight 1.0 SDK, for details look
// here: http://go.microsoft.com/fwlink/?LinkID=89144&clcid=0x409
//
///////////////////////////////////////////////////////////////////////////////
-->
<Canvas xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Height="500" Width="500">
<Canvas.Triggers>
<EventTrigger RoutedEvent="Canvas.Loaded">
<EventTrigger.Actions>
<TriggerActionCollection>
<BeginStoryboard>
<Storyboard BeginTime="0" Duration="Forever">
<DoubleAnimation Storyboard.TargetName="path1" Storyboard.TargetProperty="(Canvas.Top)" From="0" To="300" AutoReverse="true" BeginTime="0:0:0" Duration="0:0:2" RepeatBehavior="Forever"/>
<DoubleAnimation Storyboard.TargetName="path2" Storyboard.TargetProperty="(Canvas.Left)" From="0" To="400" AutoReverse="true" BeginTime="0:0:0" Duration="0:0:4" RepeatBehavior="Forever"/>
<DoubleAnimation Storyboard.TargetName="path3" Storyboard.TargetProperty="(Canvas.Top)" From="0" To="200" AutoReverse="true" BeginTime="0:0:0" Duration="0:0:8" RepeatBehavior="Forever"/>
<DoubleAnimation Storyboard.TargetName="path3" Storyboard.TargetProperty="(Canvas.Left)" From="0" To="350" AutoReverse="true" BeginTime="0:0:0" Duration="0:0:4" RepeatBehavior="Forever"/>
<DoubleAnimation Storyboard.TargetName="path4" Storyboard.TargetProperty="(Canvas.Top)" From="0" To="250" AutoReverse="true" BeginTime="0:0:0" Duration="0:0:2" RepeatBehavior="Forever"/>
<DoubleAnimation Storyboard.TargetName="path4" Storyboard.TargetProperty="(Canvas.Left)" From="0" To="30" AutoReverse="true" BeginTime="0:0:0" Duration="0:0:2" RepeatBehavior="Forever"/>
<DoubleAnimation Storyboard.TargetName="path5" Storyboard.TargetProperty="(Canvas.Top)" From="0" To="278" AutoReverse="true" BeginTime="0:0:0" Duration="0:0:4" RepeatBehavior="Forever"/>
<DoubleAnimation Storyboard.TargetName="path6" Storyboard.TargetProperty="(Canvas.Left)" From="0" To="176" AutoReverse="true" BeginTime="0:0:0" Duration="0:0:4" RepeatBehavior="Forever"/>
</Storyboard>
</BeginStoryboard>
</TriggerActionCollection>
</EventTrigger.Actions>
</EventTrigger>
</Canvas.Triggers>
<Rectangle x:Name="path1" Opacity=".65" Fill="orange" Height="100" Width="100" RadiusX="10" RadiusY="10" />
<Rectangle x:Name="path2" Opacity=".65" Fill="blue" Height="100" Width="100" RadiusX="10" RadiusY="10" />
<Rectangle x:Name="path3" Opacity=".65" Fill="red" Height="100" Width="100" RadiusX="10" RadiusY="10" />
<Rectangle x:Name="path4" Opacity=".65" Fill="yellow" Height="100" Width="100" RadiusX="10" RadiusY="10" />
<Rectangle x:Name="path5" Opacity=".65" Fill="green" Height="100" Width="100" RadiusX="10" RadiusY="10" />
<Rectangle x:Name="path6" Opacity=".65" Height="100" Width="100" RadiusX="10" RadiusY="10">
<Rectangle.Fill>
<LinearGradientBrush StartPoint="0,0.5" EndPoint="1,0.5">
<LinearGradientBrush.GradientStops>
<GradientStop Offset="0" Color="white"/>
<GradientStop Offset="1" Color="Gray"/>
</LinearGradientBrush.GradientStops>
</LinearGradientBrush>
</Rectangle.Fill>
</Rectangle>
</Canvas>

I'm not a big fan of the declarative UI movement. (XUL, Apollo, XAML, and now JavaFX). The reasons given for declarative programming usually center around making the UI code human readable making a cleaner break between the UI(view) and the controller(code driving the view). But UI's are complicated things, the code or markup used is complicated also. So what's the first thing most developers do? They go find a tool that makes sure they never, ever have to deal with the complicated markup and code. So if you're never going to read the UI code, why bother making it human readable? Apples Interface Builder has known this secret for years.

Interface Builder stores user interface resources in "nib" files. Nib files are a statically stored representation of the set of interface objects used by the application and their relationships which can be efficiently brought into memory when needed, reducing development time and making it easier to localize an application for different markets.

You could make an argument that Nib = binary XAML. The UI is "freeze dried" at design time and then reconstituted and instantiated at run time.

If you search for "Why use XAML", the pages of results never tell you what the advantage of using XAML over imperative code is. The results just say, "WPF uses it. That's why you have to use XAML".

That isn't to say there aren't some benefits to working with XAML. I love the fact that I can dump ALL my markup and UI code in one file, and concentrate on manipulating the UI in another. You could do that during standard Winforms development, but it wasn't as easy. I'm all about easy. The ability to define timelines and animations within XAML put it above the Nib format.

What benefits do you see in using XAML?

Filed under: .NET, Languages, Silverlight 12 Comments

7May/072

Confirmed: Silverlight 1.1 will only support Intel OS X machines

John Lam has posted a "gathering of facts" about Silverlight and the DLR. His #9 on the list was the one I was most interested in.

"Silverlight V1.1 will only target Intel Mac OS X machines."

That's pretty disappointing to me, but not unexpected. My bet is that this will slow, to a crawl, adoption of Silverlight by OS X users. While it's true the techno-elite, ADD generation, gotta-have-it-because-it's-new group have adopted Intel Macs en masse. There is a HUGE group of loyal Apple users still happily using their Blueberry and table-lamp iMacs using OS X. Apple's upcoming Leopard release will support PowerPC machines, but no word has come out on how long PowerPC support will continue. I'd love to hear the reasons for supporting Intel only. If I were to put out a SWAG, I'd say it has to do with Endian-ness and byte swapping. But I'd like to think that there is a more intractable problem with moving the CLR/DLR to PPC than just not wanting to write some code.

There are a couple of other facts that have been hinted at but it's nice to see them confirmed by a MS employee.

Silverlight lets you run compiled .NET code in the browser, not just Python and JScript code. Any assembly that has been compiled to target the Silverlight libraries should just work. So if you want to write code in C#, VB.NET or Boo to target Silverlight, knock yourself out.

Which is nifty and not unexpected. That's the whole point of having a Common Language Runtime.

The DLR will also run on top of the desktop CLR V2.0, not just the Silverlight CLR. We have a generic hosting API that lets us retarget the DLR to run on top of arbitrary hosts. Silverlight is only one such host.

Which is a little more interesting to me. I keep wondering if assemblies written against the DLR would be able to run against either CLR. I'm still trying to wrap my head around what MS really means when they say "CLR" in the context of Silverlight. Up until now, there has just be one CLR. It's evolved to support new language features, but the .NET Framework itself has evolved parallel to the CLR. Now it appears that we have two distinct CLR's. CLR Desktop and CLR Silverlight. Are they compatible? If you compile an assembly against one, do you have to recompile to get your assembly to work with the other (provided you use the namespaces available in Silverlight). I think it does.

An interesting side note: So now we have a "portable" CLR. Meaning you don't have to have the full .NET runtime installed on your client machine (at least as far as I can tell) to run Silverlight applications. Silverlight brings it's own small runtime along with it. It would be nice if this option were available to desktop developers as well. Meaning you hit "build" in the IDE, the compiler bundles up the specific namespaces and references that your application needs and puts them, along with the portable CLR, in your build directory. Almost like static linking.