Windows opening in background

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Windows opening in background

Nicolas Cellier
It often happens that a window opens behind the currently active one.
Typically, I want to 'debug it' on a subexpression in the debugger.
The second debugger opens in background, or does it go into background after opening?
Anyway, it's sufficiently fast that I got no feedback for my action until I minimize or move the original debugger.

With respect to my own workflow, this is sufficiently annoying to call that a regression.
Is it just me?

Nicolas


Reply | Threaded
Open this post in threaded view
|

Re: Windows opening in background

marcel.taeumel
Nicolas Cellier wrote
It often happens that a window opens behind the currently active one.
Typically, I want to 'debug it' on a subexpression in the debugger.
The second debugger opens in background, or does it go into background
after opening?
Anyway, it's sufficiently fast that I got no feedback for my action until I
minimize or move the original debugger.

With respect to my own workflow, this is sufficiently annoying to call that
a regression.
Is it just me?

Nicolas
Hi Nicolas,

this happens when you "debug it" via the context menu, right? It should not happen when you press CMD+SHIFT+D.

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: Windows opening in background

marcel.taeumel
marcel.taeumel wrote
Nicolas Cellier wrote
It often happens that a window opens behind the currently active one.
Typically, I want to 'debug it' on a subexpression in the debugger.
The second debugger opens in background, or does it go into background
after opening?
Anyway, it's sufficiently fast that I got no feedback for my action until I
minimize or move the original debugger.

With respect to my own workflow, this is sufficiently annoying to call that
a regression.
Is it just me?

Nicolas
Hi Nicolas,

this happens when you "debug it" via the context menu, right? It should not happen when you press CMD+SHIFT+D.

Best,
Marcel
Hi Nicolas,

fixed: http://forum.world.st/The-Trunk-Morphic-mt-1274-mcz-td4910898.html

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: Windows opening in background

Nicolas Cellier
thanks!
I just wonder out of where you found the fix, it does not seem at all obvious to me.

2016-08-13 13:41 GMT+02:00 marcel.taeumel <[hidden email]>:
marcel.taeumel wrote
>
> Nicolas Cellier wrote
>> It often happens that a window opens behind the currently active one.
>> Typically, I want to 'debug it' on a subexpression in the debugger.
>> The second debugger opens in background, or does it go into background
>> after opening?
>> Anyway, it's sufficiently fast that I got no feedback for my action until
>> I
>> minimize or move the original debugger.
>>
>> With respect to my own workflow, this is sufficiently annoying to call
>> that
>> a regression.
>> Is it just me?
>>
>> Nicolas
> Hi Nicolas,
>
> this happens when you "debug it" via the context menu, right? It should
> not happen when you press CMD+SHIFT+D.
>
> Best,
> Marcel

Hi Nicolas,

fixed: http://forum.world.st/The-Trunk-Morphic-mt-1274-mcz-td4910898.html

Best,
Marcel



--
View this message in context: http://forum.world.st/Windows-opening-in-background-tp4910565p4910899.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.




Reply | Threaded
Open this post in threaded view
|

Re: Windows opening in background

marcel.taeumel
Nicolas Cellier wrote
thanks!
I just wonder out of where you found the fix, it does not seem at all
obvious to me.

2016-08-13 13:41 GMT+02:00 marcel.taeumel <[hidden email]>:

> marcel.taeumel wrote
> >
> > Nicolas Cellier wrote
> >> It often happens that a window opens behind the currently active one.
> >> Typically, I want to 'debug it' on a subexpression in the debugger.
> >> The second debugger opens in background, or does it go into background
> >> after opening?
> >> Anyway, it's sufficiently fast that I got no feedback for my action
> until
> >> I
> >> minimize or move the original debugger.
> >>
> >> With respect to my own workflow, this is sufficiently annoying to call
> >> that
> >> a regression.
> >> Is it just me?
> >>
> >> Nicolas
> > Hi Nicolas,
> >
> > this happens when you "debug it" via the context menu, right? It should
> > not happen when you press CMD+SHIFT+D.
> >
> > Best,
> > Marcel
>
> Hi Nicolas,
>
> fixed: http://forum.world.st/The-Trunk-Morphic-mt-1274-mcz-td4910898.html
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/Windows-
> opening-in-background-tp4910565p4910899.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
>
Hi Nicolas,

this is how I did it:

(1) There is a window coming to front, so put "self haltOnce" in SystemWindow >> #comeToFront.
(2) Specialize that breakpoint with "if you are a workspace and the current top window is a message set" like around a workspace where I used the menu to open "implementors" on some text selection.
(3) The stack showed me that there is event bubbling going on after the menu dismissed, which surprised me because my mental model of pop-up menus in Morphic is state-based not function-based (i.e. spinning on the stack).
(4) Then I found that #yellowButtonActivity: does this functional spinning for pluggable text morphs where any other scroll pane (e.g. pluggable list morphs) do it state-based.

This most tricky part was to interpret the stack of the debugger and it required much knowledge about the event dispatching mechanism in Morphic, which I worked on a lot in the past months.

In the end, I agree with Bert's argument that function-based spinning (i.e. modal invocation) from the old MVC days is not appropriate for Morphic because it causes many sorts of bugs, which are hard to debug.

Morphic's tools and halos work better with state-based challenges/bugs. :-) For later, I also flagged TextMorph >> #yellowButtonActivity: because I have no idea how this code gets called at all. Their senders might rely on having a function-based invocation of menu.

Best,
Marcel