[Morphic] IconicButton in PartsBin,

[Lic. Edgar J. De Cleene]

I copy the mail from Scott
> Hi, Edgar,
> 
> (This correspondence arose in an exchange on Mantis on April 21, but
> since Edgar carried it over to squeak-dev, I'm following suit.)
> 
> I see that I guessed wrongly about the motivation for your
> "morphToDropFromFix" fileout on Mantis (bug #1092.)  If I'd known
> that you were trying to rearrange buttons in a "parts flap" (such as
> Supplies, Tools, or Widgets,) I would have offered up the solution
> mentioned below in #1 below right away.
> 
> However, it's also true that a small modification to your fileout
> will accomplish the result you were seeking without breaking the
> proper functioning for "normal" IconicButtons, so I've produced such
> a fileout for your inspection -- see  #4 below.
> 
> 
> (1)  There's a simple way to move a parts-button in a "parts" flap to
> be the first item in that flap.  Just choose "bring to front" from
> the halo menu of the button in question.  Voilà!  By a series of
> judiciously-chosen "send to back" and "bring to front" requests on
> the buttons in a flap, you can end up with any arrangement you want.
> 
> (2)  In the example you cite, operating in an image that has the
> original version of your fileout present, if one creates a "normal"
> IconicButton, and drops it into the Supplies Flap, you are right that
> the appearance of the resulting button in the Supplies Flap is
> "correct", but what you may not have noticed is that the resulting
> button does not work as a "parts donor" -- i.e., if you try to drag
> from it, you'll end up just "pressing" the button, rather than
> obtaining a new instance.  Thus, it may *look* right, but it doesn't
> work ;-)
> 
> (3)  BTW a quick way to get an example of a user-defined IconicButton
> for testing is:  "(IconicButton new labelGraphic: Form fromUser)
> openInHand".
> 
> (4)  FWIW I attach a fileout similar to yours but which doesn't have
> the problem of malfunctioning when a "regular" iconicButton is
> dropped into a parts flap.  It differs from yours only in that it
> does one additional test, to ascertain whether the button being
> dropped is actually a "parts donor" button in its own right, before
> deciding whether or not to accept it without further processing.
> 
> (5)  A decent case could be made for adopting this "fix" (i.e. your
> fix as tweaked in the attached.)  This would then permit the kind of
> casual rearrangement of items in a parts flap via grab and drop,
> which was your original intention.  Likewise, you could put the
> ZipViewer into the Tools flap by tearing-out (black handle) or
> duplicating (green handle) the Zip button from the Objects Catalog
> and dropping the resulting button wherever you want it in the Tools
> Flap.   What do you think?  This would be "common sense overriding
> consistency," a principle on which the house may be divided ;=)
> 
> (6)  Finally, no need to apologize about anything, and you're
> certainly not wasting anyone's time!  Your voice in the Squeak
> community is always a cheerful and earnest point of light which I for
> one have always appreciated.
> 
> Cheers,
> 
>   -- Scott


I send this why I check what in Mantis I was mistaken and the item was
closed by Markus as Scott think my first send

> An actual bug *introduced* by the proposed fileout is that a *regular*
> IconicButton (not one duplicated from or ripped out from the Objects Catalog,
> but just a normal IconicButton of the sort used throughout the system,) when
> dropped into a parts bin, would no longer yield the proper copy-producing kind
> of entry in the flap.

So, I add the Scott fix and hope find the way in new releases

Edgar

-------------- next part --------------
A non-text attachment was scrubbed...
Name: morphDropFix-edc.1.cs.gz
Type: application/octet-stream
Size: 749 bytes
Desc: not available
Url : http://liststest.squeakfoundation.org/pipermail/morphic/attachments/20051219/f2b0f308/morphDropFix-edc.1.cs.obj