Was there not some way to show the sizers in a running application? I seem to recall that Robin mentioned this at some point but I can't find the message anymore.
Werner
Werner F. Bruhin wrote:
Was there not some way to show the sizers in a running application? I seem to recall that Robin mentioned this at some point but I can't find the message anymore.
Ctrl-Alt-Shift-middle-mouse-click. It can be a bit tricky to use, as there has to be some exposed portion of the window you are interested in to click on. Otherwise you may not see all of the sizers you want to see. Also, it's only in 2.7.x.
···
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn wrote:
Werner F. Bruhin wrote:
Was there not some way to show the sizers in a running application? I seem to recall that Robin mentioned this at some point but I can't find the message anymore.
Ctrl-Alt-Shift-middle-mouse-click. It can be a bit tricky to use, as there has to be some exposed portion of the window you are interested in to click on. Otherwise you may not see all of the sizers you want to see. Also, it's only in 2.7.x.
Trying this in 2.6.3.3 on Windows, and 2.6.3 on Mac, results in a dialog showing wxWidgets library version info.
The version I get is reported as a "Debug build", which surprised me.
Is that message for real, or just a glitch (i.e. it's not really a debug build but is incorrectly reported as such)?
Is there anything special one should know about using a debug build? Performance issues, size, etc?
-Peter
Hi Robin,
Robin Dunn wrote:
Werner F. Bruhin wrote:
Was there not some way to show the sizers in a running application? I seem to recall that Robin mentioned this at some point but I can't find the message anymore.
Ctrl-Alt-Shift-middle-mouse-click. It can be a bit tricky to use, as there has to be some exposed portion of the window you are interested in to click on. Otherwise you may not see all of the sizers you want to see. Also, it's only in 2.7.x.
Any chance the red lines could be drawn in the foreground? E.g. in the sizers demo 'More Grid Features' it is difficult to see that there are sub-sizers.
Werner
Hi,
I'm trying to print WITHOUT setup dialog (using system defaults) but without sucess.
I am playing with the example from chapter 17 of THE BOOK (wxpython in action):
- If I use useSetupDialog = True, everything works ok.
- If I use useSetupDialog = False, I get no errors but also NO OUTPUT.
Here wx 2.6 AND 2.7 on Windows.
TIA
Antonio Barbosa
Re: [wxPython-users] Show sizers
Hi,
I’m trying to print WITHOUT setup dialog (using system defaults) but without sucess.
I am playing with the example from chapter 17 of THE BOOK (wxpython in action):
-
If I use useSetupDialog = True, everything works ok.
-
If I use useSetupDialog = False, I get no errors but also NO OUTPUT.
Here wx 2.6 AND 2.7 on Windows.
TIA
Antonio Barbosa
Robin Dunn wrote:
> Werner F. Bruhin wrote:
>> Was there not some way to show the sizers in a running application? I
>> seem to recall that Robin mentioned this at some point but I can't
>> find the message anymore.
>
> Ctrl-Alt-Shift-middle-mouse-click. It can be a bit tricky to use, as
> there has to be some exposed portion of the window you are interested in
> to click on. Otherwise you may not see all of the sizers you want to
> see. Also, it's only in 2.7.x.Trying this in 2.6.3.3 on Windows, and 2.6.3 on Mac, results in a dialog
showing wxWidgets library version info.The version I get is reported as a "Debug build", which surprised me.
Is that message for real, or just a glitch (i.e. it's not really a debug
build but is incorrectly reported as such)?
From what I understand, wxPython is always built as a debug binary.
Is there anything special one should know about using a debug build?
Performance issues, size, etc?
Are you currently concerned about performance issues, size, etc? If not,
don't worry.
- Josiah
···
Peter Hansen <peter@engcorp.com> wrote:
Josiah Carlson wrote:
Is that message for real, or just a glitch (i.e. it's not really a debug build but is incorrectly reported as such)?
From what I understand, wxPython is always built as a debug binary.
Fair enough, but is it well known to others what "debug binary" implies? It is not to me, I'm afraid. I can imagine it might mean things like "library file size is 4MB larger because of compiler symbol table not being stripped" or "lots of debugging hooks still in place, resulting in major slowdown compared to non-debug builds". (Obviously I wouldn't expect the latter, at least, but I really don't know to expect.)
Is there anything special one should know about using a debug build? Performance issues, size, etc?
Are you currently concerned about performance issues, size, etc? If not,
don't worry.
Sure I'm concerned. I see, for example, that our code on Mac mini is pretty sluggish. Not being really familiar with Mac performance, I don't know whether I should suspect the Mac CPU or wxPython/wxWidgets, or something else. (My guess is it has nothing to do with wx and is simply that Mac minis are sluggish... I'm not overly impressed with performance of anything GUI-related on it right now.)
If you're really asking the usual "do I need more performance?" instead of just "am I concerned?", then the answer is "we don't want our users to complain that the application appears to run much slower than similar Mac apps, and since we don't know what 'debug build' means, we do want to know whether lesser performance or memory footprint might be involved so we can make informed decisions."
Hope that helps. I appreciate any background info on this. Meanwhile I'll do a little googling to see where it says something about "wxPython is always built as a debug binary" and see if that answers my questions already.
-Peter
···
Peter Hansen <peter@engcorp.com> wrote:
Peter Hansen wrote:
Josiah Carlson wrote:
Is that message for real, or just a glitch (i.e. it's not really a debug build but is incorrectly reported as such)?
From what I understand, wxPython is always built as a debug binary.
Fair enough, but is it well known to others what "debug binary" implies? It is not to me, I'm afraid. I can imagine it might mean things like "library file size is 4MB larger because of compiler symbol table not being stripped" or "lots of debugging hooks still in place, resulting in major slowdown compared to non-debug builds". (Obviously I wouldn't expect the latter, at least, but I really don't know to expect.)
The wxPython binaries are actually a hybrid between what would traditionally be called a debug build vs. a release build. Like a release build the flags that turn on the debug symbols are not used, and compiler optimizations are turned on. What makes it appear to be a debug build is that the __WXDEBUG__ flag is turned on, which causes the wxASSERT runtime checks to be turned on. If any of these fail then wxPython turns it into a PyAssertionError exception. I feel that having these assertions/exceptions is worth the overhead of the extra code that is run to make the check, especially because in some cases it makes the difference between getting an exception and just crashing for no reason.
So yes, there is some overhead, but it is not as bad as "debug build" sounds because it is still built with the compiler optimizations turned on, etc. If you really need to eek out all the performance you can, then wxPython will work fine without a __WXDEBUG__ build of wxWidgets, (as long as you don't do anything that would trigger an assert) you will just need to do the build yourself.
Is there anything special one should know about using a debug build? Performance issues, size, etc?
Are you currently concerned about performance issues, size, etc? If not,
don't worry.Sure I'm concerned. I see, for example, that our code on Mac mini is pretty sluggish. Not being really familiar with Mac performance, I don't know whether I should suspect the Mac CPU or wxPython/wxWidgets, or something else. (My guess is it has nothing to do with wx and is simply that Mac minis are sluggish... I'm not overly impressed with performance of anything GUI-related on it right now.)
Is it a PPC or an Intel processor? I've been pretty impressed with my Intel mini, once I gave it enough RAM that it didn't need to swap out for everything.
···
Peter Hansen <peter@engcorp.com> wrote:
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Werner F. Bruhin wrote:
Hi Robin,
Robin Dunn wrote:
Werner F. Bruhin wrote:
Was there not some way to show the sizers in a running application? I seem to recall that Robin mentioned this at some point but I can't find the message anymore.
Ctrl-Alt-Shift-middle-mouse-click. It can be a bit tricky to use, as there has to be some exposed portion of the window you are interested in to click on. Otherwise you may not see all of the sizers you want to see. Also, it's only in 2.7.x.
Any chance the red lines could be drawn in the foreground? E.g. in the sizers demo 'More Grid Features' it is difficult to see that there are sub-sizers.
Submit a bug report, it's possible that having it use a wxWindowDC or a wxScreendDC instead of the wxClientDC would work okay...
···
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn wrote:
The wxPython binaries are actually a hybrid between what would traditionally be called a debug build vs. a release build. ...
So yes, there is some overhead, but it is not as bad as "debug build" sounds because it is still built with the compiler optimizations turned on, etc.
I completely agree with your judgment in keeping the assertions in there Robin. Thanks for the background.
...I see, for example, that our code on Mac mini is pretty sluggish.
Is it a PPC or an Intel processor? I've been pretty impressed with my Intel mini, once I gave it enough RAM that it didn't need to swap out for everything.
They're Intel processors (1.5GHz Intel Core Solo) with 512MB RAM. I get 34000 pystones on them.
My (subconscious?) basis for comparison is probably my Win XP laptop, with a 1.6GHz Pentium M and 512MB RAM. It clocks in at about 42000 pystones but seems much snappier.
I'm pretty sure most of the "sluggish" GUI behaviour I feel like I'm seeing is not from Python's behaviour, and possibly not even from wxPython/wxWidgets, but from some lack of responsiveness in the OS itself. Still, most of my exposure to the Mac has been testing our app on it, so I'm by no means ready to pass final judgment on it. Some of the sluggishness *was* from some poor code in portions of our GUI, and it's rather better with that fixed.
-Peter
Peter Hansen wrote:
...I see, for example, that our code on Mac mini is pretty sluggish.
Is it a PPC or an Intel processor? I've been pretty impressed with my Intel mini, once I gave it enough RAM that it didn't need to swap out for everything.
They're Intel processors (1.5GHz Intel Core Solo) with 512MB RAM. I get 34000 pystones on them.
Mine is a 1.66 GHz Core Duo, and I started at 512M. I found that most of the sluggishness of the system disappeared when I added more RAM. Keep in mind that the video buffer is shared with main memory in these systems and so you've probably really got something like 384-448 Meg of effective RAM. At that level running just a few apps at once and trying to switch between them can feel like trying to run through waist deep jello. I'm at 1.5G now, and even when when doing memory intensive things (like compiling wxPython) there is very little virtual memory swapping going on so the system is pretty snappy.
···
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
I did not realize that OSX was that memory hungry. Obviously more
memory = better, but I didn't know that the ceiling was so low.
- Josiah
···
Robin Dunn <robin@alldunn.com> wrote:
Peter Hansen wrote:
>>> ...I see, for example, that our code on Mac mini is pretty sluggish.
>>
>> Is it a PPC or an Intel processor? I've been pretty impressed with my
>> Intel mini, once I gave it enough RAM that it didn't need to swap out
>> for everything.
>
> They're Intel processors (1.5GHz Intel Core Solo) with 512MB RAM. I get
> 34000 pystones on them.Mine is a 1.66 GHz Core Duo, and I started at 512M. I found that most
of the sluggishness of the system disappeared when I added more RAM.
Keep in mind that the video buffer is shared with main memory in these
systems and so you've probably really got something like 384-448 Meg of
effective RAM. At that level running just a few apps at once and trying
to switch between them can feel like trying to run through waist deep
jello. I'm at 1.5G now, and even when when doing memory intensive
things (like compiling wxPython) there is very little virtual memory
swapping going on so the system is pretty snappy.
Josiah Carlson wrote:
Peter Hansen wrote:
...I see, for example, that our code on Mac mini is pretty sluggish.
Is it a PPC or an Intel processor? I've been pretty impressed with my Intel mini, once I gave it enough RAM that it didn't need to swap out for everything.
They're Intel processors (1.5GHz Intel Core Solo) with 512MB RAM. I get 34000 pystones on them.
Mine is a 1.66 GHz Core Duo, and I started at 512M. I found that most of the sluggishness of the system disappeared when I added more RAM. Keep in mind that the video buffer is shared with main memory in these systems and so you've probably really got something like 384-448 Meg of effective RAM. At that level running just a few apps at once and trying to switch between them can feel like trying to run through waist deep jello. I'm at 1.5G now, and even when when doing memory intensive things (like compiling wxPython) there is very little virtual memory swapping going on so the system is pretty snappy.
I did not realize that OSX was that memory hungry. Obviously more
memory = better, but I didn't know that the ceiling was so low.
It probably had as much or more to do with what I was typically running (a couple instances of CarbonEmacs, X-Windows, WingIDE sometimes, etc.) than OSX itself. Running a compile of wxPython would end up swapping everything out to disk because some of the source files are huge, and then trying to do anything after that meant that something needed swapped back in the first time it was used, even if it had been a while since the compile.
···
Robin Dunn <robin@alldunn.com> wrote:
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!