[wx-discuss] wxTNG: compatibility with wx2 API

[Julian Smart]

At 15:25 16/02/2006, you wrote:
>JS> (b) the easiest and cleanest way to do that is basically a wxWidgets 2 
>port
>JS> wrapping wxWidgets 3.
>
>  This is one possibility. The problem with this is that it will force
>dropping support for all compilers not capable of building wx3 as wx2 will
>depend on it.

True, but users will have the choice of using conventional wx2 with
any currently supported compiler, or wx3-enabled wx2 with a smaller
set of compilers. wx3 would be restricted anyway so I think people
will know what they're in for.

>  It could also create some problems with the exceptions which
>we'd have to catch in wx2 wrapper code to prevent them from escaping to old
>code not expecting them.

Right.

>  Finally, and most seriously, it would mean that
>all the existing wx2 code would have to be rewritten for wx3, including
>such things as wxDateTime (because we'd probably use boost::date classes in
>wx3) and wxFileName and not just all the GUI code.

But we can provide conversions (pretending wx3 is a completely foreign
platform).

>  Alternative solution is to make wx3 a wrapper for wx2 API. Personally I
>think it is better because:
>
>- you get something working almost immediately because all the existing
>   ports are simply reused and don't have to be changed at all and the whole
>   process is more incremental: we can continue changing wx2 in the
>   meanwhile too

It's a very attractive alternative, certainly.

>- one of the ideas for wx3 (subservient to the goal of including it to
>   boost/proposing it as a standard C++ GUI framework) is to make it
>   possible to use different backends for the implementation of the same
>   public API and so wx2 backend would be just one/first of many and it
>   would be nice to separate public API from implementation as clearly as
>   possible from the very beginning
>
>  Of course, there are problems with this approach too, main one being that
>wx3 users will continue to pay for wx2 inefficiencies. But I hope this can
>be dealt with later, by improving the implementation without changing the
>public API.

That's true - in fact we can later reverse the compatibility layering.
Once wx3 is implemented efficiently, we can remove all traces of
wx2 and then write a wx2 port to wx3. The big advantage, as you say,
is that we get started really quickly and just use wx2 as the implementation.
Whether that ultimately wastes time in doing a quick-and-dirty implementation
I don't know. But being able to get results quickly, and therefore
experiment more easily with the API, is a very compelling reason.
It certainly doesn't have to be seen as the final backend implementation.

However I don't think that wx3-on-wx2 will necessarily be a panacea for
backwards compatibility, because wx3 will need its own initialisation
and dealing with wx2 objects may not be tenable to make wx3 do the
right thing. Whereas you know with a proper wx2-on-wx3 port that
using wx2 objects is always allowed.

But one could argue for the phased approach:

1) Implement wx3-on-wx2 for speed of development.
2) Implement wx3-on-native-ports.
3) Implement wx2-on-wx3 for backwards compatibility.

Regards,

Julian




---------------------------------------------------------------------
To unsubscribe, e-mail: wx-discuss-unsubscribe at lists.wxwidgets.org
For additional commands, e-mail: wx-discuss-help at lists.wxwidgets.org