Re: [boost] [ANN] Boost.UI - a new C++ GUI library
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.
- 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.
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.
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.
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.
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. Regards, Kolya.
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...
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.
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...
On 09/28/2017 05:23 PM, Stefan Seefeld via Boost wrote:
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 ?
No, Boost.UI not supports custom events. But there is boost::ui::widget::native_handle() function that returns native object and you can do with native widgets what you want, i. e. subscribe to custom events. But it isn't supported by Boost.UI. When you call on_press(fn) function, library stores fn inside library and when event raises it calls fn. You can subscribe multiple times at the same event. It works like Boost.Signals2, but uses only predefined GUI events/signals and not supports custom signals.
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.
You can use boost::ui::call_async() to sync with main (GUI) event loop. https://kosenko.github.io/boost.ui/group__thread.html#ga3513f8b6cac36cac1d66... Regards, Kolya.
participants (2)
-
Kolya Kosenko -
Stefan Seefeld