On Sat, 29 Oct 2011 03:59:28 -0700, Jacob Carlborg <doob@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/

On 2011-10-29 22:11, Adam Wilson wrote:
> 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.

We don't have to argue about this but it sounds like WPF is a new native GUI, especially if it bypasses GDI.

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

With DWT you only pass an additional flag when creating the table, if I recall correctly.

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

What's wrong with using the lowest level of the drawing operations available on a given OS. On Mac OS X it would be Quartz which is has been hardware accelerated since a very long time. On Linux it would probably be Cairo and on Windows you could use the lowest level of WPF. Why reinvent the wheel again?

If you want to roll your own drawing operations anyway why not have the reference implementation in OpenGL, it's available on basically all platforms including Windows.

OpenGL bindings and other things like SDL and FreeType: http://dsource.org/projects/derelict

DirectX bindings and bindings in general: http://dsource.org/projects/bindings

This is not my strongest side, but wouldn't you need native windows to draw your widgets on?

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

Just for the record, the interface to C++ is very limited.

-- 
/Jacob Carlborg

On 10/30/2011 4:03 AM, Jacob Carlborg wrote:
> On 2011-10-29 22:11, Adam Wilson wrote:
>> 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.
>
> We don't have to argue about this but it sounds like WPF is a new native GUI, especially if it bypasses GDI.
That's not the issue. The "nativeness" isn't regarding GDI vs. DirectX, but it's regarding the _windowing_ framework itself (which is separate from, although related to, the graphics framework).

_Native_ windows use the _system_ window classes (e.g. SysListView32) to display themselves to the user. WPF (which uses DirectX) and GTK (which uses GDI) and most frameworks, on the other hand, don't -- rather, they try to /look/ like native windows by creating custom windows and intercepting all of the drawing operations.

And, of course, they fail. This is indeed hard to notice on XP, but it's blindingly obvious on Windows Vista and later, because, for example, the buttons no longer "feel" native, even though they might "look" native -- e.g. the way they fade or get depressed (the timeout, the fade colors, etc.), the way they get focused, etc. is completely out of sync with the rest of the system's looks.

Since native controls use GDI internally, they obviously can't be drawn with DirectX. But the key point is that the inverse is not true -- if something uses GDI (e.g. GTK), that doesn't mean it's native. So no, WPF is not "native" in any way, and neither is GTK -- the only "native" frameworks are those that use the built-in windowing classes, which include MFC, ATL, SWT, and (I /think/) Qt. Most other frameworks don't do this.

Runtime reflection on B, C, D not on A.
No reflection for private, protected.
[properties, methods, events]

class A
{
}

@reflection
class B: A
{
}


class C: B
{
}

class D: C
{
}



> I really like Gor's idea of @noreflect for this. You have a network
> class you don't want as easily reversible, or a security class, or
> private fields such as password. You just mark the module, type,
> methods, or fields, as @noreflect. It could even disable compile-time
> reflection if desired.
>