Early days of an MVP framework

> Gary,
>
> I was on an unstoppable roll (salvaged early on by Andreas' bitblt
> coaching), until I needed to repeat a "complex" GUI component and
> wanted/insisted on doing so with some reuse.  Seaside gives us components
> on web pages; we need them for GUI code too.  I tried turning my
> presenter-like structures into factories that would add morphs to a single
> shell, but it fell apart when it came time to set the framing values.  I
> was not particularly interested in fixing it, because if I could do that,
> I would simply build proper composite widgets using the fix.
>
> The problem appears to be in SystemWindow, which does some incredibly
> complicated things, all of which (correct me if I am wrong) would be
> unnecessary if only there were a good set of layout managers.  I can get
> very simple-minded about things, but it would make a whole lot more sense
> to me to create rows and columns of widgets, adding splitters between them
> until the whole things behaves as intended, rather than writing code
> (present only in a top-level shell) that tries to split things up into
> rows using its own judgment.  Not good.  I realize you did not create the
> situation, and have done wonders to make it work far better than when you
> found it.
>
> Some time ago, I built an emulated widget framework for Dolphin, which I
> needed because the combination of Dolphin's view resources and Windows
> itself was too slow for what I was trying to do.  That project included a
> somewhat strange set of layout classes, but the basics are present, and it
> is not Object Arts' IP.  I ported the classes to Pharo and did some work
> on stub View and Presenter classes that I had added to Pharo largely to
> passify my code that I was importing from Dolphin.  The layouts think in
> terms of emulated widgets, and I see no reason to change their minds: I
> might want to replicate the framework.  However, dynamic typing and a
> couple of extra methods allow them to work with just about anything.  My
> goals are modest.  Being able to compose rows and columns would do a lot
> for me.  Add splitters and the ability to fix the size of some items, and
> I could almost anything I would need.
>
> View class>>example
> | row column dot square out shell |
> dot := ( Form dotOfSize:100 ) asFormOfDepth:32.
> square := ( Form squareOfSize:100 ) asFormOfDepth:32.
> out := Array writeStream.
>
> row := ContainerView row.
> 2 timesRepeat:[
> column := row addSubview:ContainerView column.
> 2 timesRepeat:[
> out nextPut:(
> column addSubview:ImageView new
> ).
> ].
> ].
>
> out contents with:{ dot copy. square copy. square copy. dot copy. } do:[
> :view :form |
> view morph image:form.
> ].
>
> row rectangle:( 0@0 extent:400@400 ).
> row layout.
>
> shell := StandardWindow labelled:'Hello MVP'.
> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself.
>
>
> The above code produces an array of dots and squares, as intended.  One
> quirk is that the grid does not resize as the shell resizes, a consequence
> of my not having hooked it up to resize events.  I might get some
> interesting meltdowns once I begin to do that =:0  I used your PanelMorph
> as the "view" associated with ContainerView.  What, ContainView isn't a
> view???  No.  The code is biased toward Morphic, but hopefully the same
> code should extend to wx, GTK, etc.  Dolphin's views have a handle
> instance variable to control the external resource; these views have an
> instance variable pointing to their morph.  Handling of sub views works
> pretty much as in Dolphin: any view/morph can have children, but adding
> them is "legal" only for composites.
>
> Most systems I have seen treat coordinates relative to the parent/owner,
> but not Morphic.  I remember seeing plans to make the change, but nothing
> after that.  The view instances provide a natural place to fix things, so
> I took the plunge.  If we switch to some other graphical realization, we
> can simply remove the the transformation.
>
> Are the existing splitters as strange as SystemWindow?  By that I mean,
> would it be reasonable to add them between other morphs and look for
> events from them, or will they have to be replaced?  I will eventually
> need splitters, but I could initially live without them if I can get
> reliable composition where I need it.
>
> There are very few view classes at present.  MorphView can wrap almost
> anything, so it might be better to create a rich set of presenters
> instead.  Dolphin's view resources are going to be interesting to replace.
> There are some complexities that I suspect are in deference to Windows,
> and some that might be avoidable.  For our purposes, it might be enough to
> use SIXX to serialize a bunch of message sends and gzip the results to
> save memory.  Another option might be to rely on class methods; having
> full closures won't hurt; they might allow sufficient hooking that
> resources in the Dolphin sense won't even be necessary.  The desire for
> them quickly arises because views get realized in places know nothing
> about how the views should be configured; at least I think that is what
> happened to me after just a couple of hours.  I am far less interested in
> having a graphical view editor than I am in being able to write **GOOD**
> code that assembles things as I want.  If the result happens to allow a
> graphical editor too, so much the better.
>
> Any interest?
>
> Bill
>
>
> -----------------------------
>
> View
>   MorphViev
>   ImageView
>   ContainerView
>
> ViewGadgetLayoutAbstract
>   ScrollerGadgetLayout
>   NullViewGadgetLayout
>   FixedStretchFixedGadgetLayout
>   ProportionalGadgetLayout
>   PreferredExtentsGadgetLayout
>   GridGadgetRowsLayout
>   VerticalListLayout
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> Any Morph can use a layoutPolicy.
> Available are
>    none (position based)
>    Prorportional (frame/fractions/offsets)
>    Table (overly complex too)
>    Row (one of mine, quicker for simple rows)
>    Stack (mine, overlay morphs on top of each other)
>
> TEasilyThemed provides some methods like...
>
>    newRow: {aMorph, anotherMorph}
>    newColumn:
>
> Something like this works...
>
> (UITheme builder
> newColumn: {
>  UITheme builder newPanel
>   fillStyle: Color red;
>   hResizing: #spaceFill;
>   vResizing: #spaceFill.
>  UITheme builder newRow: {
>   UITheme builder newOKButton.
>   UITheme builder newCancelButton}})
> extent: 200@300;
> openInHand
>
> (can use openInWindow also)...
>
> Rather busy today, hope this helps in the meantime...
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Schwab,Wilhelm K" <[hidden email]>
> To: <[hidden email]>
> Sent: Sunday, August 08, 2010 11:46 PM
> Subject: [Pharo-project] Early days of an MVP framework
>
>
>> Gary,
>>
>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt
>> coaching), until I needed to repeat a "complex" GUI component and
>> wanted/insisted on doing so with some reuse.  Seaside gives us components
>> on web pages; we need them for GUI code too.  I tried turning my
>> presenter-like structures into factories that would add morphs to a
>> single shell, but it fell apart when it came time to set the framing
>> values.  I was not particularly interested in fixing it, because if I
>> could do that, I would simply build proper composite widgets using the
>> fix.
>>
>> The problem appears to be in SystemWindow, which does some incredibly
>> complicated things, all of which (correct me if I am wrong) would be
>> unnecessary if only there were a good set of layout managers.  I can get
>> very simple-minded about things, but it would make a whole lot more sense
>> to me to create rows and columns of widgets, adding splitters between
>> them until the whole things behaves as intended, rather than writing code
>> (present only in a top-level shell) that tries to split things up into
>> rows using its own judgment.  Not good.  I realize you did not create the
>> situation, and have done wonders to make it work far better than when you
>> found it.
>>
>> Some time ago, I built an emulated widget framework for Dolphin, which I
>> needed because the combination of Dolphin's view resources and Windows
>> itself was too slow for what I was trying to do.  That project included a
>> somewhat strange set of layout classes, but the basics are present, and
>> it is not Object Arts' IP.  I ported the classes to Pharo and did some
>> work on stub View and Presenter classes that I had added to Pharo largely
>> to passify my code that I was importing from Dolphin.  The layouts think
>> in terms of emulated widgets, and I see no reason to change their minds:
>> I might want to replicate the framework.  However, dynamic typing and a
>> couple of extra methods allow them to work with just about anything.  My
>> goals are modest.  Being able to compose rows and columns would do a lot
>> for me.  Add splitters and the ability to fix the size of some items, and
>> I could almost anything I would need.
>>
>> View class>>example
>> | row column dot square out shell |
>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32.
>> square := ( Form squareOfSize:100 ) asFormOfDepth:32.
>> out := Array writeStream.
>>
>> row := ContainerView row.
>> 2 timesRepeat:[
>> column := row addSubview:ContainerView column.
>> 2 timesRepeat:[
>> out nextPut:(
>> column addSubview:ImageView new
>> ).
>> ].
>> ].
>>
>> out contents with:{ dot copy. square copy. square copy. dot copy. }
>> do:[ :view :form |
>> view morph image:form.
>> ].
>>
>> row rectangle:( 0@0 extent:400@400 ).
>> row layout.
>>
>> shell := StandardWindow labelled:'Hello MVP'.
>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself.
>>
>>
>> The above code produces an array of dots and squares, as intended.  One
>> quirk is that the grid does not resize as the shell resizes, a
>> consequence of my not having hooked it up to resize events.  I might get
>> some interesting meltdowns once I begin to do that =:0  I used your
>> PanelMorph as the "view" associated with ContainerView.  What,
>> ContainView isn't a view???  No.  The code is biased toward Morphic, but
>> hopefully the same code should extend to wx, GTK, etc.  Dolphin's views
>> have a handle instance variable to control the external resource; these
>> views have an instance variable pointing to their morph.  Handling of sub
>> views works pretty much as in Dolphin: any view/morph can have children,
>> but adding them is "legal" only for composites.
>>
>> Most systems I have seen treat coordinates relative to the parent/owner,
>> but not Morphic.  I remember seeing plans to make the change, but nothing
>> after that.  The view instances provide a natural place to fix things, so
>> I took the plunge.  If we switch to some other graphical realization, we
>> can simply remove the the transformation.
>>
>> Are the existing splitters as strange as SystemWindow?  By that I mean,
>> would it be reasonable to add them between other morphs and look for
>> events from them, or will they have to be replaced?  I will eventually
>> need splitters, but I could initially live without them if I can get
>> reliable composition where I need it.
>>
>> There are very few view classes at present.  MorphView can wrap almost
>> anything, so it might be better to create a rich set of presenters
>> instead.  Dolphin's view resources are going to be interesting to
>> replace. There are some complexities that I suspect are in deference to
>> Windows, and some that might be avoidable.  For our purposes, it might be
>> enough to use SIXX to serialize a bunch of message sends and gzip the
>> results to save memory.  Another option might be to rely on class
>> methods; having full closures won't hurt; they might allow sufficient
>> hooking that resources in the Dolphin sense won't even be necessary.  The
>> desire for them quickly arises because views get realized in places know
>> nothing about how the views should be configured; at least I think that
>> is what happened to me after just a couple of hours.  I am far less
>> interested in having a graphical view editor than I am in being able to
>> write **GOOD** code that assembles things as I want.  If the result
>> happens to allow a graphical editor too, so much the better.
>>
>> Any interest?
>>
>> Bill
>>
>>
>> -----------------------------
>>
>> View
>>   MorphViev
>>   ImageView
>>   ContainerView
>>
>> ViewGadgetLayoutAbstract
>>   ScrollerGadgetLayout
>>   NullViewGadgetLayout
>>   FixedStretchFixedGadgetLayout
>>   ProportionalGadgetLayout
>>   PreferredExtentsGadgetLayout
>>   GridGadgetRowsLayout
>>   VerticalListLayout
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> Any Morph can use a layoutPolicy.
> Available are
>    none (position based)
>    Prorportional (frame/fractions/offsets)
>    Table (overly complex too)
>    Row (one of mine, quicker for simple rows)
>    Stack (mine, overlay morphs on top of each other)
>
> TEasilyThemed provides some methods like...
>
>    newRow: {aMorph, anotherMorph}
>    newColumn:
>
> Something like this works...
>
> (UITheme builder
> newColumn: {
>  UITheme builder newPanel
>   fillStyle: Color red;
>   hResizing: #spaceFill;
>   vResizing: #spaceFill.
>  UITheme builder newRow: {
>   UITheme builder newOKButton.
>   UITheme builder newCancelButton}})
> extent: 200@300;
> openInHand
>
> (can use openInWindow also)...
>
> Rather busy today, hope this helps in the meantime...
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Schwab,Wilhelm K" <[hidden email]>
> To: <[hidden email]>
> Sent: Sunday, August 08, 2010 11:46 PM
> Subject: [Pharo-project] Early days of an MVP framework
>
>
>> Gary,
>>
>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt
>> coaching), until I needed to repeat a "complex" GUI component and
>> wanted/insisted on doing so with some reuse.  Seaside gives us components
>> on web pages; we need them for GUI code too.  I tried turning my
>> presenter-like structures into factories that would add morphs to a
>> single shell, but it fell apart when it came time to set the framing
>> values.  I was not particularly interested in fixing it, because if I
>> could do that, I would simply build proper composite widgets using the
>> fix.
>>
>> The problem appears to be in SystemWindow, which does some incredibly
>> complicated things, all of which (correct me if I am wrong) would be
>> unnecessary if only there were a good set of layout managers.  I can get
>> very simple-minded about things, but it would make a whole lot more sense
>> to me to create rows and columns of widgets, adding splitters between
>> them until the whole things behaves as intended, rather than writing code
>> (present only in a top-level shell) that tries to split things up into
>> rows using its own judgment.  Not good.  I realize you did not create the
>> situation, and have done wonders to make it work far better than when you
>> found it.
>>
>> Some time ago, I built an emulated widget framework for Dolphin, which I
>> needed because the combination of Dolphin's view resources and Windows
>> itself was too slow for what I was trying to do.  That project included a
>> somewhat strange set of layout classes, but the basics are present, and
>> it is not Object Arts' IP.  I ported the classes to Pharo and did some
>> work on stub View and Presenter classes that I had added to Pharo largely
>> to passify my code that I was importing from Dolphin.  The layouts think
>> in terms of emulated widgets, and I see no reason to change their minds:
>> I might want to replicate the framework.  However, dynamic typing and a
>> couple of extra methods allow them to work with just about anything.  My
>> goals are modest.  Being able to compose rows and columns would do a lot
>> for me.  Add splitters and the ability to fix the size of some items, and
>> I could almost anything I would need.
>>
>> View class>>example
>> | row column dot square out shell |
>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32.
>> square := ( Form squareOfSize:100 ) asFormOfDepth:32.
>> out := Array writeStream.
>>
>> row := ContainerView row.
>> 2 timesRepeat:[
>> column := row addSubview:ContainerView column.
>> 2 timesRepeat:[
>> out nextPut:(
>> column addSubview:ImageView new
>> ).
>> ].
>> ].
>>
>> out contents with:{ dot copy. square copy. square copy. dot copy. }
>> do:[ :view :form |
>> view morph image:form.
>> ].
>>
>> row rectangle:( 0@0 extent:400@400 ).
>> row layout.
>>
>> shell := StandardWindow labelled:'Hello MVP'.
>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself.
>>
>>
>> The above code produces an array of dots and squares, as intended.  One
>> quirk is that the grid does not resize as the shell resizes, a
>> consequence of my not having hooked it up to resize events.  I might get
>> some interesting meltdowns once I begin to do that =:0  I used your
>> PanelMorph as the "view" associated with ContainerView.  What,
>> ContainView isn't a view???  No.  The code is biased toward Morphic, but
>> hopefully the same code should extend to wx, GTK, etc.  Dolphin's views
>> have a handle instance variable to control the external resource; these
>> views have an instance variable pointing to their morph.  Handling of sub
>> views works pretty much as in Dolphin: any view/morph can have children,
>> but adding them is "legal" only for composites.
>>
>> Most systems I have seen treat coordinates relative to the parent/owner,
>> but not Morphic.  I remember seeing plans to make the change, but nothing
>> after that.  The view instances provide a natural place to fix things, so
>> I took the plunge.  If we switch to some other graphical realization, we
>> can simply remove the the transformation.
>>
>> Are the existing splitters as strange as SystemWindow?  By that I mean,
>> would it be reasonable to add them between other morphs and look for
>> events from them, or will they have to be replaced?  I will eventually
>> need splitters, but I could initially live without them if I can get
>> reliable composition where I need it.
>>
>> There are very few view classes at present.  MorphView can wrap almost
>> anything, so it might be better to create a rich set of presenters
>> instead.  Dolphin's view resources are going to be interesting to
>> replace. There are some complexities that I suspect are in deference to
>> Windows, and some that might be avoidable.  For our purposes, it might be
>> enough to use SIXX to serialize a bunch of message sends and gzip the
>> results to save memory.  Another option might be to rely on class
>> methods; having full closures won't hurt; they might allow sufficient
>> hooking that resources in the Dolphin sense won't even be necessary.  The
>> desire for them quickly arises because views get realized in places know
>> nothing about how the views should be configured; at least I think that
>> is what happened to me after just a couple of hours.  I am far less
>> interested in having a graphical view editor than I am in being able to
>> write **GOOD** code that assembles things as I want.  If the result
>> happens to allow a graphical editor too, so much the better.
>>
>> Any interest?
>>
>> Bill
>>
>>
>> -----------------------------
>>
>> View
>>   MorphViev
>>   ImageView
>>   ContainerView
>>
>> ViewGadgetLayoutAbstract
>>   ScrollerGadgetLayout
>>   NullViewGadgetLayout
>>   FixedStretchFixedGadgetLayout
>>   ProportionalGadgetLayout
>>   PreferredExtentsGadgetLayout
>>   GridGadgetRowsLayout
>>   VerticalListLayout
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> This even (to get buttons on right with correct tab key navigation
> ordering...
>
> (UITheme builder
>  newColumn: {
>   UITheme builder newTabGroup: {
>    'First page' -> (UITheme builder newPanel
>     fillStyle: Color red;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill).
>    'Second page' -> (UITheme builder newPanel
>     fillStyle: Color green;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill)}.
>   (UITheme builder newRow: {
>    UITheme builder newOKButton.
>    UITheme builder newCancelButton})
>    listCentering: #bottomRight})
> extent: 200@300;
> openInWindow
>
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Gary Chambers" <[hidden email]>
> To: <[hidden email]>
> Sent: Monday, August 09, 2010 11:07 AM
> Subject: Re: [Pharo-project] Early days of an MVP framework
>
>
>> Any Morph can use a layoutPolicy.
>> Available are
>>    none (position based)
>>    Prorportional (frame/fractions/offsets)
>>    Table (overly complex too)
>>    Row (one of mine, quicker for simple rows)
>>    Stack (mine, overlay morphs on top of each other)
>>
>> TEasilyThemed provides some methods like...
>>
>>    newRow: {aMorph, anotherMorph}
>>    newColumn:
>>
>> Something like this works...
>>
>> (UITheme builder
>> newColumn: {
>>  UITheme builder newPanel
>>   fillStyle: Color red;
>>   hResizing: #spaceFill;
>>   vResizing: #spaceFill.
>>  UITheme builder newRow: {
>>   UITheme builder newOKButton.
>>   UITheme builder newCancelButton}})
>> extent: 200@300;
>> openInHand
>>
>> (can use openInWindow also)...
>>
>> Rather busy today, hope this helps in the meantime...
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Schwab,Wilhelm K" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Sunday, August 08, 2010 11:46 PM
>> Subject: [Pharo-project] Early days of an MVP framework
>>
>>
>>> Gary,
>>>
>>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt
>>> coaching), until I needed to repeat a "complex" GUI component and
>>> wanted/insisted on doing so with some reuse.  Seaside gives us
>>> components on web pages; we need them for GUI code too.  I tried turning
>>> my presenter-like structures into factories that would add morphs to a
>>> single shell, but it fell apart when it came time to set the framing
>>> values.  I was not particularly interested in fixing it, because if I
>>> could do that, I would simply build proper composite widgets using the
>>> fix.
>>>
>>> The problem appears to be in SystemWindow, which does some incredibly
>>> complicated things, all of which (correct me if I am wrong) would be
>>> unnecessary if only there were a good set of layout managers.  I can get
>>> very simple-minded about things, but it would make a whole lot more
>>> sense to me to create rows and columns of widgets, adding splitters
>>> between them until the whole things behaves as intended, rather than
>>> writing code (present only in a top-level shell) that tries to split
>>> things up into rows using its own judgment.  Not good.  I realize you
>>> did not create the situation, and have done wonders to make it work far
>>> better than when you found it.
>>>
>>> Some time ago, I built an emulated widget framework for Dolphin, which I
>>> needed because the combination of Dolphin's view resources and Windows
>>> itself was too slow for what I was trying to do.  That project included
>>> a somewhat strange set of layout classes, but the basics are present,
>>> and it is not Object Arts' IP.  I ported the classes to Pharo and did
>>> some work on stub View and Presenter classes that I had added to Pharo
>>> largely to passify my code that I was importing from Dolphin.  The
>>> layouts think in terms of emulated widgets, and I see no reason to
>>> change their minds: I might want to replicate the framework.  However,
>>> dynamic typing and a couple of extra methods allow them to work with
>>> just about anything.  My goals are modest.  Being able to compose rows
>>> and columns would do a lot for me.  Add splitters and the ability to fix
>>> the size of some items, and I could almost anything I would need.
>>>
>>> View class>>example
>>> | row column dot square out shell |
>>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32.
>>> square := ( Form squareOfSize:100 ) asFormOfDepth:32.
>>> out := Array writeStream.
>>>
>>> row := ContainerView row.
>>> 2 timesRepeat:[
>>> column := row addSubview:ContainerView column.
>>> 2 timesRepeat:[
>>> out nextPut:(
>>> column addSubview:ImageView new
>>> ).
>>> ].
>>> ].
>>>
>>> out contents with:{ dot copy. square copy. square copy. dot copy. }
>>> do:[ :view :form |
>>> view morph image:form.
>>> ].
>>>
>>> row rectangle:( 0@0 extent:400@400 ).
>>> row layout.
>>>
>>> shell := StandardWindow labelled:'Hello MVP'.
>>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself.
>>>
>>>
>>> The above code produces an array of dots and squares, as intended.  One
>>> quirk is that the grid does not resize as the shell resizes, a
>>> consequence of my not having hooked it up to resize events.  I might get
>>> some interesting meltdowns once I begin to do that =:0  I used your
>>> PanelMorph as the "view" associated with ContainerView.  What,
>>> ContainView isn't a view???  No.  The code is biased toward Morphic, but
>>> hopefully the same code should extend to wx, GTK, etc.  Dolphin's views
>>> have a handle instance variable to control the external resource; these
>>> views have an instance variable pointing to their morph.  Handling of
>>> sub views works pretty much as in Dolphin: any view/morph can have
>>> children, but adding them is "legal" only for composites.
>>>
>>> Most systems I have seen treat coordinates relative to the parent/owner,
>>> but not Morphic.  I remember seeing plans to make the change, but
>>> nothing after that.  The view instances provide a natural place to fix
>>> things, so I took the plunge.  If we switch to some other graphical
>>> realization, we can simply remove the the transformation.
>>>
>>> Are the existing splitters as strange as SystemWindow?  By that I mean,
>>> would it be reasonable to add them between other morphs and look for
>>> events from them, or will they have to be replaced?  I will eventually
>>> need splitters, but I could initially live without them if I can get
>>> reliable composition where I need it.
>>>
>>> There are very few view classes at present.  MorphView can wrap almost
>>> anything, so it might be better to create a rich set of presenters
>>> instead.  Dolphin's view resources are going to be interesting to
>>> replace. There are some complexities that I suspect are in deference to
>>> Windows, and some that might be avoidable.  For our purposes, it might
>>> be enough to use SIXX to serialize a bunch of message sends and gzip the
>>> results to save memory.  Another option might be to rely on class
>>> methods; having full closures won't hurt; they might allow sufficient
>>> hooking that resources in the Dolphin sense won't even be necessary.
>>> The desire for them quickly arises because views get realized in places
>>> know nothing about how the views should be configured; at least I think
>>> that is what happened to me after just a couple of hours.  I am far less
>>> interested in having a graphical view editor than I am in being able to
>>> write **GOOD** code that assembles things as I want.  If the result
>>> happens to allow a graphical editor too, so much the better.
>>>
>>> Any interest?
>>>
>>> Bill
>>>
>>>
>>> -----------------------------
>>>
>>> View
>>>   MorphViev
>>>   ImageView
>>>   ContainerView
>>>
>>> ViewGadgetLayoutAbstract
>>>   ScrollerGadgetLayout
>>>   NullViewGadgetLayout
>>>   FixedStretchFixedGadgetLayout
>>>   ProportionalGadgetLayout
>>>   PreferredExtentsGadgetLayout
>>>   GridGadgetRowsLayout
>>>   VerticalListLayout
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> This even (to get buttons on right with correct tab key navigation
> ordering...
>
> (UITheme builder
>  newColumn: {
>   UITheme builder newTabGroup: {
>    'First page' -> (UITheme builder newPanel
>     fillStyle: Color red;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill).
>    'Second page' -> (UITheme builder newPanel
>     fillStyle: Color green;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill)}.
>   (UITheme builder newRow: {
>    UITheme builder newOKButton.
>    UITheme builder newCancelButton})
>    listCentering: #bottomRight})
> extent: 200@300;
> openInWindow
>
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Gary Chambers" <[hidden email]>
> To: <[hidden email]>
> Sent: Monday, August 09, 2010 11:07 AM
> Subject: Re: [Pharo-project] Early days of an MVP framework
>
>
>> Any Morph can use a layoutPolicy.
>> Available are
>>    none (position based)
>>    Prorportional (frame/fractions/offsets)
>>    Table (overly complex too)
>>    Row (one of mine, quicker for simple rows)
>>    Stack (mine, overlay morphs on top of each other)
>>
>> TEasilyThemed provides some methods like...
>>
>>    newRow: {aMorph, anotherMorph}
>>    newColumn:
>>
>> Something like this works...
>>
>> (UITheme builder
>> newColumn: {
>>  UITheme builder newPanel
>>   fillStyle: Color red;
>>   hResizing: #spaceFill;
>>   vResizing: #spaceFill.
>>  UITheme builder newRow: {
>>   UITheme builder newOKButton.
>>   UITheme builder newCancelButton}})
>> extent: 200@300;
>> openInHand
>>
>> (can use openInWindow also)...
>>
>> Rather busy today, hope this helps in the meantime...
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Schwab,Wilhelm K" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Sunday, August 08, 2010 11:46 PM
>> Subject: [Pharo-project] Early days of an MVP framework
>>
>>
>>> Gary,
>>>
>>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt
>>> coaching), until I needed to repeat a "complex" GUI component and
>>> wanted/insisted on doing so with some reuse.  Seaside gives us
>>> components on web pages; we need them for GUI code too.  I tried turning
>>> my presenter-like structures into factories that would add morphs to a
>>> single shell, but it fell apart when it came time to set the framing
>>> values.  I was not particularly interested in fixing it, because if I
>>> could do that, I would simply build proper composite widgets using the
>>> fix.
>>>
>>> The problem appears to be in SystemWindow, which does some incredibly
>>> complicated things, all of which (correct me if I am wrong) would be
>>> unnecessary if only there were a good set of layout managers.  I can get
>>> very simple-minded about things, but it would make a whole lot more
>>> sense to me to create rows and columns of widgets, adding splitters
>>> between them until the whole things behaves as intended, rather than
>>> writing code (present only in a top-level shell) that tries to split
>>> things up into rows using its own judgment.  Not good.  I realize you
>>> did not create the situation, and have done wonders to make it work far
>>> better than when you found it.
>>>
>>> Some time ago, I built an emulated widget framework for Dolphin, which I
>>> needed because the combination of Dolphin's view resources and Windows
>>> itself was too slow for what I was trying to do.  That project included
>>> a somewhat strange set of layout classes, but the basics are present,
>>> and it is not Object Arts' IP.  I ported the classes to Pharo and did
>>> some work on stub View and Presenter classes that I had added to Pharo
>>> largely to passify my code that I was importing from Dolphin.  The
>>> layouts think in terms of emulated widgets, and I see no reason to
>>> change their minds: I might want to replicate the framework.  However,
>>> dynamic typing and a couple of extra methods allow them to work with
>>> just about anything.  My goals are modest.  Being able to compose rows
>>> and columns would do a lot for me.  Add splitters and the ability to fix
>>> the size of some items, and I could almost anything I would need.
>>>
>>> View class>>example
>>> | row column dot square out shell |
>>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32.
>>> square := ( Form squareOfSize:100 ) asFormOfDepth:32.
>>> out := Array writeStream.
>>>
>>> row := ContainerView row.
>>> 2 timesRepeat:[
>>> column := row addSubview:ContainerView column.
>>> 2 timesRepeat:[
>>> out nextPut:(
>>> column addSubview:ImageView new
>>> ).
>>> ].
>>> ].
>>>
>>> out contents with:{ dot copy. square copy. square copy. dot copy. }
>>> do:[ :view :form |
>>> view morph image:form.
>>> ].
>>>
>>> row rectangle:( 0@0 extent:400@400 ).
>>> row layout.
>>>
>>> shell := StandardWindow labelled:'Hello MVP'.
>>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself.
>>>
>>>
>>> The above code produces an array of dots and squares, as intended.  One
>>> quirk is that the grid does not resize as the shell resizes, a
>>> consequence of my not having hooked it up to resize events.  I might get
>>> some interesting meltdowns once I begin to do that =:0  I used your
>>> PanelMorph as the "view" associated with ContainerView.  What,
>>> ContainView isn't a view???  No.  The code is biased toward Morphic, but
>>> hopefully the same code should extend to wx, GTK, etc.  Dolphin's views
>>> have a handle instance variable to control the external resource; these
>>> views have an instance variable pointing to their morph.  Handling of
>>> sub views works pretty much as in Dolphin: any view/morph can have
>>> children, but adding them is "legal" only for composites.
>>>
>>> Most systems I have seen treat coordinates relative to the parent/owner,
>>> but not Morphic.  I remember seeing plans to make the change, but
>>> nothing after that.  The view instances provide a natural place to fix
>>> things, so I took the plunge.  If we switch to some other graphical
>>> realization, we can simply remove the the transformation.
>>>
>>> Are the existing splitters as strange as SystemWindow?  By that I mean,
>>> would it be reasonable to add them between other morphs and look for
>>> events from them, or will they have to be replaced?  I will eventually
>>> need splitters, but I could initially live without them if I can get
>>> reliable composition where I need it.
>>>
>>> There are very few view classes at present.  MorphView can wrap almost
>>> anything, so it might be better to create a rich set of presenters
>>> instead.  Dolphin's view resources are going to be interesting to
>>> replace. There are some complexities that I suspect are in deference to
>>> Windows, and some that might be avoidable.  For our purposes, it might
>>> be enough to use SIXX to serialize a bunch of message sends and gzip the
>>> results to save memory.  Another option might be to rely on class
>>> methods; having full closures won't hurt; they might allow sufficient
>>> hooking that resources in the Dolphin sense won't even be necessary.
>>> The desire for them quickly arises because views get realized in places
>>> know nothing about how the views should be configured; at least I think
>>> that is what happened to me after just a couple of hours.  I am far less
>>> interested in having a graphical view editor than I am in being able to
>>> write **GOOD** code that assembles things as I want.  If the result
>>> happens to allow a graphical editor too, so much the better.
>>>
>>> Any interest?
>>>
>>> Bill
>>>
>>>
>>> -----------------------------
>>>
>>> View
>>>   MorphViev
>>>   ImageView
>>>   ContainerView
>>>
>>> ViewGadgetLayoutAbstract
>>>   ScrollerGadgetLayout
>>>   NullViewGadgetLayout
>>>   FixedStretchFixedGadgetLayout
>>>   ProportionalGadgetLayout
>>>   PreferredExtentsGadgetLayout
>>>   GridGadgetRowsLayout
>>>   VerticalListLayout
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> This even (to get buttons on right with correct tab key navigation
> ordering...
>
> (UITheme builder
>  newColumn: {
>   UITheme builder newTabGroup: {
>    'First page' -> (UITheme builder newPanel
>     fillStyle: Color red;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill).
>    'Second page' -> (UITheme builder newPanel
>     fillStyle: Color green;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill)}.
>   (UITheme builder newRow: {
>    UITheme builder newOKButton.
>    UITheme builder newCancelButton})
>    listCentering: #bottomRight})
> extent: 200@300;
> openInWindow
>
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Gary Chambers" <[hidden email]>
> To: <[hidden email]>
> Sent: Monday, August 09, 2010 11:07 AM
> Subject: Re: [Pharo-project] Early days of an MVP framework
>
>
>> Any Morph can use a layoutPolicy.
>> Available are
>>    none (position based)
>>    Prorportional (frame/fractions/offsets)
>>    Table (overly complex too)
>>    Row (one of mine, quicker for simple rows)
>>    Stack (mine, overlay morphs on top of each other)
>>
>> TEasilyThemed provides some methods like...
>>
>>    newRow: {aMorph, anotherMorph}
>>    newColumn:
>>
>> Something like this works...
>>
>> (UITheme builder
>> newColumn: {
>>  UITheme builder newPanel
>>   fillStyle: Color red;
>>   hResizing: #spaceFill;
>>   vResizing: #spaceFill.
>>  UITheme builder newRow: {
>>   UITheme builder newOKButton.
>>   UITheme builder newCancelButton}})
>> extent: 200@300;
>> openInHand
>>
>> (can use openInWindow also)...
>>
>> Rather busy today, hope this helps in the meantime...
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Schwab,Wilhelm K" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Sunday, August 08, 2010 11:46 PM
>> Subject: [Pharo-project] Early days of an MVP framework
>>
>>
>>> Gary,
>>>
>>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt
>>> coaching), until I needed to repeat a "complex" GUI component and
>>> wanted/insisted on doing so with some reuse.  Seaside gives us
>>> components on web pages; we need them for GUI code too.  I tried
>>> turning my presenter-like structures into factories that would add
>>> morphs to a single shell, but it fell apart when it came time to set
>>> the framing values.  I was not particularly interested in fixing it,
>>> because if I could do that, I would simply build proper composite
>>> widgets using the fix.
>>>
>>> The problem appears to be in SystemWindow, which does some
>>> incredibly complicated things, all of which (correct me if I am
>>> wrong) would be unnecessary if only there were a good set of layout
>>> managers.  I can get very simple-minded about things, but it would
>>> make a whole lot more sense to me to create rows and columns of
>>> widgets, adding splitters between them until the whole things
>>> behaves as intended, rather than writing code (present only in a
>>> top-level shell) that tries to split things up into rows using its
>>> own judgment.  Not good.  I realize you did not create the
>>> situation, and have done wonders to make it work far better than when you found it.
>>>
>>> Some time ago, I built an emulated widget framework for Dolphin,
>>> which I needed because the combination of Dolphin's view resources
>>> and Windows itself was too slow for what I was trying to do.  That
>>> project included a somewhat strange set of layout classes, but the
>>> basics are present, and it is not Object Arts' IP.  I ported the
>>> classes to Pharo and did some work on stub View and Presenter
>>> classes that I had added to Pharo largely to passify my code that I
>>> was importing from Dolphin.  The layouts think in terms of emulated
>>> widgets, and I see no reason to change their minds: I might want to
>>> replicate the framework.  However, dynamic typing and a couple of
>>> extra methods allow them to work with just about anything.  My goals
>>> are modest.  Being able to compose rows and columns would do a lot
>>> for me.  Add splitters and the ability to fix the size of some items, and I could almost anything I would need.
>>>
>>> View class>>example
>>> | row column dot square out shell |
>>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32.
>>> square := ( Form squareOfSize:100 ) asFormOfDepth:32.
>>> out := Array writeStream.
>>>
>>> row := ContainerView row.
>>> 2 timesRepeat:[
>>> column := row addSubview:ContainerView column.
>>> 2 timesRepeat:[
>>> out nextPut:(
>>> column addSubview:ImageView new
>>> ).
>>> ].
>>> ].
>>>
>>> out contents with:{ dot copy. square copy. square copy. dot copy. }
>>> do:[ :view :form | view morph image:form.
>>> ].
>>>
>>> row rectangle:( 0@0 extent:400@400 ).
>>> row layout.
>>>
>>> shell := StandardWindow labelled:'Hello MVP'.
>>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself.
>>>
>>>
>>> The above code produces an array of dots and squares, as intended.  
>>> One quirk is that the grid does not resize as the shell resizes, a
>>> consequence of my not having hooked it up to resize events.  I might
>>> get some interesting meltdowns once I begin to do that =:0  I used
>>> your PanelMorph as the "view" associated with ContainerView.  What,
>>> ContainView isn't a view???  No.  The code is biased toward Morphic,
>>> but hopefully the same code should extend to wx, GTK, etc.  
>>> Dolphin's views have a handle instance variable to control the
>>> external resource; these views have an instance variable pointing to
>>> their morph.  Handling of sub views works pretty much as in Dolphin:
>>> any view/morph can have children, but adding them is "legal" only for composites.
>>>
>>> Most systems I have seen treat coordinates relative to the
>>> parent/owner, but not Morphic.  I remember seeing plans to make the
>>> change, but nothing after that.  The view instances provide a
>>> natural place to fix things, so I took the plunge.  If we switch to
>>> some other graphical realization, we can simply remove the the transformation.
>>>
>>> Are the existing splitters as strange as SystemWindow?  By that I
>>> mean, would it be reasonable to add them between other morphs and
>>> look for events from them, or will they have to be replaced?  I will
>>> eventually need splitters, but I could initially live without them
>>> if I can get reliable composition where I need it.
>>>
>>> There are very few view classes at present.  MorphView can wrap
>>> almost anything, so it might be better to create a rich set of
>>> presenters instead.  Dolphin's view resources are going to be
>>> interesting to replace. There are some complexities that I suspect
>>> are in deference to Windows, and some that might be avoidable.  For
>>> our purposes, it might be enough to use SIXX to serialize a bunch of
>>> message sends and gzip the results to save memory.  Another option
>>> might be to rely on class methods; having full closures won't hurt;
>>> they might allow sufficient hooking that resources in the Dolphin sense won't even be necessary.
>>> The desire for them quickly arises because views get realized in
>>> places know nothing about how the views should be configured; at
>>> least I think that is what happened to me after just a couple of
>>> hours.  I am far less interested in having a graphical view editor
>>> than I am in being able to write **GOOD** code that assembles things
>>> as I want.  If the result happens to allow a graphical editor too, so much the better.
>>>
>>> Any interest?
>>>
>>> Bill
>>>
>>>
>>> -----------------------------
>>>
>>> View
>>>   MorphViev
>>>   ImageView
>>>   ContainerView
>>>
>>> ViewGadgetLayoutAbstract
>>>   ScrollerGadgetLayout
>>>   NullViewGadgetLayout
>>>   FixedStretchFixedGadgetLayout
>>>   ProportionalGadgetLayout
>>>   PreferredExtentsGadgetLayout
>>>   GridGadgetRowsLayout
>>>   VerticalListLayout
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> This even (to get buttons on right with correct tab key navigation
> ordering...
>
> (UITheme builder
>  newColumn: {
>   UITheme builder newTabGroup: {
>    'First page' -> (UITheme builder newPanel
>     fillStyle: Color red;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill).
>    'Second page' -> (UITheme builder newPanel
>     fillStyle: Color green;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill)}.
>   (UITheme builder newRow: {
>    UITheme builder newOKButton.
>    UITheme builder newCancelButton})
>    listCentering: #bottomRight})
> extent: 200@300;
> openInWindow
>
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Gary Chambers" <[hidden email]>
> To: <[hidden email]>
> Sent: Monday, August 09, 2010 11:07 AM
> Subject: Re: [Pharo-project] Early days of an MVP framework
>
>
>> Any Morph can use a layoutPolicy.
>> Available are
>>    none (position based)
>>    Prorportional (frame/fractions/offsets)
>>    Table (overly complex too)
>>    Row (one of mine, quicker for simple rows)
>>    Stack (mine, overlay morphs on top of each other)
>>
>> TEasilyThemed provides some methods like...
>>
>>    newRow: {aMorph, anotherMorph}
>>    newColumn:
>>
>> Something like this works...
>>
>> (UITheme builder
>> newColumn: {
>>  UITheme builder newPanel
>>   fillStyle: Color red;
>>   hResizing: #spaceFill;
>>   vResizing: #spaceFill.
>>  UITheme builder newRow: {
>>   UITheme builder newOKButton.
>>   UITheme builder newCancelButton}})
>> extent: 200@300;
>> openInHand
>>
>> (can use openInWindow also)...
>>
>> Rather busy today, hope this helps in the meantime...
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Schwab,Wilhelm K" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Sunday, August 08, 2010 11:46 PM
>> Subject: [Pharo-project] Early days of an MVP framework
>>
>>
>>> Gary,
>>>
>>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt
>>> coaching), until I needed to repeat a "complex" GUI component and
>>> wanted/insisted on doing so with some reuse.  Seaside gives us
>>> components on web pages; we need them for GUI code too.  I tried
>>> turning my presenter-like structures into factories that would add
>>> morphs to a single shell, but it fell apart when it came time to set
>>> the framing values.  I was not particularly interested in fixing it,
>>> because if I could do that, I would simply build proper composite
>>> widgets using the fix.
>>>
>>> The problem appears to be in SystemWindow, which does some
>>> incredibly complicated things, all of which (correct me if I am
>>> wrong) would be unnecessary if only there were a good set of layout
>>> managers.  I can get very simple-minded about things, but it would
>>> make a whole lot more sense to me to create rows and columns of
>>> widgets, adding splitters between them until the whole things
>>> behaves as intended, rather than writing code (present only in a
>>> top-level shell) that tries to split things up into rows using its
>>> own judgment.  Not good.  I realize you did not create the
>>> situation, and have done wonders to make it work far better than when you found it.
>>>
>>> Some time ago, I built an emulated widget framework for Dolphin,
>>> which I needed because the combination of Dolphin's view resources
>>> and Windows itself was too slow for what I was trying to do.  That
>>> project included a somewhat strange set of layout classes, but the
>>> basics are present, and it is not Object Arts' IP.  I ported the
>>> classes to Pharo and did some work on stub View and Presenter
>>> classes that I had added to Pharo largely to passify my code that I
>>> was importing from Dolphin.  The layouts think in terms of emulated
>>> widgets, and I see no reason to change their minds: I might want to
>>> replicate the framework.  However, dynamic typing and a couple of
>>> extra methods allow them to work with just about anything.  My goals
>>> are modest.  Being able to compose rows and columns would do a lot
>>> for me.  Add splitters and the ability to fix the size of some items, and I could almost anything I would need.
>>>
>>> View class>>example
>>> | row column dot square out shell |
>>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32.
>>> square := ( Form squareOfSize:100 ) asFormOfDepth:32.
>>> out := Array writeStream.
>>>
>>> row := ContainerView row.
>>> 2 timesRepeat:[
>>> column := row addSubview:ContainerView column.
>>> 2 timesRepeat:[
>>> out nextPut:(
>>> column addSubview:ImageView new
>>> ).
>>> ].
>>> ].
>>>
>>> out contents with:{ dot copy. square copy. square copy. dot copy. }
>>> do:[ :view :form | view morph image:form.
>>> ].
>>>
>>> row rectangle:( 0@0 extent:400@400 ).
>>> row layout.
>>>
>>> shell := StandardWindow labelled:'Hello MVP'.
>>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself.
>>>
>>>
>>> The above code produces an array of dots and squares, as intended.
>>> One quirk is that the grid does not resize as the shell resizes, a
>>> consequence of my not having hooked it up to resize events.  I might
>>> get some interesting meltdowns once I begin to do that =:0  I used
>>> your PanelMorph as the "view" associated with ContainerView.  What,
>>> ContainView isn't a view???  No.  The code is biased toward Morphic,
>>> but hopefully the same code should extend to wx, GTK, etc.
>>> Dolphin's views have a handle instance variable to control the
>>> external resource; these views have an instance variable pointing to
>>> their morph.  Handling of sub views works pretty much as in Dolphin:
>>> any view/morph can have children, but adding them is "legal" only for composites.
>>>
>>> Most systems I have seen treat coordinates relative to the
>>> parent/owner, but not Morphic.  I remember seeing plans to make the
>>> change, but nothing after that.  The view instances provide a
>>> natural place to fix things, so I took the plunge.  If we switch to
>>> some other graphical realization, we can simply remove the the transformation.
>>>
>>> Are the existing splitters as strange as SystemWindow?  By that I
>>> mean, would it be reasonable to add them between other morphs and
>>> look for events from them, or will they have to be replaced?  I will
>>> eventually need splitters, but I could initially live without them
>>> if I can get reliable composition where I need it.
>>>
>>> There are very few view classes at present.  MorphView can wrap
>>> almost anything, so it might be better to create a rich set of
>>> presenters instead.  Dolphin's view resources are going to be
>>> interesting to replace. There are some complexities that I suspect
>>> are in deference to Windows, and some that might be avoidable.  For
>>> our purposes, it might be enough to use SIXX to serialize a bunch of
>>> message sends and gzip the results to save memory.  Another option
>>> might be to rely on class methods; having full closures won't hurt;
>>> they might allow sufficient hooking that resources in the Dolphin sense won't even be necessary.
>>> The desire for them quickly arises because views get realized in
>>> places know nothing about how the views should be configured; at
>>> least I think that is what happened to me after just a couple of
>>> hours.  I am far less interested in having a graphical view editor
>>> than I am in being able to write **GOOD** code that assembles things
>>> as I want.  If the result happens to allow a graphical editor too, so much the better.
>>>
>>> Any interest?
>>>
>>> Bill
>>>
>>>
>>> -----------------------------
>>>
>>> View
>>>   MorphViev
>>>   ImageView
>>>   ContainerView
>>>
>>> ViewGadgetLayoutAbstract
>>>   ScrollerGadgetLayout
>>>   NullViewGadgetLayout
>>>   FixedStretchFixedGadgetLayout
>>>   ProportionalGadgetLayout
>>>   PreferredExtentsGadgetLayout
>>>   GridGadgetRowsLayout
>>>   VerticalListLayout
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> This even (to get buttons on right with correct tab key navigation
> ordering...
>
> (UITheme builder
>  newColumn: {
>   UITheme builder newTabGroup: {
>    'First page' -> (UITheme builder newPanel
>     fillStyle: Color red;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill).
>    'Second page' -> (UITheme builder newPanel
>     fillStyle: Color green;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill)}.
>   (UITheme builder newRow: {
>    UITheme builder newOKButton.
>    UITheme builder newCancelButton})
>    listCentering: #bottomRight})
> extent: 200@300;
> openInWindow
>
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Gary Chambers" <[hidden email]>
> To: <[hidden email]>
> Sent: Monday, August 09, 2010 11:07 AM
> Subject: Re: [Pharo-project] Early days of an MVP framework
>
>
>> Any Morph can use a layoutPolicy.
>> Available are
>>    none (position based)
>>    Prorportional (frame/fractions/offsets)
>>    Table (overly complex too)
>>    Row (one of mine, quicker for simple rows)
>>    Stack (mine, overlay morphs on top of each other)
>>
>> TEasilyThemed provides some methods like...
>>
>>    newRow: {aMorph, anotherMorph}
>>    newColumn:
>>
>> Something like this works...
>>
>> (UITheme builder
>> newColumn: {
>>  UITheme builder newPanel
>>   fillStyle: Color red;
>>   hResizing: #spaceFill;
>>   vResizing: #spaceFill.
>>  UITheme builder newRow: {
>>   UITheme builder newOKButton.
>>   UITheme builder newCancelButton}})
>> extent: 200@300;
>> openInHand
>>
>> (can use openInWindow also)...
>>
>> Rather busy today, hope this helps in the meantime...
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Schwab,Wilhelm K" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Sunday, August 08, 2010 11:46 PM
>> Subject: [Pharo-project] Early days of an MVP framework
>>
>>
>>> Gary,
>>>
>>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt
>>> coaching), until I needed to repeat a "complex" GUI component and
>>> wanted/insisted on doing so with some reuse.  Seaside gives us
>>> components on web pages; we need them for GUI code too.  I tried
>>> turning my presenter-like structures into factories that would add
>>> morphs to a single shell, but it fell apart when it came time to set
>>> the framing values.  I was not particularly interested in fixing it,
>>> because if I could do that, I would simply build proper composite
>>> widgets using the fix.
>>>
>>> The problem appears to be in SystemWindow, which does some
>>> incredibly complicated things, all of which (correct me if I am
>>> wrong) would be unnecessary if only there were a good set of layout
>>> managers.  I can get very simple-minded about things, but it would
>>> make a whole lot more sense to me to create rows and columns of
>>> widgets, adding splitters between them until the whole things
>>> behaves as intended, rather than writing code (present only in a
>>> top-level shell) that tries to split things up into rows using its
>>> own judgment.  Not good.  I realize you did not create the
>>> situation, and have done wonders to make it work far better than when you found it.
>>>
>>> Some time ago, I built an emulated widget framework for Dolphin,
>>> which I needed because the combination of Dolphin's view resources
>>> and Windows itself was too slow for what I was trying to do.  That
>>> project included a somewhat strange set of layout classes, but the
>>> basics are present, and it is not Object Arts' IP.  I ported the
>>> classes to Pharo and did some work on stub View and Presenter
>>> classes that I had added to Pharo largely to passify my code that I
>>> was importing from Dolphin.  The layouts think in terms of emulated
>>> widgets, and I see no reason to change their minds: I might want to
>>> replicate the framework.  However, dynamic typing and a couple of
>>> extra methods allow them to work with just about anything.  My goals
>>> are modest.  Being able to compose rows and columns would do a lot
>>> for me.  Add splitters and the ability to fix the size of some items, and I could almost anything I would need.
>>>
>>> View class>>example
>>> | row column dot square out shell |
>>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32.
>>> square := ( Form squareOfSize:100 ) asFormOfDepth:32.
>>> out := Array writeStream.
>>>
>>> row := ContainerView row.
>>> 2 timesRepeat:[
>>> column := row addSubview:ContainerView column.
>>> 2 timesRepeat:[
>>> out nextPut:(
>>> column addSubview:ImageView new
>>> ).
>>> ].
>>> ].
>>>
>>> out contents with:{ dot copy. square copy. square copy. dot copy. }
>>> do:[ :view :form | view morph image:form.
>>> ].
>>>
>>> row rectangle:( 0@0 extent:400@400 ).
>>> row layout.
>>>
>>> shell := StandardWindow labelled:'Hello MVP'.
>>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself.
>>>
>>>
>>> The above code produces an array of dots and squares, as intended.
>>> One quirk is that the grid does not resize as the shell resizes, a
>>> consequence of my not having hooked it up to resize events.  I might
>>> get some interesting meltdowns once I begin to do that =:0  I used
>>> your PanelMorph as the "view" associated with ContainerView.  What,
>>> ContainView isn't a view???  No.  The code is biased toward Morphic,
>>> but hopefully the same code should extend to wx, GTK, etc.
>>> Dolphin's views have a handle instance variable to control the
>>> external resource; these views have an instance variable pointing to
>>> their morph.  Handling of sub views works pretty much as in Dolphin:
>>> any view/morph can have children, but adding them is "legal" only for composites.
>>>
>>> Most systems I have seen treat coordinates relative to the
>>> parent/owner, but not Morphic.  I remember seeing plans to make the
>>> change, but nothing after that.  The view instances provide a
>>> natural place to fix things, so I took the plunge.  If we switch to
>>> some other graphical realization, we can simply remove the the transformation.
>>>
>>> Are the existing splitters as strange as SystemWindow?  By that I
>>> mean, would it be reasonable to add them between other morphs and
>>> look for events from them, or will they have to be replaced?  I will
>>> eventually need splitters, but I could initially live without them
>>> if I can get reliable composition where I need it.
>>>
>>> There are very few view classes at present.  MorphView can wrap
>>> almost anything, so it might be better to create a rich set of
>>> presenters instead.  Dolphin's view resources are going to be
>>> interesting to replace. There are some complexities that I suspect
>>> are in deference to Windows, and some that might be avoidable.  For
>>> our purposes, it might be enough to use SIXX to serialize a bunch of
>>> message sends and gzip the results to save memory.  Another option
>>> might be to rely on class methods; having full closures won't hurt;
>>> they might allow sufficient hooking that resources in the Dolphin sense won't even be necessary.
>>> The desire for them quickly arises because views get realized in
>>> places know nothing about how the views should be configured; at
>>> least I think that is what happened to me after just a couple of
>>> hours.  I am far less interested in having a graphical view editor
>>> than I am in being able to write **GOOD** code that assembles things
>>> as I want.  If the result happens to allow a graphical editor too, so much the better.
>>>
>>> Any interest?
>>>
>>> Bill
>>>
>>>
>>> -----------------------------
>>>
>>> View
>>>   MorphViev
>>>   ImageView
>>>   ContainerView
>>>
>>> ViewGadgetLayoutAbstract
>>>   ScrollerGadgetLayout
>>>   NullViewGadgetLayout
>>>   FixedStretchFixedGadgetLayout
>>>   ProportionalGadgetLayout
>>>   PreferredExtentsGadgetLayout
>>>   GridGadgetRowsLayout
>>>   VerticalListLayout
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Gary,
>
> Thanks for the examples.  One thing is driving me nuts: in the past, I
> thought that creating a new row or column made a morph but did not add it
> to the morph being created.  Might I have added them redundantly?  Does
> re-adding a child have no effect or somehow replace it?  Is this a
> morphi/Polymorph beginner trap?  Be honest, I can take it :)
>
> Bill
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Gary
> Chambers
> Sent: Monday, August 09, 2010 5:45 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] Early days of an MVP framework
>
> And with a stack layout...
>
> (UITheme builder
>  newColumn: {
>   UITheme builder newTabGroup: {
>    'First page' -> ((UITheme builder newStack: {
>      (UITheme builder
>       newAlphaImage: UITheme current warningIcon
>       help: nil)
>       alpha: 0.5.
>      CircleMorph new
>       hResizing: #spaceFill;
>       vResizing: #spaceFill})
>     fillStyle: Color red;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill).
>    'Second page' -> (UITheme builder newPanel
>     fillStyle: Color green;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill)}.
>   (UITheme builder newRow: {
>    UITheme builder newOKButton.
>    UITheme builder newCancelButton})
>    listCentering: #bottomRight})
> extent: 200@300;
> openInWindow
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Gary Chambers" <[hidden email]>
> To: <[hidden email]>
> Sent: Monday, August 09, 2010 11:30 AM
> Subject: Re: [Pharo-project] Early days of an MVP framework
>
>
>> This even (to get buttons on right with correct tab key navigation
>> ordering...
>>
>> (UITheme builder
>>  newColumn: {
>>   UITheme builder newTabGroup: {
>>    'First page' -> (UITheme builder newPanel
>>     fillStyle: Color red;
>>     hResizing: #spaceFill;
>>     vResizing: #spaceFill).
>>    'Second page' -> (UITheme builder newPanel
>>     fillStyle: Color green;
>>     hResizing: #spaceFill;
>>     vResizing: #spaceFill)}.
>>   (UITheme builder newRow: {
>>    UITheme builder newOKButton.
>>    UITheme builder newCancelButton})
>>    listCentering: #bottomRight})
>> extent: 200@300;
>> openInWindow
>>
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Gary Chambers" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Monday, August 09, 2010 11:07 AM
>> Subject: Re: [Pharo-project] Early days of an MVP framework
>>
>>
>>> Any Morph can use a layoutPolicy.
>>> Available are
>>>    none (position based)
>>>    Prorportional (frame/fractions/offsets)
>>>    Table (overly complex too)
>>>    Row (one of mine, quicker for simple rows)
>>>    Stack (mine, overlay morphs on top of each other)
>>>
>>> TEasilyThemed provides some methods like...
>>>
>>>    newRow: {aMorph, anotherMorph}
>>>    newColumn:
>>>
>>> Something like this works...
>>>
>>> (UITheme builder
>>> newColumn: {
>>>  UITheme builder newPanel
>>>   fillStyle: Color red;
>>>   hResizing: #spaceFill;
>>>   vResizing: #spaceFill.
>>>  UITheme builder newRow: {
>>>   UITheme builder newOKButton.
>>>   UITheme builder newCancelButton}})
>>> extent: 200@300;
>>> openInHand
>>>
>>> (can use openInWindow also)...
>>>
>>> Rather busy today, hope this helps in the meantime...
>>>
>>> Regards, Gary
>>>
>>> ----- Original Message -----
>>> From: "Schwab,Wilhelm K" <[hidden email]>
>>> To: <[hidden email]>
>>> Sent: Sunday, August 08, 2010 11:46 PM
>>> Subject: [Pharo-project] Early days of an MVP framework
>>>
>>>
>>>> Gary,
>>>>
>>>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt
>>>> coaching), until I needed to repeat a "complex" GUI component and
>>>> wanted/insisted on doing so with some reuse.  Seaside gives us
>>>> components on web pages; we need them for GUI code too.  I tried
>>>> turning
>>>> my presenter-like structures into factories that would add morphs to a
>>>> single shell, but it fell apart when it came time to set the framing
>>>> values.  I was not particularly interested in fixing it, because if I
>>>> could do that, I would simply build proper composite widgets using the
>>>> fix.
>>>>
>>>> The problem appears to be in SystemWindow, which does some incredibly
>>>> complicated things, all of which (correct me if I am wrong) would be
>>>> unnecessary if only there were a good set of layout managers.  I can
>>>> get
>>>> very simple-minded about things, but it would make a whole lot more
>>>> sense to me to create rows and columns of widgets, adding splitters
>>>> between them until the whole things behaves as intended, rather than
>>>> writing code (present only in a top-level shell) that tries to split
>>>> things up into rows using its own judgment.  Not good.  I realize you
>>>> did not create the situation, and have done wonders to make it work far
>>>> better than when you found it.
>>>>
>>>> Some time ago, I built an emulated widget framework for Dolphin, which
>>>> I
>>>> needed because the combination of Dolphin's view resources and Windows
>>>> itself was too slow for what I was trying to do.  That project included
>>>> a somewhat strange set of layout classes, but the basics are present,
>>>> and it is not Object Arts' IP.  I ported the classes to Pharo and did
>>>> some work on stub View and Presenter classes that I had added to Pharo
>>>> largely to passify my code that I was importing from Dolphin.  The
>>>> layouts think in terms of emulated widgets, and I see no reason to
>>>> change their minds: I might want to replicate the framework.  However,
>>>> dynamic typing and a couple of extra methods allow them to work with
>>>> just about anything.  My goals are modest.  Being able to compose rows
>>>> and columns would do a lot for me.  Add splitters and the ability to
>>>> fix
>>>> the size of some items, and I could almost anything I would need.
>>>>
>>>> View class>>example
>>>> | row column dot square out shell |
>>>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32.
>>>> square := ( Form squareOfSize:100 ) asFormOfDepth:32.
>>>> out := Array writeStream.
>>>>
>>>> row := ContainerView row.
>>>> 2 timesRepeat:[
>>>> column := row addSubview:ContainerView column.
>>>> 2 timesRepeat:[
>>>> out nextPut:(
>>>> column addSubview:ImageView new
>>>> ).
>>>> ].
>>>> ].
>>>>
>>>> out contents with:{ dot copy. square copy. square copy. dot copy. }
>>>> do:[ :view :form |
>>>> view morph image:form.
>>>> ].
>>>>
>>>> row rectangle:( 0@0 extent:400@400 ).
>>>> row layout.
>>>>
>>>> shell := StandardWindow labelled:'Hello MVP'.
>>>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself.
>>>>
>>>>
>>>> The above code produces an array of dots and squares, as intended.  One
>>>> quirk is that the grid does not resize as the shell resizes, a
>>>> consequence of my not having hooked it up to resize events.  I might
>>>> get
>>>> some interesting meltdowns once I begin to do that =:0  I used your
>>>> PanelMorph as the "view" associated with ContainerView.  What,
>>>> ContainView isn't a view???  No.  The code is biased toward Morphic,
>>>> but
>>>> hopefully the same code should extend to wx, GTK, etc.  Dolphin's views
>>>> have a handle instance variable to control the external resource; these
>>>> views have an instance variable pointing to their morph.  Handling of
>>>> sub views works pretty much as in Dolphin: any view/morph can have
>>>> children, but adding them is "legal" only for composites.
>>>>
>>>> Most systems I have seen treat coordinates relative to the
>>>> parent/owner,
>>>> but not Morphic.  I remember seeing plans to make the change, but
>>>> nothing after that.  The view instances provide a natural place to fix
>>>> things, so I took the plunge.  If we switch to some other graphical
>>>> realization, we can simply remove the the transformation.
>>>>
>>>> Are the existing splitters as strange as SystemWindow?  By that I mean,
>>>> would it be reasonable to add them between other morphs and look for
>>>> events from them, or will they have to be replaced?  I will eventually
>>>> need splitters, but I could initially live without them if I can get
>>>> reliable composition where I need it.
>>>>
>>>> There are very few view classes at present.  MorphView can wrap almost
>>>> anything, so it might be better to create a rich set of presenters
>>>> instead.  Dolphin's view resources are going to be interesting to
>>>> replace. There are some complexities that I suspect are in deference to
>>>> Windows, and some that might be avoidable.  For our purposes, it might
>>>> be enough to use SIXX to serialize a bunch of message sends and gzip
>>>> the
>>>> results to save memory.  Another option might be to rely on class
>>>> methods; having full closures won't hurt; they might allow sufficient
>>>> hooking that resources in the Dolphin sense won't even be necessary.
>>>> The desire for them quickly arises because views get realized in places
>>>> know nothing about how the views should be configured; at least I think
>>>> that is what happened to me after just a couple of hours.  I am far
>>>> less
>>>> interested in having a graphical view editor than I am in being able to
>>>> write **GOOD** code that assembles things as I want.  If the result
>>>> happens to allow a graphical editor too, so much the better.
>>>>
>>>> Any interest?
>>>>
>>>> Bill
>>>>
>>>>
>>>> -----------------------------
>>>>
>>>> View
>>>>   MorphViev
>>>>   ImageView
>>>>   ContainerView
>>>>
>>>> ViewGadgetLayoutAbstract
>>>>   ScrollerGadgetLayout
>>>>   NullViewGadgetLayout
>>>>   FixedStretchFixedGadgetLayout
>>>>   ProportionalGadgetLayout
>>>>   PreferredExtentsGadgetLayout
>>>>   GridGadgetRowsLayout
>>>>   VerticalListLayout
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> Gary,
>
> Thanks for the examples.  One thing is driving me nuts: in the past, I
> thought that creating a new row or column made a morph but did not add it
> to the morph being created.  Might I have added them redundantly?  Does
> re-adding a child have no effect or somehow replace it?  Is this a
> morphi/Polymorph beginner trap?  Be honest, I can take it :)
>
> Bill
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Gary
> Chambers
> Sent: Monday, August 09, 2010 5:45 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] Early days of an MVP framework
>
> And with a stack layout...
>
> (UITheme builder
>  newColumn: {
>   UITheme builder newTabGroup: {
>    'First page' -> ((UITheme builder newStack: {
>      (UITheme builder
>       newAlphaImage: UITheme current warningIcon
>       help: nil)
>       alpha: 0.5.
>      CircleMorph new
>       hResizing: #spaceFill;
>       vResizing: #spaceFill})
>     fillStyle: Color red;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill).
>    'Second page' -> (UITheme builder newPanel
>     fillStyle: Color green;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill)}.
>   (UITheme builder newRow: {
>    UITheme builder newOKButton.
>    UITheme builder newCancelButton})
>    listCentering: #bottomRight})
> extent: 200@300;
> openInWindow
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Gary Chambers" <[hidden email]>
> To: <[hidden email]>
> Sent: Monday, August 09, 2010 11:30 AM
> Subject: Re: [Pharo-project] Early days of an MVP framework
>
>
>> This even (to get buttons on right with correct tab key navigation
>> ordering...
>>
>> (UITheme builder
>>  newColumn: {
>>   UITheme builder newTabGroup: {
>>    'First page' -> (UITheme builder newPanel
>>     fillStyle: Color red;
>>     hResizing: #spaceFill;
>>     vResizing: #spaceFill).
>>    'Second page' -> (UITheme builder newPanel
>>     fillStyle: Color green;
>>     hResizing: #spaceFill;
>>     vResizing: #spaceFill)}.
>>   (UITheme builder newRow: {
>>    UITheme builder newOKButton.
>>    UITheme builder newCancelButton})
>>    listCentering: #bottomRight})
>> extent: 200@300;
>> openInWindow
>>
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Gary Chambers" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Monday, August 09, 2010 11:07 AM
>> Subject: Re: [Pharo-project] Early days of an MVP framework
>>
>>
>>> Any Morph can use a layoutPolicy.
>>> Available are
>>>    none (position based)
>>>    Prorportional (frame/fractions/offsets)
>>>    Table (overly complex too)
>>>    Row (one of mine, quicker for simple rows)
>>>    Stack (mine, overlay morphs on top of each other)
>>>
>>> TEasilyThemed provides some methods like...
>>>
>>>    newRow: {aMorph, anotherMorph}
>>>    newColumn:
>>>
>>> Something like this works...
>>>
>>> (UITheme builder
>>> newColumn: {
>>>  UITheme builder newPanel
>>>   fillStyle: Color red;
>>>   hResizing: #spaceFill;
>>>   vResizing: #spaceFill.
>>>  UITheme builder newRow: {
>>>   UITheme builder newOKButton.
>>>   UITheme builder newCancelButton}})
>>> extent: 200@300;
>>> openInHand
>>>
>>> (can use openInWindow also)...
>>>
>>> Rather busy today, hope this helps in the meantime...
>>>
>>> Regards, Gary
>>>
>>> ----- Original Message -----
>>> From: "Schwab,Wilhelm K" <[hidden email]>
>>> To: <[hidden email]>
>>> Sent: Sunday, August 08, 2010 11:46 PM
>>> Subject: [Pharo-project] Early days of an MVP framework
>>>
>>>
>>>> Gary,
>>>>
>>>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt
>>>> coaching), until I needed to repeat a "complex" GUI component and
>>>> wanted/insisted on doing so with some reuse.  Seaside gives us
>>>> components on web pages; we need them for GUI code too.  I tried
>>>> turning
>>>> my presenter-like structures into factories that would add morphs to a
>>>> single shell, but it fell apart when it came time to set the framing
>>>> values.  I was not particularly interested in fixing it, because if I
>>>> could do that, I would simply build proper composite widgets using the
>>>> fix.
>>>>
>>>> The problem appears to be in SystemWindow, which does some incredibly
>>>> complicated things, all of which (correct me if I am wrong) would be
>>>> unnecessary if only there were a good set of layout managers.  I can
>>>> get
>>>> very simple-minded about things, but it would make a whole lot more
>>>> sense to me to create rows and columns of widgets, adding splitters
>>>> between them until the whole things behaves as intended, rather than
>>>> writing code (present only in a top-level shell) that tries to split
>>>> things up into rows using its own judgment.  Not good.  I realize you
>>>> did not create the situation, and have done wonders to make it work far
>>>> better than when you found it.
>>>>
>>>> Some time ago, I built an emulated widget framework for Dolphin, which
>>>> I
>>>> needed because the combination of Dolphin's view resources and Windows
>>>> itself was too slow for what I was trying to do.  That project included
>>>> a somewhat strange set of layout classes, but the basics are present,
>>>> and it is not Object Arts' IP.  I ported the classes to Pharo and did
>>>> some work on stub View and Presenter classes that I had added to Pharo
>>>> largely to passify my code that I was importing from Dolphin.  The
>>>> layouts think in terms of emulated widgets, and I see no reason to
>>>> change their minds: I might want to replicate the framework.  However,
>>>> dynamic typing and a couple of extra methods allow them to work with
>>>> just about anything.  My goals are modest.  Being able to compose rows
>>>> and columns would do a lot for me.  Add splitters and the ability to
>>>> fix
>>>> the size of some items, and I could almost anything I would need.
>>>>
>>>> View class>>example
>>>> | row column dot square out shell |
>>>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32.
>>>> square := ( Form squareOfSize:100 ) asFormOfDepth:32.
>>>> out := Array writeStream.
>>>>
>>>> row := ContainerView row.
>>>> 2 timesRepeat:[
>>>> column := row addSubview:ContainerView column.
>>>> 2 timesRepeat:[
>>>> out nextPut:(
>>>> column addSubview:ImageView new
>>>> ).
>>>> ].
>>>> ].
>>>>
>>>> out contents with:{ dot copy. square copy. square copy. dot copy. }
>>>> do:[ :view :form |
>>>> view morph image:form.
>>>> ].
>>>>
>>>> row rectangle:( 0@0 extent:400@400 ).
>>>> row layout.
>>>>
>>>> shell := StandardWindow labelled:'Hello MVP'.
>>>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself.
>>>>
>>>>
>>>> The above code produces an array of dots and squares, as intended.  One
>>>> quirk is that the grid does not resize as the shell resizes, a
>>>> consequence of my not having hooked it up to resize events.  I might
>>>> get
>>>> some interesting meltdowns once I begin to do that =:0  I used your
>>>> PanelMorph as the "view" associated with ContainerView.  What,
>>>> ContainView isn't a view???  No.  The code is biased toward Morphic,
>>>> but
>>>> hopefully the same code should extend to wx, GTK, etc.  Dolphin's views
>>>> have a handle instance variable to control the external resource; these
>>>> views have an instance variable pointing to their morph.  Handling of
>>>> sub views works pretty much as in Dolphin: any view/morph can have
>>>> children, but adding them is "legal" only for composites.
>>>>
>>>> Most systems I have seen treat coordinates relative to the
>>>> parent/owner,
>>>> but not Morphic.  I remember seeing plans to make the change, but
>>>> nothing after that.  The view instances provide a natural place to fix
>>>> things, so I took the plunge.  If we switch to some other graphical
>>>> realization, we can simply remove the the transformation.
>>>>
>>>> Are the existing splitters as strange as SystemWindow?  By that I mean,
>>>> would it be reasonable to add them between other morphs and look for
>>>> events from them, or will they have to be replaced?  I will eventually
>>>> need splitters, but I could initially live without them if I can get
>>>> reliable composition where I need it.
>>>>
>>>> There are very few view classes at present.  MorphView can wrap almost
>>>> anything, so it might be better to create a rich set of presenters
>>>> instead.  Dolphin's view resources are going to be interesting to
>>>> replace. There are some complexities that I suspect are in deference to
>>>> Windows, and some that might be avoidable.  For our purposes, it might
>>>> be enough to use SIXX to serialize a bunch of message sends and gzip
>>>> the
>>>> results to save memory.  Another option might be to rely on class
>>>> methods; having full closures won't hurt; they might allow sufficient
>>>> hooking that resources in the Dolphin sense won't even be necessary.
>>>> The desire for them quickly arises because views get realized in places
>>>> know nothing about how the views should be configured; at least I think
>>>> that is what happened to me after just a couple of hours.  I am far
>>>> less
>>>> interested in having a graphical view editor than I am in being able to
>>>> write **GOOD** code that assembles things as I want.  If the result
>>>> happens to allow a graphical editor too, so much the better.
>>>>
>>>> Any interest?
>>>>
>>>> Bill
>>>>
>>>>
>>>> -----------------------------
>>>>
>>>> View
>>>>   MorphViev
>>>>   ImageView
>>>>   ContainerView
>>>>
>>>> ViewGadgetLayoutAbstract
>>>>   ScrollerGadgetLayout
>>>>   NullViewGadgetLayout
>>>>   FixedStretchFixedGadgetLayout
>>>>   ProportionalGadgetLayout
>>>>   PreferredExtentsGadgetLayout
>>>>   GridGadgetRowsLayout
>>>>   VerticalListLayout
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> Gary,
>
> I tried making some changes and found it very easy to end up with an empty
> shell.  It appears that you are using the builder as a factory and are
> completely uninterested in hanging on to it :)  Is that accurate?  Is it
> good design?
>
> Bill
>
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Schwab,Wilhelm K
> Sent: Monday, August 09, 2010 5:06 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Early days of an MVP framework
>
> Gary,
>
> Thanks for the examples.  One thing is driving me nuts: in the past, I
> thought that creating a new row or column made a morph but did not add it
> to the morph being created.  Might I have added them redundantly?  Does
> re-adding a child have no effect or somehow replace it?  Is this a
> morphi/Polymorph beginner trap?  Be honest, I can take it :)
>
> Bill
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Gary
> Chambers
> Sent: Monday, August 09, 2010 5:45 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] Early days of an MVP framework
>
> And with a stack layout...
>
> (UITheme builder
>  newColumn: {
>   UITheme builder newTabGroup: {
>    'First page' -> ((UITheme builder newStack: {
>      (UITheme builder
>       newAlphaImage: UITheme current warningIcon
>       help: nil)
>       alpha: 0.5.
>      CircleMorph new
>       hResizing: #spaceFill;
>       vResizing: #spaceFill})
>     fillStyle: Color red;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill).
>    'Second page' -> (UITheme builder newPanel
>     fillStyle: Color green;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill)}.
>   (UITheme builder newRow: {
>    UITheme builder newOKButton.
>    UITheme builder newCancelButton})
>    listCentering: #bottomRight})
> extent: 200@300;
> openInWindow
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Gary Chambers" <[hidden email]>
> To: <[hidden email]>
> Sent: Monday, August 09, 2010 11:30 AM
> Subject: Re: [Pharo-project] Early days of an MVP framework
>
>
>> This even (to get buttons on right with correct tab key navigation
>> ordering...
>>
>> (UITheme builder
>>  newColumn: {
>>   UITheme builder newTabGroup: {
>>    'First page' -> (UITheme builder newPanel
>>     fillStyle: Color red;
>>     hResizing: #spaceFill;
>>     vResizing: #spaceFill).
>>    'Second page' -> (UITheme builder newPanel
>>     fillStyle: Color green;
>>     hResizing: #spaceFill;
>>     vResizing: #spaceFill)}.
>>   (UITheme builder newRow: {
>>    UITheme builder newOKButton.
>>    UITheme builder newCancelButton})
>>    listCentering: #bottomRight})
>> extent: 200@300;
>> openInWindow
>>
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Gary Chambers" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Monday, August 09, 2010 11:07 AM
>> Subject: Re: [Pharo-project] Early days of an MVP framework
>>
>>
>>> Any Morph can use a layoutPolicy.
>>> Available are
>>>    none (position based)
>>>    Prorportional (frame/fractions/offsets)
>>>    Table (overly complex too)
>>>    Row (one of mine, quicker for simple rows)
>>>    Stack (mine, overlay morphs on top of each other)
>>>
>>> TEasilyThemed provides some methods like...
>>>
>>>    newRow: {aMorph, anotherMorph}
>>>    newColumn:
>>>
>>> Something like this works...
>>>
>>> (UITheme builder
>>> newColumn: {
>>>  UITheme builder newPanel
>>>   fillStyle: Color red;
>>>   hResizing: #spaceFill;
>>>   vResizing: #spaceFill.
>>>  UITheme builder newRow: {
>>>   UITheme builder newOKButton.
>>>   UITheme builder newCancelButton}})
>>> extent: 200@300;
>>> openInHand
>>>
>>> (can use openInWindow also)...
>>>
>>> Rather busy today, hope this helps in the meantime...
>>>
>>> Regards, Gary
>>>
>>> ----- Original Message -----
>>> From: "Schwab,Wilhelm K" <[hidden email]>
>>> To: <[hidden email]>
>>> Sent: Sunday, August 08, 2010 11:46 PM
>>> Subject: [Pharo-project] Early days of an MVP framework
>>>
>>>
>>>> Gary,
>>>>
>>>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt
>>>> coaching), until I needed to repeat a "complex" GUI component and
>>>> wanted/insisted on doing so with some reuse.  Seaside gives us
>>>> components on web pages; we need them for GUI code too.  I tried
>>>> turning my presenter-like structures into factories that would add
>>>> morphs to a single shell, but it fell apart when it came time to set
>>>> the framing values.  I was not particularly interested in fixing it,
>>>> because if I could do that, I would simply build proper composite
>>>> widgets using the fix.
>>>>
>>>> The problem appears to be in SystemWindow, which does some
>>>> incredibly complicated things, all of which (correct me if I am
>>>> wrong) would be unnecessary if only there were a good set of layout
>>>> managers.  I can get very simple-minded about things, but it would
>>>> make a whole lot more sense to me to create rows and columns of
>>>> widgets, adding splitters between them until the whole things
>>>> behaves as intended, rather than writing code (present only in a
>>>> top-level shell) that tries to split things up into rows using its
>>>> own judgment.  Not good.  I realize you did not create the
>>>> situation, and have done wonders to make it work far better than when
>>>> you found it.
>>>>
>>>> Some time ago, I built an emulated widget framework for Dolphin,
>>>> which I needed because the combination of Dolphin's view resources
>>>> and Windows itself was too slow for what I was trying to do.  That
>>>> project included a somewhat strange set of layout classes, but the
>>>> basics are present, and it is not Object Arts' IP.  I ported the
>>>> classes to Pharo and did some work on stub View and Presenter
>>>> classes that I had added to Pharo largely to passify my code that I
>>>> was importing from Dolphin.  The layouts think in terms of emulated
>>>> widgets, and I see no reason to change their minds: I might want to
>>>> replicate the framework.  However, dynamic typing and a couple of
>>>> extra methods allow them to work with just about anything.  My goals
>>>> are modest.  Being able to compose rows and columns would do a lot
>>>> for me.  Add splitters and the ability to fix the size of some items,
>>>> and I could almost anything I would need.
>>>>
>>>> View class>>example
>>>> | row column dot square out shell |
>>>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32.
>>>> square := ( Form squareOfSize:100 ) asFormOfDepth:32.
>>>> out := Array writeStream.
>>>>
>>>> row := ContainerView row.
>>>> 2 timesRepeat:[
>>>> column := row addSubview:ContainerView column.
>>>> 2 timesRepeat:[
>>>> out nextPut:(
>>>> column addSubview:ImageView new
>>>> ).
>>>> ].
>>>> ].
>>>>
>>>> out contents with:{ dot copy. square copy. square copy. dot copy. }
>>>> do:[ :view :form | view morph image:form.
>>>> ].
>>>>
>>>> row rectangle:( 0@0 extent:400@400 ).
>>>> row layout.
>>>>
>>>> shell := StandardWindow labelled:'Hello MVP'.
>>>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself.
>>>>
>>>>
>>>> The above code produces an array of dots and squares, as intended.
>>>> One quirk is that the grid does not resize as the shell resizes, a
>>>> consequence of my not having hooked it up to resize events.  I might
>>>> get some interesting meltdowns once I begin to do that =:0  I used
>>>> your PanelMorph as the "view" associated with ContainerView.  What,
>>>> ContainView isn't a view???  No.  The code is biased toward Morphic,
>>>> but hopefully the same code should extend to wx, GTK, etc.
>>>> Dolphin's views have a handle instance variable to control the
>>>> external resource; these views have an instance variable pointing to
>>>> their morph.  Handling of sub views works pretty much as in Dolphin:
>>>> any view/morph can have children, but adding them is "legal" only for
>>>> composites.
>>>>
>>>> Most systems I have seen treat coordinates relative to the
>>>> parent/owner, but not Morphic.  I remember seeing plans to make the
>>>> change, but nothing after that.  The view instances provide a
>>>> natural place to fix things, so I took the plunge.  If we switch to
>>>> some other graphical realization, we can simply remove the the
>>>> transformation.
>>>>
>>>> Are the existing splitters as strange as SystemWindow?  By that I
>>>> mean, would it be reasonable to add them between other morphs and
>>>> look for events from them, or will they have to be replaced?  I will
>>>> eventually need splitters, but I could initially live without them
>>>> if I can get reliable composition where I need it.
>>>>
>>>> There are very few view classes at present.  MorphView can wrap
>>>> almost anything, so it might be better to create a rich set of
>>>> presenters instead.  Dolphin's view resources are going to be
>>>> interesting to replace. There are some complexities that I suspect
>>>> are in deference to Windows, and some that might be avoidable.  For
>>>> our purposes, it might be enough to use SIXX to serialize a bunch of
>>>> message sends and gzip the results to save memory.  Another option
>>>> might be to rely on class methods; having full closures won't hurt;
>>>> they might allow sufficient hooking that resources in the Dolphin sense
>>>> won't even be necessary.
>>>> The desire for them quickly arises because views get realized in
>>>> places know nothing about how the views should be configured; at
>>>> least I think that is what happened to me after just a couple of
>>>> hours.  I am far less interested in having a graphical view editor
>>>> than I am in being able to write **GOOD** code that assembles things
>>>> as I want.  If the result happens to allow a graphical editor too, so
>>>> much the better.
>>>>
>>>> Any interest?
>>>>
>>>> Bill
>>>>
>>>>
>>>> -----------------------------
>>>>
>>>> View
>>>>   MorphViev
>>>>   ImageView
>>>>   ContainerView
>>>>
>>>> ViewGadgetLayoutAbstract
>>>>   ScrollerGadgetLayout
>>>>   NullViewGadgetLayout
>>>>   FixedStretchFixedGadgetLayout
>>>>   ProportionalGadgetLayout
>>>>   PreferredExtentsGadgetLayout
>>>>   GridGadgetRowsLayout
>>>>   VerticalListLayout
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> Gary,
>
> Is there a way to disable a ComposableMorph and all of its children?
>
> Bill
>
>
>
>
> ________________________________________
> From: [hidden email]
> [[hidden email]] On Behalf Of Schwab,Wilhelm
> K [[hidden email]]
> Sent: Monday, August 09, 2010 10:38 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Early days of an MVP framework
>
> Gary,
>
> I have a composite GUI that appears to work.  I need to mask about 3,000
> images in pairs of three that repeat in sequences (don't worry, you'll be
> happier if you don't understand<g>).  I am hoping to use the first triad
> in each sequence as the basis for a "fill down" command that will
> hopefully leave me making only minor edits to most of the masks.
>
> Thanks!
>
> Bill
>
> ________________________________________
> From: [hidden email]
> [[hidden email]] On Behalf Of Schwab,Wilhelm
> K [[hidden email]]
> Sent: Monday, August 09, 2010 7:05 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Early days of an MVP framework
>
> Gary,
>
> I tried making some changes and found it very easy to end up with an empty
> shell.  It appears that you are using the builder as a factory and are
> completely uninterested in hanging on to it :)  Is that accurate?  Is it
> good design?
>
> Bill
>
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Schwab,Wilhelm K
> Sent: Monday, August 09, 2010 5:06 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Early days of an MVP framework
>
> Gary,
>
> Thanks for the examples.  One thing is driving me nuts: in the past, I
> thought that creating a new row or column made a morph but did not add it
> to the morph being created.  Might I have added them redundantly?  Does
> re-adding a child have no effect or somehow replace it?  Is this a
> morphi/Polymorph beginner trap?  Be honest, I can take it :)
>
> Bill
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Gary
> Chambers
> Sent: Monday, August 09, 2010 5:45 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] Early days of an MVP framework
>
> And with a stack layout...
>
> (UITheme builder
>  newColumn: {
>   UITheme builder newTabGroup: {
>    'First page' -> ((UITheme builder newStack: {
>      (UITheme builder
>       newAlphaImage: UITheme current warningIcon
>       help: nil)
>       alpha: 0.5.
>      CircleMorph new
>       hResizing: #spaceFill;
>       vResizing: #spaceFill})
>     fillStyle: Color red;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill).
>    'Second page' -> (UITheme builder newPanel
>     fillStyle: Color green;
>     hResizing: #spaceFill;
>     vResizing: #spaceFill)}.
>   (UITheme builder newRow: {
>    UITheme builder newOKButton.
>    UITheme builder newCancelButton})
>    listCentering: #bottomRight})
> extent: 200@300;
> openInWindow
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Gary Chambers" <[hidden email]>
> To: <[hidden email]>
> Sent: Monday, August 09, 2010 11:30 AM
> Subject: Re: [Pharo-project] Early days of an MVP framework
>
>
>> This even (to get buttons on right with correct tab key navigation
>> ordering...
>>
>> (UITheme builder
>>  newColumn: {
>>   UITheme builder newTabGroup: {
>>    'First page' -> (UITheme builder newPanel
>>     fillStyle: Color red;
>>     hResizing: #spaceFill;
>>     vResizing: #spaceFill).
>>    'Second page' -> (UITheme builder newPanel
>>     fillStyle: Color green;
>>     hResizing: #spaceFill;
>>     vResizing: #spaceFill)}.
>>   (UITheme builder newRow: {
>>    UITheme builder newOKButton.
>>    UITheme builder newCancelButton})
>>    listCentering: #bottomRight})
>> extent: 200@300;
>> openInWindow
>>
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Gary Chambers" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Monday, August 09, 2010 11:07 AM
>> Subject: Re: [Pharo-project] Early days of an MVP framework
>>
>>
>>> Any Morph can use a layoutPolicy.
>>> Available are
>>>    none (position based)
>>>    Prorportional (frame/fractions/offsets)
>>>    Table (overly complex too)
>>>    Row (one of mine, quicker for simple rows)
>>>    Stack (mine, overlay morphs on top of each other)
>>>
>>> TEasilyThemed provides some methods like...
>>>
>>>    newRow: {aMorph, anotherMorph}
>>>    newColumn:
>>>
>>> Something like this works...
>>>
>>> (UITheme builder
>>> newColumn: {
>>>  UITheme builder newPanel
>>>   fillStyle: Color red;
>>>   hResizing: #spaceFill;
>>>   vResizing: #spaceFill.
>>>  UITheme builder newRow: {
>>>   UITheme builder newOKButton.
>>>   UITheme builder newCancelButton}})
>>> extent: 200@300;
>>> openInHand
>>>
>>> (can use openInWindow also)...
>>>
>>> Rather busy today, hope this helps in the meantime...
>>>
>>> Regards, Gary
>>>
>>> ----- Original Message -----
>>> From: "Schwab,Wilhelm K" <[hidden email]>
>>> To: <[hidden email]>
>>> Sent: Sunday, August 08, 2010 11:46 PM
>>> Subject: [Pharo-project] Early days of an MVP framework
>>>
>>>
>>>> Gary,
>>>>
>>>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt
>>>> coaching), until I needed to repeat a "complex" GUI component and
>>>> wanted/insisted on doing so with some reuse.  Seaside gives us
>>>> components on web pages; we need them for GUI code too.  I tried
>>>> turning my presenter-like structures into factories that would add
>>>> morphs to a single shell, but it fell apart when it came time to set
>>>> the framing values.  I was not particularly interested in fixing it,
>>>> because if I could do that, I would simply build proper composite
>>>> widgets using the fix.
>>>>
>>>> The problem appears to be in SystemWindow, which does some
>>>> incredibly complicated things, all of which (correct me if I am
>>>> wrong) would be unnecessary if only there were a good set of layout
>>>> managers.  I can get very simple-minded about things, but it would
>>>> make a whole lot more sense to me to create rows and columns of
>>>> widgets, adding splitters between them until the whole things
>>>> behaves as intended, rather than writing code (present only in a
>>>> top-level shell) that tries to split things up into rows using its
>>>> own judgment.  Not good.  I realize you did not create the
>>>> situation, and have done wonders to make it work far better than when
>>>> you found it.
>>>>
>>>> Some time ago, I built an emulated widget framework for Dolphin,
>>>> which I needed because the combination of Dolphin's view resources
>>>> and Windows itself was too slow for what I was trying to do.  That
>>>> project included a somewhat strange set of layout classes, but the
>>>> basics are present, and it is not Object Arts' IP.  I ported the
>>>> classes to Pharo and did some work on stub View and Presenter
>>>> classes that I had added to Pharo largely to passify my code that I
>>>> was importing from Dolphin.  The layouts think in terms of emulated
>>>> widgets, and I see no reason to change their minds: I might want to
>>>> replicate the framework.  However, dynamic typing and a couple of
>>>> extra methods allow them to work with just about anything.  My goals
>>>> are modest.  Being able to compose rows and columns would do a lot
>>>> for me.  Add splitters and the ability to fix the size of some items,
>>>> and I could almost anything I would need.
>>>>
>>>> View class>>example
>>>> | row column dot square out shell |
>>>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32.
>>>> square := ( Form squareOfSize:100 ) asFormOfDepth:32.
>>>> out := Array writeStream.
>>>>
>>>> row := ContainerView row.
>>>> 2 timesRepeat:[
>>>> column := row addSubview:ContainerView column.
>>>> 2 timesRepeat:[
>>>> out nextPut:(
>>>> column addSubview:ImageView new
>>>> ).
>>>> ].
>>>> ].
>>>>
>>>> out contents with:{ dot copy. square copy. square copy. dot copy. }
>>>> do:[ :view :form | view morph image:form.
>>>> ].
>>>>
>>>> row rectangle:( 0@0 extent:400@400 ).
>>>> row layout.
>>>>
>>>> shell := StandardWindow labelled:'Hello MVP'.
>>>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself.
>>>>
>>>>
>>>> The above code produces an array of dots and squares, as intended.
>>>> One quirk is that the grid does not resize as the shell resizes, a
>>>> consequence of my not having hooked it up to resize events.  I might
>>>> get some interesting meltdowns once I begin to do that =:0  I used
>>>> your PanelMorph as the "view" associated with ContainerView.  What,
>>>> ContainView isn't a view???  No.  The code is biased toward Morphic,
>>>> but hopefully the same code should extend to wx, GTK, etc.
>>>> Dolphin's views have a handle instance variable to control the
>>>> external resource; these views have an instance variable pointing to
>>>> their morph.  Handling of sub views works pretty much as in Dolphin:
>>>> any view/morph can have children, but adding them is "legal" only for
>>>> composites.
>>>>
>>>> Most systems I have seen treat coordinates relative to the
>>>> parent/owner, but not Morphic.  I remember seeing plans to make the
>>>> change, but nothing after that.  The view instances provide a
>>>> natural place to fix things, so I took the plunge.  If we switch to
>>>> some other graphical realization, we can simply remove the the
>>>> transformation.
>>>>
>>>> Are the existing splitters as strange as SystemWindow?  By that I
>>>> mean, would it be reasonable to add them between other morphs and
>>>> look for events from them, or will they have to be replaced?  I will
>>>> eventually need splitters, but I could initially live without them
>>>> if I can get reliable composition where I need it.
>>>>
>>>> There are very few view classes at present.  MorphView can wrap
>>>> almost anything, so it might be better to create a rich set of
>>>> presenters instead.  Dolphin's view resources are going to be
>>>> interesting to replace. There are some complexities that I suspect
>>>> are in deference to Windows, and some that might be avoidable.  For
>>>> our purposes, it might be enough to use SIXX to serialize a bunch of
>>>> message sends and gzip the results to save memory.  Another option
>>>> might be to rely on class methods; having full closures won't hurt;
>>>> they might allow sufficient hooking that resources in the Dolphin sense
>>>> won't even be necessary.
>>>> The desire for them quickly arises because views get realized in
>>>> places know nothing about how the views should be configured; at
>>>> least I think that is what happened to me after just a couple of
>>>> hours.  I am far less interested in having a graphical view editor
>>>> than I am in being able to write **GOOD** code that assembles things
>>>> as I want.  If the result happens to allow a graphical editor too, so
>>>> much the better.
>>>>
>>>> Any interest?
>>>>
>>>> Bill
>>>>
>>>>
>>>> -----------------------------
>>>>
>>>> View
>>>>   MorphViev
>>>>   ImageView
>>>>   ContainerView
>>>>
>>>> ViewGadgetLayoutAbstract
>>>>   ScrollerGadgetLayout
>>>>   NullViewGadgetLayout
>>>>   FixedStretchFixedGadgetLayout
>>>>   ProportionalGadgetLayout
>>>>   PreferredExtentsGadgetLayout
>>>>   GridGadgetRowsLayout
>>>>   VerticalListLayout
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project