TEDIT: which process should an imageobject's when-selected function run in?

[rmkaplan]

This question came up as I have been sorting out the interactions between Tedit's buttoneventfn, which runs in the Mouse process, and other actions that run in the Tedit editing process attached to the document window.

When an image object is selected in a document, the original code runs its WHENOPERATEDONFN in the Mouse process (with HOWOPERATEDON set to SELECTED). But in one of our discussions, there was a suggestion that only lightweight computation should run in the Mouse, and heavier (or perhaps unknown) computations should run in their own separate process.

With the refactored code it is relatively* easy to have the buttoneventfn only track the mouse to determine the selection before sending it over to the Tedit process for interpretation, including execution of any imageobj functions. Is that the right thing to do, to lighten up the mouse? Or just leave it alone.

[*There is a minor complication with respect to Tedit menus, which have their own process. A little extra work to make sure that they don't steal the TTY from the main Tedit window or from somewhere else. Some but not all of the menu buttons already send the TTY back--the few outliers would have to be fixed.]

[masinter]

I think the main constraint that causes an action to be deferred to another process is when you need separate operations to be serialized, so you don't intermix the two separate operations.

[nbriggs]

Re: "need separate operations to be serialized" - yes, generally. If you don't need the serialization, but things start from a button event function, see the documentation for (SPAWN.MOUSE) and (ALLOW.BUTTON.EVENTS)

[rmkaplan]

So, suppose the function takes a long time but blocks every now and then. If the execution is passed off to the Tedit process, then the mouse would be open for another invocation before the first one completed. Is that what is avoided by staying in the mouse?

[nbriggs]

Yes. While the mouse process is operating on behalf of the TEdit buttoneventfn it can't cause any other button events - blocking may keep other processes running, but you can't, for example, close even some unrelated window. Unless... the TEdit button event fn calls ALLOW.BUTTON.EVENTS which will keep this mouse process doing its thing for TEdit, spawn another mouse process to handle any other button events, and then have this mouse process exit when it is done.

So I think the question is whether doing some other TEdit button event before this one has completed will cause trouble - if yes, then don't ALLOW.BUTTON.EVENTS, because you can't control whether it's operating on a TEdit window or some other window. The user could force a SPAWN.MOUSE via an exec (or from a break window) - so you still might have things happening in an order you don't expect.

[masinter]

i think we need a database entity relation table something like this

process (aka thread), window, stream, tty, interrupt, mouse position, mouse button

a process can have no, 1, or many windows a window can have 0 or 1 process , (WHICHW) gives you the top-moat window at the mouse position

• there are two pr
• the tty belongs to one process, receives keyboard events, and queues them or interrupts the process depending on the termtable of the process.
• windows get button events which need to be dispatched to the process
• ...

These rules aren't enforced and it is possible to break them, but you'll get anomalous behavior that you have to patch around.

[rmkaplan]

In the release sysout (old Tedit), suppose the caret is blinking in the Exec window and you click on SHOW or NEUTRAL in the paragraph or looks menu attached to a Tedit window. The caret disappears from the Exec window, and in fact, isn't blinking anywhere.

The TTY appears to have ended up in the menu's process, but not in a place that accepts type-in. Same thing happens if the caret starts out blinking in the Tedit window of the menu, or another Tedit or Sedit window.

Is that the desired behavior? If you click on a button that only displays menu information instead of in one of the fill-in fields of the menu, wouldn't it be more intuitive for the caret/TTY to go back to where it was?

[rmkaplan]

With respect to my previous comment, I think the right convention is that the TTY should go to the main Tedit window whenever the menu operation is complete, even if the TTY started somewhere else. This is to create the illusion that the attached menus are really part of the Tedit ensemble, even if they have their own separate processes. Clicking on a menu button activates that ensemble, as if you had clicked in the main window--it's just that the menu operation executes before the caret starts flashing at the selection in the main.

[nbriggs]

If I understand, if you click in a type-in field in the menu pane, then click the Apply button, the TTY would go back to the main TEdit window? I think that will make sense.

[rmkaplan]

Yes, and after you click another button, like Bold that only sets a parameter but doesn’t do anything else, the TTY now also goes back to the main Tedit window. Before, in some cases your next character would disappear, in other cases it would tell you that you had to select a place for the type-in, even though there was already a selection.

On Feb 26, 2024, at 11:48 PM, Nick Briggs @.***> wrote:

If I understand, if you click in a type-in field in the menu pane, then click the Apply button, the TTY would go back to the main TEdit window? I think that will make sense.

— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/1552#issuecomment-1965963928, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJIZGRIIMSQ5HP44A73YVWFU3AVCNFSM6AAAAABDXTE6Z6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRVHE3DGOJSHA. You are receiving this because you authored the thread.