[Cuis-dev] CoreUpdate 4548

[Juan Vuletich]

Hi Folks,

This indeed helps, Pat. It points to (at least one of the) problem(s). 
Thanks.

See the changesets I sent in a separate email "Several changesets to 
address recent issues". One of them makes menus to stay up (instead of 
auto close) when a halo opens in them. Doing just that might help.

In any case, please review those change sets (the file name states the 
intention of each one), and keep testing, to see if there are still 
problems.

Thanks!

On 4/4/2021 12:45 PM, Pat Foley via Cuis-dev wrote:
> On Apr 4 2021, at 8:50 am, Graham Kelly via Cuis-dev
> <cuis-dev at lists.cuis.st>  wrote:
>
>> Here's what I think is the issue:
>>
>> The variable
>>
>> halo
>>
>> is not initialized before returning
>>
>> halo
>>
>>
>> | halo |
>> self whenUIinSafeState: [
>> self displayBoundsForHalo ifNotNil: [ :r |
>> halo _ HaloMorph new.
>> halo popUpFor: self event: evt.
>> halo morphBounds: r ].
>> self redrawNeeded].
>> ^halo
> The previous version of Morph>>addHalo: was
>
> addHalo: evt
> 	| halo |
> 	self displayBoundsForHalo ifNotNil: [ :r |
> 		halo _ HaloMorph new.
> 		halo popUpFor: self event: evt.
> 		halo morphBounds: r ].
> 	self whenUIinSafeState: [self redrawNeeded].
> 	^halo
>
> But Luciano had a use case this didn't work for: 'BrowserWindow
> openBrowser addHalo' gives you a browser without halos. But it used to
> work, so what was the previous version? It was
>
> addHalo: evt
> 	| halo |
> 	self displayBoundsForHalo ifNotNil: [ :r |
> 		halo _ HaloMorph new.
> 		halo popUpFor: self event: evt.
> 		halo morphBounds: r ].
> 	^halo
>
> In December, Juan added the line
>
> 	self whenUIinSafeState: [self redrawNeeded].
>
> which breaks Luciano's code, and then in March pushed up the
> #whenUIinSafeState: to enclose the halo-creating block and the redraw.
>
> So what does #whenUIinSafeState: do, and why is it there? It finds the
> morph's world and passes the evaluable block along to it to be added to
> the WorldMorph's list (kept in an instance variable) of
> deferredUIMessages. That list is stepped through by
> WorldMorph>>doOneCycle and WorldMorph>>runStepMethods.
>
> So how does that work here? Here's Juan's comment with the latest
> version (4548):
> 	"Defer execution until next cycle, so if you evaluate
> 	BrowserWindow openBrowser addHalo
> 	the window is in the world and with proper bounds, before adding the halo.
> 	"
> That is, defer execution of #addHalo. Before it was only the redraw that
> was deferred, not the creation of the halos. Now you wait, let the
> window get drawn, then add halos and redraw.
>
> That should be fine, right? But evidently menus work differently, or at
> least TheWorldMenu does.
>
> System windows eventually call #openInWorld (setting some stuff and then
> calling Morph>>openInWorld, which itself includes #whenUIinSafeState)
> but menus do not. Neither do they call #openInHand. Menus instead have
> #popUpInWorld and friends (which use the current hand's position but
> open not attached to it).
>
> That's sadly as far as I've gotten. Menus take a different route to
> appearing in the world than windows, and that's enough to change when
> and how you can add halos, but I don't get why.
>
> If you do something like this in a workspace
>
>    w _ TheWorldMenu new buildWorldMenu.
>    w popUpInWorld addHalo.
>
> you first get a world menu (missing its title and stayups) with
> unresponsive halos drawn in weird places. You can get them to be where
> they should be by middle-clicking the MenuMorph, but they remain
> unusable (and middle-clicking doesn't select submorphs) just like with
> CoreUpdate 4548. That seems interesting.
>
> I'm sure this would be nearly 3 minutes of work for Juan to fix, but
> he's busy inventing the future, so I'm just digging around in his code
> so maybe someday I can help him a little.


-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich