Should Raise()/Lower() be moved to wxTopLevelWindow?
Peter Most
there is currently a little discussion going on (http://
trac.wxwidgets.org/ticket/12524) whether to move Raise() and Lower()
to wxTopLevelWindow.
These discussions come up time and time again, so I would like to know
from wx users whether you are more interested in retaining backward
compatibility or would you be more interested in a clean/intuitive
interface, even if it would mean breaking your project?
Regards Peter
Alan Shouls
Hi everybody,
Regards Peter
--
To unsubscribe, send email to wx-dev+un...@googlegroups.com
or visit http://groups.google.com/group/wx-dev
Vadim Zeitlin
PM> These discussions come up time and time again, so I would like to know
PM> from wx users whether you are more interested in retaining backward
PM> compatibility or would you be more interested in a clean/intuitive
PM> interface, even if it would mean breaking your project?
I don't think it's the right way to address such questions because you
will automatically get bias against keeping compatibility by asking people
here because people subscribed to the list(s) are bound to follow wx
development closer than its users on average and also because it seems like
a no-brainer when you ask it like this. The real question to ask would be:
Imagine you try to recompile your huge existing code base with
wxWidgets 3.0 and you start getting errors about calling Raise()
for the code which looks perfectly valid because it calls it on
wxFrame[x] and the documentation clearly shows this method there.
Will you try to fix the problem or just decide that wxWidgets 3.0
is broken (especially because you will already have had to fix a
few other issues due to Unicode changes) and just stay with the old
version?
[x] You call it via wxWindow pointer but, of course, you don't necessarily
realize that this is a problem.
Put like this, the answer seems to be obvious too, doesn't it?
So unless we can somehow convince ourselves that such cases would be
exceedingly rare (e.g. by checking that no such code occurs in a few big
open source projects using wx) I remain opposed to this change. The benefit
is just not big enough to justify the breakage.
Regards,
VZ
Carsten Fuchs
On 29.09.2010 11:51, Vadim Zeitlin wrote:
> [...]
> Will you try to fix the problem or just decide that wxWidgets 3.0
> is broken (especially because you will already have had to fix a
> few other issues due to Unicode changes) and just stay with the old
> version?
Fix the problem of course!
> The benefit
> is just not big enough to justify the breakage.
The breakage occurs only once, and even only when expected (major version upgrade!) anyway.
If the breakage happens, it's easy to locate, easy to understand and easy to fix; especially nothing
will break unnoticed (which are the *much* worse breakages).
Needlessly confusing API lasts, for months and *years*, possibly complicating every days work.
Best regards,
Carsten
--
Cafu - the open-source Game and Graphics Engine
for multiplayer, cross-platform, real-time 3D Action
Learn more at http://www.cafu.de
Dimitri Schoolwerth
> These discussions come up time and time again, so I would like to know
> from wx users whether you are more interested in retaining backward
> compatibility or would you be more interested in a clean/intuitive
> interface, even if it would mean breaking your project?
I'm in favour of keeping backwards compatibility as much as possible
between 2.8 and 3.0. I've had to make my fair share of compile time
changes (mostly Unicode related) and run time fixes when switching
from 'just' 2.8 to 2.9. They were mostly small things, but they all
add up. If it weren't for wanting 64-bit OS X support I would probably
have stuck with 2.8 for a while longer.
While a more sensible API is very important to me, I put more weight
into giving people a smoother upgrade.
Regards,
Dimitri
Ronny Krueger
>
> PM> These discussions come up time and time again, so I would like to know
> PM> from wx users whether you are more interested in retaining backward
> PM> compatibility or would you be more interested in a clean/intuitive
> PM> interface, even if it would mean breaking your project?
>
> I don't think it's the right way to address such questions because you
> will automatically get bias against keeping compatibility by asking people
> here because people subscribed to the list(s) are bound to follow wx
> development closer than its users on average and also because it seems like
> a no-brainer when you ask it like this. The real question to ask would be:
>
> Imagine you try to recompile your huge existing code base with
> wxWidgets 3.0 and you start getting errors about calling Raise()
> for the code which looks perfectly valid because it calls it on
> wxFrame[x] and the documentation clearly shows this method there.
>
> Will you try to fix the problem or just decide that wxWidgets 3.0
> is broken (especially because you will already have had to fix a
> few other issues due to Unicode changes) and just stay with the old
> version?
then I would not give up so easily. I would expect things to have
changed in a major version upgrade. After all, if everything stayed the
same what would be the point of the upgrade?
>
> [x] You call it via wxWindow pointer but, of course, you don't necessarily
> realize that this is a problem.
>
> Put like this, the answer seems to be obvious too, doesn't it?
>
> So unless we can somehow convince ourselves that such cases would be
> exceedingly rare (e.g. by checking that no such code occurs in a few big
> open source projects using wx) I remain opposed to this change. The benefit
> is just not big enough to justify the breakage.
breakage. But there are a couple of other 'little' problems that have
piled up over the years. If it is not possible to fix these problems
even with a major version upgrade then they will haunt us forever. ;-)
Best regards,
Ronny
Vadim Zeitlin
RK> If I decided that it is worth to upgrade my application to wxWidgets 3.0
RK> then I would not give up so easily.
It's an accumulation of problems which can result in this, not just this
one problem in itself, of course. Any extra incompatibility makes it more
likely that people won't finish migrating their code to 3.0 (or will do it
later) and I'd like to avoid this.
RK> You might be right about this particular problem not being worth the
RK> breakage. But there are a couple of other 'little' problems that have
RK> piled up over the years. If it is not possible to fix these problems
RK> even with a major version upgrade then they will haunt us forever. ;-)
Of course we did fix some of them but the analysis should be done case by
case and in this particular case I can only repeat that I don't think the
benefits are not worth it.
I guess my main point is that even such "minor" compatibility changes are
neither costless nor painless as some people seem to believe. Each of them
on its own might be, but the combination of them (including those that will
be needed due to the changes that had already been done) is not so they
still have a non-zero cost.
Regards,
VZ
Peter Most
> will automatically get bias against keeping compatibility by asking people
> here because people subscribed to the list(s) are bound to follow wx
> development closer than its users on average and also because it seems like
> a no-brainer when you ask it like this. The real question to ask would be:
Well, maybe I was to optimistic in assuming that everybody developing with
wxWidgets is reading the list ;-) BTW: Just to be clear, I did ask just to get
a feeling of how users think about it and not to annoy you or anything like
that!
> Will you try to fix the problem or just decide that wxWidgets 3.0
> is broken (especially because you will already have had to fix a
> few other issues due to Unicode changes) and just stay with the old
> version?
> Put like this, the answer seems to be obvious too, doesn't it?
If I wanted to update then I would fix the errors, otherwise I would simply
stay on the old version.
As you can guess from my questions and discussions, I think a little more
radical (others might even say naive) because I'm a fan of the Python approach
which simply states: "Don't update if you don't like your code to break". I'm
asking so much, because I have the feeling that a lot of time gets spend on
keeping old features or supporting ancient compilers. I ask myself whether
wxWidgets could be more/better if we simply removed some features, dropped the
support for some ancient compiler, so more time would be available for the
'important' stuff. I know what you might ask: "What if you would be the
developer with the ancient compiler? How happy would you that the support was
dropped?" Of course I wouldn't be to happy, but I would understand that the wx
developers would like to spend their time on more important things. wxTNG
anybody? ;-) I certainly think the wxWidgets code base would be a lot simpler
if we would remove some stuff like the old Connect() and all the macros it
depends on (message maps, casting macros etc.) and I'm sure we could find some
more.
But maybe you could shed some light onto it, assuming we could/would remove
all the old and/or deprecated stuff for 3.0, how much time could you or the
other main developer then spend on new stuff?
What currently concerns me the most, are the design 'oddities' like the
recently discussed SetScrollBar() which I have to deal with in wxQt. But
hopefully these are exceptions rather then the norm ;-)
Regards Peter
PS: I just checked and Qt also offers raise()/lower() for the QWidget base
class, so maybe it's not that odd to have it in wxWindow. Go figure!
PSS: Is there some document which explains how code marked as deprecated is
handled? I mean when is deprecated code going to be removed?
Vadim Zeitlin
PM> Well, maybe I was to optimistic in assuming that everybody developing with
PM> wxWidgets is reading the list
You definitely are. I don't have the exact numbers but I'm quite sure that
the vast majority of wx users are not subscribed to the list.
PM> As you can guess from my questions and discussions, I think a little more
PM> radical (others might even say naive) because I'm a fan of the Python approach
PM> which simply states: "Don't update if you don't like your code to break".
That might be fine for them because they have the manpower to update
several versions simultaneously (there are a lot of other differences
between a programming language like Python and a library like wx too). We
don't so it's pretty important to use the latest version of wx if you want
to receive any fixes and so it shouldn't be made more difficult than
necessary.
PM> I certainly think the wxWidgets code base would be a lot simpler if we
PM> would remove some stuff like the old Connect() and all the macros it
PM> depends on (message maps, casting macros etc.) and I'm sure we could
PM> find some more.
I think you vastly underestimate the complexity of removing things. It's
pretty difficult to do it without breaking something. And, of course,
removing Connect() and event macros would all but ensure that nobody
updates.
I'm very, very sceptical of the possibility to dramatically simplify the
existing code base without making it incompatible enough to not justify
keeping any sort of compatibility at all. I stated my personal (and
unfortunately not shared by anybody else AFAIK) point of view long ago: the
way forward is to create the new API interoperable with but quite different
from the existing one and provide an implementation of it using existing
wx. This would be a huge effort, of course, but it could be done
incrementally and freeing ourselves from *all* compatibility constraints
would definitely be very liberating.
PM> PSS: Is there some document which explains how code marked as deprecated is
PM> handled? I mean when is deprecated code going to be removed?
Yes, 2 (minor) versions after it was removed.
Regards,
VZ
Robert Roebling
> As you can guess from my questions and discussions, I think a little more
> radical (others might even say naive) because I'm a fan of the Python approach
> which simply states: "Don't update if you don't like your code to break".
As Vadim already pointed out, this is clearly not the approach taken
be wxWidgets and I honestly don't think it is the approach of Python
either. It is my impression that Python doesn't remove or break
something until there is an overwhelmingly good reason for doing so
and very limited risk of uers having to recode major portions of source
code - but maybe you'll find an example where this is wrong.
Robert
Trigve
> [snip]
> ... I ask myself whether
> support for some ancient compiler, so more time would be available for the
> 'important' stuff. I know what you might ask: "What if you would be the
> developer with the ancient compiler? How happy would you that the support was
> dropped?" Of course I wouldn't be to happy, but I would understand that the wx
> developers would like to spend their time on more important things. wxTNG
> anybody? ;-) I certainly think the wxWidgets code base would be a lot simpler
> if we would remove some stuff like the old Connect() and all the macros it
> depends on (message maps, casting macros etc.) and I'm sure we could find some
> more.
>
don't like to support
things that are old and/or have bad design in my projects. Whenever if
I could choose
between API break and fix the issue with something new or API stable
and hack-around the bug
I choose API break. Also for major version change API/ABI break is
reasonable. boost change
API a lot frequent and I don't have problem with it because there is
always some README
where changes are described and upgrade instruction provided.
I think that wx shouldn't support old compilers like VC6. Also VS 2003
is discussable.
I think it is better to put effort to new things and clean the code
base from old code.
Anyway when I'm upgrading some dependencies to some major version I'm
reserving some time
(about week) for upgrade (for resolving errors etc.) So far I don't
remember having big
troubles while upgrading.
Thanks
Trigve
Peter Most
I know it isn't, but maybe it could. Maybe removing some big baggage
might be a good thing. As I mentioned Connect/MessageMaps with all its
dependencies would be my first candidate. The documentation is even
recommending to use dynamic event binding:
"handling events dynamically is better in several aspects and you
should strongly consider doing it if you are just starting with
wxWidgets"
And the upcoming 3.0 release might be a good candidate for such
changes. BTW: Since Vadim mentioned that I underestimate the work, I
gladly do the work and remove the mentioned Connect/MessageMaps code
with a patch (and fix all dependent code like samples, tests etc. of
course).
> ... and I honestly don't think it is the approach of Python
> either.It is my impression that Python doesn't remove or break
> and very limited risk of uers having to recode major portions of source
> code - but maybe you'll find an example where this is wrong.
"Python 3.0 will break backwards compatibility. Totally. We're not
even aiming for a specific common subset"
Regards Peter
Vadim Zeitlin
PM> I know it isn't, but maybe it could. Maybe removing some big baggage
PM> might be a good thing.
I don't think so. Once again, for me our 2 goals are keeping existing
users and attracting new ones. Removing event table macros will create a
world of pain for the existing users and won't do anything to attract new
ones (because they can already use Connect() or Bind() without any
problems). So IMO this would be a pretty bad thing to do because it will
work against one of our goals and will do nothing for the other one.
Again, if you want to break compatibility you need to break it totally to
be able to implement the new API designed according to everything we learnt
during the last 15 years. It doesn't make sense to partially break the
existing one. You'll just alienate your users (and rightly so) without any
gain.
PM> "handling events dynamically is better in several aspects and you
PM> should strongly consider doing it if you are just starting with
PM> wxWidgets"
Well, yes, I wrote this. I don't see why do you think it implies that the
event tables should be removed.
PM> And the upcoming 3.0 release might be a good candidate for such
PM> changes. BTW: Since Vadim mentioned that I underestimate the work, I
PM> gladly do the work and remove the mentioned Connect/MessageMaps code
PM> with a patch (and fix all dependent code like samples, tests etc. of
PM> course).
I still think you underestimate it but it doesn't really matter. Removing
event tables from wx is something that is just not on the table at all, it
would be, to put it mildly, completely suicidally mad from project
management point of view.
I wrote before that each case should be considered on its own cost/benefit
merits. This one is so off the scale on towards the +inf side that I can
hardly imagine anything which would be further from inclusion in wx than
this. Well, maybe the bright idea (argued for quite seriously by a few
people many years ago) that we ought to rename all wxFoos into wx::Foo,
i.e. put all the classes in wx namespace.
PM> I let the inventor speak for himself: http://www.artima.com/weblogs/viewpost.jsp?thread=208549
PM>
PM> "Python 3.0 will break backwards compatibility. Totally. We're not
PM> even aiming for a specific common subset"
I don't have the time to read the blog now but I wonder if it wasn't a
joke because to the best of my knowledge Python 3 is very, very close to
Python 2. There are precious few things that they changed (although, of
course, even those few do provoke quite a lot of grumbling).
FWIW I personally prefer the Perl 6 way. It's a totally new language
sharing the philosophy of Perl 5 and (some) developers of the latter. This
is exactly what I think would be ideal for wx. Unfortunately I can't point
to Perl 6 as a shining success example but at least they tried and did
something very interesting -- and it's still not impossible that it does
succeed (I sincerely hope and wish it). And even right now the language
itself is pretty delicious, it's "just" the implementation that is lacking.
Regards,
VZ
Marianne Gagnon
I may point out that the patch I attached to this ticket modifies the
documentation for wxWindow::Raise/Lower to specify to use
wxTopLevelWindow::Raise/Lower instead, so I believe confusion is not
really possible
In general, I think it's definitely too radical to remove macros/
Connect, but I would indeed be in favor of a patch that updates all
samples to Bind.
I think wxWidgets 3.0 is _the_ occasion to make breaking changes in a
long while; wxWidgets is sometimes bashed for having an obtuse API. I
only see this kind of change as a needed improvement that, all in all,
should be easy to change
FYI: I searched for Raise/Lower in CodeLite, a rather large wxWidgets
project, and the few occurrences there would not break compilation
since applied directly on wxFrame. I also searched wxFormBuilder and
found the same. I also searched Audacity, and there be only a couple
lines that would need to be modified. Code::Blocks would need a couple
line changes - but these few changes include an inappropriate call to
Raise on a wxButton.
So my conclusion is that this change would not cause major breakages.
merely a couple warnings that would be easily fixed, even in very
large wx projects.
* wxGetTopLevelParent should return a wxTopLevelWindow to go along
this change painlessly. I've found this a couple times when searching
the code bases :
wxTopLevelWindow *frame =
wxDynamicCast(wxGetTopLevelParent(GetParent()), wxTopLevelWindow);
Peter Most
> users and attracting new ones. Removing event table macros will create a
but only if they decide to update to 3.0. If they don't want to change
the code, then they could simply stay on 2.9.
> and won't do anything to attract new
> ones (because they can already use Connect() or Bind() without any
> problems).
VC6, but that's my point, the wx api, in this example, is bloated with
code for ancient compilers).
> Again, if you want to break compatibility you need to break it totally to
> be able to implement the new API designed according to everything we learnt
> during the last 15 years. It doesn't make sense to partially break the
> existing one. You'll just alienate your users (and rightly so) without any
> gain.
"evolution". Sadly such revolutions rarely succeed, but if you change
the API gradually then you can 'drag' the existing users with you
until you reached the 'new' (wxTNG) API.
Regards Peter
Vadim Zeitlin
PM> > I don't think so. Once again, for me our 2 goals are keeping existing
PM> > users and attracting new ones. Removing event table macros will create a
PM> > world of pain for the existing users...
PM>
PM> but only if they decide to update to 3.0. If they don't want to change
PM> the code, then they could simply stay on 2.9.
This basically mean that they will never update. I wonder what could
possibly justify completely removing the upgrade route for all the existing
wx users.
PM> > and won't do anything to attract new ones (because they can already
PM> > use Connect() or Bind() without any problems).
PM>
PM> But why do we need both?
We don't need both but there is really absolutely no huge problem with
having them. Again, the benefits of removing Connect() are so tiny that I
just don't see why are we discussing it.
PM> What you want is a wx "revolution" were I am arguing for an wx
PM> "evolution". Sadly such revolutions rarely succeed, but if you change
PM> the API gradually then you can 'drag' the existing users with you
PM> until you reached the 'new' (wxTNG) API.
No, this will *never* succeed in this case. There are fundamental problem
with wx API which simply can not be fixed by any evolutionary approach.
Regards,
VZ
Marianne Gagnon
I already mentionned I think removing Connect and event tables is too
radical. However, I would be in favor of documenting that Bind is
preferred from new projects.
In my time spent on IRC and the wxForum, I found that a *lot* of users
learn from the wxWidgets book. If the book is updated to teach Bind
first, I'm sure new projects would get written with Bind. No need to
break all existing code.
-- Auria
Vadim Zeitlin
MG> Regarding the user being confused as to why the method was deprecated,
MG> I may point out that the patch I attached to this ticket modifies the
MG> documentation for wxWindow::Raise/Lower to specify to use
MG> wxTopLevelWindow::Raise/Lower instead, so I believe confusion is not
MG> really possible
It is, of course, we can't rely on everybody reading the documentation.
Life would be so much simpler otherwise.
MG> FYI: I searched for Raise/Lower in CodeLite, a rather large wxWidgets
MG> project, and the few occurrences there would not break compilation
MG> since applied directly on wxFrame. I also searched wxFormBuilder and
MG> found the same. I also searched Audacity, and there be only a couple
MG> lines that would need to be modified. Code::Blocks would need a couple
MG> line changes - but these few changes include an inappropriate call to
MG> Raise on a wxButton.
Well, it might be inappropriate but it probably does no harm neither. And
the fact that you did find that there is existing code out there which
would be broken (thanks a lot for doing this BTW, it's always nice to have
some facts in a discussion) is IMO the nail in the coffin of this change.
MG> So my conclusion is that this change would not cause major breakages.
Yes but the minor breakages it would cause are absolutely unnecessary.
There are no real problems with having Raise() and Lower() in wxWindow that
can't be solved by updating the documentation (which nobody will read, of
course...).
And again, Raise() and Lower() are just 2 of probably a dozen if not more
of wxWindow methods that it shouldn't have. So we don't really solve
anything by removing them, we just annoy our users for no real gain.
MG> * wxGetTopLevelParent should return a wxTopLevelWindow to go along
MG> this change painlessly.
Yes, I think this would be nice to change independently of the rest.
Regards,
VZ
Robert Roebling
Vadim Zeitlin wrote:
In my last post in the thread I agreed with you on general terms that
(even minor) breakages with little gain are not our policy of -
especially not for subjectively perceived "cleanness" of a certain API
(like renaming a method for no good reason other than that the new name
may follow naming rules better than the old one). However in this case,
the presence of wxWindow::Lower() and ::Raise() is directly misleading
and calling them with a wxWindow pointer is more likely to be just wrong
(trying to call it on a normal window) than correct (using a wxWindow
pointer to hold a wxTLW).
I'm for removing it from wxWindow.
Robert
Peter Most
> PM> "evolution". Sadly such revolutions rarely succeed, but if you change
> PM> the API gradually then you can 'drag' the existing users with you
> PM> until you reached the 'new' (wxTNG) API.
>
> No, this will *never* succeed in this case. There are fundamental problem
> with wx API which simply can not be fixed by any evolutionary approach.
reached last year:
http://groups.google.com/group/wx-dev/browse_frm/thread/8cdb94b3c2913fc6?
I don't want to say 'I told you so' but it seems another year has gone
without moving wx toward wxTNG :-( Don't get me wrong here, I'm not
questioning your motivation and dedication to wx here, but you have to
ask yourself whether wxTNG will ever become a reality or will it stay
an elusive dream?
If I understood you correctly, then wTNG should be a layer on top of
wxWidgets which then will offer a new and improved API. But who should
maintain such an effort? Again, I'm not questioning you or anybody
else's efforts here, but judging from the svn commits there either
isn't much to do for wx or developers simply don't have more time,
because they have enough to do with their daily work.
Regards Peter
PS: I can not emphasize this enough, I'm not questioning anybodies
effort for wx, but I'm quite good at asking uncomfortable questions.
Bryan Petty
> And the upcoming 3.0 release might be a good candidate for such
> changes. BTW: Since Vadim mentioned that I underestimate the work, I
> gladly do the work and remove the mentioned Connect/MessageMaps code
> with a patch (and fix all dependent code like samples, tests etc. of
> course).
Our 3.0 release _has_ been a great candidate for some major changes
already. There are a ton of things application developers will already
have to update in their code that will break when upgrading from 2.8
to 3.0, _especially_ with wxMac->wxOSX. I don't have to outline all of
the major changes, it's already been done on a nearly 5 page _summary_
overview:
http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/docs/publicity/WoWoW30.html?revision=58809&view=co
But even though I am all for removing the event table mess from
wxWidgets (I could actually see some major gains provided in regards
to new users being able to more easily figure out how to create custom
events), our general policy on even minor API breakage has been to
deprecate for one full stable version first (in the version where the
alternative solution has been provided), then actually remove it in
the stable branch following that.
Every application uses events in one way or another, and while I know
many developers have been pretty good about using Connect()
religiously, many have still been using static event tables where
Connect() wasn't necessary, and as has already been pointed out, the
samples are still teaching newbies to use static event tables. (+1
from me on a patch to the samples to move to Bind in time for the 3.0
release)
1) This is not a minor API breakage, this is a big deal, and we've had
plenty of those already to live up to a new major version.
2) The alternative solution here is actually wxEvtHandler::Bind() (not
Connect()), and that isn't in wxWidgets 2.8, so we don't have an
interim release for developers to take their time to handle updates
for planned removal. The earliest version we can reasonably remove
this is in wxWidgets 3.2.
There's nothing wrong with putting this off until 3.2 rather than 3.0,
and no, we don't have to wait until 4.0 to remove it.
I could even reasonably understand dropping VC7.0/VC7.1 with the 3.2
release too for that matter (someone mentioned this, though I didn't
catch it this had something to do with event tables or bind). Someone
will have to remind me, we are dropping support for VC6 in 3.0,
correct? (we should be if we aren't, it's ridiculous that we even
supported it in 2.8)
Actually, now that I look at it, the manual and msw/install.txt still
list for 2.9 still list Windows 95/98/ME, which I thought we were
dropping, and install.txt even still mentions that "VC5.0 can also be
used, providing Service Pack 3 is applied."
Regards,
Bryan Petty
Marianne Gagnon
> Actually, now that I look at it, the manual and msw/install.txt still
> list for 2.9 still list Windows 95/98/ME, which I thought we were
> dropping, and install.txt even still mentions that "VC5.0 can also be
> used, providing Service Pack 3 is applied."
>
-- Auria
Vadim Zeitlin
RR> the presence of wxWindow::Lower() and ::Raise() is directly misleading
I agree but so is the presence of many other methods. I don't see any big
gain from solving the problem for a couple of rarely (or almost never in
case of Lower()) used methods.
RR> and calling them with a wxWindow pointer is more likely to be just wrong
RR> (trying to call it on a normal window) than correct (using a wxWindow
RR> pointer to hold a wxTLW).
Using wxWindow pointer to hold a wxTLW is pretty common in the older code
because wxTLW is a relatively recent class (not even 10 years old...).
RR> I'm for removing it from wxWindow.
I'm still against. What we could do however would be to add an assert in
it. Then the code would still compile fine but if it does call the function
on a non-TLW then we could complain about it.
Regards,
VZ
Vadim Zeitlin
PM> > PM> What you want is a wx "revolution" were I am arguing for an wx
PM> > PM> "evolution". Sadly such revolutions rarely succeed, but if you change
PM> > PM> the API gradually then you can 'drag' the existing users with you
PM> > PM> until you reached the 'new' (wxTNG) API.
PM> >
PM> > No, this will never succeed in this case. There are fundamental problem
PM> > with wx API which simply can not be fixed by any evolutionary approach.
PM>
PM> It seems we reached the same point in the discussion which we already
PM> reached last year:
PM> http://groups.google.com/group/wx-dev/browse_frm/thread/8cdb94b3c2913fc6?
Not surprising, I arrived at this conclusion several years ago and nothing
happened to change my mind since then.
PM> I don't want to say 'I told you so' but it seems another year has gone
PM> without moving wx toward wxTNG :-( Don't get me wrong here, I'm not
PM> questioning your motivation and dedication to wx here, but you have to
PM> ask yourself whether wxTNG will ever become a reality or will it stay
PM> an elusive dream?
I don't know. Obviously there are even less chances for its success than
for that of Perl 6 but I still have some hope. I do think that I need to
start working on it as soon as 3.0 is released -- or never. Which is one of
the reasons I'd like to release 3.0 a.s.a.p. (i.e. this year).
PM> If I understood you correctly, then wTNG should be a layer on top of
PM> wxWidgets which then will offer a new and improved API. But who should
PM> maintain such an effort?
I obviously hope to attract new people to the project with this effort. I
have no illusions about doing everything myself, I can only start the ball
rolling -- and hope the others join in. Alas, so far I didn't even manage
to do this.
Regards,
VZ
iko...@earthlink.net
Well, support for VC5 was dropped after 2.8, thecode in trunk still
checks for it. Does the ticket clear up code as well?
>
>-- Auria
Peter Most
> have no illusions about doing everything myself, I can only start the ball
> rolling -- and hope the others join in. Alas, so far I didn't even manage
> to do this.
Regards Peter
Robin Dunn
> And the upcoming 3.0 release might be a good candidate for such
> changes.
Even if it was a good idea to remove these things, any deprecations done
now could not be removed until 3.2. They have to go through an entire
stable release series in the deprecated state with the replacement
available.
>
>> ... and I honestly don't think it is the approach of Python
>> either.It is my impression that Python doesn't remove or break
>> something until there is an overwhelmingly good reason for doing so
>> and very limited risk of uers having to recode major portions of source
>> code - but maybe you'll find an example where this is wrong.
>
> I let the inventor speak for himself: http://www.artima.com/weblogs/viewpost.jsp?thread=208549
>
> "Python 3.0 will break backwards compatibility. Totally. We're not
> even aiming for a specific common subset"
The incompatibilities in the 2.x --> 3.x change is the exception, not
the rule. For at least the language perspective, and most of the
standard library perspective, Python code that ran in 1.5 over a decade
ago will very likely still run in 2.7.
--
Robin Dunn
Software Craftsman
http://wxPython.org
Robert Roebling
> > ... and I honestly don't think it is the approach of Python
> > either.It is my impression that Python doesn't remove or break
> > something until there is an overwhelmingly good reason for doing so
> > and very limited risk of uers having to recode major portions of source
> > code - but maybe you'll find an example where this is wrong.
>
> I let the inventor speak for himself: http://www.artima.com/weblogs/viewpost.jsp?thread=208549
>
> "Python 3.0 will break backwards compatibility. Totally. We're not
> even aiming for a specific common subset"
I didn't know about this, but the policy was different sofar. Python
is also very different in that it probably has more than a million
users and can affort to lose a few hundred thousands who may not like
these changes. Last not least, noone knows if a big and incompatible
change will eventually actually be a success even for Python. Too
many good things have been ruined before.
Again, in this particular case (wxWindow::Raise()), I'm actually
in favor of the change.
Robert