What had you done differently?

wxPython Users
1

Hi there,

This is my very first code using wxPython, so please be gentle on me.

Like I mentioned in the title I wonder what you, experts, would had done differenty and for what reason?

All inputs are welcome… …

Can I link the statusbar (self.sb_StatusBar.) to the routine (SavePrimes) so that I can put the code

self.sb_StatusBar.SetStatusText(“Writing to file, please wait… …”)
self.sb_StatusBar.SetStatusText(“Writing to file finished.”)

in the routine itself instead of the main code?

Now I have this code twice and that’s not nice :frowning:

Thanks for inputs!

Best regards

PrimeNumbers.py (6.96 KB)

···

From my side I have 1 specific question:

2

Hi there,

Hi there,
This is my very first code using wxPython, so please be gentle on me.

We are always gentle on this list:-)

Like I mentioned in the title I wonder what you, experts, would had done differenty and for what reason?
All inputs are welcome... ...

I am no expert but I would change the following:
- don't use globals, especially not for ID's, use instead wx.ID_ABOUT, wx.ID_EXIT and wx.ID_ANY
http://wxpython.org/Phoenix/docs/html/StandardID.enumeration.html
http://docs.wxwidgets.org/trunk/page_stockitems.html
- don't use fixed sizes and positions use sizers - I particularly like to use wx.lib.sized_controls, see the demo for a sample
- if code is getting larger you might also want to put things like menu and control creation into methods and call these methods from __init__
- if you think to ever translate the UI into other languages you might want to look into 'gettext' and wrap all the text as follows
# at import time do
_ = wx.GetTranslation

# your texts
_("# Primes found: ")

From my side I have 1 specific question:
Can I link the statusbar (self.sb_StatusBar.) to the routine (SavePrimes) so that I can put the code
                self.sb_StatusBar.SetStatusText("Writing to file, please wait... ...")
                self.sb_StatusBar.SetStatusText("Writing to file finished.")
in the routine itself instead of the main code?

Either make SavePrimes a method of 'frm_Primes' or pass the instance of frm_Primes to SavePrimes, in other words call it like:
SavePrimes(self, self.fp_FilePicker.GetPath(), lstPrimes,self.spn_Maximum.GetValue(),j)

and change the signature of SavePrimes to:
def SavePrimes(parent, MyFile, MyPrimes, MyMaximum, MyCount):

then you can do in SavePrimes:
parent.sb_StatusBar.SetStatusText("Writing to file, please wait... ...")

Or if you don't want to couple SavePrimes to a parent you could use wx.lib.pubsub to send a message from SavePrimes and whoever handles the StatusBar would listen to these messages and display them.

Hope this helps
Werner

···

On 8/14/2014 9:27, 'mcs51mc' via wxPython-users wrote:

3

Hi Werner, Thanks for your reaction!

I passes the reference of frm_Primes to routine SavePrimes to access the statusbars as you suggested.
That was easier than I thought and it works fine!

I’m going through the (almost) 1000 lines of code of [LearnSizers1.py] to learn about the sizers.
I first did some trials with [wxFormBuilder] but didn’t get anywhere so I used fixed positions.

I’m confused about the [wx.ID_xxxx] stuff.
For now I can indeed use the three id’s you mentioned but how to handle more menu options in the future?
I mean, there is for sure not a unique ID for all future menu items one can create in that enumeration.
So I miss the point of using such enumeration.

Regards

4

@mcs51mc, as I understand you need a way to create many IDs.
You can create a method in your class, that will set needed IDs:
def SetIDs(self):
self.ID_OPEN = wx.NewId()
self.ID_CLOSE = wx.NewId()
When you use wx.NewId, it generates a new, unique ID, which can be safely used.
Hope this helps :slight_smile:

···

On Thursday, August 14, 2014 3:13:51 PM UTC+2, mcs51mc wrote:

Hi Werner, Thanks for your reaction!

I passes the reference of frm_Primes to routine SavePrimes to access the statusbars as you suggested.
That was easier than I thought and it works fine!

