[wx-discuss] wxTNG: compatibility with wx2 API

[Kevin Ollivier]

Hi Stefan,

On Feb 18, 2006, at 11:34 PM, Stefan Csomor wrote:

> Hi Kevin
>
>> A couple questions:
>>
>> 1) This is really a lot of work before we have a product
>> others could use outside of the wx2 backend, so I'm wondering
>> - exactly how much impact do you see this total re-write
>> having? i.e. is this something you're mostly developing for
>> your own needs/usage, or are you primarily concerned with
>> increasing the adoption of wx by the developer community?
>
> My primary concern is to have a lean, solid, speedy, clear and
> consistent implementation of a crossplatform GUI-framework, that takes
> advantage of the advancements of the last 4-5 years on the OS side and
> of the developments already visible on the horizon.
>
> I am convinced that rebuilding a new 'wx-kernel' is better suited than
> attempts to fix things here and there in wx2. Although possible to a
> certain degree, the latter will be more and more difficult (eg using
> Avalon/WPF controls), .

Well, it's always true that by starting fresh you can get a better  
result. i.e. you're not limited in any way by existing code. But what  
I'm concerned about is benefit vs. work from the developer  
perspective. If you want to convince people that it's worth it to  
work on a long-term initiative like this, you'll of course have to  
convince them that the benefits outweigh the work. I do see how your  
approach results in a less constrained API, but for reasons outlined  
in my previous email, I'm not really sure that's a major concern for  
most people.

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. 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? After all,  
you intend to continue to maintain a wx2 front end for wx3, so I  
would imagine you believe you could take advantage of many wx3  
features from within the wx2 API.

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?

> This does not mean to throw everything away, I'd rather compare it to
> switching from one factory building to another. You will take the  
> things
> that are fine and work well with you, to perhaps a better layout of  
> the
> machines according to the processes, and replace part of the machines
> with new ones.
>
> My second concern is to have already existing wx2 sources benefitting
> from these advantages via said wx2on3 bridges, as I'm afraid that the
> option - rewrite your code to wx3 to benefit from all new things.
>
> This would also give a huge testbed, so that we can then promote  
> wx3 as
> a new and yet proven way for new projects or for renewals within wx2
> sources

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?

>> 2) If the latter, why do you see this total re-write as
>> having more impact than other possible initiatives for
>> increasing our userbase? - e.g. development of better
>> documentation, a much clearer starting path for beginners,
>> modernization of existing APIs, and creation of some sort of
>> RAD toolset for users.
>
> I don't think it would create more impact, I just think it would  
> create
> more value.
>
> The problems with documentations, easy starters and RAD toolsets  
> can be
> solved - or neglected - in both approaches wx3on2 or wx2on3.

Certainly true, but this is why I asked the 'scratching your own  
itch' vs. 'scratching the user's itch' question at the end of #1.  
Because if we're primarily trying to 'scratch the user's itch' here,  
it might be more effective if we focus our resources on ensuring that  
other improvements that would benefit our users more are not neglected.

Thanks,

Kevin

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


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