Subject: Re: [boost] Thoughts for a GUI (Primitives) Library
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2010-09-06 13:26:28
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
- 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
On Thu, Sep 2, 2010 at 11:53, Thomas Klimpel <Thomas.Klimpel_at_[hidden]>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_at_[hidden]> 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 <
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk