wxWidgets version 3?

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

wxWidgets version 3?

Lasse Kärkkäinen / Tronic-6
Hi,

Eventually wxWidgets will probably be moving towards genuine C++ support,
making use of exceptions, etc. I suppose that you are already working on
that behind the scenes, even though a quick Google search didn't turn up
anything interesting.

In case this happens during the next summer, I wish to enroll as a code
monkey, trying to help you in whatever ways you find useful. However, I
need (pre-)confirmation VERY QUICKLY in order to get funding¹ for that. If
no such rework of the library is being planned, then the plan is off, of
course.

I have very strong cross-platform C++ skills and I have been using
wxWidgets for quite a while too.

Please reply directly to my e-mail, as I don't necessarily read the list.

- Tronic -

¹) An organization in Finland pays university students for developing OSS
software. No strings attached.



signature.asc (264 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: wxWidgets version 3?

Vadim Zeitlin-3
On Wed, 15 Feb 2006 00:54:39 +0200 Lasse Kärkkäinen / Tronic <[hidden email]> wrote:

LKT> Eventually wxWidgets will probably be moving towards genuine C++ support,
LKT> making use of exceptions, etc. I suppose that you are already working on
LKT> that behind the scenes, even though a quick Google search didn't turn up
LKT> anything interesting.

 I, and probably others, have some private notes but nothing definitive has
been even decided yet, and so nothing was really done (AFAIK) neither.

LKT> In case this happens during the next summer, I wish to enroll as a code
LKT> monkey, trying to help you in whatever ways you find useful. However, I
LKT> need (pre-)confirmation VERY QUICKLY in order to get funding¹ for that. If
LKT> no such rework of the library is being planned, then the plan is off, of
LKT> course.

 It is definitely planned. It's just in the rather easrly planning stages
for now :-)

LKT> ¹) An organization in Finland pays university students for developing OSS
LKT> software. No strings attached.

 Wow, that's amazing. What's the name of this wonderful organization?

 Regards,


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

Reply | Threaded
Open this post in threaded view
|

Re: wxWidgets version 3?

i386-2

Is there some kind of nice extern C api planned for people creating
bindings? or does something like this exist already.

On 2/15/2006, "Vadim Zeitlin" <[hidden email]> wrote:

>On Wed, 15 Feb 2006 00:54:39 +0200 Lasse Kärkkäinen / Tronic <[hidden email]> wrote:
>
>LKT> Eventually wxWidgets will probably be moving towards genuine C++ support,
>LKT> making use of exceptions, etc. I suppose that you are already working on
>LKT> that behind the scenes, even though a quick Google search didn't turn up
>LKT> anything interesting.
>
> I, and probably others, have some private notes but nothing definitive has
>been even decided yet, and so nothing was really done (AFAIK) neither.
>
>LKT> In case this happens during the next summer, I wish to enroll as a code
>LKT> monkey, trying to help you in whatever ways you find useful. However, I
>LKT> need (pre-)confirmation VERY QUICKLY in order to get funding¹ for that. If
>LKT> no such rework of the library is being planned, then the plan is off, of
>LKT> course.
>
> It is definitely planned. It's just in the rather easrly planning stages
>for now :-)
>
>LKT> ¹) An organization in Finland pays university students for developing OSS
>LKT> software. No strings attached.
>
> Wow, that's amazing. What's the name of this wonderful organization?
>
> Regards,
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

RE: wxWidgets version 3?

Stefan Csomor
In reply to this post by Lasse Kärkkäinen / Tronic-6
Hi

> Is there some kind of nice extern C api planned for people
> creating bindings? or does something like this exist already.

as wx is using objects, binding in languages that support objects as
well preferrably use the same architecture, that's why eg wxPython uses
SWIG, as SWIG also supports many other languages, I think this a fine
way. So if something is not supported there, adding the support to SWIG
instead of creating manual bindings looks more powerful to me, but I
haven't ever created such a a target.

Best,

Stefan

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

Reply | Threaded
Open this post in threaded view
|

Re: wxWidgets version 3?

Julian Smart
In reply to this post by Lasse Kärkkäinen / Tronic-6
At 22:54 14/02/2006, Lasse Kärkkäinen / Tronic wrote:
>Eventually wxWidgets will probably be moving towards genuine C++ support,
>making use of exceptions, etc. I suppose that you are already working on
>that behind the scenes, even though a quick Google search didn't turn up
>anything interesting.

This sounds like the proposed wxTNG (wxWidgets The Next Generation)
which would be a radical rewrite. Several people have ideas on that
but (partly because there are so possible ways to do it, and
freedom is required in the early stages) we will probably have a couple
of attempts by individuals, and then see which is the best. One of those
individuals is Stefan Csomor and I would imagine he would welcome help on
this.

So yes there are ideas floating around but not what you might call
a concrete plan and schedule -- we have our work cut out surviving and
refining current wxWidgets and we have no sponsor unlike some projects.

>¹) An organization in Finland pays university students for developing OSS
>software. No strings attached.

Very nice!

Regards,

Julian




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

Reply | Threaded
Open this post in threaded view
|

Re: wxWidgets version 3?

Lasse Kärkkäinen / Tronic-6
In reply to this post by Vadim Zeitlin-3
>  I, and probably others, have some private notes but nothing definitive has
> been even decided yet, and so nothing was really done (AFAIK) neither.

Ok. Good to hear that this work has at least kinda started. I'd be happy
to help with design too.

> This sounds like the proposed wxTNG (wxWidgets The Next Generation)
> which would be a radical rewrite. Several people have ideas on that
> but (partly because there are so possible ways to do it, and
> freedom is required in the early stages) we will probably have a couple
> of attempts by individuals, and then see which is the best. One of those
> individuals is Stefan Csomor and I would imagine he would welcome help
> on this.

WxTNG (or should we say wx::Widgets?) looks just like the project that I
am looking for. A rewrite gives free hands on designing the interface to
be optimal.

However, I'd prefer at least some degree of team work rather than
everybody doing their own version. Of course, if there are disagreements,
then it may be forked and eventually we'll see which one is better.

In either case - sharing of ideas is very important even if there are many
"competing" projects, so that we don't end up with one implementation that
is very good in some particular way and another that does something else
well, but neither does both and the two cannot easily be combined.

>  It is definitely planned. It's just in the rather easrly planning stages
> for now :-)

Okay. As long as we can get something done before autumn... Working full
days, three months, on it should do the trick. I sent mail to COSS,
telling them this as my plan :)

> LKT> ¹) An organization in Finland pays university students for developing OSS
> LKT> software. No strings attached.
>  Wow, that's amazing. What's the name of this wonderful organization?

http://www.coss.fi/en/

- Tronic -


signature.asc (264 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: wxWidgets version 3?

Stefan Csomor
In reply to this post by Lasse Kärkkäinen / Tronic-6
Hi Lasse

this is a great offer, thank you for thinking about us !

> WxTNG (or should we say wx::Widgets?) looks just like the
> project that I am looking for. A rewrite gives free hands on
> designing the interface to be optimal.
>
> However, I'd prefer at least some degree of team work rather
> than everybody doing their own version. Of course, if there
> are disagreements, then it may be forked and eventually we'll
> see which one is better.
>
> In either case - sharing of ideas is very important even if
> there are many "competing" projects, so that we don't end up
> with one implementation that is very good in some particular
> way and another that does something else well, but neither
> does both and the two cannot easily be combined.

the problem is unfortunately that designing an API is not possible by
committee, there may be several wxTNG branches, we have to move forward
with implementing our own visions, I have my views which are of course
influenced by my own experiences and work by others like PowerPlant,
MacApp, NextStep, Taligent and OpenClass etc. There should be ONE way to
achieve something, not MANY. So while discussions are very important and
an important contribution, in the end there will be one person
responsible for one wxTNG branch API, consistency is key.

Also bridging from wx2 to wxTNG must somehow be possible, we cannot
expect everybody to rewrite their software. So we cannot introduce
things which we know are impossible to bridge in some way.

> >  It is definitely planned. It's just in the rather easrly planning
> > stages for now :-)
>
> Okay. As long as we can get something done before autumn...
> Working full days, three months, on it should do the trick. I
> sent mail to COSS, telling them this as my plan :)

could you give me the approximate dates you'd be available ? deadlines
help in an OSS project ;-)

Thanks a lot,

Stefan

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

Reply | Threaded
Open this post in threaded view
|

Re[2]: wxWidgets version 3?

