Gui Engine Goals

Goals of a potential GUI-engine standard.

Please only include brief summaries in this list. Put discussion below.


I suggest that, unless contributors wish to produce another PipeDream page like KillerUserInterface, every goal should (as part of its definition) be objectively measurable (put a number on it) or qualifiable (e.g. via proof, rubric). Further, we should explicitly separate 'Goal definitions' (which name and define goals) from 'Goal sets' (a weighted set of compatible goals that some contributor thinks represents 'GUI done right'). After all, there may be incompatible goals among the definitions.

I also find the title a bit painful. 'GUI engine' in literature, colloquially, and on the Internet, pretty much means 'display framework and widgets set', like Motif or GLO or various Desktop Environments. It usually excludes anything further behind the scenes.

What alternative would you suggest?

I'm not particularly fond of DRM, but I understand the motivations of those who are. The technology is very good for other privacy management, and for ensuring need-to-know information only reaches those who need-to-know.

Re: "Encourages (or enforces) separation between the display and the data to be displayed. The typical MVC example of an analog and digital clock view being updated from the same data should be simple."

That is an IDE and/or application development pattern, not necessarily a concern of the "GUI engine". Clock shape and style is a domain issue.

I interpreted it as basically being a statement of ImmediateModeGui or data-driven: the data is managed separately from the display thereof. "Clock shape and style", to me, are presentation issues, independent of data (up to precision), and potentially independent of application. TopMind may need to clarify; the above description seems to be ambiguous.

View edit of June 16, 2009 or FindPage with title or text search