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