Vadim Zeitlin-3
In reply to this post by Lasse Kärkkäinen / Tronic-6
On Wed, 15 Feb 2006 14:23:09 +0200 Lasse Kärkkäinen / Tronic <[hidden email]> wrote:

LKT> WxTNG (or should we say wx::Widgets?) looks just like the project that I
LKT> am looking for. A rewrite gives free hands on designing the interface to
LKT> be optimal.

 The details are, as I wrote, still hazy, but I'm pretty sure we're not
going to just throw all existing code out of the window and start from
scratch so our hands won't be completely free even, if, of course, the
backwards compatibility requirements for wxTNG won't be nearly as stringent
as for the current wx versions.

LKT> Okay. As long as we can get something done before autumn...

 This is actually good as it gives us a deadline ;-)

 Regards,
VZ

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

Reply | Threaded
Open this post in threaded view
|

Re[2]: wxWidgets version 3?

Julian Smart
It would be fantastic to have such a large amount of help.

My suggestion (in the context of what Stefan was saying) is
to go with a Stefan-oriented wxTNG vision, and have Stefan manage it.

I think, at least for tricky design problems, that occasionally
it would be good to have input from others -- but this would
be strictly controlled to avoid impeding the creative process.
They would purely be suggestions feeding in to Stefan's decision-making
process and presented in such a way as to avoid sapping morale.
One way to achieve that might be to have suggestions made to a tracker
or in a Wiki so that we don't get heated discussions on mailing
lists; then Stefan can pick and choose from the information.

I know this goes against normal open source development of an
_established_ project, but we want to try to recreate conditions
of a project before it goes public, where fast progress is made
and of necessity big decisions need to be made quickly.
There can be a place where people note their own opinions, but
this should not stop progress.

Quite possibly Stefan may be open to commissioning reports,
as it were, for specific design issues. I.e. there
could be a task force looking at ways of retaining some compatibility
in a particular area, from which Stefan chooses (or chooses his own
solution). Similarly someone might implement a particular class design.

Regards,

Julian

At 15:55 15/02/2006, you wrote:

>On Wed, 15 Feb 2006 14:23:09 +0200 Lasse Kärkkäinen / Tronic
><[hidden email]> wrote:
>
>LKT> WxTNG (or should we say wx::Widgets?) looks just like the project that I
>LKT> am looking for. A rewrite gives free hands on designing the interface to
>LKT> be optimal.
>
>  The details are, as I wrote, still hazy, but I'm pretty sure we're not
>going to just throw all existing code out of the window and start from
>scratch so our hands won't be completely free even, if, of course, the
>backwards compatibility requirements for wxTNG won't be nearly as stringent
>as for the current wx versions.
>
>LKT> Okay. As long as we can get something done before autumn...
>
>  This is actually good as it gives us a deadline ;-)
>
>  Regards,
>VZ
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]

==============================================================================
Julian Smart                           [hidden email]
28/5 Gillespie Crescent, Edinburgh,    http://www.anthemion.co.uk
Midlothian, U.K., EH10 4HU             +44 (0)131 229 5306
Writer's Cafe: power tools for writers http://www.writerscafe.co.uk
HelpBlocks:    HTML help authoring     http://www.helpblocks.com
DialogBlocks:  cross-platform dialogs  http://www.anthemion.co.uk/dialogblocks
==============================================================================



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

Reply | Threaded
Open this post in threaded view
|

Re[3]: wxWidgets version 3?

Vadim Zeitlin-3
On Wed, 15 Feb 2006 16:37:24 +0000 Julian Smart <[hidden email]> wrote:

JS> My suggestion (in the context of what Stefan was saying) is
JS> to go with a Stefan-oriented wxTNG vision, and have Stefan manage it.

 Interesting, I didn't even know what Stefan-oriented wxTNG vision was to
be honest. I admit I'm a bit confused about the proposed development model
not least/especially because this is the first time I hear about it. I feel
it would be good to have a more in-depth discussion of this.

 To start with, what is the current state of Stefan's effort?

 Thanks,
VZ


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

Reply | Threaded
Open this post in threaded view
|

Re[3]: wxWidgets version 3?

Julian Smart
At 18:02 15/02/2006, you wrote:

