Re: [boost] A GUI Library

Subject: Re: [boost] A GUI Library
From: jinhao (cnjinhao_at_[hidden])
Date: 2012-06-27 10:49:49

On 2012/6/27 16:24, Klaim - Joël Lamotte wrote:
> Hi,
> 
> On Wed, Jun 27, 2012 at 2:55 PM, jinhao<cnjinhao_at_[hidden]>  wrote:
> 
>> Is there any interest in this library?
> 
> 
> My current understanding is that both Boost and the Standard C++ commitee
> are interested in fully C++ library.
> 
> However, the subject is complex and no library until now gathered
> enough consensus to even get to the review  stage of the boost process
> (from memory).
> You have to be ready for tons of feedback pointing problems.
> 
> Now, I just read the websites but I have some questions:
> 
>   1. can you write somewhere a big comparison between your library and other
> popular GUI C++ libraries?

Nana library is written though standard C++, this is a big difference between other
libraries, as the brief mentioned, C++ idioms should works with a C++ library, and
this is why the other popular GUI C++ libraries are not really C++ style at all.
Secondly, this library can be work with a thread pool, it reduces the difficulty
for threadization.

>   2. if you want to submit your library to Boost, I think  it would need to
> be compatible (or maybe just use) boost.thread instead of your own solution

I recognize that many ideas of my own solutions come from boost, not only

boost.thread, there are boost.function, boost.any and so on, this is why I

try to submit this library to boost and erase all my own solutions.

>   3. the STR macro is a big problem, I think it will be a big source of
> negative feedback. Now that we have boost.locale, would it be possible to
> work with it instead?

Somebody told me the problem before, I left the problem and searched a solution,
I found many problem can be fixed by boost, and I rethink, can't keep on stealing
ideas from boost. This is also why I try to submit this library to boost.

>   4. I understand how you can build a GUI application in a way that is
> mostly a list of statements. Does it means that you'd better organize your
> windows/forms "types" as constructor functions? (ok found this that
> partially answer my question:
> http://nanaproject.wordpress.com/2012/01/31/idioms-and-insights-for-a-good-design/)
>   5. It is said that Nana is cross-platform, but I don't see any
> demonstration of this (nevermind, I just found this:
> http://nanaproject.wordpress.com/2012/05/16/tutorial-of-release-0-2-3/ )
>      What are the target platforms?

Target platforms should be Windows, Linux and Mac OS X, but now, it only works under
Windows(GDI) and Linux(X11), the next is ready for Linux(framebuffer). A friend of
mine asks for the support of framebuffer, so I leave the Mac OS X now.

>   6. Should it work in non-graphic contexts like command-line only display?
>   (I'm thinking about GUI working in bash for example)
Yes, like ncurses. But now it is not able to work in such environment.

>   7. Is it thought to be easily extendable? For example, can I write myself
> a new front-end implementation and plug it in?

The library provide a general method to implement a customer widget, and supports
external image-processing algorithm implementation
(http://nanaproject.wordpress.com/2012/04/17/an-introduction-to-the-image-processing-interfaces-from-release-of-0-2-2/)

>   8. do you have an available example of complex application being built
> with this library?

Yes, but its language is Chinese, it is a stock software, a screenshot at
http://sourceforge.net/projects/stdex
The status of this library I give is alpha and the so library is not used widely.

Best Regards!
Jinhao