Development: wxTNG/LibsArgumentation

From WxWiki
Jump to: navigation, search

orginally posted on Development: wxTNG

Arguments against

JS: (Heresy must be heard![HK:agree100%!]) One problem I foresee when using a class from this library, a class from that library, is a lack of overall coherence. One of the things people probably like about current wxWidgets is the centralisation of the documentation, consistent naming conventions, and availability of 90% of what they need in one library. As far as I know, other GUI frameworks don't pick and choose from multiple libraries. So contrary to the argument about being easier to learn, some people will find it harder because they have to effectively learn multiple libraries, each with slightly different ways of doing things. So while the principle of reusing existing code sounds very wholesome and correct, there is the possibility that users will vote with their feet if faced with an API that seems to lack consistency. A question to be answred is: What other projects mix and match to this extent, and how successful are they? And what might existing users think? (Assuming we can't afford to alienate all our existing users.)

  • I've clarified my suggestion above regarding internal vs. external use of 3rd party libs
  • Where lack of consistency becomes a concern, I would include a 'front panel' to the 3rd party library. Examples today are wxString <-> std::string or the compatibility_iterators to the other STL classes. Looks like a wx class but uses std internally.
    • Caveat: wxFrontPanel should be directly exchangeable with the class behind.
  • wxTNG should still look like one library. If it were to use boost, it's installer should contain boost or the relevant boost subset. Same with any other libs it might need.
  • One very, very popular project that mixes and matches to an even greater extend is the Linux operating system. My assumption is also that linux programmers are quite used to using multiple libraries from different sources, whereas Windows programmers, especially newbies, will expect to get everything out of one hand. I'd try to find common ground: using other libs carefully and providing a robust installation mechanism with everything from one source.
    • Is it really a problem for users to learn libcurl if wxTNG installer included libcurl and its documentation? If wxTNG documentation had a short page refering the user to the libcurl documentation?
    • regarding license differences - need to take care here that users are not overwhelmed by lots of different licenses


  • We might offer bridging classes, that allow old-style wx code to continue to work
  • We cannot do everything ourselves, especially not in the quality that is needed. These library are broader and more optimized than most of our implementations in the respective areas. This includes documentation. We are also more appealing to a new user if the only API they have to learn is the API that is specific, not also our collection classes, event handlers etc. Boost delivers a lot of classes to the new C++ standard.

orginally postet on wxWidgets3:Goals

[HK]Make wxTNG lean and mean: avoid the "Not invented here" syndrom.

  • Concentrate our efforts on what is unique to wxWidgets.
    1. Replace as much of current wxWidgets functionality with 3rd party libraries of at least as good quality as current. Examples (these are suggestions!):
      1. Decide which 3rd party libs to use (internal use). Internal use means use of the library is hidden from the library user (our customer). Examples:
        • using std::list for internal lists (static, protected or private members)
      2. Decide which 3rd party libs to require (external use). External use means: a library user is required to pass structures defined by an external library to wxTNG. Examples:
        • using std::string for all strings. The user must pass std::string to SetLabel
        • using std::exceptions for error reporting. The user must catch std::exceptions.
        • using boost::filesystem to pass in filenames to wxXmlResource::Load
        • using boost::signal or bost::function to get versatile events / eventhadlers (kl)
      3. Decide which 'front plates' to create to hide 3rd party libs from the user. Examples:
        • Creating wxFilename class that uses boost::filesystem internally.
    2. replace WX_DECLARE_LIST... with STL
    3. replace wxThreads with boost::thread (KT Warning: I found a small bug in boost::thread, but as I didn't need to use it I even don't remember now what the bug was)
    4. wxFileName with boost::filesystem
    5. wxURL with appropriate url library
    6. Decide on an other buildsystem
        • replace bakefile with boost::build version 2
        • replace bakefile with cmake which would make maintaining static/dynamic/unicode/ etc builds very easy. (see wxArt2D, it has an optional gui and produces native makefiles / projectfiles) (kl)
  • Benefits are:
    1. Bugfixes are done by others and do not drain resources.
    2. New features become available to wxTNG without draining resources.
    3. wxTNG marketing visibility is increased when it uses popular 3rd party libraries
    4. learning curve for new users is reduced when they already know the other software
  • Drawbacks are:
    1. Care has to be taken so that wxTNG does not begin to look like a giant patchwork with poorly connected structures and confusing documentation. Only those libraries should be choosen that are either
      • Standard today (STL)
      • Quasi standard or likely to become standard (boost). Some boost classes are going to be included in the next C++ language release (an overview of what to expect in the next C++ language release).
      • Widely known