First a little background. Probably 95% of the places in a Windows or GTK application where you would use a Ctrl key, the equivalent on Mac would be to use the Cmd key instead. For example, the traditional accelerator for paste is Ctrl-V on Windows and Cmd-V on Macs. The reason for this difference is probably lost in the mists of time, so let's just call it tradition or the quirkiness of Apple.
One of wxMac's goals is to help cross-platform applications to fit in and behave more natively on Macs, so one of the first things it did was to automatically convert things like "Ctrl-V" in menu accelerators to "Cmd-V". Later on we added the concept of the CmdDown and related modifier flags to help key and char event handlers to not care whether it is the Control key or the Meta (command) key that is being pressed. In other words, CmdDown would be True on non-Macs if the Control key is pressed, and it would be True on Macs if the Command key is pressed. If it was implemented in Python code it would look like this:
def CmdDown(self):
if 'wxMac' in wx.PlatformInfo:
return self.MetaDown()
else:
return self.ControlDown()
That was the situation in 2.8.
In 2.9 things have been taken one step further. I'm not sure all of the reasons behind this, but one of them was to make it possible to have real Ctrl accelerators on Mac, in addition to those that get automatically converted to Cmd accelerators. So now we have RawControlDown and associated modifier flags and etc. On non-Mac platforms RawControlDown is the same as ControlDown. On Macs RawControlDown is used for the real Ctrl key on the keyboard, and ControlDown is used for the command key. You can also use accelerator strings like "RawCtrl-H" in menu items to create an accelerator that will always use Ctrl on all platforms, and not be converted to Cmd on Macs.
Unfortunately I noticed last week that not all of this has been exposed to wxPython yet (the RawControlDown method was missing) so you'll need to get the latest 2.9.4 preview build to be able to use it.
···
On 6/24/12 9:39 AM, Barry Scott wrote:
I noticed, my app broke, that the handling of keys has changed
from 2.8 to 2.9.3.1.
In OnKeyDown the Mac Cmd key causes 2.9.3.1 to claim
that both ControlDown() and CmdDown() are true.
Where as The MAc Ctrl key cause 2.9.3.1 to claim
that both ControlDown() and CmdDown() are false.
You also have changed the names of the keys
in 2.8 Cmd is WXK_COMMAND changed to WXK_CONTROL
in 2.8 Ctrl is WXK_CONTROL changed to WKX_RAW_CONTROL
In 2.8 holding down Cmd or Ctrl allows OnChar to be called
but in 2.9.3.1 they prevent OnChar being called.
Am I looking at bugs? (COontrolDown/CmdDown behaviour seems buggy)
Needing to migrate code?
I noticed, my app broke, that the handling of keys has changed
from 2.8 to 2.9.3.1.
In OnKeyDown the Mac Cmd key causes 2.9.3.1 to claim
that both ControlDown() and CmdDown() are true.
Where as The MAc Ctrl key cause 2.9.3.1 to claim
that both ControlDown() and CmdDown() are false.
You also have changed the names of the keys
in 2.8 Cmd is WXK_COMMAND changed to WXK_CONTROL
in 2.8 Ctrl is WXK_CONTROL changed to WKX_RAW_CONTROL
In 2.8 holding down Cmd or Ctrl allows OnChar to be called
but in 2.9.3.1 they prevent OnChar being called.
Am I looking at bugs? (COontrolDown/CmdDown behaviour seems buggy)
Needing to migrate code?
First a little background. Probably 95% of the places in a Windows or GTK application where you would use a Ctrl key, the equivalent on Mac would be to use the Cmd key instead. For example, the traditional accelerator for paste is Ctrl-V on Windows and Cmd-V on Macs. The reason for this difference is probably lost in the mists of time, so let's just call it tradition or the quirkiness of Apple.
Copied from the mac where windows and CDE did not have a command key so ctrl was used.
One of wxMac's goals is to help cross-platform applications to fit in and behave more natively on Macs, so one of the first things it did was to automatically convert things like "Ctrl-V" in menu accelerators to "Cmd-V". Later on we added the concept of the CmdDown and related modifier flags to help key and char event handlers to not care whether it is the Control key or the Meta (command) key that is being pressed. In other words, CmdDown would be True on non-Macs if the Control key is pressed, and it would be True on Macs if the Command key is pressed. If it was implemented in Python code it would look like this:
def CmdDown(self):
if 'wxMac' in wx.PlatformInfo:
return self.MetaDown()
else:
return self.ControlDown()
That was the situation in 2.8.
In 2.9 things have been taken one step further. I'm not sure all of the reasons behind this, but one of them was to make it possible to have real Ctrl accelerators on Mac, in addition to those that get automatically converted to Cmd accelerators. So now we have RawControlDown and associated modifier flags and etc. On non-Mac platforms RawControlDown is the same as ControlDown. On Macs RawControlDown is used for the real Ctrl key on the keyboard, and ControlDown is used for the command key. You can also use accelerator strings like "RawCtrl-H" in menu items to create an accelerator that will always use Ctrl on all platforms, and not be converted to Cmd on Macs.
I will have to work with these changes in my barry's emacs and pysvn to see if you are making life easier or harder.
Unfortunately I noticed last week that not all of this has been exposed to wxPython yet (the RawControlDown method was missing) so you'll need to get the latest 2.9.4 preview build to be able to use it
Where can i download this from ?
···
On 25 Jun 2012, at 17:31, Robin Dunn <robin@alldunn.com> wrote:
On 25 Jun 2012, at 17:31, Robin Dunn <robin@alldunn.com> wrote:
Unfortunately I noticed last week that not all of this has been exposed to wxPython yet (the RawControlDown method was missing) so you'll need to get the latest 2.9.4 preview build to be able to use it
Hello,
I've been using wxpython on windows for a few years and very happy with it. I recently purchased a Mac air which runs 64 bit OS. I installed python 27 and wxpython but it crashes when I import wx. The error is "no matching architecture in universal wrapper". I googled the error and it appears wxpython is not able to run 64bit python on Mac OS. The workaround seems to be to simply run python as 32 bit... I'm wondering if there will be a release in the near future to resolve this issue?
Thanks!
···
On Jun 25, 2012, at 2:34 PM, Robin Dunn <robin@alldunn.com> wrote:
On 6/25/12 2:16 PM, Barry Scott wrote:
On 25 Jun 2012, at 17:31, Robin Dunn <robin@alldunn.com> wrote:
Unfortunately I noticed last week that not all of this has been exposed to wxPython yet (the RawControlDown method was missing) so you'll need to get the latest 2.9.4 preview build to be able to use it
There is, but it's the 2.9 series, which is slightly less stable (both
with respect to API, and actual performance). I've been using this
for more than a year without too many problems - most of my Mac users
are running this, in fact. You can download binaries here (you want
the one with "cocoa" in the file name):
On Tue, Jun 26, 2012 at 9:52 AM, Jeff Peery <jeffpeery@yahoo.com> wrote:
I've been using wxpython on windows for a few years and very happy with it. I recently purchased a Mac air which runs 64 bit OS. I installed python 27 and wxpython but it crashes when I import wx. The error is "no matching architecture in universal wrapper". I googled the error and it appears wxpython is not able to run 64bit python on Mac OS. The workaround seems to be to simply run python as 32 bit... I'm wondering if there will be a release in the near future to resolve this issue?