Live! from Orlando: “The cooler the code name, the more boring the final product name.”

All this Vista stuff certainly does look cool, but I shudder to think of yet another platform upheaval....

Yes, keep the reports coming.

I'm personally skeptical of the latest batch of Vista-related Microsoft gee-gaws, but I'm trying to keep an open mind. I have two basic concerns: one, that this "Windows" thing just keeps getting bigger and bigger, with more and more interrelated parts and dependencies; and two, I'm unsure of what the vision/drive is behind all this. Are people clamoring for it? Is demand driving supply, or is this speculative supply in hope of a demand? I have similar concerns with what a behemoth Visual Studio is becoming.

I'm really just thinking out loud here, but I think Microsoft would be better off with a direction of simplification and decomposition, as opposed to the way we're going, which appears to be to keep building (and rebuilding) bigger and bigger monoliths--and often in the process messing up what was good about previous versions (for example, the abomination that they introduced into Word a few years ago relative to headings and lists).

All that said, Windows Presentation Foundation looks interesting and fun. Since Cristi Potlog mentioned him here a few weeks ago, I've been following Charles Petzold's blog. He's doing some cool things with XAML as he works on his new WPF book.

Dan

"Turner wowed the audience by resizing a form, demonstrating that all the form elements (buttons, listboxes, etc.) dynamically resized and maintained their relative positions (without code). The edges were smooth and images zoomed without that annoying pixel distortion. Turner demonstrated a fish-shaped command button liberated from rectangular confines. The technology includes reading features that reformats text into readable columns on the fly."

Definitely cool Donna. However, the algorithm for resizing rectangular form elements is pretty darn simple because it is based on the Fundamental Law:

x/y = x'/y' after resize

That is (das ist), where x and y unprime are the rectangular dimensions before resize and x and y prime after, OR the xy coordinates of the upper left hand element it is Duck Soup (potage du canard) to iterate through the controls collection and solve for new x and ys...IF you remember to make this iteration recursive when an element of Controls is-a (ist-ein) Kollection.

You have an additional problem, which Turner either solved, or hid in his demo, and this is smooth resize of fonts on controls. The problem is that for a fully general resize tool, the resized form has to use a font that is well-behaved, being either Truetype or having smaller versions. Microsoft cannot assure the customer of existing solutions that their developers never used Dingbats, Cuneiform, Oracle Bones, Church Slavonic, Early Gnome or other runic fonts.

For this reason the resize underwhelms me. Furthermore, I thought that Microsoft had solved it already in Visual Studio beta.

Turning to controls other than the ubiquitous rectangle, I agree it is time, as it was in the late 1950s for hep cats and kitties to get ovoid and otherwise irregular in shape: in the late 1950s, my Mom bought all new furniture that was of irregular shape usually ovoid to replace her severe American Colonial of the Eisenhower years.

However, each new shape is no special case. Knuth shows the math, but if a "package" is used, the math will remain a mystery, and given unconstrained featuritis users may see ovoid buttons change shape alarmingly to Alien eggs.

Microsoft developers are aware that each new shape is no special case; this is evident from their use of the word "vector". The problem is that the software overencapsulates this knowledge and will convince its user that he need not know the math.

Most generally a shape is a set of points but for each common shape there is an equation. I'd advise ovoid developers to first do the math in order to master the feature.

I am also troubled by the unmentioned phenomenon of control overlap because the classic Windows form is a two dimensional space, BUT controls can overlap. I'd like to re-vision the Form as a shallow Cube or glass box wherein controls are like Fish in an aquarium.

But Windows locks us into a two-dimensional world. I would like to replace it with an operating system which unseats the central metaphor while retaining the rectilinearity of the window, the Cube, and I'd like to name my unwritten OS Cuba, or perhaps Fidel. That would be fun.

In Cuba/Fidel, you would have baseline support for virtual reality tasks in which you would see a three-dimensional file cabinet.

Well, that's not so cool. I would want instead to see a beach and the Tropic Tan Girls swim and tan team.

Seriously, if designers at VSLive are as I understand applauding the resize of a rectilinear form, then this is why Open Source people think they are amusing. I solved the rectilinear resize problem but in closed source had no way of sharing the simple solution. We have to wait for Microsoft to bless the idea.

Yes, even I have added code to my forms in the past that caused the controls to resize with the form. However, it was rather nice to see that functionality built in with no coding required, as it is rather to be expected that the controls should behave that way. In the demo he did not use pretty girls for controls, but did use a fish, so I guess you're thinking alike.

Having said that, I have to agree with Dan's earlier comments and perhaps your implications. Is bigger (Supersize VB) better? If you start with a blank canvas, you're required to choose the colors, design, and be creative (and maybe understand the math/logic behind what you're creating). If Microsoft is giving us big, fat, paint-by-the-numbers on velveteen, what will we have when we finish, and what will it do to our skills?

Having said that, I've been reading the book A Beautiful Mind after seeing the movie Proof, all due to influences here. Apparently Nash was quite a snob in his day, looking down on those less brilliant than he. That's one aspect of this profession I'm not fond of: the thought that one camp (Open Sourcers, for example) might be looking for reasons to poke fun at another group as being intellectually inferior because they clapped at a demo.

I did like Proof.

By saying, aargh, woman, we be did such things in the earlies, 'tis nothing to resize ye Formme, burn me buttocks, I was being, in a way, the worst kind of Ancient Programmer and also a bit of a "Tony"...with the difference that I did not make my critique a personal putdown. I try to use the Bible text, where you're not supposed to say "raca, thou fool, you are a Butt Head" by way of criticism, with just a little success.

Now it's true, woman, that we be did such Things in the earlies when men were men and the women were glad of it and the sheep were nervous, as you have. The problem is that resize is being applauded so late in the game.

I would demur from the phrase "no coding required". I know what it means. It means that the programmer of the business application doesn't have to code and can instead ponder upon The Business Problem instead, such as when is it lunch. But coding IS or was required, at Redmond. My question was...does this coding take into account the font resize problem?

By the way, kiddo, I misspoke. NO element of the Controls collection is a collection. Instead the designer of a proper resize for general use by the workers of the world had to plan for a Control that contains a non-empty collection of controls.

She also needs to realize that in .Net as opposed to archaic VB, Forms have learned their place. They are a proper subclass of controls.

However, MOST forms don't feature controls with nonempty controls collections: these appear in things like group boxes. It's easy enough to forget that a Form is a Control, and a Control is a tree of Controls and not a vector. But probably everybunny knows this.

See my blog for more info.