WPF and Pixel Accurracy

I wonder who had the idea that UI graphics should no longer be pixel accurate. Naturally, most developers have abandoned WPF and Silverlight by now and have started looking int jQueryUI or other web-based UI managers, but I wonder what they were thinking.

I guess they imagined that screen resolutions would just “grow and grow” and we’d all have screens with phenomenal resolution in the future. But then what happened? Every other panel out there is 1080p for workstations (save for a few exceptions), while most laptops come with 1400×800 or something in that range. Smaller panels as found in smartphones have a high pixel density but small displays, and, I might add Microsoft hardly has any presence in that segment.

Man, I am fed up with WPF right about now.

Mindless Consistency Is The Hobgoblin…

When you work with WPF for a while, you realize that a lot of people who decide to share their knowledge are probably dogmatists. The dogma seem to be that separation of presentation and data is paramount, any mixture of code and presentation is evil and must be avoided at all cost.

I might be wrong about this, but I think we are hinging a lot of the examples on the facade pattern. The idea that you create different facades depending on the presentation context. E.g. a geometric object – say a circle – does not know anything about the presentation. To present a circle to a user, a facade is created. If the context is a web-page, the facade might create a PNG and return it to the user, in a regular app, we might just use GDI to draw a circle on the screen.

This frees the Circle-developer from knowing anything about HTML and mime-types, or GDI, or if a new technology comes along we just create a new facade. But the flipside is that the interface between the circle and the facades need to be fairly static. The circle dev might decide to add color to the circle, but now the facade developers in the other end of the world need to update all their circle presenting facades… ugh..

I like to have object “render themselves”. I think this is a little more object oriented. If I decide to add color to my circle object, then I will need to fix “drawToBitmap” and “drawToScreen” in my class (or inherited classes). But it seems logical to me that when I change the object, I will frequently know if the change also affects the presentation, and subsequently require editing of the presentation FUNCTIONS (rather than classes).

One example I came across was to show and hide an element based on whether the mouse was over ANOTHER element. Fairly simple to implement in code (a.onMouseOver = show b), but in “pure” XAML it becomes a hellish brew of┬áancestral selectors and relative bindings. In Javascript this would be an absolute piece of cake, and we’re mixing “code” with “presentation” like there was no tomorrow. WPF does not prevent you from doing this (at all, and that’s the route I take), but naturally I have to be aware if the code I am writing is “logic code” or “presentation code”.

If XAML is a hammer, some XAML tutors are seeing nails all over the place.