Re: [Pharo-project] Early days of an MVP framework

Aug. 10, 2010


      UITheme builder answers a singleton ComposableMorph so is technically 
reused.

Regards, Gary

----- Original Message ----- 
From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu>
To: <Pharo-project@lists.gforge.inria.fr>
Sent: Tuesday, August 10, 2010 12:05 AM
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: pharo-project-bounces@lists.gforge.inria.fr 
[mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of 
Schwab,Wilhelm K
Sent: Monday, August 09, 2010 5:06 PM
To: Pharo-project@lists.gforge.inria.fr
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: pharo-project-bounces@lists.gforge.inria.fr 
[mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary 
Chambers
Sent: Monday, August 09, 2010 5:45 AM
To: Pharo-project@lists.gforge.inria.fr
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" <gazzaguru2@btinternet.com>
To: <Pharo-project@lists.gforge.inria.fr>
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" <gazzaguru2@btinternet.com>
To: <Pharo-project@lists.gforge.inria.fr>
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" <bschwab@anest.ufl.edu>
To: <pharo-project@lists.gforge.inria.fr>
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
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project