Development: wxTNG

There are a few threads related to wxWidgets3, which is generally referred to as wxTNG (the next generation - a star trek reference for the oblivious :))
This page is an attempt to try to bring ideas together information about it

Phase 1: Set the goals for wxTNG

Main goals

• Make it possible to use different backends to implement the same public API (rationale: the framework can't be acceptable to everyone otherwise)
• Use value-like semantics for the window classes instead of working with pointers to them, the user code shouldn't be concerned with memory management

Backwards compatibility

wxWidgets3 API can't be directly compatible with wxWidgets2 but we can't totally break the compatibility, so we need to provide wx2-compatible way to use wx3. Basically it's the 3-step plan with all steps being interleaved. We all agree on the API and build this as a library in CVS HEAD with several back-ends:

• Native back-ends
  • MSW
  • Mac
  • GTK2
  • etc.
• wxWidgets2 back-end (aka wxTNG2)

If we agree on the API, then we should be able to nibble away at the problem in both directions. Something like the building of the Chunnel, meeting at the middle :-) It also gives a fun element of competition, to see which approach bears fruit first, but neither approach will be redundant.[1]

Phase 2: Answer some crucial questions about global project organization

????

Phase 3: Propose (draft) API

• Moving away from an MFC-like API
  • Pros:
    • More modern API
  • Cons:
    • Sort of silly but what if part of wx's success is built upon its similarity/familiarity with MFC. (Well, someone had to put something here.) JS: this is certainly the case, a percentage of wxWidgets' success definitely is for this reason. These same people may also be conflicted about the need for compatibility/familiarity, versus moving on to better ways of doing things. This is where we need a magic trick whereby old-style and new-style programming styles co-exist. Or, a good way to migrate old code to new, such as a very clever translation tool.
    • Some_Random_User: I'm just a humble user of wxWidgets, but: i think it would be a bad idea to stick with an MFC-like API. There may be ppl wo are used to that API, but on the other hand I know many ppl who won't use wxWidgets just because "it smells so MFCish". And after all a change in the major version number is all about breaking an API and building a new one, and not just about improving the existing one, right?
• Using exceptions
• Using namespaces
• Using STL
• Using 3rd party libs (see below)
• Using templates
  • Use member templates (VC6 has no support etc.)?
  • Implement templates in source file or all in header for compiler (I.E. VC6) compatability?
  • kl: something like wxTextCtrl<double> would be great. (throws if no conversion possible) currently i use templated accessors to get functionality like this, but my hacks ontop of wx are quite lacking.
• Make it easy for language bindings to be created and maintained (see below)
• Making a runtime for wx like XPCOM
• Using C++'s built-in RTTI rather than wx's own
• Having everything ref-counted (presumably thread-safe)
• Using CSS-like fonts descriptions
• Drop support for VC6 and below due to its lack of member templates?
  • kl: if templates are used it would mean immense additionaly work and code obfuscation. if someone uses broken tools and better ones exist, it's not the librarys due to get it right.

(See the talk page for discussion.)

Phase 4: Implement it

The easy part?

Basing on other libraries...

For argumentation, see Development:_wxWidgets_3/LibsArgumentation

Pros & Cons

• Bugfixes are done by others and do not drain resources.
• New features become available to wxTNG without draining resources.
• wxTNG marketing visibility is increased when it uses popular 3rd party libraries
• learning curve for new users is reduced when they already know the other software
• Care has to be taken so that wxTNG does not begin to look like a giant patchwork with poorly connected structures and confusing documentation.

Requirements

• Wrap external libraries to provide a consistent interface within wxWidgets
  • except Boost?
• Distribute a copy of each external lib with wxWidgets
• Integrate external liberaries' documentation into wxWidget's documentation (or at least provide a copy)
• Make sure that there aren't any licence conflicts

Candidates

• IBM's Unicode library (ICU)
• libcurl
• boost
• libXml2

Binding to other Languages

(RD)

Reduce the reliance on virtual methods to be as small as possible

At least the goal should be that there are no virtual methods that are required to be used for end-user classes that derive from framework classes, including, if possible, creating custom controls and etc., and instead use something like events or signals/slots or whatever to get the same dynamic dispatch functionality. If there is something that will much be better implemented with a virtual and you don't want to give up the virtual, then there should also be an event/slot mechanism to do the same thing, or that is used by default. See wxWidgets3:API for an example.

• Pros:
  • Easier to wxPython/SWIG, possibly faster code
• Cons:
  • May result in complicated code

"Clean" headers without a lot of heavy macro use or complex C++ cruft

If the headers to be #included by the user code that define the public interfaces are relatively clean and simple then I can feed them directly to SWIG instead of needing to hand-craft an interface file for SWIG. All the complex and implementation specific things can be put in headers that only the framework sees. (I guess that this probably implies using the pImpl pattern or similar, which is probably a good thing anyway for maintaining ABI compatibility, etc.) A possible alternative is to put all the info about the public classes in some form of meta-data structure and then be able generate the interface definition files for wxPython from that, (and perhaps also the C++ headers and the API reference docs too!)

User-Data Pointer

Most C++ class instances should have a user-data pointer that is not used for anything in the framework. Where those pointers exist today I've been able to use them very effectively in wxPython for attaching some wxPython specific thing to the C++ object, that I can then access later when needed. This is especially true for whatever event dispatch mechanism will be used in wxTNG, as in that case the user-data pointer is a reference to the Python callable object to be called to handle the event.

• VZ: This is a very C-ish approach, in C++ there are really better ways. But I think that this is not very important, in the worst case you can just use a map to associate user-data with any pointer anyhow.
• CS: Agreed, I don't think we should map that to a true m_userRef datamember. In XTI I've implemented "Generic Properties" using a string keyed dictionary. Having a java package naming scheme should give each binding their own space.

Separation of __WXDEBUG__ and wxASSERT and similar

It would be nice if there was a separation of __WXDEBUG__ and wxASSERT and similar. In other words, if there was a way to leave the wxASSERTs, wxCHECKs, and etc. to be compiled in to the code without needing to have all of the rest of the __WXDEBUG__ code too. This is because I turn the wxASSERTs into Python exceptions that get raised when control returns to Python. On the other hand, if most of what we are using wxASSERT for today got turned into C++ exceptions which I could catch and turn into Python exceptions, and if those exceptions were still checked for and thrown even when __WXDEBUG__ is turned off then that would be just as good (and probably much better.)

Mailing list threads on this issue include:

wx-dev

1. Big API changes in wxWidgets - possible?
2. branch in cvs ? directory-layout ?
3. wxTNG: Object runtime and other musings
4. Event handling in wxTNG
5. wxTNG and Boost library
6. wxTNG or plugins:C++ ABI
7. wxTNG for newbies/tng branch in CVS?
8. Component support in wxTNG
9. wxWidgets and GNOME (tng)

wx-discuss

1. Future release strategy - sort of old and only slightly related
2. Chandler - the framework issue
3. Moving wxWidgets off the sidelines

Existing experimental implementations

• OMGUI can be seen as a try of wxTNG with the involvement of Mart Raudsepp and Robin McNeill, among other, that disregards any kind of compatibility with wxWidgets in favour of a fully clean API. It has existing core code and ideas.