>On Wed, 15 Feb 2006 16:37:24 +0000 Julian Smart <[hidden email]>
>wrote:
>
>JS> My suggestion (in the context of what Stefan was saying) is
>JS> to go with a Stefan-oriented wxTNG vision, and have Stefan manage it.
>
>  Interesting, I didn't even know what Stefan-oriented wxTNG vision was to
>be honest. I admit I'm a bit confused about the proposed development model
>not least/especially because this is the first time I hear about it. I feel
>it would be good to have a more in-depth discussion of this.

It's really an extension or logical conclusion of what we discussed about
having several wxTNG efforts, each reflecting a particular vision. This
is based on the notion that when starting (almost) from scratch, there could
be many ways to go compared with an established project that evolves,
leading to potentially unresolvable conflicts and possible disillusion.

I get the impression that Stefan is one of the more vocal advocates
of a radical reworking, and he has a broad view of GUI APIs and technologies.

An alternative is the more conventional joint approach, of course, but it
has the disadvantages of the committee approach that may outweigh the
advantages
(e.g. design compromises to try to suit all opinions that may end up
suiting few, stalling due to lack of agreement, arguing in circles, etc.).

>  To start with, what is the current state of Stefan's effort?

AFAIK mostly in-head design :-) including what's been discussed on wx-dev.

Regards,

Julian



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

Reply | Threaded
Open this post in threaded view
|

Re[4]: wxWidgets version 3?

Vadim Zeitlin-3
On Wed, 15 Feb 2006 18:52:56 +0000 Julian Smart <[hidden email]> wrote:

JS> It's really an extension or logical conclusion of what we discussed about
JS> having several wxTNG efforts, each reflecting a particular vision.

 Sorry, I've somehow entirely missed this. Was it on wx-discuss by chance?
I wasn't subscribed to it until recently so maybe this explains it.

JS> An alternative is the more conventional joint approach, of course, but it
JS> has the disadvantages of the committee approach that may outweigh the
JS> advantages

 I really don't think we have an alternative though. I'm absolutely
convinced that wxTNG effort is much more than a single person could do so I
just don't see how could it be remotedly successful if we don't all work on
it.

 Of course, if we can't agree on what do we want from wxTNG, there would be
a problem. But AFAIK there was no disagreement yet -- and for a good reason
that there were no really precise proposals about wxTNG. I have a very
rough draft of one but I probably won't finish it any time soon, so maybe
it would make sense to start discussing what the others got without waiting
for it.

 Regards,
VZ


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

Reply | Threaded
Open this post in threaded view
|

Re[4]: wxWidgets version 3?

Julian Smart
Hi Vadim,

Relevant threads include:

Re: [wx-dev] [tng] branch in cvs ? directory-layout ?
Re: [wx-dev] Big API changes in wxWidgets - possible?

but they're not really what I meant, and it's possible I
dreamed the discussion... but I'm pretty sure we talked
about the multiple-wxTNG-attempts-in-CVS thing somewhere.

Still, it's only a suggestion, so it's "more hands make
light work" versus "too many cooks spoil the broth" :-)
Certainly it'll need many hands to make progress, I'm
thinking of the initial design and first cut really.

I think a wxTNG coordinator would make sense in both scenarios.

Regards,

Julian

At 19:03 15/02/2006, you wrote:

>On Wed, 15 Feb 2006 18:52:56 +0000 Julian Smart <[hidden email]>
>wrote:
>
>JS> It's really an extension or logical conclusion of what we discussed about
>JS> having several wxTNG efforts, each reflecting a particular vision.
>
>  Sorry, I've somehow entirely missed this. Was it on wx-discuss by chance?
>I wasn't subscribed to it until recently so maybe this explains it.
>
>JS> An alternative is the more conventional joint approach, of course, but it
>JS> has the disadvantages of the committee approach that may outweigh the
>JS> advantages
>
>  I really don't think we have an alternative though. I'm absolutely
>convinced that wxTNG effort is much more than a single person could do so I
>just don't see how could it be remotedly successful if we don't all work on
>it.
>
>  Of course, if we can't agree on what do we want from wxTNG, there would be
>a problem. But AFAIK there was no disagreement yet -- and for a good reason
>that there were no really precise proposals about wxTNG. I have a very
>rough draft of one but I probably won't finish it any time soon, so maybe
>it would make sense to start discussing what the others got without waiting
>for it.
>
>  Regards,
>VZ
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]

