I noticed that in the demo's Main.py that (wx)FloatBar had been deprecated.
What replaced it? According to the docs, (wx)ToolBar's float flag only works
on GTK. Is that a typo?
Jeff Grimmett wrote:
I noticed that in the demo's Main.py that (wx)FloatBar had been deprecated.
What replaced it? According to the docs, (wx)ToolBar's float flag only works
on GTK. Is that a typo?
The main reason it got depecated was because its author didn't support it any more and I got tired of fixing bugs in it and even when it worked it didn't work all that well.
BTW, I've just realized that there is a potential problem with your renaming the demo modules while you are working on them. I am also making funciton changes to some of the modules to correct runtime problems (API changes and such) but you won't get those changes merged with yours with a CVS update if you've renamed the files... So you may want to change the filenames back and then after we've merged your changes into CVS we can do the renaming. Make sense?
···
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Jeff Grimmett wrote:
> I noticed that in the demo's Main.py that (wx)FloatBar had been
deprecated.
> What replaced it? According to the docs, (wx)ToolBar's float
flag only works
> on GTK. Is that a typo?
The main reason it got depecated was because its author didn't support
it any more and I got tired of fixing bugs in it and even when it worked
it didn't work all that well.
Is it coming out of the package completely?
At any rate, the demo *has* been converted and appears to work.
BTW, I've just realized that there is a potential problem with your
renaming the demo modules while you are working on them. I am also
making funciton changes to some of the modules to correct runtime
problems (API changes and such) but you won't get those changes merged
with yours with a CVS update if you've renamed the files... So you may
want to change the filenames back and then after we've merged your
changes into CVS we can do the renaming. Make sense?
Ya know, no matter how you look at that, it's gonna be ugly. As I'm renaming
them I'm also changing the lookup tables used by the demo and verifying that
they're working correctly, so it's a little more than just a rename thing.
However, one thing I could do is merge your changes into mine before I send
the final 'product' to you. I imagine the merging is more grunt work which
I'm quite quallified for (g) and I'd be happy to do it if it'll streamline
things for you.
If you'd prefer not, I'll do a massive rename back after I've completed my
changes and send them to you that way. Your call, chief 
Jeff Grimmett wrote:
The main reason it got depecated was because its author didn't support
it any more and I got tired of fixing bugs in it and even when it worked
it didn't work all that well.Is it coming out of the package completely?
Probably not.
At any rate, the demo *has* been converted and appears to work.
I guess we coudl reenable the demo then.
BTW, I've just realized that there is a potential problem with your
renaming the demo modules while you are working on them. I am also
making funciton changes to some of the modules to correct runtime
problems (API changes and such) but you won't get those changes merged
with yours with a CVS update if you've renamed the files... So you may
want to change the filenames back and then after we've merged your
changes into CVS we can do the renaming. Make sense?Ya know, no matter how you look at that, it's gonna be ugly. As I'm renaming
them I'm also changing the lookup tables used by the demo and verifying that
they're working correctly, so it's a little more than just a rename thing.However, one thing I could do is merge your changes into mine before I send
the final 'product' to you. I imagine the merging is more grunt work which
I'm quite quallified for (g) and I'd be happy to do it if it'll streamline
things for you.If you'd prefer not, I'll do a massive rename back after I've completed my
changes and send them to you that way. Your call, chief
However you want to handle it would be fine. I just thought that renaming the files back, doing the cvs update and letting it merge the changes and then renaming the files again would be easier for you.
···
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
However you want to handle it would be fine. I just thought that
renaming the files back, doing the cvs update and letting it merge the
changes and then renaming the files again would be easier for you.
Thought about it at work and realized that I will be doing another full pass
after we get a V2.5 installable anyway, since there were a few things that
had to be done before it could be marked as 'complete', so what I'll do is
rename them back before I send them to you. I'll save the 'Great Renaming'
for the last step before committing the completed demo conversion to you.
At the rate I'm going, I should have the first pass ready for you by the end
of the weekend. Sooner if I get more time in on it this weekend.
Jeff Grimmett wrote:
However you want to handle it would be fine. I just thought that
renaming the files back, doing the cvs update and letting it merge the
changes and then renaming the files again would be easier for you.Thought about it at work and realized that I will be doing another full pass
after we get a V2.5 installable anyway, since there were a few things that
had to be done before it could be marked as 'complete', so what I'll do is
rename them back before I send them to you. I'll save the 'Great Renaming'
for the last step before committing the completed demo conversion to you.
Sounds good. Just be sure to *not* update your copy of the demo from CVS until after you have a 2.5 binary as some of the changes I'm making will not be compatible. (Yeah, it's a chicken/egg problem...)
···
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
> rename them back before I send them to you. I'll save the
'Great Renaming'
> for the last step before committing the completed demo
conversion to you.Sounds good. Just be sure to *not* update your copy of the demo from
CVS until after you have a 2.5 binary as some of the changes I'm making
will not be compatible. (Yeah, it's a chicken/egg problem...)
Yeah, I sorta noticed that A lot of the demos require importing of
docstrings from the library they are demonstrating, for example, and the wx
renamer in 2.4 isn't dealing well with that. I thought about debugging that,
but I figured that I'd wait until I had a nice comfy 2.5 environment to work
in since I might be debugging something I can't fix without it.
I think it's a given that the first 'ready to run' 2.5 dev release will have
a largely non-functional demo, but that sort of thing happens on big API
changes.
Out of curiosity, has anyone ever built wx from CVS within the cygwin
environment, or is it completely dependent on MS Visual Studio?
Jeff Grimmett wrote:
Out of curiosity, has anyone ever built wx from CVS within the cygwin
environment, or is it completely dependent on MS Visual Studio?
wxWindows will build with mingw32 or cygwin, but wxPython's setup.py would need some work to make it possible.
···
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Jeff Grimmett wrote:
> Out of curiosity, has anyone ever built wx from CVS within the cygwin
> environment, or is it completely dependent on MS Visual Studio?wxWindows will build with mingw32 or cygwin, but wxPython's setup.py
would need some work to make it possible.
OK, next question: should the resulting library be identical, or will it
require the cygwin library to run?
If I build it locally, I just want to make sure I have something realistic
to test against, is all.
Jeff Grimmett wrote:
Jeff Grimmett wrote:
Out of curiosity, has anyone ever built wx from CVS within the cygwin
environment, or is it completely dependent on MS Visual Studio?wxWindows will build with mingw32 or cygwin, but wxPython's setup.py
would need some work to make it possible.OK, next question: should the resulting library be identical, or will it
require the cygwin library to run?
It will require cygwin. Even if you use mingw32 so it doesn't need the cygwin DLL you'll still end up with different wxPython extensions because the C++ names are mangled differently between compilers. So it is an all or nothing deal.
···
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
> OK, next question: should the resulting library be identical, or will it
> require the cygwin library to run?It will require cygwin. Even if you use mingw32 so it doesn't need the
cygwin DLL you'll still end up with different wxPython extensions
because the C++ names are mangled differently between compilers. So it
is an all or nothing deal.
Doesn't sound like it's worth pursuing from other than academic interest,
then. Thanks.