Hello,
I gave my program a "Focus on window" menu item which puts the
keyboard focus on the `Frame` so keyboard shortcuts will work.
However, that doesn't work on Mac. It seems like Mac can't focus on a
Frame. Is this right?
What *can* I focus on when using Mac OS so that keyboard shortcuts
will work?
Thanks,
Ram.
Hello,
I gave my program a "Focus on window" menu item which puts the
keyboard focus on the `Frame` so keyboard shortcuts will work.
However, that doesn't work on Mac. It seems like Mac can't focus on a
Frame. Is this right?
Yes.
What *can* I focus on when using Mac OS so that keyboard shortcuts
will work?
If you have a panel in the frame then put the focus there. If that panel has children then the focus will move automatically to a child widget that can accept the focus. As long as the focus is somewhere within the frame then any accelerators associated with it (from the menubar or explicitly from an accelerator table) will be active.
On 12/6/10 11:53 AM, cool-RR wrote:
--
Robin Dunn
Software Craftsman
My shortcuts aren’t implemented with accelerators; I’m using EVT_KEY_DOWN.
Also, my frame is PyAUI-managed.
Ram.
On Mon, Dec 6, 2010 at 11:13 PM, Robin Dunn robin@alldunn.com wrote:
On 12/6/10 11:53 AM, cool-RR wrote:
Hello,
I gave my program a “Focus on window” menu item which puts the
keyboard focus on the
Frameso keyboard shortcuts will work.However, that doesn’t work on Mac. It seems like Mac can’t focus on a
Frame. Is this right?
Yes.
What can I focus on when using Mac OS so that keyboard shortcuts
will work?
If you have a panel in the frame then put the focus there. If that panel has children then the focus will move automatically to a child widget that can accept the focus. As long as the focus is somewhere within the frame then any accelerators associated with it (from the menubar or explicitly from an accelerator table) will be active.
Robin Dunn
Ok, then I suppose setting the focus to some custom control and binding the key events there would do it. You can make the control tiny (1x1) so it doesn't mess with your UI. Or some other widget you already have within the frame.
On 12/6/10 1:18 PM, cool-RR wrote:
On Mon, Dec 6, 2010 at 11:13 PM, Robin Dunn <robin@alldunn.com > <mailto:robin@alldunn.com>> wrote:
On 12/6/10 11:53 AM, cool-RR wrote:
Hello,
I gave my program a "Focus on window" menu item which puts the
keyboard focus on the `Frame` so keyboard shortcuts will work.
However, that doesn't work on Mac. It seems like Mac can't focus
on a
Frame. Is this right?Yes.
What *can* I focus on when using Mac OS so that keyboard shortcuts
will work?If you have a panel in the frame then put the focus there. If that
panel has children then the focus will move automatically to a child
widget that can accept the focus. As long as the focus is somewhere
within the frame then any accelerators associated with it (from the
menubar or explicitly from an accelerator table) will be active.
Robin DunnMy shortcuts aren't implemented with accelerators; I'm using EVT_KEY_DOWN.
--
Robin Dunn
Software Craftsman
If a control is just a small wx.window and a frame is just a wx.window what on the Mac prevents a frame from getting the focus if a control can? Is this a native widget thing?
Yes. IIUC there is a bigger difference between Windows (what we use for top-level windows like wxFrame) and Controls (what we use for pretty much everything else, native or generic) than there is on the other platforms. There are even different data types in the Carbon API for them, WindowRef and ControlRef.
On 12/6/10 1:26 PM, Dev Player wrote:
If a control is just a small wx.window and a frame is just a wx.window
what on the Mac prevents a frame from getting the focus if a control
can? Is this a native widget thing?
--
Robin Dunn
Software Craftsman
Wow. So making a cross platform UI with consistant use and feel as wxPython attempts to do is really challeging on this little OS differect alone.
For a MS windows UI you take a “window” and subclass it to make controls. But if you want the Mac to have a consistant user interface/usage pattern as MS you’d have to take a control and make it look like a frame. I’m thinking of menus too. And im sure there’s more.
So the most logical solution would be not to do this but to expect your “constant” use and feel to be inherintly different on different OSes. And as Mac users, I’m sure they are not interested on average to have the same use and feel as MS. (I don’t have a problem with this). Of course this makes crossplatform become harder and harder over time.
So then the question for me becomes, as MS changes it’s controls, how will Mac diverge from MS. Will the Mac develop ribbons? Will the Mac make heavier or less use of tool/menu strips?
Any crossplatform developement framework like wxPython that can juggle these differences is probably what make them so valuable.
Yeah. If you want your app to look and behave the same on all
operating systems, then you'll need to use generic widgets or a
toolkit that draws all its own widgets, like PyQT. If you want your
app to look and feel right on each OS, then wxPython rocks!
On Dec 6, 4:08 pm, Dev Player <devpla...@gmail.com> wrote:
Wow. So making a cross platform UI with consistant use and feel as wxPython
attempts to do is really challeging on this little OS differect alone.For a MS windows UI you take a "window" and subclass it to make controls.
But if you want the Mac to have a consistant user interface/usage pattern as
MS you'd have to take a control and make it look like a frame. I'm thinking
of menus too. And im sure there's more.So the most logical solution would be not to do this but to expect your
"constant" use and feel to be inherintly different on different OSes. And as
Mac users, I'm sure they are not interested on average to have the same use
and feel as MS. (I don't have a problem with this). Of course this makes
crossplatform become harder and harder over time.So then the question for me becomes, as MS changes it's controls, how will
Mac diverge from MS. Will the Mac develop ribbons? Will the Mac make heavier
or less use of tool/menu strips?Any crossplatform developement framework like wxPython that can juggle these
differences is probably what make them so valuable.
-------------------
Mike Driscoll
Wow. So making a cross platform UI with consistant use and feel as
wxPython attempts to do is really challeging on this little OS differect
alone.
For a MS windows UI you take a "window" and subclass it to
make controls. But if you want the Mac to have a consistant user
interface/usage pattern as MS you'd have to take a control and make it
look like a frame. I'm thinking of menus too. And im sure there's more.
Huh?
So the most logical solution would be not to do this but to expect your
"constant" use and feel to be inherintly different on different OSes.
And as Mac users, I'm sure they are not interested on average to have
the same use and feel as MS. (I don't have a problem with this).
Yes, many Mac users care very much about consistency and standards compliance in the applications UI. Generic or custom widgets are probably okay for most people as long as the look like they integrate well and follow similar patterns as the native widgets and applications, so they look like they belong there.
Of
course this makes crossplatform become harder and harder over time.
So then the question for me becomes, as MS changes it's controls, how
will Mac diverge from MS. Will the Mac develop ribbons? Will the Mac
make heavier or less use of tool/menu strips?
I doubt Apple will ever have anything that is as crowded and cluttered as the ribbon as a stock widget type, they seem to be trending to more minimalistic UIs with lots of space between items and larger icons. OTOH, MSOffice:Mac 2011 has a ribbon-like widget in the UI and I think they did a fairly good job of making it look like it belongs in a Mac UI.
If somebody could tweak wx.lib.agw.ribbon to look like the MSOffice:Mac 2011 ribbon by default I would be happy.
Any crossplatform developement framework like wxPython that can juggle
these differences is probably what make them so valuable.
wxMac does some things to help you follow platform standards. It could probably do more.
On 12/6/10 2:08 PM, Dev Player wrote:
--
Robin Dunn
Software Craftsman
Hi Robin,
Wow. So making a cross platform UI with consistant use and feel as
wxPython attempts to do is really challeging on this little OS differect
alone.
For a MS windows UI you take a "window" and subclass it to
make controls. But if you want the Mac to have a consistant user
interface/usage pattern as MS you'd have to take a control and make it
look like a frame. I'm thinking of menus too. And im sure there's more.Huh?
So the most logical solution would be not to do this but to expect your
"constant" use and feel to be inherintly different on different OSes.
And as Mac users, I'm sure they are not interested on average to have
the same use and feel as MS. (I don't have a problem with this).Yes, many Mac users care very much about consistency and standards
compliance in the applications UI. Generic or custom widgets are probably
okay for most people as long as the look like they integrate well and follow
similar patterns as the native widgets and applications, so they look like
they belong there.Of
course this makes crossplatform become harder and harder over time.
So then the question for me becomes, as MS changes it's controls, how
will Mac diverge from MS. Will the Mac develop ribbons? Will the Mac
make heavier or less use of tool/menu strips?I doubt Apple will ever have anything that is as crowded and cluttered as
the ribbon as a stock widget type, they seem to be trending to more
minimalistic UIs with lots of space between items and larger icons. OTOH,
MSOffice:Mac 2011 has a ribbon-like widget in the UI and I think they did a
fairly good job of making it look like it belongs in a Mac UI.If somebody could tweak wx.lib.agw.ribbon to look like the MSOffice:Mac 2011
ribbon by default I would be happy.
Do you have a screenshot of it (the ribbon part I mean)? In which
way(s) it is different from the Windows RibbonBar?
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
==> Never *EVER* use RemovalGroup for your house removal. You'll
regret it forever.
The Doomed City: Removal Group: the nightmare <==
On 7 December 2010 09:22, Robin Dunn wrote:
On 12/6/10 2:08 PM, Dev Player wrote:
Mainly just the colors and gradients. Also the tabs are shaped a little differently, and the font for the labels is a bit larger.
There are a bunch of screenshots here, but they have been reduced in size: BGR - Tech & Entertainment News, Reviews, & Deals
I've put a few full size images at http://www.dropbox.com/gallery/727255/1/MSOfficeMac2011?h=ab9601
The asterix icon on the right pops up a menu for going to ribbon preferences, etc. The chevron icon next to it causes the ribbon to roll up (animated) such that only the tabs are showing. The chevron then flips over to point down. You can also do the roll-up by clicking on the already selected tab, and roll down by selecting any tab. Tabs can have sub-tabs that are inserted (again with some simple animation) when needed, such as when the caret is inside a table then the Table Layout tab is inserted as shown in the screen shots.
I haven't used an MS Office for Windows since before the ribbon UI was introduced, so I don't know how much of this behavior is the same as on Windows or if any of it is Mac-specific.
On 12/7/10 2:00 AM, Andrea Gavana wrote:
Hi Robin,
On 7 December 2010 09:22, Robin Dunn wrote:
I doubt Apple will ever have anything that is as crowded and cluttered as
the ribbon as a stock widget type, they seem to be trending to more
minimalistic UIs with lots of space between items and larger icons. OTOH,
MSOffice:Mac 2011 has a ribbon-like widget in the UI and I think they did a
fairly good job of making it look like it belongs in a Mac UI.If somebody could tweak wx.lib.agw.ribbon to look like the MSOffice:Mac 2011
ribbon by default I would be happy.Do you have a screenshot of it (the ribbon part I mean)? In which
way(s) it is different from the Windows RibbonBar?
--
Robin Dunn
Software Craftsman