==============================================================================
Julian Smart                           [hidden email]
28/5 Gillespie Crescent, Edinburgh,    http://www.anthemion.co.uk
Midlothian, U.K., EH10 4HU             +44 (0)131 229 5306
Writer's Cafe: power tools for writers http://www.writerscafe.co.uk
HelpBlocks:    HTML help authoring     http://www.helpblocks.com
DialogBlocks:  cross-platform dialogs  http://www.anthemion.co.uk/dialogblocks
==============================================================================



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

Reply | Threaded
Open this post in threaded view
|

RE: Re[4]: wxWidgets version 3?

Stefan Csomor
In reply to this post by Lasse Kärkkäinen / Tronic-6
HI

> but they're not really what I meant, and it's possible I
> dreamed the discussion... but I'm pretty sure we talked about
> the multiple-wxTNG-attempts-in-CVS thing somewhere.

yes, I think we had our last round of discussions on wx-discuss here.

[wx-discuss] Chandler - The Framework Issue

Best,

Stefan

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

Reply | Threaded
Open this post in threaded view
|

RE: Re[4]: wxWidgets version 3?

Stefan Csomor
In reply to this post by Lasse Kärkkäinen / Tronic-6
Hi

>  Sorry, I've somehow entirely missed this. Was it on
> wx-discuss by chance?
> I wasn't subscribed to it until recently so maybe this explains it.

yes, I think the last thread was

[wx-discuss] Chandler - The Framework Issue
 
> JS> An alternative is the more conventional joint approach,
> of course,
> JS> but it has the disadvantages of the committee approach that may
> JS> outweigh the advantages
>
>  I really don't think we have an alternative though. I'm
> absolutely convinced that wxTNG effort is much more than a
> single person could do so I just don't see how could it be
> remotedly successful if we don't all work on it.

I agree on the amount of all work to be done, but I think that the
development of ideas and APIs should in the end have one person
responsible, with discussions of course, to craft the overall
architecture. And there may be another suggestion with someone else's
ideas, but they have to be carried on, until a certain degree of
completeness can be reached. We will need prototypes in order to prove
feasibility and usability of ideas. And consistency will break if we
just put together pieces.

>  Of course, if we can't agree on what do we want from wxTNG,
> there would be a problem. But AFAIK there was no disagreement
> yet -- and for a good reason that there were no really
> precise proposals about wxTNG. I have a very rough draft of
> one but I probably won't finish it any time soon, so maybe it
> would make sense to start discussing what the others got
> without waiting for it.

In the past there have been situations where the way to solve things to
me seemed obvious, yet we disagreed, I was not able to convince you and
you couldn't convince me. Changing wx2 is very difficult, but wxTNG
doesn't have this burden from the start. So yes, I think that we cannot
find compromises where two entirely different views exist. And mixing
different views in the same API is not reasonable at all. I understand
that my view of wxTNG may not be the one that will be accepted in the
end, but I want to at least make the proposal so that things can be
seen, discussed and tested with real code. I thought about setting up a
Wiki (never done that before) where we could start with all the items we
have on the table, links to possible solutions, so that discussions can
always refer to the same base material.

Best,

Stefan

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

Reply | Threaded
Open this post in threaded view
|

Re: wxWidgets version 3?

Robin Dunn
In reply to this post by Vadim Zeitlin-3
Vadim Zeitlin wrote:

> On Wed, 15 Feb 2006 18:52:56 +0000 Julian Smart <[hidden email]> wrote:
>
> JS> It's really an extension or logical conclusion of what we discussed about
> JS> having several wxTNG efforts, each reflecting a particular vision.
>
>  Sorry, I've somehow entirely missed this. Was it on wx-discuss by chance?
> I wasn't subscribed to it until recently so maybe this explains it.
>
> JS> An alternative is the more conventional joint approach, of course, but it
> JS> has the disadvantages of the committee approach that may outweigh the
> JS> advantages
>
>  I really don't think we have an alternative though. I'm absolutely
> convinced that wxTNG effort is much more than a single person could do so I
> just don't see how could it be remotedly successful if we don't all work on
> it.

