[wx-discuss] wxTNG: compatibility with wx2 API

[Stefan Csomor]

Hi Kevin 

> For example, I think some people would feel that wx is, for 
> the most part, clear and consistent and that inconsistencies 
> are exceptions, not the rule. Replacing a few poorly designed 
> classes would probably get us light-years towards resolving 
> these matters in our users' eyes.

if we agree to change an API / some classes substantially in a certain
direction is fine, then this would also benefit the end user, but don't
think we will get consensus on that, because backwards source
compatibility was always a very high priority, and I think that we
should try to maintain that.

> As for lean, solid and speedy, those are implementation 
> matters that may touch the API, but do not primarily concern 
> it. So my question becomes: how does the wx2 API restrict us 
> from solving these issues? Why shouldn't we make limited 
> changes to the wx2 API to address these, rather than start on 
> a new API altogether? 

getting something lean IMHO is quite difficult because of the codesize
and interdependancies we are in. Look at changes to the sizers /
bestsize / window systems, they are always intertwined, when running
into problems we try to patch things here and there, because they have
to catch everything. If we add eg error handling, exception safety then
this promotes throughout all code lines, that's why I think that
rebuilding the functionality - including as I said reusing parts of the
code - would be a more realistic task. Adding Factories into wx2 code
would in the end mean adding pImpls to the involved classes, rebuilding
a second hierarchy, indeed kind of implement 'wx2on3' but not exposing
it as an API of its own ...

Replacing wx' own implementations (not the 'frontend' API) with third
party libraries is of course possible also within wx2.

> There is, lastly, the matter of API compatibility with new OS 
> toolkits, but how hard would it be to internally use 
> Avalon/WPF controls with the wx API? Are you saying wx2 
> backend would not be able to take advantage of these controls?

it all depends where we put the efforts, if we put the efforts on wx3
then we'd have to either write a new backend - leaving wx2 apps
neglected - or add the backend in wx2 - using the 'old way' of doing
things.

> Yes, but as Vadim said, the startup cost to get something 
> fairly complete working will be quite high, so I think what 
> people, or at least I, am wondering, is what specific 
> benefits you see that only exist with wx2on3 that cannot be 
> obtained with a wx3on2 approach?

to me having wx3on2 is more kind of 'old wine in new wineskins',
building a new backend against this wx3 would be fine, but lacks the
bridge for wx2 users.

But as we've agreed, we can still start with API discussions, and 

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