Re[5]: wxTNG: compatibility with wx2 API

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re[5]: wxTNG: compatibility with wx2 API

Ryan Norton
> When Julian says that wx2-on-wx3 approach is the cleanest and the
> easiest
> one to implement, I agree with the first part but strongly disagree with
> the second one. I'm afraid wx3-on-wx2 is the only possibility in practice.

Vadim, this seems like a really bad idea. I mean, what's the point of
"upgrading" if the new API itself is a wrapper around the old
(already "heavyweight") API! One could add a few new features to the
new wx3 version over time, but that really isn't much incentive plus
people would probably just port that feature to the older wx2 API.

wx2 wrapping wx3 makes MUCH more sense* because it means a more efficient
implementation base and a real incentive for people to switch. Once you
guys have wx3 ready you'll have plenty of code monkeys [points to self]
willing to implement the wx2 wrapper.

* - except in the case of old compilers/embedded systems which is probably
my big question


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re[6]: wxTNG: compatibility with wx2 API

Vadim Zeitlin-3
On Thu, 16 Feb 2006 10:18:14 -0800 Ryan Norton <[hidden email]> wrote:

RN> Vadim, this seems like a really bad idea. I mean, what's the point of
RN> "upgrading" if the new API itself is a wrapper around the old
RN> (already "heavyweight") API!

 The point is that having a good API we can always reimplement it later.
And we hopefully won't be the only ones doing it neither. For me a better
API is much more important than run-time efficiency (this doesn't mean that
I don't care about it) and even than new fancy features.

RN> wx2 wrapping wx3 makes MUCH more sense

 I don't disagree with this but I just don't believe this is going to
happen. Or if it does, we risk to just end up with all the legacy code from
wx2 in wx3 and this is something I'd really want to avoid.

 Again, consider how are you going to do this? You need to:

1. write wx3 _entirely_
2. write wx2 port to it

and during all this time you can't modify wx2 codebase because merging will
be all but impossible later. Do you realize how much time and effort will
it take? And you won't see anything come out of this before many months if
not years.


RN> * - except in the case of old compilers/embedded systems which is probably
RN> my big question

 This is an interesting question on its own but I'd rather have a separate
thread about embedded systems than discuss it in this one.

 Regards,
VZ


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: wxTNG: compatibility with wx2 API

Hajo Kirchhoff
In reply to this post by Ryan Norton
Ryan Norton wrote:

>
> Vadim, this seems like a really bad idea. I mean, what's the point of
> "upgrading" if the new API itself is a wrapper around the old
> (already "heavyweight") API! One could add a few new features to the

No, I agree with Vadim. You are just being too impatient ;-) Start with
a new API as a wrapper around the old one. Then, one by one, replace the
old API with new code. That way the new API is in place right from the
start and the codebase is working all of the time.

Yes, this will take quite some time until wx3 will loose the old wx2
library and code bloat, but this is the only way I see that we can
create a better API.

> wx2 wrapping wx3 makes MUCH more sense* because it means a more efficient
> implementation base and a real incentive for people to switch. Once you
> guys have wx3 ready you'll have plenty of code monkeys [points to self]
> willing to implement the wx2 wrapper.
>
> * - except in the case of old compilers/embedded systems which is probably
> my big question


--






--------------------------------------------
Lit Window Library - Speed up GUI coding 10x
   http://www.litwindow.com/library?src=ml

wxVisualSetup - integrate wxWidgets into Visual Studio .NET
   http://www.litwindow.com/Products/products.html?src=ml

BugLister - Defect Tracker
   http://www.litwindow.com/buglister?src=ml

Tips & Tricks for wxWidgets & MS Visual Studio
   http://www.litwindow.com/Knowhow/knowhow.html?src=ml


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: wxTNG: compatibility with wx2 API

Julian Smart
At 18:41 16/02/2006, you wrote:

>Ryan Norton wrote:
>
>>Vadim, this seems like a really bad idea. I mean, what's the point of
>>"upgrading" if the new API itself is a wrapper around the old (already
>>"heavyweight") API! One could add a few new features to the
>
>No, I agree with Vadim. You are just being too impatient ;-) Start with a
>new API as a wrapper around the old one. Then, one by one, replace the old
>API with new code. That way the new API is in place right from the start
>and the codebase is working all of the time.
>
>Yes, this will take quite some time until wx3 will loose the old wx2
>library and code bloat, but this is the only way I see that we can create
>a better API.

As a stepping stone it seems appropriate. I don't think it's the only way,
but progress would be so much more rapid, without worrying too much about
platform-specific details.

I think this hinges on whether you believe that the speed of development
of wx3-on-wx2 is outweighed by the things that wx2 limit you to. However these
limitations can (mostly) be fixed in wx2 which benefits both wx2 and wx3:
one can argue these efforts will be wasted, but I doubt it, since work is
shared between both ports and the extra features will still be available
in case wx3 doesn't see the light of day.

Regards,

Julian




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]