Hi, in latest update we integrated several patches needed for proper working of ConfiguratonOfMorphicCore. This simple configuration loads Morphic-Core package into the minimal image and initializes it so the result is a small standalone Morphic subset. But some issues that I would like to discuss with the community left: SystemWindows support ============================ SystemWindow is quite complex morph that requires many of other morph classes including text morphs, theming support etc. But in several situations the system windows play special role and the Morphic core classes need to be aware of them. So we have several options: - (current) do not have SystemWindow & co. in the image but let basic support of them. That will produce some unimplemented calls - create very simple SystemWindow superclass that will be part of the Morphic-Core but will not have look and possibilities of real SystemWindow - include SystemWindow and supporting classes 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. 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
On 24/7/14 13:37, Pavel Krivanek wrote:
Hi,
in latest update we integrated several patches needed for proper working of ConfiguratonOfMorphicCore. This simple configuration loads Morphic-Core package into the minimal image and initializes it so the result is a small standalone Morphic subset.
But some issues that I would like to discuss with the community left:
SystemWindows support ============================ SystemWindow is quite complex morph that requires many of other morph classes including text morphs, theming support etc. But in several situations the system windows play special role and the Morphic core classes need to be aware of them. So we have several options:
- (current) do not have SystemWindow & co. in the image but let basic support of them. That will produce some unimplemented calls
- create very simple SystemWindow superclass that will be part of the Morphic-Core but will not have look and possibilities of real SystemWindow
- include SystemWindow and supporting classes I had the same questions than you: - I have the impression that systemWindow is really linked to widgets.
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.
I think that keymapping should not be a tool but the default way to change and control shortcuts. Do you have a take on this?
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
2014-07-24 13:47 GMT+02:00 stepharo <stepharo@free.fr>:
On 24/7/14 13:37, Pavel Krivanek wrote:
Hi,
in latest update we integrated several patches needed for proper working of ConfiguratonOfMorphicCore. This simple configuration loads Morphic-Core package into the minimal image and initializes it so the result is a small standalone Morphic subset.
But some issues that I would like to discuss with the community left:
SystemWindows support ============================ SystemWindow is quite complex morph that requires many of other morph classes including text morphs, theming support etc. But in several situations the system windows play special role and the Morphic core classes need to be aware of them. So we have several options:
- (current) do not have SystemWindow & co. in the image but let basic support of them. That will produce some unimplemented calls
- create very simple SystemWindow superclass that will be part of the Morphic-Core but will not have look and possibilities of real SystemWindow
I would take this one. Having a minimal Morphic is to be able to do GUI stuff, and this requires some form of SystemWindow. Maybe a fullscreen SystemWindow / world abstraction then? If I only load Morphic-Core, then I can use it for full-screen demos.
- include SystemWindow and supporting classes
I had the same questions than you: - I have the impression that systemWindow is really linked to widgets.
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.
I think that keymapping should not be a tool but the default way to change and control shortcuts. Do you have a take on this?
Looks like an integration fault to me (hidden dependency on KeyMapping). handleKeystroke: was a Keymapping-Core-override in 2.0. In 3.0 and 4.0, it's a core method of Morph... If you go back to 2.0, no more problem :) Thierry
Hi, On Thu, Jul 24, 2014 at 1:47 PM, stepharo <stepharo@free.fr> wrote:
On 24/7/14 13:37, Pavel Krivanek wrote:
Hi,
SystemWindows support ============================ SystemWindow is quite complex morph that requires many of other morph classes including text morphs, theming support etc. But in several situations the system windows play special role and the Morphic core classes need to be aware of them. So we have several options:
- (current) do not have SystemWindow & co. in the image but let basic support of them. That will produce some unimplemented calls
- create very simple SystemWindow superclass that will be part of the Morphic-Core but will not have look and possibilities of real SystemWindow
- include SystemWindow and supporting classes
I had the same questions than you: - I have the impression that systemWindow is really linked to widgets.
I think we should go with option 2 and have a way of providing basic windows. SystemWindow is too much anyway.
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.
I think that keymapping should not be a tool but the default way to change and control shortcuts. 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 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
-- www.tudorgirba.com "Every thing has its own flow"
2014-07-24 15:01 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Thu, Jul 24, 2014 at 1:47 PM, stepharo <stepharo@free.fr> wrote:
On 24/7/14 13:37, Pavel Krivanek wrote:
Hi,
SystemWindows support ============================ SystemWindow is quite complex morph that requires many of other morph classes including text morphs, theming support etc. But in several situations the system windows play special role and the Morphic core classes need to be aware of them. So we have several options:
- (current) do not have SystemWindow & co. in the image but let basic support of them. That will produce some unimplemented calls
- create very simple SystemWindow superclass that will be part of the Morphic-Core but will not have look and possibilities of real SystemWindow
- include SystemWindow and supporting classes
I had the same questions than you: - I have the impression that systemWindow is really linked to widgets.
I think we should go with option 2 and have a way of providing basic windows. SystemWindow is too much anyway.
one problem is that SystemWindow/isSystemWindow is hardcoded on so many places...
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.
I think that keymapping should not be a tool but the default way to change and control shortcuts. 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
-- www.tudorgirba.com
"Every thing has its own flow"
2014-07-24 15:42 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
2014-07-24 15:01 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Thu, Jul 24, 2014 at 1:47 PM, stepharo <stepharo@free.fr> wrote:
On 24/7/14 13:37, Pavel Krivanek wrote:
Hi,
SystemWindows support ============================ SystemWindow is quite complex morph that requires many of other morph classes including text morphs, theming support etc. But in several situations the system windows play special role and the Morphic core classes need to be aware of them. So we have several options:
- (current) do not have SystemWindow & co. in the image but let basic support of them. That will produce some unimplemented calls
- create very simple SystemWindow superclass that will be part of the Morphic-Core but will not have look and possibilities of real SystemWindow
- include SystemWindow and supporting classes
I had the same questions than you: - I have the impression that systemWindow is really linked to widgets.
I think we should go with option 2 and have a way of providing basic windows. SystemWindow is too much anyway.
one problem is that SystemWindow/isSystemWindow is hardcoded on so many places...
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.
I think that keymapping should not be a tool but the default way to change and control shortcuts. 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)
https://pharo.fogbugz.com/f/cases/13681/replace-Smalltalk-tools-shortcuts-wi...
-- 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
-- www.tudorgirba.com
"Every thing has its own flow"
one problem is that SystemWindow/isSystemWindow is hardcoded on so many places...
yes but let us make a list to evaluate it. Because Smalltalk was hardcoded and PackageInfo and Preferences and we killed them all :). Stef
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.
I think that keymapping should not be a tool but the default way to change and control shortcuts. 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)
Yes it looks nice. but For morphic-core you do not want to have shortcut.
-- 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
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
Really great! Doru On Thu, Jul 24, 2014 at 1:37 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi,
in latest update we integrated several patches needed for proper working of ConfiguratonOfMorphicCore. This simple configuration loads Morphic-Core package into the minimal image and initializes it so the result is a small standalone Morphic subset.
But some issues that I would like to discuss with the community left:
SystemWindows support ============================ SystemWindow is quite complex morph that requires many of other morph classes including text morphs, theming support etc. But in several situations the system windows play special role and the Morphic core classes need to be aware of them. So we have several options:
- (current) do not have SystemWindow & co. in the image but let basic support of them. That will produce some unimplemented calls
- create very simple SystemWindow superclass that will be part of the Morphic-Core but will not have look and possibilities of real SystemWindow
- include SystemWindow and supporting classes
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.
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
-- www.tudorgirba.com "Every thing has its own flow"
participants (4)
-
Pavel Krivanek -
stepharo -
Thierry Goubier -
Tudor Girba