GLMAction and PharoShortcut
Hi, While writing these tooltips for the debugger, it seems to me some refactoring is needed in the use of Pharo shortcut: https://pharo.fogbugz.com/f/cases/19684/GLMAction-and-PharoShortcut-need-ref... because the current situation to have Glamour tk rendering short cut as 'Ctrl-A' then Spec as 'Meta-A' Any opinion on the topic. Hilaire -- Dr. Geo http://drgeo.eu
On Sun, Feb 12, 2017 at 6:32 PM, Hilaire <hilaire@drgeo.eu> wrote:
Hi,
While writing these tooltips for the debugger, it seems to me some refactoring is needed in the use of Pharo shortcut: https://pharo.fogbugz.com/f/cases/19684/GLMAction-and- PharoShortcut-need-refactoring
because the current situation to have Glamour tk rendering short cut as 'Ctrl-A' then Spec as 'Meta-A'
Any opinion on the topic.
Well spotted. They should be consistent. I guess the next questions are; * Does Glamour convert cross platform Meta-x definitions to platform specific in its rendering? Or are the Ctrl-xx hard coded? * If the former, can Spec be made to do the same conversion for its rendering? * Or do we prefer to refer to the general Meta-x throughout the UI? cheers -ben
Le 12/02/2017 à 11:53, Ben Coman a écrit :
Well spotted. They should be consistent. I guess the next questions are; * Does Glamour convert cross platform Meta-x definitions to platform specific in its rendering? Or are the Ctrl-xx hard coded?
GLMAction comes with a method to render a print representation of shor tcut, but it is not its responsibility to do so. It is the short cut responsibility, so other widget can also use the same and consistent print representation. The responsability should go to instance of KMModifiedKeyCombination, not sure about that though. The way the modifier is selected in the GLamour looks strange, why not using the modifier instance?
* If the former, can Spec be made to do the same conversion for its rendering? * Or do we prefer to refer to the general Meta-x throughout the UI?
The way short cuts are rendered in menu or tool tip is not consistent. In Nautilus you have for example: 'Ctrl + A', in debugger it is rendered 'ctrl+a' for Ctrl-a or 'ctrl+shift+a' for Ctrl-A. In playground you can see both depending on you are viewing a menu or a button tool tip. Now I see another place where short cut gets a print representation: MorphicMenuItemAdapter>>shortcutText -- Dr. Geo http://drgeo.eu
For the record we were discussing with denis to have a hierarchy of command each one encapsulating its shortcut and other. Now it should work for calypso and we will remove Nautilus in 70. But the problem is all the places where shortcuts are hardcoded and we will have to work on them. Now I'm not saying that we should not do anything now to fix the current problem. I just mention our current thoughts. Stef
Le 12/02/2017 à 11:53, Ben Coman a écrit :
Well spotted. They should be consistent. I guess the next questions are; * Does Glamour convert cross platform Meta-x definitions to platform specific in its rendering? Or are the Ctrl-xx hard coded?
GLMAction comes with a method to render a print representation of shor tcut, but it is not its responsibility to do so. It is the short cut responsibility, so other widget can also use the same and consistent print representation.
The responsability should go to instance of KMModifiedKeyCombination, not sure about that though.
The way the modifier is selected in the GLamour looks strange, why not using the modifier instance?
* If the former, can Spec be made to do the same conversion for its rendering? * Or do we prefer to refer to the general Meta-x throughout the UI?
The way short cuts are rendered in menu or tool tip is not consistent. In Nautilus you have for example: 'Ctrl + A', in debugger it is rendered 'ctrl+a' for Ctrl-a or 'ctrl+shift+a' for Ctrl-A. In playground you can see both depending on you are viewing a menu or a button tool tip.
Now I see another place where short cut gets a print representation: MorphicMenuItemAdapter>>shortcutText
-- Using Opera's mail client: http://www.opera.com/mail/
Ok got it. It will be great to clarify the keymap implementation and use, both for QA reasons and developers. What is the status of the KM hierarchy? Hilaire Le 12/02/2017 à 18:51, stepharong a écrit :
For the record we were discussing with denis to have a hierarchy of command each one encapsulating its shortcut and other. Now it should work for calypso and we will remove Nautilus in 70. But the problem is all the places where shortcuts are hardcoded and we will have to work on them.
Now I'm not saying that we should not do anything now to fix the current problem. I just mention our current thoughts.
-- Dr. Geo http://drgeo.eu
On Mon, 13 Feb 2017 09:41:26 +0100, Hilaire <hilaire@drgeo.eu> wrote:
Ok got it. It will be great to clarify the keymap implementation and use, both for QA reasons and developers.
What is the status of the KM hierarchy?
we should continue to use and expand it.
Hilaire
Le 12/02/2017 à 18:51, stepharong a écrit :
For the record we were discussing with denis to have a hierarchy of command each one encapsulating its shortcut and other. Now it should work for calypso and we will remove Nautilus in 70. But the problem is all the places where shortcuts are hardcoded and we will have to work on them.
Now I'm not saying that we should not do anything now to fix the current problem. I just mention our current thoughts.
-- Using Opera's mail client: http://www.opera.com/mail/
Hi, Good catch. Indeed GLMAction>>#shortcutAsString should go to the keymap object. Apart from the inconsistencies that you mention, there is in my view another one. For example, in the debugger in the context menu of the stack modifiers are displayed using special characters (at least on mac). In tooltips they are display using Shift, Meta, Ctrl, etc. Right now the logic for printing shortcuts that way is in ToggleMenuItemShortcut>>#owner:keyText: and it's a bit complicated to reuse. See GTSpotterCategoryTitleBrick>>#setShortcutBrickTextFor: for an example. Cheers, Andrei On Sun, Feb 12, 2017 at 11:32 AM, Hilaire <hilaire@drgeo.eu> wrote:
Hi,
While writing these tooltips for the debugger, it seems to me some refactoring is needed in the use of Pharo shortcut: https://pharo.fogbugz.com/f/cases/19684/GLMAction-and-PharoShortcut-need-ref...
because the current situation to have Glamour tk rendering short cut as 'Ctrl-A' then Spec as 'Meta-A'
Any opinion on the topic.
Hilaire
-- Dr. Geo http://drgeo.eu
Thanks for the update. Based on previous Steph post, should we move this bug ticket to Pharo7 or keep it for Pharo6? Hilaire Le 13/02/2017 à 18:46, Andrei Chis a écrit :
Hi,
Good catch. Indeed GLMAction>>#shortcutAsString should go to the keymap object.
Apart from the inconsistencies that you mention, there is in my view another one. For example, in the debugger in the context menu of the stack modifiers are displayed using special characters (at least on mac). In tooltips they are display using Shift, Meta, Ctrl, etc. Right now the logic for printing shortcuts that way is in ToggleMenuItemShortcut>>#owner:keyText: and it's a bit complicated to reuse. See GTSpotterCategoryTitleBrick>>#setShortcutBrickTextFor: for an example.
Cheers, Andrei
-- Dr. Geo http://drgeo.eu
It would be better for pharo 7 On Tue, Feb 14, 2017 at 10:13 AM, Hilaire <hilaire@drgeo.eu> wrote:
Thanks for the update. Based on previous Steph post, should we move this bug ticket to Pharo7 or keep it for Pharo6?
Hilaire
Le 13/02/2017 à 18:46, Andrei Chis a écrit :
Hi,
Good catch. Indeed GLMAction>>#shortcutAsString should go to the keymap object.
Apart from the inconsistencies that you mention, there is in my view another one. For example, in the debugger in the context menu of the stack modifiers are displayed using special characters (at least on mac). In tooltips they are display using Shift, Meta, Ctrl, etc. Right now the logic for printing shortcuts that way is in ToggleMenuItemShortcut>>#owner:keyText: and it's a bit complicated to reuse. See GTSpotterCategoryTitleBrick>>#setShortcutBrickTextFor: for an example.
Cheers, Andrei
-- Dr. Geo http://drgeo.eu
participants (5)
-
Andrei Chis -
Ben Coman -
Hilaire -
Stephane Ducasse -
stepharong