Hi Chris,


I honestly don't think that we should individualize the behavior of the message body per kind of the dialog window. Even if there is a list chooser, it may still contain a relevant message text that I'd like to copy. And how often will such "stray mouse clicks" occur in real life? And if it occurred, you should have your fingers at your mouse anyway ;)


If at all, I would rather like to press Escape or Tab when the message text has the focus, in order to move the focus back to the dialog window.

If we wanted this, we either could implement this in Editor or, via an event filter, in DialogWindow. What do you think?


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Chris Cunningham <cunningham.cb at gmail.com>
Gesendet: Samstag, 6. Juni 2020 19:13:57
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: Morphic-cbc.1665.mcz

What do you think about Morphic-cbc.1667?

It accepts your changes, removes mine, and still locks the message for (at present) 3 dialogs boxes in the image:
- In ListChooser, when you have selected a partial of a choice, it asks to confirm a partial, a new, or cancel
- In MonticelloConfirgurationBrowser, asking you to confirm saving the configuration
- Any generic call to UserDialogBoxMorph>>confirm:trueChoice:falseChoice:  (where it locks the static message text 'Please Confirm:')

-cbc

On Sat, Jun 6, 2020 at 9:36 AM Chris Cunningham <cunningham.cb at gmail.com<mailto:cunningham.cb at gmail.com>> wrote:
Ok.  There are definite benefits with this.  However, a stray mouse click still reduces the usefulness of a list chooser.

Maybe ListChooser should be able to request the message rejects keyboard (this dialog is all about choosing a value, not about displaying a notice), while others could use ct.1666?  At least with this the enter button will close the dialog - but allow full interaction with the message (as long as you start by using the mouse).

-cbc

On Sat, Jun 6, 2020 at 5:22 AM Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>> wrote:

Hi Chris,


what do you think about Morphic-ct.1666? :-) It would be nice if we did not completely lose the opportunity to manually activate the message and interact with it via keyboard.


Best,

Christoph


________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org<mailto:squeak-dev-bounces at lists.squeakfoundation.org>> im Auftrag von Chris Cunningham <cunningham.cb at gmail.com<mailto:cunningham.cb at gmail.com>>
Gesendet: Samstag, 6. Juni 2020 04:41:50
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: Morphic-cbc.1665.mcz

This fixes the mangling I accidentally did to Marcel's changes, following his suggestion (roughly).

I now get the best of both worlds in my image.  If noone objects, I'll move it to trunk in a few days.

-cbc

On Fri, Jun 5, 2020 at 7:38 PM <commits at source.squeak.org<mailto:commits at source.squeak.org>> wrote:
A new version of Morphic was added to project The Inbox:
http://source.squeak.org/inbox/Morphic-cbc.1665.mcz

==================== Summary ====================

Name: Morphic-cbc.1665
Author: cbc
Time: 5 June 2020, 7:38:31.284262 pm
UUID: c887ffd7-40ae-3547-8240-13186db081c8
Ancestors: Morphic-cbc.1664

Add support for locking a morph so that it doesn't accept keyboard actions - but is still accessible with the mouse.  Sending #rejectKeyboardFocus will make that morph completely ignore keyboard events of any kind.  A morph can be tested with #shouldRejectKeyboardFocus to see if this should happen.
DialogWindow has been modified to reject keyboard focus, so that in (say, ConfirmDialogs) you can still use the keyboard to interact with the keys AND you can interact with the message text via the mouse.
(Also updated StringMorph similarly.)

=============== Diff against Morphic-cbc.1664 ===============

Item was changed:
  ----- Method: DialogWindow>>createMessage: (in category 'initialization') -----
  createMessage: aString

        messageMorph := aString asText asMorph.
        messageMorph
                name: 'Message';
                readOnly: true;
                setProperty: #indicateKeyboardFocus toValue: #never;
+               rejectKeyboardFocus.
-               lock.
        self setMessageParameters.
        ^ messageMorph!

Item was added:
+ ----- Method: Morph>>rejectKeyboardFocus (in category 'accessing') -----
+ rejectKeyboardFocus
+       self rejectKeyboardFocus: true.!

Item was added:
+ ----- Method: Morph>>rejectKeyboardFocus: (in category 'accessing') -----
+ rejectKeyboardFocus: boolean
+       self setProperty: #rejectKeyboardFocus toValue: boolean!

Item was changed:
  ----- Method: Morph>>rejectsEvent: (in category 'events-processing') -----
  rejectsEvent: anEvent
        "Return true to reject the given event. Rejecting an event means neither the receiver nor any of it's submorphs will be given any chance to handle it."
+       ^self isLocked or: [self visible not or: [anEvent isKeyboard and: [self shouldRejectKeyboardFocus]]]!
-       ^self isLocked or:[self visible not]!

Item was added:
+ ----- Method: Morph>>rejectsKeyboardFocus (in category 'testing') -----
+ rejectsKeyboardFocus
+       ^self valueOfProperty: #rejectKeyboardFocus ifAbsent: [false]!

Item was added:
+ ----- Method: Morph>>shouldRejectKeyboardFocus (in category 'testing') -----
+ shouldRejectKeyboardFocus
+       ^self valueOfProperty: #rejectKeyboardFocus ifAbsent: [false]!

Item was changed:
  ----- Method: StringMorph>>wouldAcceptKeyboardFocus (in category 'event handling') -----
  wouldAcceptKeyboardFocus
+       ^ self isLocked not and: [self shouldRejectKeyboardFocus not]!
-       ^ self isLocked not!



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200606/6de9d967/attachment.html>