WPFfor d

[Adam Wilson]

On Sun, 17 Feb 2013 15:01:20 -0800, rumbu <rumbu at rumbu.ro> wrote:

> On Sunday, 17 February 2013 at 21:56:26 UTC, Adam Wilson wrote:
>> On Sun, 17 Feb 2013 11:06:40 -0800, Jacob Carlborg <doob at me.com> wrote:
>>
>>> On 2013-02-17 20:00, Adam Wilson wrote:
>>>
>>> I've been thinking for a long time to try and serialize widgets in  
>>> DWT. And then build a tool for graphically creating GUIs. I guess  
>>> that's similar to how XAML works.
>>>
>>
>> It is similar yes. In WPF, XAML is specialized XML that is deserialized  
>> at compile-time and translated into C#/VB.NET etc.
>
> XAML code is embedded in assembly as BAML and deserialized to a visual  
> tree at *runtime* through Application.LoadComponent subsequentely  
> calling XamlReader.LoadBaml.
>

Correct, but the BAML isn't XAML, it's a binary encoding that deserializes  
quicker. IMHO, it's still terribly slow. You should see some of the  
contortions we've made to your WPF interfaces to make them load faster ...

>> I think for D compile-time deserialization makes sense for two reasons.  
>> The first is that you get more flexibility to work around D's lack of  
>> the deep reflection capabilites of .NET.
>
> I doubt that it's possible to implement something like a  
> DependencyProperty mechanism or a simple INotifyPropertyChanged without  
> runtime reflection.
>

In WPF that statement is true, however, most of the reflection in WPF is  
not, strictly speaking, required, it's just how they choose to do it,  
along with a few other monumentally stupid decisions, like rendering a 2D  
circle as ~1000 polygons...

It turns out that if they hadn't gone the deserialization route, they  
could have done something like DependencyObject.GetValue("PropertyName"),  
instead of DependencyObject.GetValue(DependencyProperty). Internally it  
wouldn't have made one iota of difference in speed as the internal  
implementation of DependencyObject as it is essentially a Dictionary<>  
collection. If you go the code generation route like I've proposed, the  
first option is trivially easy and MUCH faster at runtime. The biggest  
loss? You have to recompile to change the UI. Theoretically in WPF you  
could change the actual XAML on the fly, in reality, I've never heard of  
that being done in production code (and MS seems to agree because those  
features are conspicuously absent in Silverlight/WinRT).

> Anyway, if you intend to set-up a team in this direction, you can count  
> on me.

I'd love to get a team going on this. Note that I have no code written at  
this point. But as it stands, we'd all need to hash out some design  
decisions anyways.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/