[ANN] Boost.UI - a new C++ GUI library

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
Hello,

Here is my C++ GUI library based on Boost, it
- is cross-platform
- uses native system-provided widgets
- has STL-like and Boost-like API
- compatible with other Boost libraries
- supports modern C++11/14/17 features

Currently supported modules:
- Graphics
- Widgets
   * Command widgets
   * Data input-output widgets
     + Date and time pickers
     + Strings container widgets
     + Text widgets
   * Informational widgets
     + Logging
   * Containers
     + Alerts
     + Notifications
     + Prompts
- Layouts
- Events
- Audio
- Coordinates
- Localization
- Thread support
- Helpers

Documentation (and "Hello, World!" application source code):
https://kosenko.github.io/boost.ui/

Source code:
https://github.com/kosenko/ui

Beman's challenge:
https://github.com/kosenko/ui/blob/master/example/cpp11/beman.cpp

Re-implemented GUI examples from Bjarne Stroustrup's book:
https://github.com/kosenko/ui/blob/master/example/cpp11/stroustrup.cpp

Other examples:
https://github.com/kosenko/ui/tree/master/example

What do you think?

Regards,
Kolya Kosenko.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
I don't like the fact that it introduces its own event loop that I have no
control on.
What if I have other sources of data I want to poll in the main thread?

On 28 September 2017 at 12:11, Kolya Kosenko via Boost <
[hidden email]> wrote:

> Hello,
>
> Here is my C++ GUI library based on Boost, it
> - is cross-platform
> - uses native system-provided widgets
> - has STL-like and Boost-like API
> - compatible with other Boost libraries
> - supports modern C++11/14/17 features
>
> Currently supported modules:
> - Graphics
> - Widgets
>    * Command widgets
>    * Data input-output widgets
>      + Date and time pickers
>      + Strings container widgets
>      + Text widgets
>    * Informational widgets
>      + Logging
>    * Containers
>      + Alerts
>      + Notifications
>      + Prompts
> - Layouts
> - Events
> - Audio
> - Coordinates
> - Localization
> - Thread support
> - Helpers
>
> Documentation (and "Hello, World!" application source code):
> https://kosenko.github.io/boost.ui/
>
> Source code:
> https://github.com/kosenko/ui
>
> Beman's challenge:
> https://github.com/kosenko/ui/blob/master/example/cpp11/beman.cpp
>
> Re-implemented GUI examples from Bjarne Stroustrup's book:
> https://github.com/kosenko/ui/blob/master/example/cpp11/stroustrup.cpp
>
> Other examples:
> https://github.com/kosenko/ui/tree/master/example
>
> What do you think?
>
> Regards,
> Kolya Kosenko.
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Hi,

On 28.09.2017 07:11, Kolya Kosenko via Boost wrote:
> Hello,
>
> Here is my C++ GUI library based on Boost, it
> - is cross-platform
> - 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 ?

> - has STL-like and Boost-like API
> - compatible with other Boost libraries

What does that mean ?

> - supports modern C++11/14/17 features
>
> Currently supported modules:
> - Graphics
> - Widgets
>    * Command widgets
>    * Data input-output widgets
>      + Date and time pickers
>      + Strings container widgets
>      + Text widgets
>    * Informational widgets
>      + Logging
>    * Containers
>      + Alerts
>      + Notifications
>      + Prompts
> - Layouts
> - Events
> - Audio
> - Coordinates
> - Localization
> - Thread support
> - Helpers
>
> Documentation (and "Hello, World!" application source code):
> https://kosenko.github.io/boost.ui/

I'd be interested in some high-level documentation explaining the basic
programming and execution model of the API. For example, how are events
handled and how are they bound to particular actions ? Are programs
inherently multi-threaded or single-threaded (e.g., does the main event
loop run in its own thread) ?
Is your library mostly just a (thin) layer over existing
platform-specific GUI libraries, or does it reimplement a lot of the
logic itself ?

(And what is that cryptic "ui_main()" function ? :-) )

>
> Source code:
> https://github.com/kosenko/ui
>
> Beman's challenge:
> https://github.com/kosenko/ui/blob/master/example/cpp11/beman.cpp
>
> Re-implemented GUI examples from Bjarne Stroustrup's book:
> https://github.com/kosenko/ui/blob/master/example/cpp11/stroustrup.cpp
>
> Other examples:
> https://github.com/kosenko/ui/tree/master/example
>
> What do you think?
>
> Regards,
> Kolya Kosenko.

Thanks,
        Stefan

--

      ...ich hab' noch einen Koffer in Berlin...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> I don't like the fact that it introduces its own event loop that I have no
> control on.

This loop is designed to interact with user, all GUI librararies have
it. When user press button key he should wait while your loop have a
time to handle users request?

> What if I have other sources of data I want to poll in the main thread?

You can create your own thread and use boost::ui::call_async()
function to send data to main GUI thread.

Regards,
Kolya.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Hi Kolya,

> Here is my C++ GUI library based on Boost, it
> - is cross-platform
> - uses native system-provided widgets
> - has STL-like and Boost-like API
> - compatible with other Boost libraries
> - supports modern C++11/14/17 features
> […]

I looked at the code examples, which look neat. I also like the goal to have a cross-platform C++ lib for GUIs, but isn't an UI library too elaborate/invested for Boost? I am quite familiar with Qt and its a huge library, and yet it is moving fast to keep up with new trends. You would need a lot of active and dedicated developers to keep up and provide similar amounts of features.

Some people here probably shiver at the thought how Qt distorted C++ get things done, introducing its own preprocessor and missing language features in a non-standard way. I am not a fan either. And still, Qt is easy to work with and the documentation is outstanding. With KDE it has a large user base, too. It is hard to beat such competition.

Just my 2 cents.

Hans

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 9/28/2017 7:11 AM, Kolya Kosenko via Boost wrote:
> Hello,
>
> Here is my C++ GUI library based on Boost, it
> - is cross-platform
> - uses native system-provided widgets
> - has STL-like and Boost-like API
> - compatible with other Boost libraries
> - supports modern C++11/14/17 features

Here are some suggestions for what needs to be specified in the docs at
a general level:

1) Some explanation of the major concepts of your library.
2) On what Boost libraries does your library depend.
3) Level of C++ needed, header files to be included, and namespaces
being used, and possibly on what compilers it has been tested.

>
> Currently supported modules:
> - Graphics
> - Widgets
>     * Command widgets
>     * Data input-output widgets
>       + Date and time pickers
>       + Strings container widgets
>       + Text widgets
>     * Informational widgets
>       + Logging
>     * Containers
>       + Alerts
>       + Notifications
>       + Prompts
> - Layouts
> - Events
> - Audio
> - Coordinates
> - Localization
> - Thread support
> - Helpers
>
> Documentation (and "Hello, World!" application source code):
> https://kosenko.github.io/boost.ui/
>
> Source code:
> https://github.com/kosenko/ui
>
> Beman's challenge:
> https://github.com/kosenko/ui/blob/master/example/cpp11/beman.cpp
>
> Re-implemented GUI examples from Bjarne Stroustrup's book:
> https://github.com/kosenko/ui/blob/master/example/cpp11/stroustrup.cpp
>
> Other examples:
> https://github.com/kosenko/ui/tree/master/example
>
> What do you think?
>
> Regards,
> Kolya Kosenko.
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
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
> 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...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 09/28/2017 03:53 PM, Edward Diener via Boost wrote:
> On 9/28/2017 7:11 AM, Kolya Kosenko via Boost wrote:
> Here are some suggestions for what needs to be specified in the docs at
> a general level:

Thanks.

> 1) Some explanation of the major concepts of your library.

This concepts is already described in documentation, isn't it? Is it not
enough? "Boost.UI is a C++ User Interface Boost library that is
cross-platform, uses native system-provided widgets, has STL-like and
Boost-like API, compatible with other Boost libraries and supports
modern C++11/14/17 features."

> 2) On what Boost libraries does your library depend.

It depends only on Boost.Config library, other libraries could be
connected for data exchange.

> 3) Level of C++ needed,

It supports C++03/11/14/17 levels.

> header files to be included, and namespaces
> being used,

As described in examples master include file is boost/ui.hpp and
boost::ui namespace are used.

> and possibly on what compilers it has been tested.

I tested it with gcc 5.4.0, clang 3.8.0, msvc 9.0, 14.0.
I tried to add Boost.UI to blincubator.com, but this site seems broken.

There is no details in documentation because it is just first public
announce and many things could be changed.

Regards,
Kolya.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
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...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 09/28/2017 03:22 PM, Hans Dembinski via Boost wrote:
> I looked at the code examples, which look neat. I also like the goal to have a cross-platform C++ lib for GUIs, but isn't an UI library too elaborate/invested for Boost? I am quite familiar with Qt and its a huge library, and yet it is moving fast to keep up with new trends. You would need a lot of active and dedicated developers to keep up and provide similar amounts of features.

It isn't so hard as you think. Qt rewrites C++11/Boost features into own
library, so we can rewrite GUI features into Boost :)

> Some people here probably shiver at the thought how Qt distorted C++ get things done, introducing its own preprocessor and missing language features in a non-standard way. I am not a fan either. And still, Qt is easy to work with and the documentation is outstanding. With KDE it has a large user base, too. It is hard to beat such competition.

Qt has old style C++ API, moc and QML aren't C++ at all. Boost.UI for
developers that prefer modern C++11/17-like API with Boost libraries
support. Boost don't need to beat Qt, it is placed in an other niche.

Regards,
Kolya.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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#ga3513f8b6cac36cac1d66076e787298ac

Regards,
Kolya.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 9/28/2017 9:20 AM, Kolya Kosenko via Boost wrote:

> On 09/28/2017 03:53 PM, Edward Diener via Boost wrote:
>> On 9/28/2017 7:11 AM, Kolya Kosenko via Boost wrote:
>> Here are some suggestions for what needs to be specified in the docs at
>> a general level:
>
> Thanks.
>
>> 1) Some explanation of the major concepts of your library.
>
> This concepts is already described in documentation, isn't it? Is it not
> enough? "Boost.UI is a C++ User Interface Boost library that is
> cross-platform, uses native system-provided widgets, has STL-like and
> Boost-like API, compatible with other Boost libraries and supports
> modern C++11/14/17 features."

That is not an explanation of the major concepts of your library. That's
just a one-line overview.

>
>> 2) On what Boost libraries does your library depend.
>
> It depends only on Boost.Config library, other libraries could be
> connected for data exchange.
>
>> 3) Level of C++ needed,
>
> It supports C++03/11/14/17 levels.

That does not explain what library constructs support what levels. Are
you telling me that no matter what C++ level I compile your library
with, everything is implemented with the exact same syntax, and works
properly ? If not you need to explain what functionality needs what
level of C++.

>
>> header files to be included, and namespaces
>> being used,
>
> As described in examples master include file is boost/ui.hpp and
> boost::ui namespace are used.

Examples are not explanations.

>
>> and possibly on what compilers it has been tested.
>
> I tested it with gcc 5.4.0, clang 3.8.0, msvc 9.0, 14.0.
> I tried to add Boost.UI to blincubator.com, but this site seems broken.
>
> There is no details in documentation because it is just first public
> announce and many things could be changed.

It is precisely the details of what concepts your library implements
that will attract interested end-users.

I do not mean to sound harsh or not be encouraging, but Boost libraries
try to explain what they are about and are not documented only as a list
  of classes and a set of code examples.

>
> Regards,
> Kolya.
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Edward Diener via Boost
> Sent: 28 September 2017 16:21
> To: [hidden email]
> Cc: Edward Diener
> Subject: Re: [boost] [ANN] Boost.UI - a new C++ GUI library
>
> On 9/28/2017 9:20 AM, Kolya Kosenko via Boost wrote:


> > There is no details in documentation because it is just first public
> > announce and many things could be changed.

That's fine, but it isn't enough to be accepted as a Boost library - yet.
 
> It is precisely the details of what concepts your library implements
> that will attract interested end-users.

> I do not mean to sound harsh or not be encouraging, but Boost libraries
> try to explain what they are about and are not documented only as a list
>   of classes and a set of code examples.

I'd be very encouraging.  I suspect it meets a number of people's needs (if niche as you say).

From a quick view of the documentation, I felt I needed a tutorial to get me started.

You've got an excellent set of examples (and examples are often the most useful to novice users).

You might build on those examples by some text that refers (using links) to many of the examples explaining how/what they show.

Despite its good documenting of functions, class etc, the end results from Doxygen are generally very unpopular with users (often
having been bitten by the deluded who think that just feeding the code into is 'job done').

You haven't made this mistake, using the Doxygen syntax to document functions, class etc., and also using the text facilities to
provide some text.  You could consider using Quickbook etc. toolchain that is popular with Boost libraries and users, but that's
quite a big job unless you are sure that you have a user base.  Ask me if you want to start on this as I can probably make the
learning curve less precipitous ;-)

Good luck.

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
+44 (0) 1539 561830









_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, Sep 28, 2017 at 8:13 AM, Kolya Kosenko via Boost
<[hidden email]> wrote:

> > I don't like the fact that it introduces its own event loop that I have no
> > control on.

> This loop is designed to interact with user, all GUI librararies have
> it. When user press button key he should wait while your loop have a
> time to handle users request?

I haven't looked over your library at all yet, but I have bumped into
the problem of trying to integrate application code with an
inaccessible main loop.

Instead of providing your own main loop, you might consider using an
Asio io_service as your main event loop, and exposing (a subset of)
its API to your own library consumers. That would give you a certain
level of extensibility right out of the box.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
On 09/28/2017 11:27 PM, Nat Goodspeed via Boost wrote:
> I have bumped into
> the problem of trying to integrate application code with an
> inaccessible main loop.

Why you need a main loop? You can create an other (worker) thread and
sync all data and calls with GUI loop using boost::ui::call_async()
function.

Actually there is boost::ui::event_loop class, but it is only for
advanced users. You can see usage example in ui/src/frame.cpp file.

> Instead of providing your own main loop, you might consider using an
> Asio io_service as your main event loop, and exposing (a subset of)
> its API to your own library consumers. That would give you a certain
> level of extensibility right out of the box.

It sounds like a good idea. Thanks! :) Unfortunately I'm not familiar
with ASIO yet. boost::ui::event_loop looks very similar to io_service class.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>>> I don't like the fact that it introduces its own event loop that I have no
>>> control on.
>
>> This loop is designed to interact with user, all GUI librararies have
>> it. When user press button key he should wait while your loop have a
>> time to handle users request?
>
> I haven't looked over your library at all yet, but I have bumped into
> the problem of trying to integrate application code with an
> inaccessible main loop.
>
> Instead of providing your own main loop, you might consider using an
> Asio io_service as your main event loop, and exposing (a subset of)
> its API to your own library consumers. That would give you a certain
> level of extensibility right out of the box.

Another option is to copy AFIO's io_service design
https://ned14.github.io/afio/classafio__v2__xxx_1_1io__service.html:

- Don't implement a main loop, implement a function e.g. run() which
dispatches exactly one pending event, returning true if there was an
event processed.
- Said run() also comes in run_until(deadline) form, where deadline can
be "now" i.e. poll for an event, if one present dispatch it, else return
immediately.
- A post() routine lets any thread cause some user supplied callable to
be executed in the run().

Thence the programmer may write:

// Dispatch events, blocking if no new events, returning false if
// no work pending.
while(service.run());

Or they might write:

// Polling implementation, exits loop if no work pending
while(service.run_until(0))
{
  do other work;
}

The point is to open up your event dispatch so it can coexist with
whatever existing system the user is already using.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
On Thu, Sep 28, 2017 at 6:06 PM, Niall Douglas via Boost
<[hidden email]> wrote:

> - Don't implement a main loop, implement a function e.g. run() which
> dispatches exactly one pending event, returning true if there was an
> event processed.
> - Said run() also comes in run_until(deadline) form, where deadline can
> be "now" i.e. poll for an event, if one present dispatch it, else return
> immediately.
> - A post() routine lets any thread cause some user supplied callable to
> be executed in the run().

Yup, that's pretty much the subset of the io_service API I had in mind.

> The point is to open up your event dispatch so it can coexist with
> whatever existing system the user is already using.

Yes. Many applications and even frameworks want to own the main loop.
By default, Asio is one of them. Fortunately it does have these
integration-friendly alternatives.

Since you propose a Boost library, it would be a valuable exercise to
consider how best to integrate your framework with Asio -- especially
considering that something very like Asio is well on its way to
becoming part of the C++ Standard.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Boost.UI - a new C++ GUI library

Boost - Dev mailing list
I appreciate that someone has taken the (huge) step towards a cross
platform gui for c++ within boost, it's really something that I think it's
a big step forward for both boost and C++. (I havn't had the time to more
than glance through the examples)
It would be really great if it's crossplatforminess event extended to
android\ios\web assembly.

/Viktor

On Fri, Sep 29, 2017 at 7:51 PM Nat Goodspeed via Boost <
[hidden email]> wrote:

> On Thu, Sep 28, 2017 at 6:06 PM, Niall Douglas via Boost
> <[hidden email]> wrote:
>
> > - Don't implement a main loop, implement a function e.g. run() which
> > dispatches exactly one pending event, returning true if there was an
> > event processed.
> > - Said run() also comes in run_until(deadline) form, where deadline can
> > be "now" i.e. poll for an event, if one present dispatch it, else return
> > immediately.
> > - A post() routine lets any thread cause some user supplied callable to
> > be executed in the run().
>
> Yup, that's pretty much the subset of the io_service API I had in mind.
>
> > The point is to open up your event dispatch so it can coexist with
> > whatever existing system the user is already using.
>
> Yes. Many applications and even frameworks want to own the main loop.
> By default, Asio is one of them. Fortunately it does have these
> integration-friendly alternatives.
>
> Since you propose a Boost library, it would be a valuable exercise to
> consider how best to integrate your framework with Asio -- especially
> considering that something very like Asio is well on its way to
> becoming part of the C++ Standard.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12