On 09/08/2010 08:53 AM, Mathias Gaunard wrote:
The current trend for GUIs is for them to be declarative, data-driven, and as automatic as possible. Basically, what would be nice, is specifying what data you have, what data you want, and not have to deal with any other detail. The system should then automatically select the most suitable widget, with the suitable disposition and sizes, and resize everything automatically on window resize etc.
You are raising a very important point here: As this entire discussion proves, the term "GUI library" is highly ambiguous. While some understand it to mean a library that implements a GUI *engine* (with a wide range of often conflicting requirements), others understand it as an API that is useful to *programatically interface* with a GUI toolkit. What application developers care most about is a powerful and convenient API that lets them bind their application logic to a graphical frontend. As such, I think this interface should be minimal, and focus on semantics, rather than style (for example by following the Model-View-Controller paradigm). (Styling from within the library should only be done as much as is required to convey the semantics. Everything else could be done completely outside this API, to give application users control over the styling, not programmers.) In contrast, some people seem to suggest that the internals of the (to-be-rewritten) GUI engine itself need to be implemented using boost components. All this strongly reminds me of the various discussions about a boost.xml library we had in the past: I argued that the API is the most important part of it (leaving room for third-party implementations to be plugged in), while others argued that the XML parser needs to be written using spirit, etc. The views didn't necessarily contradict each other, but demonstrate how different the focus was / is. Stefan -- ...ich hab' noch einen Koffer in Berlin...