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