Hi guys
Since this is interesting for all of us I prefer to publicly discuss it. From: Fernando Olivero <[hidden email]> > Date: March 31, 2011 8:40:26 AM GMT+02:00 > To: [hidden email], Stéphane Ducasse <[hidden email]> > Subject: Regarding SimpleMorphic > Reply-To: [hidden email] > > Hi, i've been working on the necessary steps to ease the adoption of > SimpleMorphic. Excellent! > I found it really nice, and would like to code the new > version of Gaucho on top of it. I post here the conclusions roadmap, > maybe you are starting the same effort, so this is just to collect > feedback or let you know! We want to join forces. I would love to have key widgets: list, tree ported and totally revised so that we do not have 20 of them but just two or four. > I always start from the Morphic in CUIS 3.1, and then go one by one > trying to port the relevant classes, honoring the intent behind Pharo > UI by, for example, adding in the UIManager uses whenever posible, > > Saludos, > Fernando Question: should we look in Cuis3.1 or Pharo1.3 SMx > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > CUIS > System > 1) Review Editor and friends: Separate hierarchy or try to merge with > the existing one in Pharo? Alain's great work on EditorState is > missing in CUIS. Yes I love the selection and highlights of Alain. > 2) import TextModel and hierarchy or maintain a separate hierarchy? > The changes in text model and subclasses seem to be good to have! > 3) (CUIS )DifferenceFinder vs (Pharo)TextDiffBuilder ? ( Seems that > DifferenceFinder has extra funcionality) No idea there. > 4) Transcript and TranscriptMorph. DONE ISSUE 3736 soon in Pharo1.3 > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > CUIS3.1 into Pharo1.3 SimpleMorphic So what is the difference with the one we have. > 1) Make current implementation of SMx load in Pharo1.3. > DONE ISSUE 3878: Implementing enableTextChange > DONE ISSUE 3584: Cleanup removing DisplayText =>to remove > UIManager>>composeForm: > DONE ISSUE 3915: DiffMorph requests thru UIManager: so we don't have > to change senders such as ChangeList and VersionBrowser. Good. > 2) World, ActiveHand, ActiveEvent and ActiveWorld cleanup in Morphic. > To merge Morphic and SimpleMorphic handling of the global state, > centralizing the accessors in UIManager, by removing Globals. ALMOSTE > DONE ISSUE 3903 > 3) general up to date from CUIS 3.1: ALMOST DONE > 4) tools?: Revise the SMxBrowser and family, replace maybe with the > new TextModel>>openAsMorph: , etc… For the Browser we plan - to simply **Throw** away all the stringHolder and codeHolder classes and subclasses. Benjamin can show you Nautilus beta. - We will remove also ToolBuilder (as soon as we have a new version of the test runner) - We need a model for the debugger (we should check glamour people for that). So we will temporary keep stringHolde but compact it only for the debugger. > 5) Remove SMxTheWorldMenu and replace with MenuPragmaBuilder as in Pharo. Yes > 6) ? > > ++++++++++++++++++++++ > LOAD ORDER (uncomplete) > 3878 > 3584 > 3915 > 3736 > (PENDING) 3903 > ... |
OK! Thanks for the feedback.
In CUIS 3.1, Juan simplified many things. For example there's only one button class, which suffices for all the different needs of todays buttons. Then the layout part was simplified. Also themes were introduced, and above all: AMAZING rounded corners appearance! (Look at the attached figure) Anwsers: 1) Editors and EditorState: Ok, i will coordinate with Alain for this. 2) 4) Regarding TextModel and subclasses such as CodeProvider and Browser in CUIS: so it means that hierarchy wouldn't be needed at all in Pharo. At least Nautilus must have a model for the text ? In CUIS the root class is called TextModel , in Pharo 1.3 is called StringHolder. I propose moving this discussion on another thread. Maybe Benjamin could clarify this? So then i believe that for the SimpleMorphic part, it would just a matter of porting Nautilus to SimpleMorphic, to be have "System browsers". As we spoke with Alain, we will first make SimpleMorphic run side by side with Morphic on Pharo1.3. Then start to enhance SM, to the point of not needing Morphic anymore! For example: porting Polymorph (Merging UITheme and SMxTheme, for example). Please look at Juan's email about simple morphic, i believe the simplicity of this Morphic system deserves this effort. Fernando On Thu, Mar 31, 2011 at 9:21 AM, Stéphane Ducasse <[hidden email]> wrote: > Hi guys > > Since this is interesting for all of us I prefer to publicly discuss it. > > From: Fernando Olivero <[hidden email]> >> Date: March 31, 2011 8:40:26 AM GMT+02:00 >> To: [hidden email], Stéphane Ducasse <[hidden email]> >> Subject: Regarding SimpleMorphic >> Reply-To: [hidden email] >> >> Hi, i've been working on the necessary steps to ease the adoption of >> SimpleMorphic. > > Excellent! > >> I found it really nice, and would like to code the new >> version of Gaucho on top of it. I post here the conclusions roadmap, >> maybe you are starting the same effort, so this is just to collect >> feedback or let you know! > > We want to join forces. > I would love to have key widgets: list, tree ported and totally revised so that we > do not have 20 of them but just two or four. > >> I always start from the Morphic in CUIS 3.1, and then go one by one >> trying to port the relevant classes, honoring the intent behind Pharo >> UI by, for example, adding in the UIManager uses whenever posible, >> >> Saludos, >> Fernando > > Question: should we look in Cuis3.1 or Pharo1.3 SMx > >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> CUIS >> System >> 1) Review Editor and friends: Separate hierarchy or try to merge with >> the existing one in Pharo? Alain's great work on EditorState is >> missing in CUIS. > > Yes I love the selection and highlights of Alain. > >> 2) import TextModel and hierarchy or maintain a separate hierarchy? >> The changes in text model and subclasses seem to be good to have! > > >> 3) (CUIS )DifferenceFinder vs (Pharo)TextDiffBuilder ? ( Seems that >> DifferenceFinder has extra funcionality) > > No idea there. > >> 4) Transcript and TranscriptMorph. DONE ISSUE 3736 > > soon in Pharo1.3 >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> CUIS3.1 into Pharo1.3 SimpleMorphic > > So what is the difference with the one we have. > >> 1) Make current implementation of SMx load in Pharo1.3. >> DONE ISSUE 3878: Implementing enableTextChange >> DONE ISSUE 3584: Cleanup removing DisplayText =>to remove >> UIManager>>composeForm: >> DONE ISSUE 3915: DiffMorph requests thru UIManager: so we don't have >> to change senders such as ChangeList and VersionBrowser. > > Good. > >> 2) World, ActiveHand, ActiveEvent and ActiveWorld cleanup in Morphic. >> To merge Morphic and SimpleMorphic handling of the global state, >> centralizing the accessors in UIManager, by removing Globals. ALMOSTE >> DONE ISSUE 3903 >> 3) general up to date from CUIS 3.1: ALMOST DONE >> 4) tools?: Revise the SMxBrowser and family, replace maybe with the >> new TextModel>>openAsMorph: , etc… > > For the Browser we plan > - to simply **Throw** away all the stringHolder and codeHolder classes and subclasses. > Benjamin can show you Nautilus beta. > - We will remove also ToolBuilder (as soon as we have a new version of the test runner) > - We need a model for the debugger (we should check glamour people for that). > So we will temporary keep stringHolde but compact it only for the debugger. > > >> 5) Remove SMxTheWorldMenu and replace with MenuPragmaBuilder as in Pharo. > > Yes > >> 6) ? >> >> ++++++++++++++++++++++ >> LOAD ORDER (uncomplete) >> 3878 >> 3584 >> 3915 >> 3736 >> (PENDING) 3903 >> ... > > > SqueakScreen.1.png (385K) Download Attachment |
> OK! Thanks for the feedback.
> > In CUIS 3.1, Juan simplified many things. For example there's only one > button class, which suffices for all the different needs of todays > buttons. :) > Then the layout part was simplified. I thought is was already in PharoSimpleMorphic > Anwsers: > > 1) Editors and EditorState: Ok, i will coordinate with Alain for this. excellent > 2) 4) Regarding TextModel and subclasses such as CodeProvider and > Browser in CUIS: so it means that hierarchy wouldn't be needed at all > in Pharo. At least Nautilus must have a model for the text ? In CUIS > the root class is called TextModel , in Pharo 1.3 is called > StringHolder. I propose moving this discussion on another thread. > Maybe Benjamin could clarify this? benjamin will let us know. > So then i believe that for the SimpleMorphic part, it would just a > matter of porting Nautilus to SimpleMorphic, to be have "System > browsers". yes. So it requires TreeMorphTreeMorph So what we would be good is to have a nice ListMorph (with icons, with multiple selection) TreeMorph ... So that we can rebuild everything on that. > As we spoke with Alain, we will first make SimpleMorphic run side by > side with Morphic on Pharo1.3. Good. > Then start to enhance SM, to the point of not needing Morphic anymore! For example: porting Polymorph > (Merging UITheme and SMxTheme, for example). Good. > Please look at Juan's email about simple morphic, i believe the > simplicity of this Morphic system deserves this effort. Don;t get me wrong. I'm convinced about that but I do not have the expertise to do it. > > Fernando > > > On Thu, Mar 31, 2011 at 9:21 AM, Stéphane Ducasse > <[hidden email]> wrote: >> Hi guys >> >> Since this is interesting for all of us I prefer to publicly discuss it. >> >> From: Fernando Olivero <[hidden email]> >>> Date: March 31, 2011 8:40:26 AM GMT+02:00 >>> To: [hidden email], Stéphane Ducasse <[hidden email]> >>> Subject: Regarding SimpleMorphic >>> Reply-To: [hidden email] >>> >>> Hi, i've been working on the necessary steps to ease the adoption of >>> SimpleMorphic. >> >> Excellent! >> >>> I found it really nice, and would like to code the new >>> version of Gaucho on top of it. I post here the conclusions roadmap, >>> maybe you are starting the same effort, so this is just to collect >>> feedback or let you know! >> >> We want to join forces. >> I would love to have key widgets: list, tree ported and totally revised so that we >> do not have 20 of them but just two or four. >> >>> I always start from the Morphic in CUIS 3.1, and then go one by one >>> trying to port the relevant classes, honoring the intent behind Pharo >>> UI by, for example, adding in the UIManager uses whenever posible, >>> >>> Saludos, >>> Fernando >> >> Question: should we look in Cuis3.1 or Pharo1.3 SMx >> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> CUIS >>> System >>> 1) Review Editor and friends: Separate hierarchy or try to merge with >>> the existing one in Pharo? Alain's great work on EditorState is >>> missing in CUIS. >> >> Yes I love the selection and highlights of Alain. >> >>> 2) import TextModel and hierarchy or maintain a separate hierarchy? >>> The changes in text model and subclasses seem to be good to have! >> >> >>> 3) (CUIS )DifferenceFinder vs (Pharo)TextDiffBuilder ? ( Seems that >>> DifferenceFinder has extra funcionality) >> >> No idea there. >> >>> 4) Transcript and TranscriptMorph. DONE ISSUE 3736 >> >> soon in Pharo1.3 >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> CUIS3.1 into Pharo1.3 SimpleMorphic >> >> So what is the difference with the one we have. >> >>> 1) Make current implementation of SMx load in Pharo1.3. >>> DONE ISSUE 3878: Implementing enableTextChange >>> DONE ISSUE 3584: Cleanup removing DisplayText =>to remove >>> UIManager>>composeForm: >>> DONE ISSUE 3915: DiffMorph requests thru UIManager: so we don't have >>> to change senders such as ChangeList and VersionBrowser. >> >> Good. >> >>> 2) World, ActiveHand, ActiveEvent and ActiveWorld cleanup in Morphic. >>> To merge Morphic and SimpleMorphic handling of the global state, >>> centralizing the accessors in UIManager, by removing Globals. ALMOSTE >>> DONE ISSUE 3903 >>> 3) general up to date from CUIS 3.1: ALMOST DONE >>> 4) tools?: Revise the SMxBrowser and family, replace maybe with the >>> new TextModel>>openAsMorph: , etc… >> >> For the Browser we plan >> - to simply **Throw** away all the stringHolder and codeHolder classes and subclasses. >> Benjamin can show you Nautilus beta. >> - We will remove also ToolBuilder (as soon as we have a new version of the test runner) >> - We need a model for the debugger (we should check glamour people for that). >> So we will temporary keep stringHolde but compact it only for the debugger. >> >> >>> 5) Remove SMxTheWorldMenu and replace with MenuPragmaBuilder as in Pharo. >> >> Yes >> >>> 6) ? >>> >>> ++++++++++++++++++++++ >>> LOAD ORDER (uncomplete) >>> 3878 >>> 3584 >>> 3915 >>> 3736 >>> (PENDING) 3903 >>> ... >> >> >> > <SqueakScreen.1.png> |
Thanks for the answers Stef!
Comments: The layout was improved in the first version of SMx, but completely rethought for CUIS3.1, after Juan published SMx for pharo. See in CUIS 3.1, the LayoutMorph and examples. The last remark was actually for the rest of the community, in case they didn't understand why was it worth it to migrate to SimpleMorphic! I know from previous emails that the adoption of simplicity and a clean Morphic was on your mind. I'm looking forward for completing this project , once i finish writing for my thesis. Fernando On Thu, Mar 31, 2011 at 10:50 AM, Stéphane Ducasse <[hidden email]> wrote: >> OK! Thanks for the feedback. >> >> In CUIS 3.1, Juan simplified many things. For example there's only one >> button class, which suffices for all the different needs of todays >> buttons. > > :) > >> Then the layout part was simplified. > > I thought is was already in PharoSimpleMorphic > >> Anwsers: >> >> 1) Editors and EditorState: Ok, i will coordinate with Alain for this. > > excellent > >> 2) 4) Regarding TextModel and subclasses such as CodeProvider and >> Browser in CUIS: so it means that hierarchy wouldn't be needed at all >> in Pharo. At least Nautilus must have a model for the text ? In CUIS >> the root class is called TextModel , in Pharo 1.3 is called >> StringHolder. I propose moving this discussion on another thread. >> Maybe Benjamin could clarify this? > > benjamin will let us know. > >> So then i believe that for the SimpleMorphic part, it would just a >> matter of porting Nautilus to SimpleMorphic, to be have "System >> browsers". > > yes. > So it requires TreeMorphTreeMorph > So what we would be good is to have a nice > ListMorph (with icons, with multiple selection) > TreeMorph > ... > So that we can rebuild everything on that. > >> As we spoke with Alain, we will first make SimpleMorphic run side by >> side with Morphic on Pharo1.3. > > Good. > >> Then start to enhance SM, to the point of not needing Morphic anymore! For example: porting Polymorph >> (Merging UITheme and SMxTheme, for example). > > Good. > >> Please look at Juan's email about simple morphic, i believe the >> simplicity of this Morphic system deserves this effort. > > Don;t get me wrong. I'm convinced about that but I do not have the expertise to do it. >> >> Fernando >> >> >> On Thu, Mar 31, 2011 at 9:21 AM, Stéphane Ducasse >> <[hidden email]> wrote: >>> Hi guys >>> >>> Since this is interesting for all of us I prefer to publicly discuss it. >>> >>> From: Fernando Olivero <[hidden email]> >>>> Date: March 31, 2011 8:40:26 AM GMT+02:00 >>>> To: [hidden email], Stéphane Ducasse <[hidden email]> >>>> Subject: Regarding SimpleMorphic >>>> Reply-To: [hidden email] >>>> >>>> Hi, i've been working on the necessary steps to ease the adoption of >>>> SimpleMorphic. >>> >>> Excellent! >>> >>>> I found it really nice, and would like to code the new >>>> version of Gaucho on top of it. I post here the conclusions roadmap, >>>> maybe you are starting the same effort, so this is just to collect >>>> feedback or let you know! >>> >>> We want to join forces. >>> I would love to have key widgets: list, tree ported and totally revised so that we >>> do not have 20 of them but just two or four. >>> >>>> I always start from the Morphic in CUIS 3.1, and then go one by one >>>> trying to port the relevant classes, honoring the intent behind Pharo >>>> UI by, for example, adding in the UIManager uses whenever posible, >>>> >>>> Saludos, >>>> Fernando >>> >>> Question: should we look in Cuis3.1 or Pharo1.3 SMx >>> >>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>> CUIS >>>> System >>>> 1) Review Editor and friends: Separate hierarchy or try to merge with >>>> the existing one in Pharo? Alain's great work on EditorState is >>>> missing in CUIS. >>> >>> Yes I love the selection and highlights of Alain. >>> >>>> 2) import TextModel and hierarchy or maintain a separate hierarchy? >>>> The changes in text model and subclasses seem to be good to have! >>> >>> >>>> 3) (CUIS )DifferenceFinder vs (Pharo)TextDiffBuilder ? ( Seems that >>>> DifferenceFinder has extra funcionality) >>> >>> No idea there. >>> >>>> 4) Transcript and TranscriptMorph. DONE ISSUE 3736 >>> >>> soon in Pharo1.3 >>>> >>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>> CUIS3.1 into Pharo1.3 SimpleMorphic >>> >>> So what is the difference with the one we have. >>> >>>> 1) Make current implementation of SMx load in Pharo1.3. >>>> DONE ISSUE 3878: Implementing enableTextChange >>>> DONE ISSUE 3584: Cleanup removing DisplayText =>to remove >>>> UIManager>>composeForm: >>>> DONE ISSUE 3915: DiffMorph requests thru UIManager: so we don't have >>>> to change senders such as ChangeList and VersionBrowser. >>> >>> Good. >>> >>>> 2) World, ActiveHand, ActiveEvent and ActiveWorld cleanup in Morphic. >>>> To merge Morphic and SimpleMorphic handling of the global state, >>>> centralizing the accessors in UIManager, by removing Globals. ALMOSTE >>>> DONE ISSUE 3903 >>>> 3) general up to date from CUIS 3.1: ALMOST DONE >>>> 4) tools?: Revise the SMxBrowser and family, replace maybe with the >>>> new TextModel>>openAsMorph: , etc… >>> >>> For the Browser we plan >>> - to simply **Throw** away all the stringHolder and codeHolder classes and subclasses. >>> Benjamin can show you Nautilus beta. >>> - We will remove also ToolBuilder (as soon as we have a new version of the test runner) >>> - We need a model for the debugger (we should check glamour people for that). >>> So we will temporary keep stringHolde but compact it only for the debugger. >>> >>> >>>> 5) Remove SMxTheWorldMenu and replace with MenuPragmaBuilder as in Pharo. >>> >>> Yes >>> >>>> 6) ? >>>> >>>> ++++++++++++++++++++++ >>>> LOAD ORDER (uncomplete) >>>> 3878 >>>> 3584 >>>> 3915 >>>> 3736 >>>> (PENDING) 3903 >>>> ... >>> >>> >>> >> <SqueakScreen.1.png> > > |
Hi Fernando,
These are good news. I am very interested in using this in Glamour. Just one question: What is the expected schedule? Cheers, Doru On 31 Mar 2011, at 12:51, Fernando Olivero wrote: > Thanks for the answers Stef! > > Comments: > The layout was improved in the first version of SMx, but completely > rethought for CUIS3.1, after Juan published SMx for pharo. See in CUIS > 3.1, the LayoutMorph and examples. > > The last remark was actually for the rest of the community, in case > they didn't understand why was it worth it to migrate to > SimpleMorphic! I know from previous emails that the adoption of > simplicity and a clean Morphic was on your mind. I'm looking forward > for completing this project , once i finish writing for my thesis. > > Fernando > > > On Thu, Mar 31, 2011 at 10:50 AM, Stéphane Ducasse > <[hidden email]> wrote: >>> OK! Thanks for the feedback. >>> >>> In CUIS 3.1, Juan simplified many things. For example there's only one >>> button class, which suffices for all the different needs of todays >>> buttons. >> >> :) >> >>> Then the layout part was simplified. >> >> I thought is was already in PharoSimpleMorphic >> >>> Anwsers: >>> >>> 1) Editors and EditorState: Ok, i will coordinate with Alain for this. >> >> excellent >> >>> 2) 4) Regarding TextModel and subclasses such as CodeProvider and >>> Browser in CUIS: so it means that hierarchy wouldn't be needed at all >>> in Pharo. At least Nautilus must have a model for the text ? In CUIS >>> the root class is called TextModel , in Pharo 1.3 is called >>> StringHolder. I propose moving this discussion on another thread. >>> Maybe Benjamin could clarify this? >> >> benjamin will let us know. >> >>> So then i believe that for the SimpleMorphic part, it would just a >>> matter of porting Nautilus to SimpleMorphic, to be have "System >>> browsers". >> >> yes. >> So it requires TreeMorphTreeMorph >> So what we would be good is to have a nice >> ListMorph (with icons, with multiple selection) >> TreeMorph >> ... >> So that we can rebuild everything on that. >> >>> As we spoke with Alain, we will first make SimpleMorphic run side by >>> side with Morphic on Pharo1.3. >> >> Good. >> >>> Then start to enhance SM, to the point of not needing Morphic anymore! For example: porting Polymorph >>> (Merging UITheme and SMxTheme, for example). >> >> Good. >> >>> Please look at Juan's email about simple morphic, i believe the >>> simplicity of this Morphic system deserves this effort. >> >> Don;t get me wrong. I'm convinced about that but I do not have the expertise to do it. >>> >>> Fernando >>> >>> >>> On Thu, Mar 31, 2011 at 9:21 AM, Stéphane Ducasse >>> <[hidden email]> wrote: >>>> Hi guys >>>> >>>> Since this is interesting for all of us I prefer to publicly discuss it. >>>> >>>> From: Fernando Olivero <[hidden email]> >>>>> Date: March 31, 2011 8:40:26 AM GMT+02:00 >>>>> To: [hidden email], Stéphane Ducasse <[hidden email]> >>>>> Subject: Regarding SimpleMorphic >>>>> Reply-To: [hidden email] >>>>> >>>>> Hi, i've been working on the necessary steps to ease the adoption of >>>>> SimpleMorphic. >>>> >>>> Excellent! >>>> >>>>> I found it really nice, and would like to code the new >>>>> version of Gaucho on top of it. I post here the conclusions roadmap, >>>>> maybe you are starting the same effort, so this is just to collect >>>>> feedback or let you know! >>>> >>>> We want to join forces. >>>> I would love to have key widgets: list, tree ported and totally revised so that we >>>> do not have 20 of them but just two or four. >>>> >>>>> I always start from the Morphic in CUIS 3.1, and then go one by one >>>>> trying to port the relevant classes, honoring the intent behind Pharo >>>>> UI by, for example, adding in the UIManager uses whenever posible, >>>>> >>>>> Saludos, >>>>> Fernando >>>> >>>> Question: should we look in Cuis3.1 or Pharo1.3 SMx >>>> >>>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>>> CUIS >>>>> System >>>>> 1) Review Editor and friends: Separate hierarchy or try to merge with >>>>> the existing one in Pharo? Alain's great work on EditorState is >>>>> missing in CUIS. >>>> >>>> Yes I love the selection and highlights of Alain. >>>> >>>>> 2) import TextModel and hierarchy or maintain a separate hierarchy? >>>>> The changes in text model and subclasses seem to be good to have! >>>> >>>> >>>>> 3) (CUIS )DifferenceFinder vs (Pharo)TextDiffBuilder ? ( Seems that >>>>> DifferenceFinder has extra funcionality) >>>> >>>> No idea there. >>>> >>>>> 4) Transcript and TranscriptMorph. DONE ISSUE 3736 >>>> >>>> soon in Pharo1.3 >>>>> >>>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>>> CUIS3.1 into Pharo1.3 SimpleMorphic >>>> >>>> So what is the difference with the one we have. >>>> >>>>> 1) Make current implementation of SMx load in Pharo1.3. >>>>> DONE ISSUE 3878: Implementing enableTextChange >>>>> DONE ISSUE 3584: Cleanup removing DisplayText =>to remove >>>>> UIManager>>composeForm: >>>>> DONE ISSUE 3915: DiffMorph requests thru UIManager: so we don't have >>>>> to change senders such as ChangeList and VersionBrowser. >>>> >>>> Good. >>>> >>>>> 2) World, ActiveHand, ActiveEvent and ActiveWorld cleanup in Morphic. >>>>> To merge Morphic and SimpleMorphic handling of the global state, >>>>> centralizing the accessors in UIManager, by removing Globals. ALMOSTE >>>>> DONE ISSUE 3903 >>>>> 3) general up to date from CUIS 3.1: ALMOST DONE >>>>> 4) tools?: Revise the SMxBrowser and family, replace maybe with the >>>>> new TextModel>>openAsMorph: , etc… >>>> >>>> For the Browser we plan >>>> - to simply **Throw** away all the stringHolder and codeHolder classes and subclasses. >>>> Benjamin can show you Nautilus beta. >>>> - We will remove also ToolBuilder (as soon as we have a new version of the test runner) >>>> - We need a model for the debugger (we should check glamour people for that). >>>> So we will temporary keep stringHolde but compact it only for the debugger. >>>> >>>> >>>>> 5) Remove SMxTheWorldMenu and replace with MenuPragmaBuilder as in Pharo. >>>> >>>> Yes >>>> >>>>> 6) ? >>>>> >>>>> ++++++++++++++++++++++ >>>>> LOAD ORDER (uncomplete) >>>>> 3878 >>>>> 3584 >>>>> 3915 >>>>> 3736 >>>>> (PENDING) 3903 >>>>> ... >>>> >>>> >>>> >>> <SqueakScreen.1.png> >> >> > -- www.tudorgirba.com "It's not how it is, it is how we see it." |
In reply to this post by Stéphane Ducasse
On Mar 31, 2011, at 10:50 AM, Stéphane Ducasse wrote: >> >> 2) 4) Regarding TextModel and subclasses such as CodeProvider and >> Browser in CUIS: so it means that hierarchy wouldn't be needed at all >> in Pharo. At least Nautilus must have a model for the text ? In CUIS >> the root class is called TextModel , in Pharo 1.3 is called >> StringHolder. I propose moving this discussion on another thread. >> Maybe Benjamin could clarify this? > > benjamin will let us know. I think that the text should be handled by a Browser but by the TextMorph, or you will have the same ugly hierarchy than StringHolder, when a Model/View are badly mixed and where each tool that manage source code inherits from it, without using properly inheritance ... IMHO, it should be orthogonal to that, and should be "pluggable" in each tool which need it. Right now for Nautilus, I have borrowed only 3-4 methods from StringHolder/CodeHolder/Browser, almost all expected behavior is provided by PluggableTextMorph Ben |
In CUIS the intent is to provide specialization on the model, And then
each model holds the responsibility of creating the appropriate view (SystemWindow), by creating a composition of widgets. This is a subset of the model hierarchy, Model TextModel Workspace PluggableTextModel TextProvider CodeProvider Browser HierarchyBrowser Debugger Inspector From what i've understood, you want to do something similar, but instead specialize the "View", and have a single "model"? Did i understood correctly you intent? If that is the case, then i advice to look at CUIS before. I believe the arguments below are quite strong ones for the CUIS approach ( Specialized Model and Generic View). I believe this scheme is flexible and extensible, because you make the view "stupid", and specialize the model. You avoid polluting an unique class (for example the mess in CodeHolder), and put the behavior in the model( in the proper sublcass). And you make the view dont know about the model logic, because it's just a composition of widgets. The downside is that the model knows how to "assemble" the view. But this means that you put the interaction handling logic in a model, and can assemble many different views on the same model Please dont take it the wrong way, i'm favor of discussing before blindly porting CUIS code, but i would like to know more about the reason behind your approach. So we can clean and simplify the ugly parts of the system! Thanks, Fernando On Thu, Mar 31, 2011 at 1:28 PM, Benjamin <[hidden email]> wrote: > > On Mar 31, 2011, at 10:50 AM, Stéphane Ducasse wrote: > >>> >>> 2) 4) Regarding TextModel and subclasses such as CodeProvider and >>> Browser in CUIS: so it means that hierarchy wouldn't be needed at all >>> in Pharo. At least Nautilus must have a model for the text ? In CUIS >>> the root class is called TextModel , in Pharo 1.3 is called >>> StringHolder. I propose moving this discussion on another thread. >>> Maybe Benjamin could clarify this? >> >> benjamin will let us know. > > I think that the text should be handled by a Browser but by the TextMorph, or you will have the same ugly hierarchy than StringHolder, when a Model/View are badly mixed and where each tool that manage source code inherits from it, without using properly inheritance ... > > IMHO, it should be orthogonal to that, and should be "pluggable" in each tool which need it. > > Right now for Nautilus, I have borrowed only 3-4 methods from StringHolder/CodeHolder/Browser, almost all expected behavior is provided by PluggableTextMorph > > > > Ben > |
On Mar 31, 2011, at 2:14 PM, Fernando Olivero wrote: > In CUIS the intent is to provide specialization on the model, And then > each model holds the responsibility of creating the appropriate view > (SystemWindow), by creating a composition of widgets. This is a subset > of the model hierarchy, > > Model > TextModel > Workspace > PluggableTextModel > TextProvider > CodeProvider > Browser > HierarchyBrowser > Debugger > Inspector Workspace is not a model, it's a view basically. So why it inherits from Model ? The same for Browser, HierarchyBrowser, Debugger, Inspector and so on... Maybe it's better to have something like > > From what i've understood, you want to do something similar, but > instead specialize the "View", and have a single "model"? Did i > understood correctly you intent? > > If that is the case, then i advice to look at CUIS before. I believe > the arguments below are quite strong ones for the CUIS approach ( > Specialized Model and Generic View). > > I believe this scheme is flexible and extensible, because you make the > view "stupid", and specialize the model. You avoid polluting an unique > class (for example the mess in CodeHolder), and put the behavior in > the model( in the proper sublcass). And you make the view dont know > about the model logic, because it's just a composition of widgets. The > downside is that the model knows how to "assemble" the view. But this > means that you put the interaction handling logic in a model, and can > assemble many different views on the same model > > Please dont take it the wrong way, i'm favor of discussing before > blindly porting CUIS code, but i would like to know more about the > reason behind your approach. So we can clean and simplify the ugly > parts of the system! Do not worry about, I'm always open to discussion, and always happy to learn ;) Ben > > Thanks, > Fernando > > > > > On Thu, Mar 31, 2011 at 1:28 PM, Benjamin > <[hidden email]> wrote: >> >> On Mar 31, 2011, at 10:50 AM, Stéphane Ducasse wrote: >> >>>> >>>> 2) 4) Regarding TextModel and subclasses such as CodeProvider and >>>> Browser in CUIS: so it means that hierarchy wouldn't be needed at all >>>> in Pharo. At least Nautilus must have a model for the text ? In CUIS >>>> the root class is called TextModel , in Pharo 1.3 is called >>>> StringHolder. I propose moving this discussion on another thread. >>>> Maybe Benjamin could clarify this? >>> >>> benjamin will let us know. >> >> I think that the text should be handled by a Browser but by the TextMorph, or you will have the same ugly hierarchy than StringHolder, when a Model/View are badly mixed and where each tool that manage source code inherits from it, without using properly inheritance ... >> >> IMHO, it should be orthogonal to that, and should be "pluggable" in each tool which need it. >> >> Right now for Nautilus, I have borrowed only 3-4 methods from StringHolder/CodeHolder/Browser, almost all expected behavior is provided by PluggableTextMorph >> >> >> >> Ben >> > BrowserInheritance.pdf (18K) Download Attachment |
+ 1 :)
So I like the discussion. It would be nice to have Views that do not inherit from model. :) So let us get real model. Stef > In CUIS the intent is to provide specialization on the model, And then >> each model holds the responsibility of creating the appropriate view >> (SystemWindow), by creating a composition of widgets. This is a subset >> of the model hierarchy, >> > >> Model >> TextModel >> Workspace >> PluggableTextModel >> TextProvider >> CodeProvider >> Browser >> HierarchyBrowser >> Debugger >> Inspector > > For me, this hierarchy is bad. > Workspace is not a model, it's a view basically. So why it inherits from Model ? > The same for Browser, HierarchyBrowser, Debugger, Inspector and so on... > > > Maybe it's better to have something like > > > > <BrowserInheritance.pdf> > > > > > >> >> From what i've understood, you want to do something similar, but >> instead specialize the "View", and have a single "model"? Did i >> understood correctly you intent? >> >> If that is the case, then i advice to look at CUIS before. I believe >> the arguments below are quite strong ones for the CUIS approach ( >> Specialized Model and Generic View). >> >> I believe this scheme is flexible and extensible, because you make the >> view "stupid", and specialize the model. You avoid polluting an unique >> class (for example the mess in CodeHolder), and put the behavior in >> the model( in the proper sublcass). And you make the view dont know >> about the model logic, because it's just a composition of widgets. The >> downside is that the model knows how to "assemble" the view. But this >> means that you put the interaction handling logic in a model, and can >> assemble many different views on the same model >> >> Please dont take it the wrong way, i'm favor of discussing before >> blindly porting CUIS code, but i would like to know more about the >> reason behind your approach. So we can clean and simplify the ugly >> parts of the system! > > > Do not worry about, I'm always open to discussion, and always happy to learn ;) > > > Ben > > >> >> Thanks, >> Fernando >> >> >> >> >> On Thu, Mar 31, 2011 at 1:28 PM, Benjamin >> <[hidden email]> wrote: >>> >>> On Mar 31, 2011, at 10:50 AM, Stéphane Ducasse wrote: >>> >>>>> >>>>> 2) 4) Regarding TextModel and subclasses such as CodeProvider and >>>>> Browser in CUIS: so it means that hierarchy wouldn't be needed at all >>>>> in Pharo. At least Nautilus must have a model for the text ? In CUIS >>>>> the root class is called TextModel , in Pharo 1.3 is called >>>>> StringHolder. I propose moving this discussion on another thread. >>>>> Maybe Benjamin could clarify this? >>>> >>>> benjamin will let us know. >>> >>> I think that the text should be handled by a Browser but by the TextMorph, or you will have the same ugly hierarchy than StringHolder, when a Model/View are badly mixed and where each tool that manage source code inherits from it, without using properly inheritance ... >>> >>> IMHO, it should be orthogonal to that, and should be "pluggable" in each tool which need it. >>> >>> Right now for Nautilus, I have borrowed only 3-4 methods from StringHolder/CodeHolder/Browser, almost all expected behavior is provided by PluggableTextMorph >>> >>> >>> >>> Ben >>> >> > |
In reply to this post by Fernando olivero-2
On Mar 31, 2011, at 2:14 PM, Fernando Olivero wrote: > Model > TextModel > Workspace > PluggableTextModel > TextProvider > CodeProvider > Browser > HierarchyBrowser > Debugger > Inspector Why this hierarchy is wrong? Wheel Car We do not like that Car inherits from Wheel? We prefer to say Car has Weels So BrowserModel inherits from Model but not from TextModel BrowserModel has a textModel et other stuff A BrowserModel should not inherit from CodeProvider it has a code provider. Let us kill this StringHolder crap and be in 2010. Stef |
In reply to this post by Benjamin Van Ryseghem (Pharo)
Benjamin,
Testing the understanding of the diagram of yours: Model, Pluggable TextMorph, Pluggable CodeMorph, Browser, Browser Model, Debugger and Debugger Model all inherit from Object? the representation of "based on" means that it changes states in the model counterpart, and "use" means that has some similarity but not enough to inherit from the other classes? Could you elaborate this with a more complete UML diagram? Thanks for giving thoughts on this subject. Regards, -- Cesar Rabak Em 31/03/2011 10:29, Benjamin < [hidden email] > escreveu: On Mar 31, 2011, at 2:14 PM, Fernando Olivero wrote: > In CUIS the intent is to provide specialization on the model, And then > each model holds the responsibility of creating the appropriate view > (SystemWindow), by creating a composition of widgets. This is a subset > of the model hierarchy, > > Model > TextModel > Workspace > PluggableTextModel > TextProvider > CodeProvider > Browser > HierarchyBrowser > Debugger > Inspector For me, this hierarchy is bad. Workspace is not a model, it's a view basically. So why it inherits from Model ? The same for Browser, HierarchyBrowser, Debugger, Inspector and so on... Maybe it's better to have something like |
In reply to this post by Stéphane Ducasse
+1
Doru On 31 Mar 2011, at 18:31, Stéphane Ducasse wrote: > > On Mar 31, 2011, at 2:14 PM, Fernando Olivero wrote: > >> Model >> TextModel >> Workspace >> PluggableTextModel >> TextProvider >> CodeProvider >> Browser >> HierarchyBrowser >> Debugger >> Inspector > > > Why this hierarchy is wrong? > > Wheel > Car > > We do not like that Car inherits from Wheel? > We prefer to say > > Car > has Weels > > > So > BrowserModel inherits from Model but not from TextModel > BrowserModel > has a textModel et other stuff > > > A BrowserModel should not inherit from CodeProvider > it has a code provider. > > Let us kill this StringHolder crap and be in 2010. > > Stef > -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar." |
In reply to this post by Stéphane Ducasse
Em 31/03/2011 13:31, Stéphane Ducasse < [hidden email] > escreveu:
[snipped] > Let us kill this StringHolder crap and be in 2010. Stef, I'm sure you really miss last year, but we're entering the second quarter of 2011 ;-) []s Getting back to the technical part of your post, I also always tried to understand why in some cases we end up with this strange hierarchy (which you mock saying Car inherits from Wheel), specially if we take in account Smalltalk is a single inheritance language, so you have only a shot to specialize a given class. Maybe the folks that did it in the past were less used to composing than inheriting and the second way saves writing some new methods to avoid breaking the Demeter principle? Perhaps understanding the "crucial incident" could lead us to better roadmap. . . -- Cesar Rabak |
>>
> > Stef, > > I'm sure you really miss last year, but we're entering the second quarter of 2011 ;-) > > []s > > Getting back to the technical part of your post, I also always tried to understand why in some cases we end up with this strange hierarchy people long time ago thought that inheritance = reuse. > (which you mock saying Car inherits from Wheel), specially if we take in account Smalltalk is a single inheritance language, so you have only a shot to specialize a given class. > > Maybe the folks that did it in the past were less used to composing than inheriting and the second way saves writing some new methods to avoid breaking the Demeter principle? I'm quite sure that LOD was not their concern. > > Perhaps understanding the "crucial incident" could lead us to better roadmap. . . No. We know design. We should just implement it. Stef |
In reply to this post by csrabak
On Mar 31, 2011, at 8:08 PM, [hidden email] wrote: > Benjamin, > > Testing the understanding of the diagram of yours: > > Model, Pluggable TextMorph, Pluggable CodeMorph, Browser, Browser Model, Debugger and Debugger Model all inherit from Object? > > the representation of "based on" means that it changes states in the model counterpart, and > "use" means that has some similarity but not enough to inherit from the other classes? based on means, that the view (on right) is based on the model (on left) use means that the View use/is composed with the other view. By example, Browser is based on BrowserModel, and Browser (as a Morph by example) contains a PluggableCodeMorph Is it better like that ? (I'm sorry, but I'm not sure to be able to do a good UML ^^) Ben > > Could you elaborate this with a more complete UML diagram? > > Thanks for giving thoughts on this subject. > > Regards, > > -- > Cesar Rabak > > > Em 31/03/2011 10:29, Benjamin < [hidden email] > escreveu: > > On Mar 31, 2011, at 2:14 PM, Fernando Olivero wrote: > >> In CUIS the intent is to provide specialization on the model, And then >> each model holds the responsibility of creating the appropriate view >> (SystemWindow), by creating a composition of widgets. This is a subset >> of the model hierarchy, >> > >> Model >> TextModel >> Workspace >> PluggableTextModel >> TextProvider >> CodeProvider >> Browser >> HierarchyBrowser >> Debugger >> Inspector > > For me, this hierarchy is bad. > Workspace is not a model, it's a view basically. So why it inherits from Model ? > The same for Browser, HierarchyBrowser, Debugger, Inspector and so on... > > > Maybe it's better to have something like > > > > > > |
Em 31/03/2011 18:10, Benjamin <[hidden email]> escreveu:
> On Mar 31, 2011, at 8:08 PM, [hidden email] wrote: > > > Benjamin, > > Testing the understanding of the diagram of yours: > > Model, Pluggable TextMorph, Pluggable CodeMorph, Browser, Browser > > Model, Debugger and Debugger Model all inherit from Object? > > the representation of "based on" means that it changes states in > > the model counterpart, and "use" means that has some similarity > > but not enough to inherit from the other classes? > > based on means, that the view (on right) is based on the model (on > left) This still tautological: does "based on" means the structure is one-to-one correspondent? Or are we re-introducing the MVC paradigm and the "based on" means that the View has to know the inners of the Model in order to be built? > use means that the View use/is composed with the other view. > By example, Browser is based on BrowserModel, and Browser (as a > Morph by example) contains a PluggableCodeMorph This one explains well your thought, or at least I've the belief I understood. > > > Is it better like that ? The second part, much better, for the first one I'm still lost :-( > (I'm sorry, but I'm not sure to be able to do a good UML ^^) OK. Let's see if after fully understanding your idea we can come by something. |
On Apr 1, 2011, at 8:29 PM, [hidden email] wrote: > Em 31/03/2011 18:10, Benjamin <[hidden email]> escreveu: > >> On Mar 31, 2011, at 8:08 PM, [hidden email] wrote: >> >>> Benjamin, >>> Testing the understanding of the diagram of yours: >>> Model, Pluggable TextMorph, Pluggable CodeMorph, Browser, Browser >>> Model, Debugger and Debugger Model all inherit from Object? >>> the representation of "based on" means that it changes states in >>> the model counterpart, and "use" means that has some similarity >>> but not enough to inherit from the other classes? >> >> based on means, that the view (on right) is based on the model (on >> left) > > This still tautological: does "based on" means the structure is one-to-one correspondent? > > Or are we re-introducing the MVC paradigm and the "based on" means that the View has to know the inners of the Model in order to be built? Yes it's MVC, the problem is there is no proper controllers ... Ben > >> use means that the View use/is composed with the other view. >> By example, Browser is based on BrowserModel, and Browser (as a >> Morph by example) contains a PluggableCodeMorph > > This one explains well your thought, or at least I've the belief I understood. > >> >> >> Is it better like that ? > > The second part, much better, for the first one I'm still lost :-( > >> (I'm sorry, but I'm not sure to be able to do a good UML ^^) > > OK. > > Let's see if after fully understanding your idea we can come by something. > > |
In reply to this post by Stéphane Ducasse
On 31 March 2011 22:03, Stéphane Ducasse <[hidden email]> wrote:
>>> >> >> Stef, >> >> I'm sure you really miss last year, but we're entering the second quarter of 2011 ;-) >> >> []s >> >> Getting back to the technical part of your post, I also always tried to understand why in some cases we end up with this strange hierarchy > > people long time ago thought that inheritance = reuse. > It is strange, because i learned that inheritance is _specialization_. And i actually haven't took much care about subtleties of this, before i met smalltalk and start coding in it. It is in smalltalk, where it become apparent to me: - subclassing is not a way to "extend" a superclass, it is a way to specialize a superclass. >> (which you mock saying Car inherits from Wheel), specially if we take in account Smalltalk is a single inheritance language, so you have only a shot to specialize a given class. >> >> Maybe the folks that did it in the past were less used to composing than inheriting and the second way saves writing some new methods to avoid breaking the Demeter principle? > > I'm quite sure that LOD was not their concern. >> >> Perhaps understanding the "crucial incident" could lead us to better roadmap. . . > > No. We know design. We should just implement it. > > Stef > -- Best regards, Igor Stasenko AKA sig. |
A nice paper on this topic,
On the Notion of Inheritance (1996) by Antero Taivalsaari http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.110.7221 Fernando On Mon, Apr 4, 2011 at 2:01 PM, Igor Stasenko <[hidden email]> wrote: > On 31 March 2011 22:03, Stéphane Ducasse <[hidden email]> wrote: >>>> >>> >>> Stef, >>> >>> I'm sure you really miss last year, but we're entering the second quarter of 2011 ;-) >>> >>> []s >>> >>> Getting back to the technical part of your post, I also always tried to understand why in some cases we end up with this strange hierarchy >> >> people long time ago thought that inheritance = reuse. >> > > It is strange, because i learned that inheritance is _specialization_. > > And i actually haven't took much care about subtleties of this, before > i met smalltalk and start coding in it. It is in smalltalk, where it > become apparent to me: > - subclassing is not a way to "extend" a superclass, it is a way to > specialize a superclass. > > >>> (which you mock saying Car inherits from Wheel), specially if we take in account Smalltalk is a single inheritance language, so you have only a shot to specialize a given class. >>> >>> Maybe the folks that did it in the past were less used to composing than inheriting and the second way saves writing some new methods to avoid breaking the Demeter principle? >> >> I'm quite sure that LOD was not their concern. >>> >>> Perhaps understanding the "crucial incident" could lead us to better roadmap. . . >> >> No. We know design. We should just implement it. >> >> Stef >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
In reply to this post by Benjamin Van Ryseghem (Pharo)
On Apr 4, 2011, at 1:44 09PM, Benjamin wrote: > > On Apr 1, 2011, at 8:29 PM, [hidden email] wrote: > >> Em 31/03/2011 18:10, Benjamin <[hidden email]> escreveu: >> >>> On Mar 31, 2011, at 8:08 PM, [hidden email] wrote: >>> >>>> Benjamin, >>>> Testing the understanding of the diagram of yours: >>>> Model, Pluggable TextMorph, Pluggable CodeMorph, Browser, Browser >>>> Model, Debugger and Debugger Model all inherit from Object? >>>> the representation of "based on" means that it changes states in >>>> the model counterpart, and "use" means that has some similarity >>>> but not enough to inherit from the other classes? >>> >>> based on means, that the view (on right) is based on the model (on >>> left) >> >> This still tautological: does "based on" means the structure is one-to-one correspondent? >> >> Or are we re-introducing the MVC paradigm and the "based on" means that the View has to know the inners of the Model in order to be built? > > Yes it's MVC, the problem is there is no proper controllers ... > > > Ben "Problem" is a bit harsh of a word. Controllers are great for when you want modal behaviour for an object (like, a canvas in a drawing program responding to mouseclicks differently based on current brush). For typical widgets where behaviour is non--modal, they are mostly, if not entirely, an unnecessary level of indirection. My 2c at least :) Cheers, Henry |
Free forum by Nabble | Edit this page |