-
Notifications
You must be signed in to change notification settings - Fork 336
Primary and Secondary Goals
Jinhao edited this page Apr 6, 2019
·
1 revision
That is. By putting it short and clear (specially the "standard" part) all the secondary goals, most designs decisions, implementation strategies, style, etc. are easy to define and understand. The "like" part avoids endless discussions about the convenience, practicability or even “political correctness” of proposing a std::gui
for C++. To our knowledge, no other C++ GUI library has this as a main goal, which assures a firm niche for nana existence.
This make easy to enumerate the secondary goals and characteristics of nana (just reproduce what is expected from any standard library - there is no need to defend/critic the technical solutions that do not fit the major goal).
- The really important part is the API (the design of the global structure, main classes and functions)
- GUI (and only GUI) programming support.
- The implementation is secondary, but is also important because there is a need to demonstrate that the API is viable.
- Nana have to be usable and used by many people to demonstrate that the API is viable.
- Need to play very well with the rest of the standard C++.
- Simply things have to be simple to do, but also offer a way to do complex things.
- etc.
Some explanations:
- With few exceptions, the (C++) standard defines only the API. Only some basic characteristics of the implementation are fixed in the standard. Most of the implementation is up to the “vendor” of the compiler or library to choose. Nana may add just some general recommendations about the structure of the code of the implementation and the impact it have on the users and the API.
- Almost any other GUI library try to offer a "complete packet", adding networking, data base, others language, etc. or whatever they think they need to support. As a C++ standard-like GUI library, nana do not need to add all of this.