German wrote on Sunday, June 19, 2011 at 21:31:01:
- A library for designing dialogs and forms - A library for specifying bindings between the interface and the application's data (or creating a view of it).
I think I will start by these two fundamental libraries on top of gtk.
I want that the specification of the gui can directly be embedded in C++ at compile time and that signals and bindings can also be given at runtime by name.
perhaps my opinion is biased by qt framework influence but it's a very mature product with 15 years of development history so i think they know what they are doing i think it's a mistake to try to do everything at compile time let's say half of the time the gui elements are dynamic in runtime sense so the compile-time-magic code would be used only roughly in 50% of cases while the runtime api should be there anyway once you start speaking about model-view-controller and variations you should drop the static (i.e. compile time) thing because the model, for instance, may be changed not only from the "gui end" but from some other place (e.g. from a non-gui-message handler) and the view may or may not be notified of this change and everything is setup at runtime in non trivial case i can't imagine a compile time code that will manage all the combined cases which may appear so my point is that primarily you should provide the "runtime" api rather than try to make a compile time dsel or the like (which means, yes, inheritance, virtual functions etc.) sorry for lengthy message, i hope you got my point but let me add that for me a portable gui library should be that with "qt spirit" which is, in fact, qt itself -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out