I missed out on prior discussions too, but I do see the value in letting
a few people work in isolation in the very early stages.  They're not
setting out to do the whole thing, but just to dream up the general
approach to take, the foundation of the design, and maybe just a little
proof of concept code.  I want to stress the "little" here because the
more code that is done before final decisions are made then the harder
it will be to abandon it and go with something better if suggested.  The
benefit of working in isolation at this idea stage is that it is easier
to focus on the needs of the foundation and not go flying off on
tangents when confronted by committee politics and personalities wanting
to get their own idea du jour incorporated in the plan, those kinds of
things should either come later or should be the basis of a separate
proposal that can be compared with the others.

When done those proposals can be brought to light where the rest of us
can poke holes in them based on prior experience, or to suggest better
ways to have a stronger foundation and framework.  And if there is more
than one proposal perhaps we can pick and choose the best attributes of
each and put them together.  It's at that point that the many hands
working together to build on that foundation and fill in the framework
have real value.

Just my $0.02...

--
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!


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

Reply | Threaded
Open this post in threaded view
|

Re[6]: wxWidgets version 3?

Vadim Zeitlin-3
In reply to this post by Stefan Csomor
On Wed, 15 Feb 2006 21:39:49 +0100 Stefan Csomor <[hidden email]> wrote:

SC> [wx-discuss] Chandler - The Framework Issue

 BTW, I know this list was just subscribed to gmane, but would it be
possible to also import the existing archives into it?

 Anyhow, I don't really see anything concrete in the thread above. Ok,
wxTNG will be using templates and exceptions -- this much is obvious.
But there are so many questions after this...

SC> In the past there have been situations where the way to solve things to
SC> me seemed obvious, yet we disagreed,

 Funny, I don't think it happened that often. But anyhow, I don't say it's
impossible that we disagree but I do think that we should at least try to
agree first. And this is very difficult without having something concrete
to discuss.

SC> And mixing different views in the same API is not reasonable at all.

 For now we don't have many different views, we don't have (at least
publicly) even a single one!

SC> I thought about setting up a Wiki

 Why not use existing wxWiki?


 Anyhow, to turn this into something more productive: although I don't have
the time to write anything precise really right now (I am going to be
awfully busy until the end of the next week), I think that the plan should
be:

I. Set the goals for wxTNG
II. Answer some crucial questions about global project organization
III. Propose (draft) API, or at least the driving principles behind it
IV. Implement it

It would be nice to at least start with I.

 Regards,
VZ


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

Reply | Threaded
Open this post in threaded view
|

Re: wxWidgets version 3?

Robin Dunn
Vadim Zeitlin wrote:

>  Anyhow, to turn this into something more productive: although I don't have
> the time to write anything precise really right now (I am going to be
> awfully busy until the end of the next week), I think that the plan should
> be:
>
> I. Set the goals for wxTNG
> II. Answer some crucial questions about global project organization
> III. Propose (draft) API, or at least the driving principles behind it
> IV. Implement it
>
> It would be nice to at least start with I.

Goal #1:  wxTNG shall make it very easy to create language bindings such
as wxPython.  For me this has four main components:

a. Reduce the reliance on virtual methods to be as small as possible.
At least the goal should be that there are no virtual methods that are
required to be used for end-user classes that derive from framework
classes, including, if possible, creating custom controls and etc., and
instead use something like events or signals/slots or whatever to get
the same dynamic dispatch functionality.  If there is something that
will much be better implemented with a virtual and you don't want to
give up the virtual, then there should also be an event/slot mechanism
to do the same thing, or that is used by default.

b. "Clean" headers without a lot of heavy macro use or complex C++
cruft.  If the headers to be #included by the user code that define the
public interfaces are relatively clean and simple then I can feed them
directly to SWIG instead of needing to hand-craft an interface file for
SWIG.  All the complex and implementation specific things can be put in
headers that only the framework sees.  (I guess that this probably
implies using the pImpl pattern or similar, which is probably a good
thing anyway for maintaining ABI compatibility, etc.)  A possible
alternative is to put all the info about the public classes in some form
of meta-data structure and then be able generate the interface
definition files for wxPython from that, (and perhaps also the C++
headers and the API reference docs too!)

