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 Development: wxTNG/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.
    • Third_Random_User as a correction to Other_Random_User: Recently (2008) the Visual C++ team committed to supporting and extending MFC in the future, so MFC is NOT history and the version in VS 2008 will even support Windows Vista's new dialogs. But, (and here comes the interesting part) there's a chance they may come up with a modernized API for the Visual Studio that ships after VS 2008!. With C++ 0x round the corner its imperative that MFC gears up for the better, no question on dropping it. MS is trying to make it simpler , just to make users focus on .NET, which is again Windows Programming/Event handling , behind the scenes.
  • 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.
    • Current wxWidgets API is great, simple, intuitive and friendly enough. Backwards compatibility is much more important for me than new wrappers and fancy abstraction layers. Small size is also very important (you know, Wx2 isn't so bloated as Qt, so with wx2 it is possible to write really nice small applications without distribution of 10 mb dlls as in Qt). IMHO, Revolution must be replaced with Evolution. What I really expect in v3.0: improved stability, fixed bugs in GTK, support for Mac Cocoa, and maybe some new useful components.
• Using 3rd party libs (see below)
  • 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)
• Having everything ref-counted (presumably thread-safe)
• Using CSS-like fonts descriptions
• There are many things going on XHTML 2.0 initiative (XForms, RDF, etc.). These will have significant impact on the way people will use UI. So, need to consider their merits in wxTNG development.
• Boost C++ user wiki has many good points discussed on GUI development (BoostGUI). Looking into those is a good idea.
• Small footprint (mobile devices) is an important factor have to consider, in addition to portability.
• Do not use STL. It is undesirable to make wxWidgets dependent on another large library that may have to be downloaded and installed. In addition, use of templates can lead to executable bloat, which is something wxWidgets is strenuously trying to avoid. Not all compilers can handle templates adequately, so STL can dramatically reduce the number of compilers and platforms that could be supported.
  • 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: wxTNG/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
• wxTNG will look more attractive to developers who dislike wxWidgets for all the duplicated and overlapping functionality with 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?

Candidates

• International Components for Unicode (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. (Look for OMGUI in the Internet Archive)

• GTKmm is a C++ GUI library that unfortunately isn't truely cross-platform, as it is based on GTK, which doesn't use native widgets. However, the API is very good and it would also allow native widgets. It openly uses various external libraries instead of trying to wrap them and is also transparently compatible with the standard library. Auto storage (stack) allocation for widgets is supported, so that one isn't forced to new everything.

Draw inspiration from other projects

See comments at http://wxwidgets.blogspot.com/2007/11/looking-forward-to-wxwidgets-3.html

The WTL project (http://wtl.sourceforge.net/) is a rather nice template-based wrapper around Win32 API, some conceptual ideas could be drawn from there. Also, the Dabo project (http://dabodev.com/) and the quite informed critique from one of its authors given in http://dabodev.com/pycon2007 (seek forward 5 minutes from start for wxWidgets-specific discussion) should be reviewed. It is Python, but most Pythonic concepts have a modern C++ counterpart.

The main problems outlined are naming and consistency, there are too many widget-specific ways to do the same thing, e.g. set a text label of a widget (button: setLabel(), grid column: setColLabelValue(), menu: setTitle(), tree node: setItemText()), event and font handling should be simplified etc. The guiding principle should be that developers should be able to not repeat themselves and write as little code as possible.

Use Python to create the desirable API, then translate the idioms to C++

My experience has shown that Python is excellent not only for programming but also for designing good software. By using Python for API drafting, the community as a whole can participate in the design (but of course, wx BDFLs get the final word). If you think how easy it is to explore event handler, namespace and inheritance hierarchy design with Python, this proposal doesn't look as crazy as it might.

The Python design should specify the interfaces and inheritance hierarchies of the most important concepts of the library, e.g. UI widget base classes, event handling etc, and should not try to be comprehensive (i.e. cover all classes).