Vista (windows generally) suffers from not having a powerful GUI toolkit
One powerful GUI toolkit available from early version would save Windows' GUI consistency and work of all platform developers.
I like Vista, but things like this really bring the user experience down, because of inconsistency.
I noticed, that on Linux, it is mostly solved by having universal GUI toolkits (GTK and QT), and that way, application's look and feel is always consistent, and it is possible to update the look of an app simply by replacing toolkit's files in a system.
On the windows platform, however, apps are directly acessing windows API and implementing their menus and other GUI parts, and without an intermediate layer of GUI framework, they need to be rewritten to be updated to a new look.
And that is the problem of Vista leading to a sites like Long Zheng's UX Taskforce - apparently, there is a lot of programming teams in MS, and each one has a bit different opinion as to how interface should look. This is nothing unexpected - try to synchronize aesthetical feelings of several thousand developers - but it is unnecessary, and it shows that more is less. If there was only one way to do menu, abstracted from look, things would be easier on both sides - look, windows, here is a hierarchical structure with menu items, shortcuts, icons and callbacks, and now draw it as you like, in a manner consistent with a platform.
Another thing - layout: QT and GTK have a nice layout support, so it is possible to just stack some layout placeholders, and have everything resized automatically, even when window size/dpi/font height/ammount of text changes. In pure windows API, this needs to be coded by hand, and if everyone does it on his own, everyone will do it differently (and everyone will forget some edge case when things will get broken).
OK, there appeared some GUI frameworks that solve this, but still, each one of them do things differently, so it is still much worse, compared to situation when windows would have a powerful GUI tookit from the beginning.
So, sorry MS, but you are the cause of inconsistencies, which bring you laughter from both apple and linux fanboys (and cost you millions on maintenance costs with every new version of windows), and being a Vista fan, I must agree with them - sadly, though.
On the other side - making the platform developers sprinkle their code with unportable windows API constructions is maybe the best way to ensure that code won't get ported to competing platform. But if there was an evil mastermind behind it, it caused a huge pain to every windows developer. How sad :/.
PS: Of course, now with .NET System.Forms and WPF, things are much better, and easily maintainable, but so far, 99% of applications in Vista installation are native, written in C++ and Windows API.
- 2158x přečteno

Komentáře/Comments
you are right
Yes, you are right, also the Win32 API to program GUI applications is the most hard to learn API that I know. I really don't like Windows, because everything is going out of any known standard, in Linux and *BSD systems most of the POSIX and X-Open Standards are implemented, which standard reigns in Microsoft platforms?.
Thanks, I wrote this as I had
Thanks, I wrote this as I had to deal with win API a bit in the past, and since then I have seen other toolkit approaches, and I cannot believe how much more convenient they are.
I guess that Windows API have to be binary backwards compatible now, but some intermediate layer inserted in times of windows 95 would have freed Microsoft's hands in changin things.
A little parallel of this is in terminal implementation - Unix programs use system console trough its API, and the console i/o can be redirected to another computer or to console window very easily, and on the other side, all DOS programs wrote directly to graphic card memory and read from keyboard buffer, so any change of i/o would result to hacking or emulating those hardware resources.
Unfortunately, Windows 7 is still C++ update of old code, and I think that to stay on top, Microsoft will need to part with history like Apple between Mac OS 9 and OS X, write new system on some minimal managed kernel, and add emulation/virtual layer for legacy code. Not now, but in next 4-10 years yes, and the sooner, the better.
Very interesting, i like this
Very interesting, i like this website.
Poslat nový komentář