c. Most C++ class instances should have a user-data pointer that is not
used for anything in the framework.  Where those pointers exist today
I've been able to use them very effectively in wxPython for attaching
some wxPython specific thing to the C++ object, that I can then access
later when needed.  This is especially true for whatever event dispatch
mechanism will be used in wxTNG, as in that case the user-data pointer
is a reference to the Python callable object to be called to handle the
event.

d. It would be nice if there was a separation of __WXDEBUG__ and
wxASSERT and similar.  In other words, if there was a way to leave the
wxASSERTs, wxCHECKs, and etc. to be compiled in to the code without
needing to have all of the rest of the __WXDEBUG__ code too.  This is
because I turn the wxASSERTs into Python exceptions that get raised when
control returns to Python.  On the other hand, if most of what we are
using wxASSERT for today got turned into C++ exceptions which I could
catch and turn into Python exceptions, and if those exceptions were
still checked for and thrown even when __WXDEBUG__ is turned off then
that would be just as good (and probably much better.)

e. There are probably one or two other things that I am not thinking of
right now...

--
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!


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

Reply | Threaded
Open this post in threaded view
|

Re[2]: wxWidgets version 3?

Vadim Zeitlin-3
On Wed, 15 Feb 2006 15:45:31 -0800 Robin Dunn <[hidden email]> wrote:

RD> Goal #1:  wxTNG shall make it very easy to create language bindings such
RD> as wxPython.

 It's not very surprizing that you should say this, of course, but it can
potentially be quite a big problem because some of the other changes risk
to go in the opposite direction.

RD> a. Reduce the reliance on virtual methods to be as small as possible.

 In one possible design I'm thinking of there are no virtual functions at
all so this might make you happy.

RD> b. "Clean" headers without a lot of heavy macro use or complex C++
RD> cruft.

 OTOH just about anything I think of for wxTNG involves using complex C++
which will probably be unparsable by SWIG (unless its template support has
improved beyong my wildest dreams). I really don't know how to reconcile
wxTNG plans with SWIG features. I'm very curious how does Stefan deal with
this.

 Personally I think that maybe the only way to make it work is to have a
wx2-like low-level library with wxTNG API on top of it. This would allow to
continue using SWIG (on low-level library headers) and also keep some
(most?) compatibility with wx2 API, too.

RD> c. Most C++ class instances should have a user-data pointer that is not
RD> used for anything in the framework.

 This is a very C-ish approach, in C++ there are really better ways. But I
think that this is not very important, in the worst case you can just use a
map to associate user-data with any pointer anyhow.

RD> d. It would be nice if there was a separation of __WXDEBUG__ and
RD> wxASSERT

 This is pretty minor as well but it's probably still worth it to add to
the page Ryan mentioned:

        http://www.wxwidgets.org/wiki/index.php/WxWidgets3

 Regards,
VZ


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

Reply | Threaded
Open this post in threaded view
|

Re: wxWidgets version 3?

Robin Dunn
Vadim Zeitlin wrote:

> On Wed, 15 Feb 2006 15:45:31 -0800 Robin Dunn <[hidden email]> wrote:
>
> RD> Goal #1:  wxTNG shall make it very easy to create language bindings such
> RD> as wxPython.
>
>  It's not very surprizing that you should say this, of course, but it can
> potentially be quite a big problem because some of the other changes risk
> to go in the opposite direction.
>
> RD> a. Reduce the reliance on virtual methods to be as small as possible.
>
>  In one possible design I'm thinking of there are no virtual functions at
> all so this might make you happy.

It certainly would!

>
> RD> b. "Clean" headers without a lot of heavy macro use or complex C++
> RD> cruft.
>
>  OTOH just about anything I think of for wxTNG involves using complex C++
> which will probably be unparsable by SWIG (unless its template support has
> improved beyong my wildest dreams). I really don't know how to reconcile
> wxTNG plans with SWIG features. I'm very curious how does Stefan deal with
> this.

If this is the price of having to virtuals then I would be willing to
give up on this one.  On the other hand, the template support in SWIG
has improved, although I haven't tried using it to know how much
improvement.

>
>  Personally I think that maybe the only way to make it work is to have a
> wx2-like low-level library with wxTNG API on top of it. This would allow to
> continue using SWIG (on low-level library headers) and also keep some
> (most?) compatibility with wx2 API, too.

That sounds like a lot of work, and would probably have maintenance
issues, unless some parts of it could be autogenerated in some way.

--
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!


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

12