[wx-discuss] wxTNG: compatibility with wx2 API

[Kevin Ollivier]

Hi Stefan,

On Feb 19, 2006, at 9:40 PM, Stefan Csomor wrote:

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

Well, even if we fix things using wx3, if we do indeed change the  
class substantially in wx3 then I don't think we could just "hide it  
under the hood" for the wx2 backend anyways, or in some cases we'd be  
doing a disservice to our wx2 users by doing so. e.g. assigning an  
encoding to strings, or moving to floating point coordinates for wx3  
DCs. So I think, realistically, we have to understand that no matter  
what we do, some degree of wx2 backwards compatibility is going to be  
broken.

Personally, I don't think breaking source compatibility is a problem,  
provided that 1) you don't do it frequently, 2) you put it into a  
major new release, and 3) you give your users a real heads-up about  
changes beforehand. I think most users understand that sometimes you  
do have to fix what's broken and that fixing it sometimes means  
breaking bad code.

>> 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 use the existing implementation of the current sizers and  
bestsize systems in the new codebase, we'll end up with the same  
problem. As great as sizers are, we shouldn't even need 'bestsize'  
logic/API - all controls up to top-level windows should have internal  
default sizers (override-able, of course) that specify default  
behavior and are HIG-aware. A number of sizing hacks exist on wxMac  
with composite controls because we try to guess border sizes and the  
like, and calculate a default/best size that way.

So it's not to me so much a matter of being able to fix it in a new  
API, but not in the existing one. We can fix it either way, and in  
both cases we'll re-use what code we can and write replacement code  
for what we can't use. The only difference I see with wx3on2 in this  
sense is that we can do one change at a time and test it as it's  
complete, regarldess of where we fix it (i.e. in the new or old API).  
With wx2on3, the infrastructure for (wx)Windows, (wx)Sizers, etc.  
would have to be in place before we could test any changes to sizing  
logic, for example. Plus, the only way to test those changes  
throughout the entire codebase would be to code wx3 entirely first,  
or test each control for a bevy of fixed conditions as we add it in.

In short, unless wx3 fundamentally alters the API and defines major  
changes in how we approach things like sizing, we'll get faster and  
mostly equivalent results by fixing things one thing at a time  
wx3on2. If wx3 does fundamentally alter things like sizing (e.g.  
providing an alternative to sizers), which I would assume would be  
the point of ensuring the API is not constrained by wx2  
implementation matters, then that's a whole other discussion because  
we can't even be sure that things like existing wxSizers would work  
under the new implementation, or even if they could be made to work,  
that there wouldn't be major implementation issues in trying to turn  
a sizer into it's wx3 equivalent and vice-versa.

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

It's perhaps a less complex task, but again we could do this with wx2  
so long as we agree on breaking backwards compatibility. And again, I  
don't think we'll get away from it no matter how we approach the  
issue, so we might as well agree to allow some degree of it. (We  
should still, of course, avoid unnecessary breakage if possible.)

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

Well, I don't see why we couldn't add/fix public APIs so that they  
can take advantage of features at least certain backends have. And in  
fact, really, we already have a need for a pimpl approach on wxMac,  
with wxDC, wxToolbar, wxTextCtrl, wxComboBox.... It's annoying that  
we should need it, but realistically both implementations have  
advantages in some scenarios, and both should be allowed when they're  
the better approach. What would in fact be really great is if we  
could do things like compile the native wxComboBox even under  
Panther, but have the default logic be to make it the default pimpl  
only under Tiger. The most interesting thing about this is that, if  
the user isn't relying on getting a selection event notification, s/ 
he could actually change it to the default on Panther and use it.

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

Yes, and I personally think this is a good way to approach the issue.

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

Or adjusting the 'old way' to allow for new features, that simply  
won't work on old backends.

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

Right, I'm just hoping for a compromise on the bridge issue because  
API discussions will go a lot smoother if all sides have the same  
basic goals. As I said earlier, if wx2 compatibility isn't a big deal  
in the API design, you could radically change things in ways that may  
be very hard to backport into the wx2 API.

Anyways, as you said, the next step is to discuss APIs and see where  
to go from there.

Thanks,

Kevin

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


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