I've taken a look at the libraries mentioned in this thread. My comments: - main/WinMain/whatever (notus, omgui): The library shall not implement the main() for me. I may want to use it as a sub-library in my library. To eliminate the need of writing #ifdefed main in standalone apps, it's better to use a MACRO that expands to the correct entry function. - Static event handling tables (omgui, gtkmm): This is "what you don't use you don't pay for" issue. In most cases I don't need to do dynamic handler connect/disconnect. So, if there are N copies of my custom-omega-super-control with M event handlers, I want the memory footprint be O(N+M), not O(NM). - Model/View (omgui, gtkmm): As Tony already noted: "Ask the model, not the view". A checkbox with isChecked() function is wrong. Actually both these libraries implement multi-platform interface to low-level primitives. They don't simplify gui development. Really, I don't see how they are better than e.g. wxWidgets. They all (including wxWidgets and Qt) just mimic OS interface in a portable way and add a bit sugar to object oriented event handling. Both Notus and Adam&Eve sounds promising in the last aspect. However Adam&Eve aim to simplify dialog development only, they're not a general gui framework, right? On Thu, Sep 2, 2010 at 11:53, Thomas Klimpel <Thomas.Klimpel@synopsys.com>wrote:
There are also lots of other C++ GUI systems around, none of which I have ever found personally flexible enough.
Still, why start yet another imperfect GUI system then? Wouldn't it make more sense to help one of the existing GUI systems to become more perfect (or at least perfect enough to be acceptable)?
Because the design of existing GUI systems is rotten. 6 out of 7 general purpose gui libraries mentioned in this thread actually have the same 20 years old design (see Model/View above). You can't radically change the design of an existing project, it's either very hard or people won't agree. On Thu, Sep 2, 2010 at 22:09, Binglong Xie <binglongx@gmail.com> wrote:
2). Design tool support. Crafting GUI with lines and lines of hand written C++ code may not scale for complex GUI (unless C++ reaches that expressiveness of a much higher level). The C++ GUI framework will need to have a matching GUI design tool. [...] None of above is easy.
In assumption that you solved all the other problem, this one becomes a piece of cake.
[...] Maybe lessons from Java could be learned. AWT vs. Swing, native look&feel vs. uniform look&feel blah blah. Each one has lovers and haters. [...]
On Thu, Sep 2, 2010 at 23:04, Simonson, Lucanus J < lucanus.j.simonson@intel.com> wrote:
What application domain are you targeting? Games have pretty different requirements from office type applications.
These two are good metrics for generality of the library. It should be possible to easily switch the back-ends. E.g. changing from native look&feel to uniform look&feel. The same is true for GUI for games. How exactly do games have different requirement? It's the same concepts at the end. Yakov