Mantis - Squeak
Viewing Issue Advanced Details
5940 Morphic minor always 02-06-07 08:42 03-01-07 06:03
new 3.9  
0005940: Asking an Annotation window to openCenteredInWorld causes strange results.
For this one
In a fresh squeak 7067
from the tools flap get an annotation editing window.

Using the debug halo handle get an inspector on the window.

in the evaluation pane evaluate "self openCenteredInWorld".

expected: the window will move to be centered in world and it will remain its present size.

instead the size gets changed to the default window size (large) and the resulting window will NOT be centered in the display.

This is a puzzler. From the code I've tracked thru so far I can't find where things go astray.

Asking the window to open in hand gets one of the right size. Asking one to open centered gets the wrong size and a position that varies depending on where your morph started (as far as I can tell so far.)

An interesting puzzle.

Yours in service, --Jerome Peace

02-26-07 10:37   
This is not specific to "Annotation windows" -- you could as easily have used *any* SystemWindow and encountered the same phenomenon. Looking at the senders of #openCenteredInWorld, it's clear that its sole intention and use are in the context of modal dialogs that are in the process of being constructed.

BTW if you have a morph that is already present on the screen, and if you want that morph to be *centered* within its world, just send it the #center: message, thus, for example, "aMorph center: aMorph world center".
02-26-07 22:19   

Hi Scott.
Thanks for the analysis.

As a user story I want "openCenteredInWorld" to work reasonably for any morph. The fact that it originated for a specialized purpose does not mean it should not have a generalized meaning. Especially as the meaning is pretty obvious.
Indeed it has become my opener of choice since it is easier (in theory) to use than openInHand; places the morph where I can see it; and insures it is in the world.

"MyMorphClass initializedInstance openCenteredInWorld"
          should get you something you can predict in all cases.

So I consider the perverseness of system windows when given this message a bug.

Which needs to be fixed going forward.

The example I gave was not meant to be a practical one just a sure way of demonstrating the offending behavior. I ran into it while working on a refactoring of the Annotation browser.

I'll check out some other system windows and see what they do.

Thank you for your attention to this matter, the clue is a useful one.

Yours in curiosity and service, --Jeorme Peace
02-27-07 06:52   

Probably a method defined as follows would fit your criteria:

    "Open the receiver, with its center at the center of the world"

    self openInWorld.
    self center: self world center

A cursory check seems to show that this implementation would not break the existing senders of #openInWorldCentered, but of course you'd want to make *certain* of that before proposing acceptance of a "fix" such as the above.
02-28-07 03:58   
Hi Scott,

Thanks for your suggestion.

Did you mean #openInWorldCentered as distinct from
#openCenteredInWorld? Or did you mean for the repair to redefine the latter?

#openCenteredInWorld is defined in only one place (as of 6067).
and the other is not defined at all.

However if I were defining a new message I would not make it so close to the old one. I makes it hard to read code without getting confused.

Also the problems I am running into with the annotation browser are partly because it is an oddball. Its generated on the fly by Preferences rather than having its own model and class. So there is nowhere to stick a #initailizedExtent for the RealEstateManager to find.

The shame of its odd ball nature is that is such a wonderful UI. Its very natural to pick a lists of things by well, literally picking them up an moving them from column to column. So I am looking a ways to generalize that.

I keep thinking it would be a nice way to do shopping lists or to do lists.

Back to the problem with system windows and RealEstateManager.
There seems to be something there that assumes too much and does not allow for an extent to be already determined. And maybe that's the problem.

If I can I'd like to solve the problem before the morph is opened and displaying else it will jump around like inspector windows do.

Thanks for your time and attention.

Yours in service, --Jerome Peace
02-28-07 18:26   
What I meant was that the two-line implementation I suggested, which I created under a different selector name only so that I could compare the old and the new side-by-side, is probably a suitable replacement for the original.

03-01-07 06:03   
Ahh. Side by side comparison.

That makes sense.

Thanks for clarifying.

I think there is also something more that has to be added to get the annotation browser to init correctly. So I'm going to wait to see if the clever part of my mind can figure out a more general fix. If not, I agree your solution should be an improvement.

The other notion I've had is that the RealEstateManger (or something like it ) would be useful for arranging collapsed icons such as collapsing image morphs make in 3.8. In one of my experiments I refactored the collapse to icon stuff by moving it up a level and allowing it to apply to collapsing everything except system windows. It works a treat but places all the icons initially at the top left. Now if I had a RealEstateManager that simply found good locations for any rectange of a given extent then that would complete that repair.