Slashdot Mirror
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. "
I'm a firm believer that most people act in the best intrests of others. I think this is something that geeks hold especially true, so when I see some sort of error with a computer system, I try to figure out what the developers were thinking when they put the thing together.
But when it comes to some windows issues... I'm at a loss. I actually have to ask myself how, in good faith, a developer implemented something that either works poorly or not at all. Why keep that "feature" in there (espeically when talking about a GUI) when it doesn't work as adertised?
I think my answer lies somewhere in management.
"Shell Revealed"? I think "Shell Shocked" would have been a much more apt name :-/
WARNING: If accidentally read, induce vomiting.
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.
No.
In the course of every project, it will become necessary to shoot the scientists and begin production.
...I have no idea what goes on at Microsoft in 2006 but let me tell you what went on circa 1990 at a (now-defunct) Fortune 500 minicomputer company, in the days of so-called "CHUI" interfaces (GUI-like interfaces implemented via line-drawing and X-Y character addressing on 80x24 green-screen terminals). I think I've told this story before on Slashdot, so apologies if you've heard it.
A developer was proudly showing off his spiffy new application. I started playing with it, and discovered that there were _three consecutive screens_ each containing the same field, into which the user was required to type the same entry, manually, three consecutive times. And there were no "copy" or "paste" functions. You actually needed to type your phone number or your SSN whatever it was three times in a row.
When I asked about this, he pulled a 150-page functional spec out of a drawer and showed me that he had implemented that the spec called for. It had slipped by. It's not that easy to previsualize how a UI will work based on a paper description.
When I suggested he change it, he said "No way. It took nine months to get that spec approved. Any change would require a review cycle and several meetings to get it approved. And if I change it without getting the spec changed, it won't pass SQA. This project is already behind schedule. I'm implementing it exactly the way this piece of paper says."
Another source of UI weirdness at another company I worked at was a CEO who fancied himself a UI expert. Or at least felt entitled to have the UI tailored to his personal tastes. He was always dictating changes in details of UIs. Unfortunately, he sometimes didn't previsualize how that change would interact with other details, and if you wanted to ask him "Say, now that we've done this thing here hadn't we better change this other thing there so that thus-and-such-bad thing won't happen," his secretary would schedule the appointment for a date a couple weeks from today.
I don't say this is how incomprehensibly strange UI happens at Microsoft. I say these are two ways in which it can happen.
"How to Do Nothing," kids activities, back in print!
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.