[ANN] Boost.UI - a new C++ GUI library - Boost

[ANN] Boost.UI - a new C++ GUI library

older
Boost Trac, random, No-Maintainer?

Kolya Kosenko

28 Sep 2017 28 Sep '17

11:11 a.m.

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 - 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.

Show replies by date

Mathias Gaunard

28 Sep 28 Sep

12:02 p.m.

I don't like the fact that it introduces its own event loop that I have no 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 < boost@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 - 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

Kolya Kosenko

12:13 p.m.

...

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?

...

What if I have other sources of data I want to poll in the main thread?

You can create your own thread and use boost::ui::call_async() function to send data to main GUI thread. Regards, Kolya.

Nat Goodspeed

8:27 p.m.

On Thu, Sep 28, 2017 at 8:13 AM, Kolya Kosenko via Boost 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?

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.

Kolya Kosenko

9:58 p.m.

On 09/28/2017 11:27 PM, Nat Goodspeed via Boost wrote:

...

I have bumped into the problem of trying to integrate application code with an inaccessible main loop.

Why you need a main loop? You can create an other (worker) thread and 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.

It sounds like a good idea. Thanks! :) Unfortunately I'm not familiar with ASIO yet. boost::ui::event_loop looks very similar to io_service class.

Niall Douglas

10:06 p.m.

...

...
...
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?

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.

Another option is to copy AFIO's io_service design 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

29 Sep 29 Sep

5:51 p.m.

On Thu, Sep 28, 2017 at 6:06 PM, Niall Douglas via Boost 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().

Yup, that's pretty much the subset of the io_service API I had in mind.

...

The point is to open up your event dispatch so it can coexist with whatever existing system the user is already using.

Yes. Many applications and even frameworks want to own the main loop. 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

9:51 p.m.

I appreciate that someone has taken the (huge) step towards a cross 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 On Fri, Sep 29, 2017 at 7:51 PM Nat Goodspeed via Boost < boost@lists.boost.org> wrote:

...

On Thu, Sep 28, 2017 at 6:06 PM, Niall Douglas via Boost 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().

Yup, that's pretty much the subset of the io_service API I had in mind.

...
The point is to open up your event dispatch so it can coexist with whatever existing system the user is already using.

Yes. Many applications and even frameworks want to own the main loop. 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.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Niall Douglas

10:17 p.m.

...

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, but in AFIO's case we 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

30 Sep 30 Sep

12:12 a.m.

On Sep 29, 2017 6:17 PM, "Niall Douglas 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, Sorry for the ambiguity, Niall, my remark was directed at the OP.

Stefan Seefeld

12:23 a.m.

On 29.09.2017 20:12, Nat Goodspeed via Boost wrote:

...

On Sep 29, 2017 6:17 PM, "Niall Douglas 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,

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...

Stefan Seefeld

28 Sep 28 Sep

12:02 p.m.

Hi, 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...

Hans Dembinski

12:22 p.m.

Hi Kolya,

...

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

Kolya Kosenko

2:25 p.m.

On 09/28/2017 03:22 PM, Hans Dembinski via Boost wrote:

...

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.

It isn't so hard as you think. Qt rewrites C++11/Boost features into own 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.

Qt has old style C++ API, moc and QML aren't C++ at all. Boost.UI for 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.

Edward Diener

12:53 p.m.

On 9/28/2017 7:11 AM, Kolya Kosenko via Boost 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

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. 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.

...

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

Kolya Kosenko

1:20 p.m.

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."

...

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.

...

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. Regards, Kolya.

Edward Diener

3:20 p.m.

On 9/28/2017 9:20 AM, Kolya Kosenko via Boost wrote:

...

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."

That is not an explanation of the major concepts of your library. That's 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.

That does not explain what library constructs support what levels. Are 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.

Examples are not explanations.

...

...
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.

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.

...

Regards, Kolya.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Paul A. Bristow

3:52 p.m.

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener via Boost Sent: 28 September 2017 16:21 To: boost@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.

That's fine, but it isn't enough to be accepted as a Boost library - yet.

...

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.

I'd be very encouraging. I suspect it meets a number of people's needs (if niche as you say).

...

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

Gottlob Frege

10 Oct 10 Oct

3 p.m.

On Thu, Sep 28, 2017 at 7:11 AM, Kolya Kosenko via Boost 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

Can I incorporate my own layout system? I find most UI toolkits embed layout stuff into the widgets instead of making it orthogonal.

...

- 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

Kolya Kosenko

6:17 p.m.

On 10/10/2017 06:00 PM, Gottlob Frege via Boost wrote:

...

Can I incorporate my own layout system? I find most UI toolkits embed layout stuff into the widgets instead of making it orthogonal.

I think it is possible, but I haven't tested it yet. There is 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.

Klaim - Joël Lamotte

4:08 p.m.

On 28 September 2017 at 13:11, Kolya Kosenko via Boost < boost@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

7:56 p.m.

On 10/10/2017 07:08 PM, Klaim - Joël Lamotte via Boost wrote:

...

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.

2588

Age (days ago)

2600

Last active (days ago)

List overview

Download

21 comments

11 participants

participants (11)

Edward Diener
Gottlob Frege
Hans Dembinski
Klaim - Joël Lamotte
Kolya Kosenko
Mathias Gaunard
Nat Goodspeed
Niall Douglas
Paul A. Bristow
Stefan Seefeld
Viktor Sehr