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.
- 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 ?
It uses both Boost and C++11 classes )) For example you can use both std::chrono::duration and boost::chrono::duration classes in on_timeout() function.
what "subscription" model do you use ?
Sorry what does it means?
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.
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.
Are you saying that to use your library I have to run multiple threads ?
No, Boost.UI applications usually are single threaded, but thread 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.
Yes, documentation are weak like my English level. Regards, Kolya.