From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-26 06:34:54
* Andreas Pokorny <dieMumiee_at_[hidden]> [2004-12-26 05:02]:
> Alan Gutierrez wrote
> > > * Martin Slater <mslater_at_[hidden]> [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_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk