Summary of Nana 2016 Survey

Thank you to 103 people who responded the survery! We’re thankful for all the great feedback.
What’s the status that you use Nana?

We got 34% people using Nana, 41% people are going to try. Through the number of users is very small, these people have been very loyal to the little opensource project.

There are 38% projects whose codebase is over 10K lines. It is certainly a good sign.

The most used widget

listbox, combox, treebox, tabbar, checkbox,  group,  inputbox,  slider, panel

Continually improving these widgets is the main task.

Summery of comment

I really cannot get used to the layout management.

I wanted to create a different layout management which is easy to use and supports dynamic change without writting complicated logical code. So I found a possible solution and designed a class place for layout management based on above principles. The class place is like a layout engine. Give a rule for the layout of a window, it automatically manages position and size of its child windows. The rule is expressed by a string, it is called div-text. In my opinion, div-text is better than traditional style of layout, you just write a string rather than write many lines codes and many layout objects. The layout can be changed when program runs by changing the div-text. It can keep your code clean. Now the class place is enhanced with many useful features, such as splitbar and dockable pane, and a new feature which can adjust a window according to its content is developing now.

Meanwhile, we need to face new problems. For example, layouting a window in the center, the div-text looks like this “vert <><<><window><>><>”, it is a bit werid. I am also looking forward to a new idea shared by contributors to perfectly fix these problems.

Would be great if some tooling was developed to design GUI.
There is no GUI designer tool.
A gui designer would be great.

Get 3 responses about the designer. I advocate to hande-code, because class place can simplify the layout management, and you can write more elegant code to help maintenance and integration. Moreover I don’t have much resource to start a such huge project, but fortunately, there is an early experiment, namely nana-creator. It’s new and young, if you like it and have much free time, please try to contribute code for it.

It would be great if there was a more complete documentation with examples for the various features.
More documentation would benefit the library
Try strictly base the documentation on Doxygen. It will make cross referencing easy, automatic, and consistent.

I will have to build up the examples and tutorials. I also encourage people to share your own experence by writting blog, then send me a link to the blog post.

Nana need modern light flat style IMHO. Classic 3D gradient style is obsolete a little now.

Agree with you, but I am not good at art design.

Maybe adding more info on the exception object so client code could see what could go wrong.

Very good suggestion.  I will improve the description of the exceptions. But there is still a problem. Generally, the outter functions doesn’t check the parameters if it is unnecessary, the inner functions will check the parameters and throw an exception if one of parameter doesn’t meet the requirement. The main problem is that the inner functions only can provide the info about what the error is, but how/why the error occurs.

OSX support would be nice.
You say it’s cross platform but OS X is not supported. Too bad

Hi, open “c++defines.hpp” you will find a line like this

#elif defined(APPLE)    //Mac OS X

But OS X is still experimental.

I suppose 4K resolution display will be common within a decade, so it would be really great if nana’s GUI rendering is DPI-aware.

The support of high DPI and DPI-aware are planned. This work will begin after release of 1.5.

The particular thing I use frequently (currently in WTL) is combo-boxes with a list of available serial ports that are updated based on the “plug-and-play” Windows messages.

Nana provides a platform-independent events system at a high-level abstraction, it does support to handle the native Windows messages. But using subclassing, it is possible to handle the native Windows messages. Please refer to the window-subclassing for details, see the WinMain().

Any chance to get Nana in standard lib or boost lib?

Really hard!

That’s the first time I have heard about Nana lib from the Meeting C++ tweet. Looks interesting, may be you can find an awareness sponsor.

It seems that no benefit for the sponsor now. Maybe I can provide some adv banners 🙂

One Comment

Leave a Reply