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
On 28.09.2017 08:58, Kolya Kosenko via Boost wrote: 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...