[Squeak] Need for GUI-Building-Tool

Richard A. O'Keefe ok at cs.otago.ac.nz
Tue Jul 16 06:35:14 UTC 2002


	Why a PluggableListMorph rather than a Morph that has some buttons in=20
	it? That might be easier to wire up, but...
	
Because I *tried* the buttons approach and it was a lot more work.

	It's designed to be put inside of things.
	
Yes, but it doesn'T SAY that.

	>     - the PluggableListMorph is way too big for its contents
	
	ditto.
	
Ditto.

	>     - the highlighting doesn't change; when I click on an item it
	>       _is_ selected, but that doesn't show up on the screen.
	
	That's because it's transparent.
	
Because *what* is transparent?  The first selection *is* highlighted
and remains highlighted.

	Why would you want one of these things by themselves when they work so=20
	much better with a parent?
	
Because there is *nothing* around that could reasonably *be* its parent.
And because there wasn't the slightest hint in the comments.

	It's super simple to make (say) a PasteUpMorph or a RectangleMorph or=20
	something to hold it.

It is nowhere near as simple as NOT doing it.

	> The bottom line is that on the day that I decided to do this, I
	> _was_ able to do it, but met with some frustration on the way.  In
	> retrospect, the problems mostly stem from a single cause:
	>
	>     Most system uses of PluggableListMorph want to drop a list into
	>     a specified portion of an existing window, but I wanted a
	>     free-standing list.
	
	But you wanted the wrong thing.

That is not as courteously worded as I would have expected from someone
as helpful as Ned Konz.  In fact it made me quite angry.

What I *want* is my business.
It so happens that what I want is
 - a morph
 - that implements a list
 - and is pluggable
 - and is freestanding like so many morphs are.
When you go looking for such a thing, what you find is PluggableListMorph,
with never a hint that it won't work freestanding.

I mean, here is the class comment (from SqueakV3.sources):

    ...
    When a PluggableListMorph is in focus, type in a letter (or several
    letters quickly) to go to the next item that begins with that letter.
    Special keys (up, down, home, etc.) are also supported.

That's the entire comment; take the three dots at the front literally.
My point is not the difficulty or otherwise of using PluggableListMorph,
BUT THE TOTALLY INADEQUATE CLASS COMMENT.

You can tell me that PluggableListMoprh is not what I want,
and I'll believe you (except that it VERY NEARLY is; it required less
hacking to get this working than the buttons-in-a-box approach).
But it's really not nice to say I wanted the wrong thing.

	Since the PLM wasn't designed to be=20
	used by itself,

Yes, but it doesn't *SAY* that.
There is nothing in the class comment.
There are no examples.
There is NO HINT ANYWHERE (and believe me, I've looked and looked and
looked) that PluggableListMorphs are not meant to stand alone.

Above all, these things will #openInWorld perfectly happily;
there is no error message to say "don't do this".

	you're giving yourself a big headache by trying to do so.

Well, no.  It was never at any time a big enough headache to tell me
"try something else".  The next step was always simpler than scrapping
the code and starting again.

	There's no advantage to using a PLM by itself.
	
Yes there is.  Less memory.  Simpler code.  Aren't they advantages?

All that's needed is one more method
    PluggableListMorph>>standalone: autoSize
to be called after creation and before #openInWorld.
and then these things would be *perfect* for my requirements, no extra
morphs needed.  (OK, I'd have to set the #position:  by hand, but let's
face it, I'd have to do this anyway.)

	It doesn't need to be in a window; a RectangleMorph is an adequate
	parent/background.
	
Then why the heck can't it make its _own_ RectangleMorph when run freestanding?

When I try it, the ListTester example chops off the bottom of
"This is item 10", even though that's only half way down the rectangle.
I had to manually resize the List to be the size it appeared to be.


Now that I have gone looking for a PluggableListMorph tutorial,
I've found one.  See
	http://coweb.cc.gatech.edu/cs2340/2247

(Aside:  I *do* wish people wouldn't say 'implement' when they mean 'use'.)

Guess what:
    IT OPENS A FREE-STANDING PLUGGABLELISTMORPH!

	openView: aPoint
	    |window aListMorph|
	    aListMorph := PluggableListMorph
		on: self
		list: #list
		selected: #listIndex
		changeSelected: #listIndex:
		menu: #listMenu.
	    aListMorph color: Color random.
	    aListMorph x: xCoord y: yCoord.
	    aListMorph openInWord. "sic."

This points to http://minnow.cc.gatech.edu/squeak/1093
(which also says 'implement' for 'use').
That one uses a SystemWindow as "background"; the coweb.cc.gatech.edu
#openView: was obviously edited from #openAViewOnMe here.

It turns out that the key point is that the changeSelected: selector
is responsible for calling "self changed: thatSelector"; this is not
stated anywhere in the PluggableListMorph sources that I can see.

If you hunt for PluggableListMorph on the Swiki, you find
http://minnow.cc.gatech.edu/squeak/2093
which just says
    "PluggableListMorph is a widget for displaying lists and selecting
     items from them.  See _What is Pluggble Model View Controller_."
which certainly suggests to me that a PluggableListMorph is basically
_all_ you need to do this.

At any rate, the bottom line is that if you go looking for PluggableListMorph
tutorials, the very first one you find tells you that free-standing ones are
OK.  Perhaps Ned Konz could add his ListTester example to the Swiki page?




More information about the Squeak-dev mailing list