Rather than use ComposableMorph directly you will be better off just using it to build the morphs you need.

A PanelMorph will pass on #enabled: to its submorphs, rows and columns are made from PanelMorphs too.

An example:


|row|
row := UITheme builder newRow: {
UITheme builder
 newCheckboxFor: nil
 getSelected: nil
 setSelected: nil
 label: 'Checkbox in a panel'
 help: nil.
UITheme builder
 newButtonFor: nil
 action: nil
 label: 'Button in panel'
 help: nil}.
row
vResizing: #spaceFill;
listCentering: #center;
wrapCentering: #center.
((UITheme builder newColumn: {
row.
UITheme builder newRow: {
 (UITheme builder
  newButtonFor: row
  action: #enabled:
  label: 'Enable panel'
  help: nil)
  arguments: {true}.
 (UITheme builder
  newButtonFor: row
  action: #enabled:
  label: 'Disable panel'
  help: nil)
  arguments: {false}}})
extent: 3...@100;
openInWindow)
 setLabel: 'Panel Enablement'


Regards, Gary

----- Original Message ----- From: "Schwab,Wilhelm K" <[email protected]>
To: <[email protected]>
Sent: Tuesday, August 10, 2010 5:19 AM
Subject: Re: [Pharo-project] Early days of an MVP framework


Gary,

Is there a way to disable a ComposableMorph and all of its children?

Bill




________________________________________
From: [email protected] [[email protected]] On Behalf Of Schwab,Wilhelm K [[email protected]]
Sent: Monday, August 09, 2010 10:38 PM
To: [email protected]
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: [email protected] [[email protected]] On Behalf Of Schwab,Wilhelm K [[email protected]]
Sent: Monday, August 09, 2010 7:05 PM
To: [email protected]
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: [email protected] [mailto:[email protected]] On Behalf Of Schwab,Wilhelm K
Sent: Monday, August 09, 2010 5:06 PM
To: [email protected]
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: [email protected] [mailto:[email protected]] On Behalf Of Gary Chambers
Sent: Monday, August 09, 2010 5:45 AM
To: [email protected]
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: 2...@300;
openInWindow

Regards, Gary

----- Original Message -----
From: "Gary Chambers" <[email protected]>
To: <[email protected]>
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: 2...@300;
openInWindow


Regards, Gary

----- Original Message -----
From: "Gary Chambers" <[email protected]>
To: <[email protected]>
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: 2...@300;
openInHand

(can use openInWindow also)...

Rather busy today, hope this helps in the meantime...

Regards, Gary

----- Original Message -----
From: "Schwab,Wilhelm K" <[email protected]>
To: <[email protected]>
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:4...@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
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to