Compiler patch for runtime reflection

[Jacob Carlborg]

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?

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

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

-- 
/Jacob Carlborg