Compiler patch for runtime reflection

[Adam Wilson]

On Sat, 29 Oct 2011 03:59:28 -0700, Jacob Carlborg <doob at me.com> wrote:

> On 2011-10-28 21:36, Adam Wilson wrote:
>> Ahh, thats the true power of WPF. Presentation and Implementation are
>> cleanly separated. I recent re-skinned every scrollbar in one of our WPF
>> apps by writing the 30-line style once, placing it in the global
>> resource dictionary with implicit styling enabled, and bam, every
>> scrollbar in the app looks different, but functions in the exact same
>> way any windows user would expect. There are cases where you can write
>> code that calls up into the presentation layer and thus introducing a
>> dependency on the presentation layer, but this is actively discouraged,
>> and when I found one recently in a 3rd party vendors control, it was
>> removed by the next release.
>> I can go on and on, but the point is, there are only two frameworks in
>> existence that can do that are the WPF family and JavaFX. JavaFX is
>> pathetic compared to WPF and is of course tied to an Oracle *shudder*
>> controlled langauge. And a few months ago we had thousands of developers
>> on the Silverlight forum looking for WPF family alternatives, all that
>> they could find was JavaFX.
>
> It's not the look of the, in this example, scroll bar, it's the  
> behavior. It may look like a scroll bar but it may not behave in all the  
> ways as a real, native, scroll bar would.
>
>> Nobody, in fact WPF has three default looks out of the box, one for
>> Windows 2000, another for WinXP, and another for Aero (Vista+). WPF
>> defaults to the correct one for that system unless you override it. It's
>> just that in my experience, the default look is a lowest common
>> demoninator, and not a good one.
>
> To me it sounds like WPF is the native GUI. Then why are you complaining  
> about native GUI's?
>

WPF isn't the native GUI, it just comes with skins that emulate the look  
of the native GUI. The native GUI in Windows is called Win32 GDI  
(Graphices Device Interface). WPF is built on top of DirectX which is  
analagous to OpenGL and is primarily used for games. DirectX completely  
bypasses the GDI and communicates directly with the hardware. It's primary  
claim to fame is that it is fast, but it's not as compatible, whereas GDI  
is compatible with everything that implements VESA (which is everything  
since the early 90's), but it's slow.

>> Neither am I really, I am a programmer by trade who cut his teeth back
>> in the C++ days before C# came along and made me actually productive,
>> but design isn't that hard, if one is willing to let go of their
>> preferences. More to the point though, my company has no on staff
>> designer, so it was either pay large sums of money to a consultant, or I
>> as team lead could do it. I lost. To some degree it's a totally
>> different way of thinking and I find that after a good design session (a
>> week or two), it takes me a couple of days to realign my brain to
>> left-brain-progammer-mode. But hey, they pay me, I jump to. *shrug*
>> There is no mystical powers that are given to designers, anyone can make
>> a good design.
>
> I'm just saying that I'm not a good designer and if a designer is  
> available I would prefer that they did the design.
>
>> Actually we found that by re-skinning our app intelligently we were able
>> to load a large list of complex data 4x faster than the default skin.
>> The reason for this is that in WPF all drawing is done the same way, it
>> doesn't matter if it's a system skin or not, it's just a skin, there are
>> no special shortcuts for the system skin to take. At it's heart WPF is
>> based on DirectX9. This means that screen complexity is the ONLY
>> limiting factor.
>
> If the changing the skin of an application can increase the data load by  
> four times it sounds like something is seriously  wrong.
>
> On Mac OS X a list only loads the data that is displayed so I don't  
> think the amount of data matters. The same can be done using virtual  
> tables in DWT.
>

Ok, so I apologize for generalizing there. It turns out that WPF is really  
bad at drawing round shapes, and the default skins (which the exception of  
the Windows 2000 skin) rely heavily on rounded corners. We replaced the  
default skin with one that used square corners and had fewer Measure and  
Arrange stages (where WPF figures out where to place the controls) which  
are equally expensive. WPF has virtual lists as well, and we do use it,  
which also helped contribute to our speed gains, but it is not enabled by  
default. My complaint is that the working with WPF requires a non-trivial  
amount of esoteric experience with it to make it work well.

>> The other thing that WPF allows is data / presentation separation. I can
>> pass a list box a chunk of data, and the data does not have to concern
>> itself with how the presentation looks or vice versa. The listbox will
>> display the data according to however the style is setup it. And THEN if
>> I really want to I can change the presentation style on the fly based on
>> user input. Can DWT do that in 2 lines of code? WPF Can. That's the
>> power of reflection based data-binding. In fact I spend most of my time
>> writing (much more compact) XAML code to do presentation layer work than
>> I do write C#, to the point where the C# coding makes up less than half
>> of the work done on a screen. It's usually things like load this item
>> based on a selection changed event or some such that XAML has no way to
>> do (and shouldn't, thats implementation).
>
> No, probably not. It's not as easy to change the theme in SWT/DWT since  
> it's supposed to use the native look and feel.
>
> It appears that you can at least set colors and similar properties using  
> CSS: http://jaxenter.com/css-styling-in-eclipse-helios-32465.html
>
>>> Anyway, you can still use DWT to draw your own widgets. Even if you
>>> don't use any native widgets you still need to be able to draw
>>> something on a surface. DWT has a platform independent way of doing  
>>> that.
>>>
>>
>> Yea, but how much work is it? Can I create a completely new look for a
>> control in 30 lines or less without modifying the implementation code at
>> all to make the new look work? That's the power I'm after.
>
> No you probably can't. I don't know what you want to achieve with your  
> project but I got the impression that you were looking to build a new  
> GUI library that behaves something like WPF.
>
> Regardless of how this GUI library works you need somehow to draw the  
> widgets on the screen. I'm just saying that DWT has a platform  
> independent way of doing this. On the other hand, if you're creating a  
> completely new GUI library you probably would not want to depend on DWT.  
> But instead creating bindings directly to the underlying drawing  
> operations for Cairo, Quartz and DirectX or whatever Windows uses these  
> days.
>

I am looking to create an open-source implementation of a GUI framework  
that is 'lookless', i.e. it's underlying implementation has no  
dependencies on how it looks and the look can be changed to however the  
designer wants it to look without having to worry about code. WPF and  
JavaFX are the only two frameworks that are examples of how this might  
work.

I absolutely agree that relying on something else is probably not the best  
idea, because for better or worse you end up inheriting their design  
choices, which may or may not work for your project. Since I am windows  
guy, the reference implementation is going to be DirectX. First I just  
have to create Direct2D bindings for D...

And another goal of the framework beyond platform independence is language  
independence. I have to admit that one of the big draws for me of D was  
the C++ ABI and COM compatibility of D while having a MUCH more modern  
capability set. However, it's still lacking in a few key areas for my  
project, and runtime reflection is one of them...

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.com/