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

Back-ends

It must be possible to use different backends (wxMSW, wxMac, etc) to implement the same public API [1].

Possible approaches:

• pImpl-based (like OMGUI)
• template-based (like WxWidgets3:API)
• making a runtime for wx like XPCOM (see discussion page)

RD: 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. (Easier to wxPython/SWIG)

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 we all agree on the API and build this as a library in CVS HEAD with several back-ends[2]:

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

Pros

• This approach allows us to get something running (using the new API) almost immediately using the wx2 back-end
• This approach still provides an easy way to build new native back-ends in the long term
• Improvements in wx2 will result in improvements of wx3 when using the wx2 back-end
• No major modifications of wx2 required

Others

• 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

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
    • 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?
    • Other_Random_User: Coming from the Unix world, I wasn't very happy about some old fashioned, sloppy aspects of the API; As I know the MFC API a bit, I soon realized that this is just "the windows way" to do it. Please get rid of that! Also you should note, the MFC is history itself, so in some years, nobody would think of a MFCish API as esp. "familiar" to him.
  • 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.
• 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)
• 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.
  • VC2003 (aka VC7) has nasty restrictions on distributing the C library DLLs which serious affect GPL software. VC6 C library is distributed with the OS so that isn't a problem. VC2005 should be examined for VC8 redistributeables. The point is that dropping VC6 can have serious licensing implications for apps that want to use wxWidgets

(See the talk page for discussion.)

Phase 4: Implement it

The easy part?

Basing on other libraries...

For argumentation, see Development:_wxWidgets_3/LibsArgumentation and [3]

Pros & Cons

• Bugfixes are done by others and do not drain resources.
  • On the flip side, it makes the project depedant on those who are familiar with said libraries to fix the code - and sometimes that means wx itself.
• 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
• Do these libs support all our platforms?
  • embedded ones?
• Do these libs support all significant compilers?
• What about overhead?
  • code size on embedded apps?
  • What about library and app compilation speed?
• Make the install of wx and other library easier for the simple user, when there is many libraries it become more difficult !

Candidates

• IBM's Unicode library (ICU)
• libcurl
• boost
• libXml2
• SpiderMonkey (Mozilla JavaScript engine)
• WebKit
• PTypes

RD: Binding to other Languages

"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.