I’m going through the (almost) 1000 lines of code of [LearnSizers1.py] to learn about the sizers.
I first did some trials with [wxFormBuilder] but didn’t get anywhere so I used fixed positions.

I’m confused about the [wx.ID_xxxx] stuff.
For now I can indeed use the three id’s you mentioned but how to handle more menu options in the future?
I mean, there is for sure not a unique ID for all future menu items one can create in that enumeration.
So I miss the point of using such enumeration.

Regards

5

Hi GamerCat,
Thanks for your reply!

I knew I had a lot of things to learn :slight_smile:
I changed the code as you suggested, 1 step closer to professionalism, many 2 go :wink:
Update code with both your suggestions in attachment…

Regards

PrimeNumbers.py (6.95 KB)

6

I’m confused about the [wx.ID_xxxx] stuff.

For now I can indeed use the three id’s you mentioned but how to handle more menu options in the future?
I mean, there is for sure not a unique ID for all future menu items one can create in that enumeration.
So I miss the point of using such enumeration.

If there are standard IDs, then you want to use them. That way, wx can adjust things to conform to platform standards, like put the quit and help menu items in the right place.

For your own items that don’t have standard IDs, you should use wx.ID_ANY where possible, and not use IDs to track things at all, but rather keep references to widgets you need to access. Menu items are a bit tricky, but it can be done. See:

http://wiki.wxpython.org/wxPython%20Style%20Guide

For other style suggestions.

(Note: that page is linked from the front page in the “advanced” section–that should be more prominent. sorry, I’m not going to try to fix that on a phone :wink: )

HTH,

-Chris

Chris

···

Regards

–

You received this message because you are subscribed to the Google Groups “wxPython-users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

7

Hi Chris,

If there are standard IDs, then you want to use them. That way, wx can adjust things to conform to platform standards, like put the quit and help menu items in the right place.

What do you mean by what I put in bold in above phrase?
It’s not by assigning “ID_OPEN” to a menu item that wx will put that item in the second place of a menu called “File”, right?
So what do you mean by this “wx can adjust things”?
What wil wx really do when you assing “ID_ABOUT” to a menu item?

I found almost the same idea in the “Style Guide for wxPython code”

It is useful to use the standard IDs because they may turn on standard functionality, such as menu item remapping for wxMac, automatic Dialog completion or cancellation, using stock button labels and images, etc.

But stil it’s unclear to me what the benefice is for those standard ID’s :frowning:

The menu options are locate in the menu according to the code written whatever the ID is, so ???
Also it’s rather confusing to use a “ID_EXIT” for a “Quit” button or “Quit” menu item as shown in line 60 of the example code of the “Style Guide for wxPython code”.

item = FileMenu.Append(wx.ID_EXIT, text="&Quit")

Bottom line: That ID stuff is still fuzzy to me… …

Best regards

···

On Thursday, 14 August 2014 16:45:37 UTC+2, Chris Barker - NOAA Federal wrote:

8

The order of items Appended to a menu determines the order they’re displayed. The Ctrl-Q stuff for quit/exit is called an accelerator. See here for a nice explanation of how to do all this menu and accelerator stuff:

Otherwise your code looks like it works… I never use explicit sizes or positions, so that’d be my only main difference (I’d change the menu stuff too to not use explicit IDs). Sizers are quite simple really though, they’re just like arrays/lists, setting up the position of everything is just like a 2D array then, pretty simple. There are more complex sizers too, but they basically follow the same 2D-array-mindset rules, but have some exceptions for allowing certain places to extend into the next-door areas.

···

On Thursday, August 14, 2014 10:10:02 AM UTC-7, mcs51mc wrote:

Hi Chris,
On Thursday, 14 August 2014 16:45:37 UTC+2, Chris Barker - NOAA Federal wrote:

If there are standard IDs, then you want to use them. That way, wx can adjust things to conform to platform standards, like put the quit and help menu items in the right place.

What do you mean by what I put in bold in above phrase?
It’s not by assigning “ID_OPEN” to a menu item that wx will put that item in the second place of a menu called “File”, right?
So what do you mean by this “wx can adjust things”?
What wil wx really do when you assing “ID_ABOUT” to a menu item?

