On Sun, 17 Feb 2013 11:06:40 -0800, Jacob Carlborg <doob@me.com> wrote:

> On 2013-02-17 20:00, Adam Wilson wrote:
>
>> If you're looking for something that is as easy to use as WPF with as
>> much power, you won't find it in the open-source world. WPF is over
>> 40,000 classes strong, and while Open-Source is generally good for large
>> systems projects WPF requires some specialized knowledge to pull off
>> with any success. I have the graphics training required and I would love
>> to get started on a WPF for D but given that it is such a huge
>> undertaking i'd need help, if you're interested in helping let me know.
>> I'd love to put together a team and starting hacking out some code....
>
> 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. In Silverlight/WinRT it is deserialized at runtime. 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. The second is that as good as XAML is, it is ridiculously verbose. Creating a purpose-built DSL would be a much more efficient implementation idea IMHO. This would also make it much easier to re-target the GUI language and libraries to other languages.

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

Am 17.02.2013 20:21, schrieb rumbu:
> On Sunday, 17 February 2013 at 19:01:14 UTC, Adam Wilson wrote:
>> On Sat, 16 Feb 2013 19:28:27 -0800, js.mdnq <js_adddot+mdng@gmail.com>
>> wrote:
>>
> ... if you're interested in helping let me know. I'd love to
>> put together a team and starting hacking out some code....
>
> I'm interested, especially in databinding features of WPF. Right now I
> have no idea how this can be implemented in D without runtime reflection.

Compile time reflection could be good enough probably.

On Sun, 17 Feb 2013 11:21:54 -0800, rumbu <rumbu@rumbu.ro> wrote:

> On Sunday, 17 February 2013 at 19:01:14 UTC, Adam Wilson wrote:
>> On Sat, 16 Feb 2013 19:28:27 -0800, js.mdnq <js_adddot+mdng@gmail.com> wrote:
>>
> ... if you're interested in helping let me know. I'd love to
>> put together a team and starting hacking out some code....
>
> I'm interested, especially in databinding features of WPF. Right now I have no idea how this can be implemented in D without runtime reflection.

I think it could be easily implemented if instead of using runtime XAML deserialization and reflection we used a specialized GUI definition language that is translated into D at compile time. This would give the required flexibility to work around D's lack of the deep reflection capabilities that .NET has and make the app much quicker at runtime. I'd prefer to avoid reflection as much as possible due to the associated performance hits.

I love the ideas behind WPF, but as usual at Microsoft, WPF is a very poor implementation of a fantastic idea.

Thumbnail sketch of my vision for a WPF-like GUI Library in D, for now I'll call it Horizon:
- Purpose built domain specific language for GUI declaration
- Pluggable language compiler back-end to support different target languages.
- Dependency Property system similar to WPF to support flexible databinding.
- Concurrent Dependency Properties to allow multi-threaded access to the UI. (Needs specialized container support in Phobos.)
- Pluggable rendering core to support multiple operating systems.

Make no mistake, this will be a huge undertaking, WPF is massive! But it could very well be the killer app for D. The ability to make GUI apps that function at native speeds while retaining much of the ease of WPF is highly attractive to a lot of developers, myself included...

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

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@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.

> 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.

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

On Sun, 17 Feb 2013 15:01:20 -0800, rumbu <rumbu@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@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/

Am 18.02.2013 00:29, schrieb Adam Wilson:
> [...]>>
>
> 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...
>  [...]

I have seen this quite a few times.

It is not only how good a compiler/JIT is, but how things get coded as well.

Sometimes before reaching for C and C++, it would be enough to use the
right data structures or algorithms.



--
Paulo

On Sun, 17 Feb 2013 15:49:57 -0800, Paulo Pinto <pjmlp@progtools.org> wrote:

> Am 18.02.2013 00:29, schrieb Adam Wilson:
>> [...]>>
>>
>> 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...
>>  [...]
>
> I have seen this quite a few times.
>
> It is not only how good a compiler/JIT is, but how things get coded as well.
>
> Sometimes before reaching for C and C++, it would be enough to use the
> right data structures or algorithms.
>
>
>
> --
> Paulo
>

Well that's kind of my point. The method they used to draw a circle was about the most naive possible way it could be done with the tools they had. In short, the algorithm they used is stupidly brute force.

http://jeremiahmorrill.wordpress.com/2011/02/14/a-critical-deep-dive-into-the-wpf-rendering-system/

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

On Sunday, 17 February 2013 at 19:06:41 UTC, Jacob Carlborg wrote:
> On 2013-02-17 20:00, Adam Wilson wrote:
>
>> If you're looking for something that is as easy to use as WPF with as
>> much power, you won't find it in the open-source world. WPF is over
>> 40,000 classes strong, and while Open-Source is generally good for large
>> systems projects WPF requires some specialized knowledge to pull off
>> with any success. I have the graphics training required and I would love
>> to get started on a WPF for D but given that it is such a huge
>> undertaking i'd need help, if you're interested in helping let me know.
>> I'd love to put together a team and starting hacking out some code....
>
> 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.

The features that WPF has is XAML - The ability to do much of gui design in a markup language, Binding - The ability to bind variables to each other so one can update another, good "widgets" that all support these types of features, retained mode graphics, and a whole framework that is tightly integrated with the design.

Of course, you pay a high price in performance for this but generally it works well for business applications.

XAML is basically similar in concept html but it is designed to tie in well with code behind. Anything you do in XAML can be done in code behind. QT 5 has something similar now and maybe better. (in fact, QT seems to have picked up a bunch of wpf concepts and ran with them)

On 2013-02-17 22:56, Adam Wilson wrote:

> It is similar yes. In WPF, XAML is specialized XML that is deserialized
> at compile-time and translated into C#/VB.NET etc. In Silverlight/WinRT
> it is deserialized at runtime. 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. The second is that as good as XAML is, it is
> ridiculously verbose. Creating a purpose-built DSL would be a much more
> efficient implementation idea IMHO. This would also make it much easier
> to re-target the GUI language and libraries to other languages.

I would at least start with deserializing at runtime, since that seems easier.

This is also how GUI's are built on Mac OS X. Create the GUI in Xcode/InterfaceBuilder and it will serialize it to binary or XML. Then it will be deserialized at runtime.

-- 
/Jacob Carlborg

On 2013-02-18 00:29, Adam Wilson wrote:

> 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 ...

On Mac OS X it works fine with runtime deserialization.

-- 
/Jacob Carlborg