Re: [boost] Thoughts for a GUI (Primitives) Library

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
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_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 <
lucanus.j.simonson_at_[hidden]> 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