* Andreas Pokorny <dieMumiee@gmx.de> [2004-12-26 05:02]:
Alan Gutierrez wrote
* Martin Slater <mslater@hellinc.net> [2004-12-26 00:38]:
Seconded, I dislike immensely UI's that do not have a native look. In the end they just look unprofessional to me. The're fine for hacking quick tools together but if the product is intented to be released to the wider public they must look and feel like the native OS apps.
As noted elsewhere, providing native look and feel in a UI manager is not the challenge on Macintosh, where the controls are designed to particpate in any aspect of UI.
I want look and feel. Aqua look and feel for Mac. Skinnable look and feel for media gizmos. Pen oriented look and feel for handhelds.
I'm only trying to raise a red flag and say that a simple wrapper around the UI widgets is not enough. That look and feel is a pretty big issue, especially with the Win32 GDI, native controls do not participate in overlayed layout managment.
That last part was suppposed to read:
That look and feel is a pretty big issue, especially when, with the Win32 GDI, native controls do not participate in overlayed layout managment.
I have the feeling that a gui library has to many different customers, and wishes to make that all available in a single library. I would love to see a library that allows really cute self made themes, and simplifies extending the library with custom widgets, by adding a class that uses a vector rendering library, like for example Anti-Grain-Geometry.
That is, actually, an excellent architecture. I'd like to have a Document library, that I could use to render reflowing edit controls, and a Canvas library that could be used to render vector graphics controls. Furthermore, I think they should be independent of each other.
But already these two wishes create lots of problems. Then there are again other people that want to only take care about the data presented, and just want the library to display the data in a gui. E.g an application could run as ncurses, fb or x11 gui, without rebuilding the code.
And then there are users that want the native look and feel. Here the differences between the gui systems might make applications written for the library unportable.
Then one might think that the time for simple 2D gui is over, and that we should think about the next level of user interfaces, and write a library that presents data in a completetly different way. 3D Controls on curved surfaces spread in a view frustum with perspective projection.
Is there a solution that satisfies all users?
I think that part of the problem with GUI libraries is that they are based on an object heirarchy. That with generic programming, aspects of GUI programming can be added or removed. The everything is a widget concept, or everything is a window, does not address the wide array of devices on which an application must today run. Indeed, my FGDC taxonomy, was put forward, because I envisioned writing PalmOS Form applications, and for that I'll have no call for a vector redering library. But that should not matter. When filling out a data structure, I should be able to say, choose 1 of N items, and not be overly concerned of how that is being said. If I'm designing a UI, I should be able to choose a a radio set, or a drop down, and not be too concerned about the look and feel. I might choose a different "controled vocabulary" section device when on PalmOS than on OS X, but the "controled vocabluary" is a universal data entry concept. Even if you are on a desktop, once you've created your custom widget with your vector rendering library to create your drop down list, you don't want to have to get to your selection through the vector rendering library. I think a powerful GUI library realizes that you can't use the same code on different platforms, but you can use same idioms. Another reason for FGDC, is to raise the concern that advanced vector graphics comes at a cost, and shouldn't be a part of some UI idioms. An XML Document can be rendered using axis-aligned boxes, fonts and that's it. If my target already, has an image library, I can ship without code that draws a curve. However, if I did want vector graphics in my document, I can flow a vector graphics renderer into the flow of the document, just like an image. If I want a nicely formatted call-out on my ER diagam, I can give a document renderer a co-ordiante in the vector graphics canvas. There is, of course, so solution to statify all users, but the native component issues have been resolved time and again, the separation of rendering from model is expressed in MV[CP]. I feel that the 2d GUI has only recently evoloved to the point where development time and cost are getting reduced, and that an integration of UI concepts is due. In closing, I don't expect to be able to recompile a spreadsheet written for OS X and have it run on PalmOS. I do expect that when I have to write a PalmOS form, or write an OS X dialog box, that I can use the same language, libraries and idioms. Thank you for the provocative question. -- Alan Gutierrez - alan@engrm.com