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 <stephane.ducasse@inria.fr> wrote:
Hi guys
Since this is interesting for all of us I prefer to publicly discuss it.
From: Fernando Olivero <fernando.olivero@usi.ch>
Date: March 31, 2011 8:40:26 AM GMT+02:00 To: alain.plantec@free.fr, Stéphane Ducasse <stephane.ducasse@inria.fr> Subject: Regarding SimpleMorphic Reply-To: fernando.olivero@usi.ch
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>