Update vs. Open tools attached to mouse cursor

[j4yk]

Because the update is blocking, I cannot move the transcript into a place where I can already read the text. I can only do that once the update is finished.

Priority: minor. Squeak Trunk update 22050->22132 (when I took the screenshot)

[LinqLover]

Oh yes, this has been irritating me for years, too. My attempt was to disable the preference while the update is being performed. But since the update can be interrupted (e.g., during a merge conflict), the resulting behavior felt inconsistent. Maybe add a specific Transcript openInWorldIfNone?

[j4yk]

I wondered whether one can specifically open a Transcript off the hand, ignoring the preference, when the update is started. If desired, the update could also attach it to the hand at the end if this makes sense and the preference is enabled.

[LinqLover]

But does it make sense to restrict such a preference to the transcript? During a longer period of non-interactive operations (such as installing an update), every window that is opened in hand tends to look ugly ...

Yes, a #dontOpenToolsInHandDuring: or #deferOpenToolsInHandDuring: could be useful. I implemented a proposal for the former in openToolsInHandStrategy ... it is just waiting for a review. :-)

[j4yk]

Hmm, I would not like to let the concept of attaching tools to the mouse cursor leak into code that may not be related to tools or GUI at all (such as managing a long-running operation). For example, putting the code to circumvent the preference into the code for the "Update Squeak" menu item would be fine for me, but not putting it into the McmUpdater.

So if you want a general solution, you would need some magic trigger that detects or indicates long-running operations in the UI process... and by the time that triggers, something might have been attached to the cursor already.

[LinqLover]

Fair point ... Ideally, we would not have blocking operations at all but just background jobs, right? :D

Here's another idea: Store all "attach requests" in a queue and apply them at the end of the world cycle/at the beginning of the next world cycle, just like deferred UI messages and step messages. Wdyt?

[j4yk]

Fair point ... Ideally, we would not have blocking operations at all but just background jobs, right? :D

For a system that has forever had concurrent processing, Squeak's GUI is a bit behind the state of the art in this regard. ;-)

Here's another idea: Store all "attach requests" in a queue and apply them at the end of the world cycle/at the beginning of the next world cycle, just like deferred UI messages and step messages. Wdyt?

Sounds like it could work. This is probably something that you could quickly implement and try out for a while. You do not even need a separate queue; just use addDeferredUiMessage for the addMorph to the hand, no?

[LinqLover]

Fair point ... Ideally, we would not have blocking operations at all but just background jobs, right? :D

For a system that has forever had concurrent processing, Squeak's GUI is a bit behind the state of the art in this regard. ;-)

+1. But it also has its upsides ... modal dialogs communicate the timespan of an operation very nicely.

Here's another idea: Store all "attach requests" in a queue and apply them at the end of the world cycle/at the beginning of the next world cycle, just like deferred UI messages and step messages. Wdyt?

Sounds like it could work. This is probably something that you could quickly implement and try out for a while. You do not even need a separate queue; just use addDeferredUiMessage for the addMorph to the hand, no?

Right. Everyone who wishes shall participate in this experiment:

SystemWindow-openAsTool.zip

[LinqLover]

Right. Everyone who wishes shall participate in this experiment:

SystemWindow-openAsTool.zip

Two hick-ups I noticed so far:

• The tool must not be opened in hand if it was already deleted again when the stepping message is processed
• For debuggers, this currently looks shaky because the debugger redraws the world (the debugger window not being attached to the hand at this moment) before the next stepping messages are processed.