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