I found almost the same idea in the “Style Guide for wxPython code”

It is useful to use the standard IDs because they may turn on standard functionality, such as menu item remapping for wxMac, automatic Dialog completion or cancellation, using stock button labels and images, etc.

But stil it’s unclear to me what the benefice is for those standard ID’s :frowning:

The menu options are locate in the menu according to the code written whatever the ID is, so ???
Also it’s rather confusing to use a “ID_EXIT” for a “Quit” button or “Quit” menu item as shown in line 60 of the example code of the “Style Guide for wxPython code”.

item = FileMenu.Append(wx.ID_EXIT, text="&Quit")

Bottom line: That ID stuff is still fuzzy to me… …

Best regards

9

I found almost the same idea in the "Style Guide for wxPython code"

*It is useful to use the standard IDs because they may turn on standard
functionality, such as menu item remapping for wxMac, automatic Dialog
completion or cancellation, using stock button labels and images, etc. *

But stil it's unclear to me what the benefice is for those standard ID's :frowning:

that's pretty clear to me, but...

I think this would make most sense to you if you have a Mac -- *nix (GTK)
doesn't really have clear standards. But Windows sort of does, and Mac very
much does. So, for instance, on the Mac:

The Quit and Preferences menu items go on the "application" menu, not the
File menu -- wx will move them for you if you use the standard ID.

I also think default placement for "OK" and "Cancel" buttons is different
on standard dialogs on different systems. wx will make those
platform-style-conforming too.

Short version -- use a standard ID when there is one to use -- no reason
not to, and it it will make your app more platfrom native for free.

The menu options are locate in the menu according to the code written
whatever the ID is, so ???

nope -- wx will move things for you.

Also it's rather confusing to use a "ID_EXIT" for a "Quit" button or
"Quit" menu item as shown in line 60 of the example code of the "Style
Guide for wxPython code".

well, "quit" and "exit" are synonyms -- I think "Quit") is teh MAc standard
name, but maybe other systems use "exit" -- I don't know that those get
re-written for you...

item = FileMenu.Append(wx.ID_EXIT, text="&Quit")

Bottom line: That ID stuff is still fuzzy to me... ...

yeah -- a good reason not to use them except for the standard ones.

-HTH,
  - Chris

···

On Thu, Aug 14, 2014 at 10:10 AM, 'mcs51mc' via wxPython-users < wxpython-users@googlegroups.com> wrote:

Best regards

--
You received this message because you are subscribed to the Google Groups
"wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

10

Hi,
Thanks for the constructive reactions!
Yesterday I did some trials using standard and my own ID’s for menu items and whatever I used, the menu items appears in the menu as I added them in my code. Nathan’s post tends to confirm this behaviour. That’s why I had some doubts about “… wx can adjust things to conform to platform standards,… …” as Chris mentioned.

But when it comes to Buttons & Sizers it’s a different story!
With code below one gets indeed a standard lay out OK button on the left, Cancel button on the right both on the right hand side of the box whatever order is used in the code.
cmd_Quit = wx.Button(self, wx.ID_CANCEL, “&Quit”)
cmd_OK = wx.Button(self, wx.ID_OK, “&OK”)
cmd_OK.SetDefault()
btnSizer = wx.StdDialogButtonSizer()
btnSizer.AddButton(cmd_OK)
btnSizer.AddButton(cmd_Quit)
btnSizer.Realize()

Even better, when using ‘wx.ID_EXIT’ for the cmd_Quit button it doesn’t appear in the box at all. For sure because the ‘wx.StdDialogButtonSizer()’ routine don’t know what to do with that ID, it expects ID_OK & ID_CANCEL, nothing else.

So, regarding buttons it’s indeed recommended to use standard ID’s but when it comes to menus I think it’s meaningless, right?

Best regards
Alain

11

Hi Alain,

You might even want to try this:

         cmd_Quit = wx.Button(self, wx.ID_CANCEL)
         cmd_OK = wx.Button(self, wx.ID_OK)

