one problem is that SystemWindow/isSystemWindow is hardcoded on so many places...
Yes it looks nice.
��I think that keymapping should not be a tool but the default way to change and control shortcuts.
Tools
============================
The current image generated by this configuraton will crash as soon as you try to press some keyboard button. The reason is in the method Morph>>#handleKeystroke. This method contains this code to support Keymapping
Smalltalk tools shortcuts handleKeystroke: anEvent inMorph: self.
Do you have a take on this?
+1. Although it can still be improved, keymapping is better than any other option we have and we should promote it as the default mechanism.��Cheers,Doru
I checked the package dependensies of Keymappings and Keymapping-Core, Keymapping-KeyCombinations and Keymapping-Pragmas. The only ugly dependency is on MenuRegistration (that is dependent on several other packages).��Becuase this is only one place where the Keymappings are used in Morphic-Core, I whould prefer to add a class variable named ShortcutsHandler to Morph and register Keymappings here (or let it be nil for Morphic-Core)
-- Pavel��
The #tools message is part of Tool-Base package and need to be there because it uses lazy evaluation that creates a ToolRegistry instance. Because Tool-Base is not loaded in the minimal nor Morphic-Core image, it raises DNU
Solutions:
- introduce some safer form like Smalltalk withToolsDo: [:tools | ...]. In this case it will not be able to look if the class variable "Tools" is nil (because of lazy evaluation) but it will need to do some ugly check of presence of ToolRegistry class or something similar. In this case we will produce more unimplemented calls (on several places in the image because withToolsDo: may be handy in other cases too)
- something different :)
Cheers,
-- Pavel