Subject: Re: [boost] [ANN] Boost.UI - a new C++ GUI library
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-09-28 13:14:21
On 28.09.2017 08:58, Kolya Kosenko via Boost wrote:
> 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.
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 ?
>>> - 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
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.
Â Â Â Â Â Â Stefan
-- ...ich hab' noch einen Koffer in Berlin...