Re: Nana, a free C++ GUI library, v0.1.16 released
Am 16.12.2011 18:21, schrieb Jinhao:
I have been working on an open-source C++ library for GUI application.
The library is designed to be cross-platform and C++ style.
Get it from http://stdex.sourceforge.net
Although C++ is a powerful and sytnax-agile language, in fact, many
programmers don't like to do GUI in C++, because it is so difficault
to make GUI in C++. Some exsiting C++ GUI frameworks define their own
rule that makes you write some stiff code for running, it always
causes some problems, such as leaving your code in a deep inheritance
hierarchy, making maintenance painful. Now, there is an alternative,
Nana C++ Library, a pure C++ library that will guide you in doing GUI
with your immense and extensive C++ knowledge/skill/idioms, it makes a
great progress in doing GUI in C++.
Easy-to-Learn, Easy-to-Use
How easy to create a Hello World program with Nana?
#include<nana/gui/wvl.hpp>
#include<nana/gui/widgets/label.hpp>
int main()
{
using namespace nana::gui;
form fm;
label lb(fm, 0, 0, fm.size().width, fm.size().width);
lb.caption(STR("Hello, World"));
fm.show();
exec();
}
I think it is a great idea of you to freshly start to define a new C++
UI API based on modern concepts of the language and it looks to me like
a good base for a possible extension suggestion for C++.
My main complain is just visible in your first example code: I'm really
not happy with this construction
STR("Hello, World")
where any basic usage of your UI library would require using a macro
like STR and reminds me to TCHAR windowisms. If users ask for it, just
give it to them, but it seems that your design focuses on this. I would
very much prefer if you basic API would not require this. It would be
great if your library would allow either of char or wchar_t (or even
either of the other new character types) or just allow all of them.
Compare this with a recent C++ TR2 suggestion for a file_system library
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3239.html
that provides an alternative approach. Here exists an
implementation-specific path::value_type that could be any character
type, but the library provides templates (allowing either of char,
wchar_t, char16_t, or char32_t) as arguments for functions taking
characters or character sequences.
This means that your library could still keep with a single character
type, but that you provide templates to allow user-code to use any
character type.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]