[wx-discuss] wxTNG: compatibility with wx2 API

[Stefan Csomor]

Hi 

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

I was referring to the step by step in the following sense :

- when I implement a new wx3-dc on mac, I have to write a wx2-wx3 bridge
in order to test it, but if I have bridged colour, brush, dc then I can
test it already, I can now add an implementation for msw, use the same
bridge test that again etc ..

> 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?

It depends, some attempts to fix things rather remind me of plumbing,
and part of that is because of they way they are implemented in wx2, so
I really would think that the amount involved in fixing several problems
is indeed less in a new implementation
 
>  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.
>
 
but the code quality in wx3 does not help if string manipulations in wx2
are faulty. so from the stability standpoint wx3 helps by enforcing
rules, making things simpler etc. but a lot of safety cannot be achived
without changing the implementation base wx2 itself, and using wx3on2
have our limits there, as wx2 code should still run more or less the
same way

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

who will be able to benefit ? IIUC only people writing against the wx3
API - or also wx2 users ? of course having a clean API with pluggable
implementations for .NET, wx2, qt etc. could help acceptance by boost,
but this would be an entirely new framework and wx2 users would never be
able to benefit from it, unless they rewrite, or we would provide them
with a then again wx2on3 bridge ...

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

I don't think making everyone happy is key, IMHO consistency is, but
IIRC both approaches still have one area in common 

- craft a new API

this is not touched - or should not be touched by the way it is
implemented. 

I don't know how much agreement there is on the fact that this API
should stand where possible on the shoulders of boost etc, instead of
corresponding wx2 classes.

Best,

Stefan





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