see also the wxPython demo for Stock Buttons.

So, regarding buttons it’s indeed recommended to use standard ID’s but when it comes to menus I think it’s meaningless, right?

Have you done a test on a Mac? IIRC Chris is mainly working on that platform and I would just take his word:-) .

I (and I believe Chris and others) would even advocate NOT to use ID's unless you have to (meaning if wx requires then just use wx.ID_ANY) and if you have to use standard ID's if they exist and only use your own ID's otherwise.

Werner

···

On 8/15/2014 9:14, 'mcs51mc' via wxPython-users wrote:

12

Hi Werner,
I forgot to mention in my previous post, I don’t have a Mac available; I can only test on my Win8.1Pro machine using Python 2.7.
With only the 2 buttons like you suggested I got a window with the 2 buttons on top of each other. The first programmed is visible, the other not.
Did you expect to see the button with the “ID_EXIT” or “ID_CANCEL” (tried both with same outcome) in the lower right corner of the window?
If that is the case on your machine, it’s not on mine :frowning:
On this web page click one can read “The standard id will automatically add an icon and a shortcut. Ctrl + Q in our case.”
Well that isn’t the case when I run that code :frowning:
No icon and no shortcut on the menu item, only the “Quit” word.
Therefore I was a bit skeptical regarding that “automatic” stuff.

It’s not that I don’t believe you guys, it’s just that when I run some code found here and there it’s not always acting like mentioned.
Can one of you try that “zetcode” (above link) and tell me if you have that icon & shortcut or not?

Maybe I miss something on my system… …

Best regards
Alain

13

Hey Alain.
I've tested this script and...

I got exit icon on Linux, but no icons on Mac and Windows.
That's strange. Maybe it is because of wxPython version? On Linux I have
2.8, while on Mac and Win 3.x.
Or maybe it is because this tutorial was written for Linux...

But I think you still can put icons there. I remember making apps with
icon in the menu bar on Windows.

Good luck!
GamerCat

···

On Fri, 2014-08-15 at 01:04 -0700, 'mcs51mc' via wxPython-users wrote:

Hi Werner,
I forgot to mention in my previous post, I don’t have a Mac available;
I can only test on my Win8.1Pro machine using Python 2.7.

With only the 2 buttons like you suggested I got a window with the 2
buttons on top of each other. The first programmed is visible, the
other not.
Did you expect to see the button with the “ID_EXIT” or
“ID_CANCEL” (tried both with same outcome) in the lower right corner
of the window?
If that is the case on your machine, it’s not on mine :frowning:

On this web page click one can read “The standard id will
automatically add an icon and a shortcut. Ctrl + Q in our case.”
Well that isn’t the case when I run that code :frowning:
No icon and no shortcut on the menu item, only the "Quit" word.
Therefore I was a bit skeptical regarding that “automatic” stuff.

It’s not that I don’t believe you guys, it’s just that when I run some
code found here and there it’s not always acting like mentioned.
Can one of you try that “zetcode” (above link) and tell me if you have
that icon & shortcut or not?

Maybe I miss something on my system… …

Best regards
Alain

14

Hi Alain,

Note that a lot of the demo's out there and some even on the wx wiki are not always up to date, or influenced by the writers preferred platform.

...

It’s not that I don’t believe you guys, it’s just that when I run some code found here and there it’s not always acting like mentioned.
Can one of you try that “zetcode” (above link) and tell me if you have that icon & shortcut or not?

Maybe I miss something on my system… …

With the attached modified sample from zetcode (one should tell them that the shebang is wrong).

I see:
On Windows:
- the correct/expected text for menu and buttons using standard ID's is shown, but no icon nor short cut

On Linux Mint 17:
- the correct/expected text for menu with shortcut and icon and the correct text for buttons is shown

On MAC:
that is still on the wish list:), therefore can't test it there.

Note that all this is using Native controls (which is the nice thing about wx) and therefore does maybe not always do what you would expect on all platforms.

Note that if you I18N enable your application these texts will be translated into the language the user has active when running the app.

Werner

