Vista Shell Team now Blogging

davevr writes "Have you ever wanted to ask the people behind the Vista UI exactly what they were thinking when they did things like Flip 3D or the windows that turn black when maximized? Want a last chance to complain directly to the source about your favorite Vista UI glitch before it is foisted on you and the rest of the world? Just wondering what sort of people work on Windows all day? Well, look no further. The Windows Shell team now has a blog site for your reading pleasure. Head over to Shell Revealed and check it out. "

Comments

100% correct

[brunes69]

Have you seen OpenGL? All the eye candy, and it runs on my old laptop.

I think you mean Xgl, but your point is still valid. For anyone who has not seen Xgl in action, head over to YouTube and search up some videos.

I have Xgl running on my Xp1800 computer with a Geforce2MX video card from 2000 in it, and it is *smoking fast*, and the effects are far beyond anything that Vista does. The parent is really 100% correct - why does Microsoft need this much CPU power to do it's (relatively simple) GFX in Vista? Seems like they are a bit behind the times in terms of software here.

Re:100% correct

[Phisbut]

I think you mean Xgl, but your point is still valid. For anyone who has not seen Xgl in action, head over to YouTube and search up some videos.

Yes, I have seen Xgl in action, I have even used Xgl for a while on my box. While the spinning cube and the wobbling windows are nice and all, it is simply hell when you try to simply resize a window. I don't know the inner-workings of Xgl, but how can they make such 3D stuff and wobbling windows so efficient, while totally killing the actual usefulness of managing windows by resizing them? They don't show *that* in the videos.

I'll use Xgl again when I see a video of a window being resized as fast as it is with a regular 2D desktop.

Dear Win32 developers, why is the API so ugly?

[master_p]

Dear Win32 developers, why is your API so ugly?

Here is a short temp list of problems:

1) why did you force an object-oriented system on your window system? why each window has to be an object? why didn't you separate the windowing system from the widgets library? the OO system you have adds an additional overhead for languages that want to have their own OO system.

2) why only one message queue? why not multiple message queues? why each windows message can not have an arbitrary amount of data?

3) why do I have to register a windows class? the API could have been much simpler if I simply passed a set of attributes in the creation routine.

4) why the return value of WindowProc is so strange? sometimes the valid return value is 0, sometimes it is 1.

5) why the function GetMessage returns a BOOL which actually has 3 values (TRUE, FALSE and -1)?

6) why your widgets are not autosizing? I have to manually resize each widget when its content changes (for example text or font). Why there isn't geometry negotiation as in MOTIF?

7) why every window has to have a frame? why didn't you separated window frames from windows? all the messages like WM_PAINT, etc are duplicated as WM_NCPAINT etc.

8) why didn't you use a property system for windows and you had to use the problematic 'set values' interface?

9) why the text resources of a GUI app can not be changed on the fly? why text is not a separate file?

There is no doubt that the Windows Shell is and has always been eye-catching...but to program it, one needs to use an API on top of it that abstracts its ugly details. And don't tell me it is because system-level programming of GUIs is difficult, because there are many window systems around that prove you wrong.