[boost] [ANN] Boost.UI - a new C++ GUI library
Kolya Kosenko via Boost
Here is my C++ GUI library based on Boost, it
- is cross-platform
- uses native system-provided widgets
- has STL-like and Boost-like API
- compatible with other Boost libraries
- supports modern C++11/14/17 features
Currently supported modules:
- Graphics
- Widgets
* Command widgets
* Data input-output widgets
+ Date and time pickers
+ Strings container widgets
+ Text widgets
* Informational widgets
+ Logging
* Containers
+ Alerts
+ Notifications
+ Prompts
- Layouts
- Events
- Audio
- Coordinates
- Localization
- Thread support
- Helpers
Documentation (and "Hello, World!" application source code):
https://kosenko.github.io/boost.ui/
Source code:
https://github.com/kosenko/ui
Beman's challenge:
https://github.com/kosenko/ui/blob/master/example/cpp11/beman.cpp
Re-implemented GUI examples from Bjarne Stroustrup's book:
https://github.com/kosenko/ui/blob/master/example/cpp11/stroustrup.cpp
Other examples:
https://github.com/kosenko/ui/tree/master/example
What do you think?
Regards,
Kolya Kosenko.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Mathias Gaunard via Boost
control on.
What if I have other sources of data I want to poll in the main thread?
On 28 September 2017 at 12:11, Kolya Kosenko via Boost <
Stefan Seefeld via Boost
On 28.09.2017 07:11, Kolya Kosenko via Boost wrote:
> Hello,
>
> Here is my C++ GUI library based on Boost, it
> - is cross-platform
> - uses native system-provided widgets
what widgets do you consider "system-provided" ? What backends do you
bind to on the different platforms, and can those bindings be changed ?
> - has STL-like and Boost-like API
> - compatible with other Boost libraries
What does that mean ?
> - supports modern C++11/14/17 features
>
> Currently supported modules:
> - Graphics
> - Widgets
> * Command widgets
> * Data input-output widgets
> + Date and time pickers
> + Strings container widgets
> + Text widgets
> * Informational widgets
> + Logging
> * Containers
> + Alerts
> + Notifications
> + Prompts
> - Layouts
> - Events
> - Audio
> - Coordinates
> - Localization
> - Thread support
> - Helpers
>
> Documentation (and "Hello, World!" application source code):
> https://kosenko.github.io/boost.ui/
I'd be interested in some high-level documentation explaining the basic
programming and execution model of the API. For example, how are events
handled and how are they bound to particular actions ? Are programs
inherently multi-threaded or single-threaded (e.g., does the main event
loop run in its own thread) ?
Is your library mostly just a (thin) layer over existing
platform-specific GUI libraries, or does it reimplement a lot of the
logic itself ?
(And what is that cryptic "ui_main()" function ? :-) )
>
> Source code:
> https://github.com/kosenko/ui
>
> Beman's challenge:
> https://github.com/kosenko/ui/blob/master/example/cpp11/beman.cpp
>
> Re-implemented GUI examples from Bjarne Stroustrup's book:
> https://github.com/kosenko/ui/blob/master/example/cpp11/stroustrup.cpp
>
> Other examples:
> https://github.com/kosenko/ui/tree/master/example
>
> What do you think?
>
> Regards,
> Kolya Kosenko.
Thanks,
Stefan
--
...ich hab' noch einen Koffer in Berlin...
Kolya Kosenko via Boost
> control on.
it. When user press button key he should wait while your loop have a
time to handle users request?
> What if I have other sources of data I want to poll in the main thread?
function to send data to main GUI thread.
Regards,
Kolya.
Hans Dembinski via Boost
> Here is my C++ GUI library based on Boost, it
> - is cross-platform
> - uses native system-provided widgets
> - has STL-like and Boost-like API
> - compatible with other Boost libraries
> - supports modern C++11/14/17 features
> […]
I looked at the code examples, which look neat. I also like the goal to have a cross-platform C++ lib for GUIs, but isn't an UI library too elaborate/invested for Boost? I am quite familiar with Qt and its a huge library, and yet it is moving fast to keep up with new trends. You would need a lot of active and dedicated developers to keep up and provide similar amounts of features.
Some people here probably shiver at the thought how Qt distorted C++ get things done, introducing its own preprocessor and missing language features in a non-standard way. I am not a fan either. And still, Qt is easy to work with and the documentation is outstanding. With KDE it has a large user base, too. It is hard to beat such competition.
Just my 2 cents.
Hans
Edward Diener via Boost
> Hello,
>
> Here is my C++ GUI library based on Boost, it
> - is cross-platform
> - uses native system-provided widgets
> - has STL-like and Boost-like API
> - compatible with other Boost libraries
> - supports modern C++11/14/17 features
a general level:
1) Some explanation of the major concepts of your library.
2) On what Boost libraries does your library depend.
3) Level of C++ needed, header files to be included, and namespaces
being used, and possibly on what compilers it has been tested.
Kolya Kosenko via Boost
>> - uses native system-provided widgets
>
> bind to on the different platforms, and can those bindings be changed ?
Windows Controls, Cocoa etc.
>> - compatible with other Boost libraries
>
coordinates, Boost.Chrono - boost::ui::on_timeout() function,
Boost.Date_Time library are used in date and time pickers etc.
> I'd be interested in some high-level documentation explaining the basic
> programming and execution model of the API.
> For example, how are events
> handled and how are they bound to particular actions ?
press button, native event handler eventually calls Boost.UI event
handler.
> Are programs
> inherently multi-threaded or single-threaded (e.g., does the main event
> loop run in its own thread) ?
your own threads using boost::ui::call_async() function.
Boost.UI library (like all other C++ GUI libraries) aren't thread safe
because native toolkits are not thread safe.
> Is your library mostly just a (thin) layer over existing
> platform-specific GUI libraries, or does it reimplement a lot of the
> logic itself ?
> (And what is that cryptic "ui_main()" function ? :-) )
deinitialization, cleanup. It is required for underlying toolkits.
Actually you can call some functions directly from main() function,
but it is at your own risk.
Regards,
Kolya.
Stefan Seefeld via Boost
> On 09/28/2017 03:02 PM, Stefan Seefeld via Boost wrote:
>>> - uses native system-provided widgets
>> what widgets do you consider "system-provided" ? What backends do you
>> bind to on the different platforms, and can those bindings be changed ?
> Native system-provided widgets means widgets from toolkits GTK+, Qt,
> Windows Controls, Cocoa etc.
header-only), this means that there will be multiple binaries to wrap
GTK or Qt, etc., yes ? Or do you use some plugin system to let end-users
load a backend at runtime ?
>>> - compatible with other Boost libraries
>> What does that mean ?
> Boost.Geometry and Boost.Polygon could be used with Boost.UI
> coordinates, Boost.Chrono - boost::ui::on_timeout() function,
> Boost.Date_Time library are used in date and time pickers etc.
why not simply use stdC++ (11) for this ?
>> I'd be interested in some high-level documentation explaining the basic
>> programming and execution model of the API.
> You can ask for implementation details here. Documentation explains only API.
Not quite: programming and execution models are hardly implementation
details. They are arguably more important than the API itself, to decide
whether this library is usable for specific applications.
>> For example, how are events
>> handled and how are they bound to particular actions ?
> Library subscribes to event handlers in native toolkit. When user
> press button, native event handler eventually calls Boost.UI event
> handler.
what "subscription" model do you use ? What are the events that I can
subscribe to ? How can I add my own event types & sources, and how do I
register callbacks ? (Again, this is first and foremost a conceptual
question, before being about the specific API.)
>> Are programs
>> inherently multi-threaded or single-threaded (e.g., does the main event
>> loop run in its own thread) ?
> There is main GUI thread and you should call GUI functions from other
> your own threads using boost::ui::call_async() function.
>
> Boost.UI library (like all other C++ GUI libraries) aren't thread safe
> because native toolkits are not thread safe.
Are you saying that to use your library I have to run multiple threads ?
>> Is your library mostly just a (thin) layer over existing
>> platform-specific GUI libraries, or does it reimplement a lot of the
>> logic itself ?
> Boost.UI is a rather thin layer with C++11/Boost support.
>
>> (And what is that cryptic "ui_main()" function ? :-) )
> ui_main() function call required for GUI initialization,
> deinitialization, cleanup. It is required for underlying toolkits.
> Actually you can call some functions directly from main() function,
> but it is at your own risk.
That's all a bit vague. This definitely requires better documentation if
you want to convince others to use your library.
Best,
Stefan
--
...ich hab' noch einen Koffer in Berlin...
Kolya Kosenko via Boost
> Here are some suggestions for what needs to be specified in the docs at
> a general level:
> 1) Some explanation of the major concepts of your library.
enough? "Boost.UI is a C++ User Interface Boost library that is
cross-platform, uses native system-provided widgets, has STL-like and
Boost-like API, compatible with other Boost libraries and supports
modern C++11/14/17 features."
> 2) On what Boost libraries does your library depend.
connected for data exchange.
> 3) Level of C++ needed,
> header files to be included, and namespaces
> being used,
boost::ui namespace are used.
> and possibly on what compilers it has been tested.
I tried to add Boost.UI to blincubator.com, but this site seems broken.
There is no details in documentation because it is just first public
announce and many things could be changed.
Regards,
Kolya.
Kolya Kosenko via Boost
> Who decides which ? Assuming your library is compiled (as opposed to
> header-only), this means that there will be multiple binaries to wrap
> GTK or Qt, etc., yes ? Or do you use some plugin system to let end-users
> load a backend at runtime ?
runtime is not supported, sorry.
>>>> - compatible with other Boost libraries
>>> What does that mean ?
>> Boost.Geometry and Boost.Polygon could be used with Boost.UI
>> coordinates, Boost.Chrono - boost::ui::on_timeout() function,
>> Boost.Date_Time library are used in date and time pickers etc.
>
For example you can use both std::chrono::duration and
boost::chrono::duration classes in on_timeout() function.
> what "subscription" model do you use ?
> What are the events that I can
> subscribe to ?
member functions. For example boost::ui::button::on_press(fn) calls fn
when user clicks on button.
> How can I add my own event types & sources, and how do I
> register callbacks ? (Again, this is first and foremost a conceptual
> question, before being about the specific API.)
are a part of GUI or GUI-related, for these you can use Boost.Signals2
library. Probably you can extend Boost.UI by your own classes in your
application, but it isn't tested yet.
> Are you saying that to use your library I have to run multiple threads ?
synchronization are supported:
https://github.com/kosenko/ui/blob/master/example/thread.cpp
> That's all a bit vague. This definitely requires better documentation if
> you want to convince others to use your library.
Stefan Seefeld via Boost
> On 09/28/2017 04:14 PM, Stefan Seefeld via Boost wrote:
>> Who decides which ? Assuming your library is compiled (as opposed to
>> header-only), this means that there will be multiple binaries to wrap
>> GTK or Qt, etc., yes ? Or do you use some plugin system to let end-users
>> load a backend at runtime ?
> It is decided during compilation and linking. Loading GUI backend at
> runtime is not supported, sorry.
Fine. My point is: this needs to be documented.
[...]
>
>> what "subscription" model do you use ?
> Sorry what does it means?
What is the mechanism you use to bind events to callbacks ? Is it
extensible, i.e. does it support adding new event types and event
sources ? Are events consumed by callbacks, or can I bind multiple
callbacks to a single event ? (And if so, is there a well-defined order
by which callbacks are executed ?) Etc., etc., that's all the stuff that
makes up a "subscription model".
>> What are the events that I can
>> subscribe to ?
> Event handler function called with on_*() prefix. Usually it is a class
> member functions. For example boost::ui::button::on_press(fn) calls fn
> when user clicks on button.
OK, so "button click" is an event type. Can I add my own ? And how is
the connection to the handler established ?
>> How can I add my own event types & sources, and how do I
>> register callbacks ? (Again, this is first and foremost a conceptual
>> question, before being about the specific API.)
> Custom event types and sources are not supported. I'm not sure that they
> are a part of GUI or GUI-related, for these you can use Boost.Signals2
> library. Probably you can extend Boost.UI by your own classes in your
> application, but it isn't tested yet.
custom event types and sources may not be GUI related, but they need to
be integrated with the application's main event loop. This kind of
extensibility needs to be designed right into the API.
Thanks,
Stefan
--
...ich hab' noch einen Koffer in Berlin...
Kolya Kosenko via Boost
> I looked at the code examples, which look neat. I also like the goal to have a cross-platform C++ lib for GUIs, but isn't an UI library too elaborate/invested for Boost? I am quite familiar with Qt and its a huge library, and yet it is moving fast to keep up with new trends. You would need a lot of active and dedicated developers to keep up and provide similar amounts of features.
library, so we can rewrite GUI features into Boost :)
> Some people here probably shiver at the thought how Qt distorted C++ get things done, introducing its own preprocessor and missing language features in a non-standard way. I am not a fan either. And still, Qt is easy to work with and the documentation is outstanding. With KDE it has a large user base, too. It is hard to beat such competition.
developers that prefer modern C++11/17-like API with Boost libraries
support. Boost don't need to beat Qt, it is placed in an other niche.
Regards,
Kolya.
Kolya Kosenko via Boost
>> Event handler function called with on_*() prefix. Usually it is a class
>> member functions. For example boost::ui::button::on_press(fn) calls fn
>> when user clicks on button.
>
> the connection to the handler established ?
boost::ui::widget::native_handle() function that returns native object
and you can do with native widgets what you want, i. e. subscribe to
custom events. But it isn't supported by Boost.UI.
When you call on_press(fn) function, library stores fn inside library
and when event raises it calls fn. You can subscribe multiple times at
the same event. It works like Boost.Signals2, but uses only predefined
GUI events/signals and not supports custom signals.
> custom event types and sources may not be GUI related, but they need to
> be integrated with the application's main event loop. This kind of
> extensibility needs to be designed right into the API.
https://kosenko.github.io/boost.ui/group__thread.html#ga3513f8b6cac36cac1d66076e787298ac
Edward Diener via Boost
> On 09/28/2017 03:53 PM, Edward Diener via Boost wrote:
>> On 9/28/2017 7:11 AM, Kolya Kosenko via Boost wrote:
>> Here are some suggestions for what needs to be specified in the docs at
>> a general level:
>
> Thanks.
>
>> 1) Some explanation of the major concepts of your library.
>
> This concepts is already described in documentation, isn't it? Is it not
> enough? "Boost.UI is a C++ User Interface Boost library that is
> cross-platform, uses native system-provided widgets, has STL-like and
> Boost-like API, compatible with other Boost libraries and supports
> modern C++11/14/17 features."
just a one-line overview.
>
>> 2) On what Boost libraries does your library depend.
>
> It depends only on Boost.Config library, other libraries could be
> connected for data exchange.
>
>> 3) Level of C++ needed,
>
> It supports C++03/11/14/17 levels.
you telling me that no matter what C++ level I compile your library
with, everything is implemented with the exact same syntax, and works
properly ? If not you need to explain what functionality needs what
level of C++.
>
>> header files to be included, and namespaces
>> being used,
>
> As described in examples master include file is boost/ui.hpp and
> boost::ui namespace are used.
>
>> and possibly on what compilers it has been tested.
>
> I tested it with gcc 5.4.0, clang 3.8.0, msvc 9.0, 14.0.
> I tried to add Boost.UI to blincubator.com, but this site seems broken.
>
> There is no details in documentation because it is just first public
> announce and many things could be changed.
that will attract interested end-users.
I do not mean to sound harsh or not be encouraging, but Boost libraries
try to explain what they are about and are not documented only as a list
of classes and a set of code examples.
Paul A. Bristow via Boost
> From: Boost [mailto:boost-...@lists.boost.org] On Behalf Of Edward Diener via Boost
> Sent: 28 September 2017 16:21
> To: bo...@lists.boost.org
> Cc: Edward Diener
> Subject: Re: [boost] [ANN] Boost.UI - a new C++ GUI library
>
> On 9/28/2017 9:20 AM, Kolya Kosenko via Boost wrote:
> > There is no details in documentation because it is just first public
> > announce and many things could be changed.
> It is precisely the details of what concepts your library implements
> that will attract interested end-users.
> I do not mean to sound harsh or not be encouraging, but Boost libraries
> try to explain what they are about and are not documented only as a list
> of classes and a set of code examples.
From a quick view of the documentation, I felt I needed a tutorial to get me started.
You've got an excellent set of examples (and examples are often the most useful to novice users).
You might build on those examples by some text that refers (using links) to many of the examples explaining how/what they show.
Despite its good documenting of functions, class etc, the end results from Doxygen are generally very unpopular with users (often
having been bitten by the deluded who think that just feeding the code into is 'job done').
You haven't made this mistake, using the Doxygen syntax to document functions, class etc., and also using the text facilities to
provide some text. You could consider using Quickbook etc. toolchain that is popular with Boost libraries and users, but that's
quite a big job unless you are sure that you have a user base. Ask me if you want to start on this as I can probably make the
learning curve less precipitous ;-)
Good luck.
Paul
---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
+44 (0) 1539 561830
Nat Goodspeed via Boost
<bo...@lists.boost.org> wrote:
> > I don't like the fact that it introduces its own event loop that I have no
> > control on.
> This loop is designed to interact with user, all GUI librararies have
> it. When user press button key he should wait while your loop have a
> time to handle users request?
the problem of trying to integrate application code with an
inaccessible main loop.
Instead of providing your own main loop, you might consider using an
Asio io_service as your main event loop, and exposing (a subset of)
its API to your own library consumers. That would give you a certain
level of extensibility right out of the box.
Kolya Kosenko via Boost
> I have bumped into
> the problem of trying to integrate application code with an
> inaccessible main loop.
sync all data and calls with GUI loop using boost::ui::call_async()
function.
Actually there is boost::ui::event_loop class, but it is only for
advanced users. You can see usage example in ui/src/frame.cpp file.
> Instead of providing your own main loop, you might consider using an
> Asio io_service as your main event loop, and exposing (a subset of)
> its API to your own library consumers. That would give you a certain
> level of extensibility right out of the box.
with ASIO yet. boost::ui::event_loop looks very similar to io_service class.
Niall Douglas via Boost
>>> control on.
>
>> This loop is designed to interact with user, all GUI librararies have
>> it. When user press button key he should wait while your loop have a
>> time to handle users request?
>
> I haven't looked over your library at all yet, but I have bumped into
> the problem of trying to integrate application code with an
> inaccessible main loop.
>
> Instead of providing your own main loop, you might consider using an
> Asio io_service as your main event loop, and exposing (a subset of)
> its API to your own library consumers. That would give you a certain
> level of extensibility right out of the box.
https://ned14.github.io/afio/classafio__v2__xxx_1_1io__service.html:
- Don't implement a main loop, implement a function e.g. run() which
dispatches exactly one pending event, returning true if there was an
event processed.
- Said run() also comes in run_until(deadline) form, where deadline can
be "now" i.e. poll for an event, if one present dispatch it, else return
immediately.
- A post() routine lets any thread cause some user supplied callable to
be executed in the run().
Thence the programmer may write:
// Dispatch events, blocking if no new events, returning false if
// no work pending.
while(service.run());
Or they might write:
// Polling implementation, exits loop if no work pending
while(service.run_until(0))
{
do other work;
}
The point is to open up your event dispatch so it can coexist with
whatever existing system the user is already using.
Niall
--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Nat Goodspeed via Boost
<bo...@lists.boost.org> wrote:
> - Don't implement a main loop, implement a function e.g. run() which
> dispatches exactly one pending event, returning true if there was an
> event processed.
> - Said run() also comes in run_until(deadline) form, where deadline can
> be "now" i.e. poll for an event, if one present dispatch it, else return
> immediately.
> - A post() routine lets any thread cause some user supplied callable to
> be executed in the run().
> The point is to open up your event dispatch so it can coexist with
> whatever existing system the user is already using.
By default, Asio is one of them. Fortunately it does have these
integration-friendly alternatives.
Since you propose a Boost library, it would be a valuable exercise to
consider how best to integrate your framework with Asio -- especially
considering that something very like Asio is well on its way to
becoming part of the C++ Standard.
Viktor Sehr via Boost
platform gui for c++ within boost, it's really something that I think it's
a big step forward for both boost and C++. (I havn't had the time to more
than glance through the examples)
It would be really great if it's crossplatforminess event extended to
android\ios\web assembly.
/Viktor
Niall Douglas via Boost
> consider how best to integrate your framework with Asio -- especially
> considering that something very like Asio is well on its way to
> becoming part of the C++ Standard.
cannot be in any way compatible with ASIO's io_service. On POSIX async
file and socket i/o use completely incompatible systems, and on Windows
the 99% latencies with file i/o on IOCP are an order of magnitude worse
than the alertable i/o mechanism used by AFIO.
Besides, according to empirical testing, most users will not want to use
async file i/o with anything but non-cached i/o i.e. 4Kb multiples to
4Kb aligned offsets. Async i/o with cached i/o is never better, and
usually much worse, than synchronous i/o on SSD or better storage. AFIO
v2 is designed accordingly, there isn't much async actually in there
compared to v1. Hardware and OSs have very significantly changed.
A whole new generation of storage (DAX) lands next year, it appears to
the CPU as if it were RAM, so it's basically permanently mapped into
memory and taking advantage of that 64 bit address space. AFIO performs
excellently on such storage, nanosecond scale i/o latencies. But it
completely upends how you design i/o, for example iostreams really sucks
on DAX storage, it's unbelievably inefficient. You simply cannot max out
a DAX device if you're using iostreams, not even close.
I may float AFIO for standardisation next year. C++ will need to keep up
with hardware improvements in order to stay relevant.
Niall
--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Nat Goodspeed via Boost
wrote:
> Since you propose a Boost library, it would be a valuable exercise to
> consider how best to integrate your framework with Asio -- especially
> considering that something very like Asio is well on its way to
> becoming part of the C++ Standard.
Not sure if that was intended for me or the OP,
Stefan Seefeld via Boost
> On Sep 29, 2017 6:17 PM, "Niall Douglas via Boost" <bo...@lists.boost.org>
> wrote:
>
>> Since you propose a Boost library, it would be a valuable exercise to
>> consider how best to integrate your framework with Asio -- especially
>> considering that something very like Asio is well on its way to
>> becoming part of the C++ Standard.
> Not sure if that was intended for me or the OP,
>
>
> Sorry for the ambiguity, Niall, my remark was directed at the OP.
(You should consider fixing your mail client. Even in this reply it
isn't clear what's yours and what's Niall's reply...)
Stefan
--
...ich hab' noch einen Koffer in Berlin...
Gottlob Frege via Boost
<bo...@lists.boost.org> wrote:
> Hello,
>
> Here is my C++ GUI library based on Boost, it
> - is cross-platform
> - uses native system-provided widgets
> - has STL-like and Boost-like API
> - compatible with other Boost libraries
> - supports modern C++11/14/17 features
>
> Currently supported modules:
> - Graphics
> - Widgets
> * Command widgets
> * Data input-output widgets
> + Date and time pickers
> + Strings container widgets
> + Text widgets
> * Informational widgets
> + Logging
> * Containers
> + Alerts
> + Notifications
> + Prompts
> - Layouts
I find most UI toolkits embed layout stuff into the widgets instead of
making it orthogonal.
Klaim - Joël Lamotte via Boost
bo...@lists.boost.org> wrote:
> Hello,
>
> Here is my C++ GUI library based on Boost, it
> - is cross-platform
> - uses native system-provided widgets
> - has STL-like and Boost-like API
> - compatible with other Boost libraries
> - supports modern C++11/14/17 features
>
> [...]
> Documentation (and "Hello, World!" application source code):
> https://kosenko.github.io/boost.ui/
Could you clarify how does this library compares, in the fundamentals
concepts, to the Nana gui library?
http://nanapro.org/en-us/
Or is it following the same principles?
Joël Lamotte
Kolya Kosenko via Boost
> Can I incorporate my own layout system?
> I find most UI toolkits embed layout stuff into the widgets instead of
> making it orthogonal.
boost::ui::widget::on_resize() function and you can move widgets. Client
widget area isn't exposed yet, but it is possible to add it.
Also you can implement layout similar to vbox and hbox classes.
Kolya Kosenko via Boost
> Could you clarify how does this library compares, in the fundamentals
> concepts, to the Nana gui library?
> http://nanapro.org/en-us/
>
> Or is it following the same principles?
Nana library don't uses native widgets. And it is a huge problem. Users
will not have expected look and feel. Widgets on screenshots are awful.
Even GTK+ and Qt applications under Windows looks much better then Nana
applications.
Also Boost.UI has fluent interfaces for widget initialization, that is
much simpler for developers then Nana library approach. Nana has
unsubstantiate complex API.