menuAndButtons.py (1.2 KB)

···

On 8/15/2014 10:04, 'mcs51mc' via wxPython-users wrote:

15

Hi,
Thanks for testing GamerCat!
I also have version 3.0 of wxPython and no automatic shortcut & icon in menu items when using standard ID’s.
Maybe someone forgot something in version 3.0 ?!?

Best regards
Alain

16

I think/guess it is platform native behaviour - but really not sure.

Just had a look at the doc for wxPython Phoenix which confirms the above:
http://wxpython.org/Phoenix/docs/html/Button.html?highlight=standard%20button

Werner

···

On 8/15/2014 11:29, 'mcs51mc' via wxPython-users wrote:

Hi,
Thanks for testing GamerCat!
I also have version 3.0 of wxPython and no automatic shortcut & icon in menu items when using standard ID's.
Maybe someone forgot something in version 3.0 ?!?

17

hi,
I have changed only a thing, now every time that calculates the primes the data are saved in a log.txt file
that you can read from the bar of the menu going on file log.
I have also changed other things…:slight_smile:
just for funny…
regards

p.s.
I’m on debian 6, with python 2.6 and wxpython 2.8

prime_numbers.py (6.6 KB)

···

Il giorno giovedì 14 agosto 2014 09:27:49 UTC+2, mcs51mc ha scritto:

Hi there,

This is my very first code using wxPython, so please be gentle on me.

Like I mentioned in the title I wonder what you, experts, would had done differenty and for what reason?

All inputs are welcome… …

From my side I have 1 specific question:

Can I link the statusbar (self.sb_StatusBar.) to the routine (SavePrimes) so that I can put the code

self.sb_StatusBar.SetStatusText(“Writing to file, please wait… …”)
self.sb_StatusBar.SetStatusText(“Writing to file finished.”)

in the routine itself instead of the main code?

Now I have this code twice and that’s not nice :frowning:

Thanks for inputs!

Best regards

18

Hi Werner,
Thanks for testing on different systems!
Not having icons in the menu isn’t a life-threatening issue, so I can live with it.
What do you mean by “I18N” at the end of your post?

Hi beppe,
Except for the algorithm itself I barely recognized my code, but it’s a good start for me to learn some things on sizers.
Showing the primes in a control is not such a good idea since when a large number is chosen it takes a looong looong time to fill up that control.
You can for sure have a cappuchino while waiting :slight_smile: :slight_smile:
So I skipped some things from your code an used some other ones to come to this (final) version using sizers.
I still don’t
feel 100% comfortable using sizers but : practice makes perfect … …

Thanks to all of you for the instructive inputs!
Best regards
Alain

PrimeNumbers.py (7.63 KB)

19

…a cappuccino even not but a coffee of sure, with self.spn_Maximum set to max 900000

to calculate 71274 prime numbers, write results on widget, idem on file 51,15 sec

I thought worse…:wink:

regars
beppe

···

Il giorno venerdì 15 agosto 2014 19:14:18 UTC+2, mcs51mc ha scritto:

Hi Werner,
Thanks for testing on different systems!
Not having icons in the menu isn’t a life-threatening issue, so I can live with it.
What do you mean by “I18N” at the end of your post?

Hi beppe,
Except for the algorithm itself I barely recognized my code, but it’s a good start for me to learn some things on sizers.
Showing the primes in a control is not such a good idea since when a large number is chosen it takes a looong looong time to fill up that control.
You can for sure have a cappuchino while waiting :slight_smile: :slight_smile:
So I skipped some things from your code an used some other ones to come to this (final) version using sizers.
I still don’t
feel 100% comfortable using sizers but : practice makes perfect … …

Thanks to all of you for the instructive inputs!
Best regards
Alain

20

Internationalization (I18N), see Internationalization - wxPyWiki

Werner

···

On 8/15/2014 19:14, 'mcs51mc' via wxPython-users wrote:

Hi Werner,
Thanks for testing on different systems!
Not having icons in the menu isn’t a life-threatening issue, so I can live with it.
What do you mean by “I18N” at the end of your post?