[wx-discuss] wxTNG: compatibility with wx2 API

[Vadim Zeitlin]

On Thu, 16 Feb 2006 19:08:13 +0100 Stefan Csomor <csomor at advancedconcepts.ch> wrote:

SC> >  It's true that I mostly concentrate on new and better API 
SC> > than on new and better features. And from the point of view 
SC> > of new features wx2-on-wx3 does make more sense. But I think 
SC> > we can find a compromise: work on wx3-on-wx2 but provide new 
SC> > implementations of just some classes:
SC> 
SC> the clean API can be done in wx3 whether it is above or below wx2.

 Yes, in theory. In practice I'd still like to know how it will really
happen if you go wx2on3 way.

SC> wx2 on wx3 will allow to replace things step by step,

 Err, how so? You'd need to have written entirely wx3 first, how is this
"step by step"? Unless you propose to just copy wx2 into wx3 and then start
improving it incrementally but this just won't work.

SC> have the new implementation tested immediately,

 Again, I have the feeling that you exchanged the 2 approaches here. The
wx3on2 approach will allow immediate testing. With wx2on3 you will need to
spend what I conservatively estimate as one person-year before being able
to run anything. Just how are you going to test anything before having
written the implementation? And this won't happen immediately...

SC> whereas wx3 on wx2 will be plagued by all the problems wx2 has,

 I agree if you mean implementation problems. But surely they can be fixed
in wx2 and fixing them in wx3 will be about as simple/difficult?

 OTOH I'm still thinking of

1. better API
2. improved code quality

and surely in these aspects wx3 won't be affected by wx2 codebase at all.

SC> any effort to remedy them in wx2 will be either wasted or wx2 will never
SC> be replaced at all. The latter is an option of course, but then it
SC> should be stated upfront, because replacing wx2 completely when it is
SC> sitting under wx3 is an even more herculean task, with the added
SC> disadvantage of leaving all wx2 code users in the dust ...

 As I said, I do expect wx2 to stay alive for quite some time (I'm speaking
about years here, maybe 5, more likely 10). But this doesn't mean wx3 will
still be using it in a couple of years -- e.g. I fully expect/hope to have
a native .NET implementation of wx3 relatively soon.

SC> > SC> We could eg also start implementing a new DC architecture using 
SC> > SC> paths, colours etc. and have a wx2 wxDC that is more or less the 
SC> > SC> same on all platforms that is implemented using wx3::dc
SC> > 
SC> >  This probably could be done in wx2 too, so why not add these 
SC> > new features in wx2 DC class?
SC> 
SC> implementing this as wx3 and using wx2 to bridge upon will give the
SC> chance for a cleaner API and new features at the same time

 Well, again, I'd like to find a compromise acceptable to everyone and I
think that even if choose to do wx3on2 globally in some cases we can
implement stuff in wx3 and then somehow back fit it into wx2 (i.e. while
wx::Window would be initially implemented in terms of wxWindow, wx::DC
could be implemented natively from the beginning and we'd then have a wxDC
implementation using it -- certainly somewhat confusing but if this is what
it takes to make everyone happy, why not).

 Regards,
VZ


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