Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

Time sharing: The use of many people by the computer.


programming / comp.lang.tcl / Re: Looking for non-modal alternatives to tk_messageBox

SubjectAuthor
* Looking for non-modal alternatives to tk_messageBoxMichael Soyka
`* Re: Looking for non-modal alternatives to tk_messageBoxsaitology9
 `* Re: Looking for non-modal alternatives to tk_messageBoxMichael Soyka
  +* Re: Looking for non-modal alternatives to tk_messageBoxAndreas Leitgeb
  |`* Re: Looking for non-modal alternatives to tk_messageBoxRobert Heller
  | +- Re: Looking for non-modal alternatives to tk_messageBoxMichael Soyka
  | `* Re: Looking for non-modal alternatives to tk_messageBoxMichael Soyka
  |  +- Re: Looking for non-modal alternatives to tk_messageBoxRobert Heller
  |  `* Re: Looking for non-modal alternatives to tk_messageBoxsaitology9
  |   +* Re: Looking for non-modal alternatives to tk_messageBoxRobert Heller
  |   |+* Re: Looking for non-modal alternatives to tk_messageBoxMichael Soyka
  |   ||`- Re: Looking for non-modal alternatives to tk_messageBoxRobert Heller
  |   |`- Re: Looking for non-modal alternatives to tk_messageBoxsaitology9
  |   `* Re: Looking for non-modal alternatives to tk_messageBoxSchelte
  |    +* Re: Looking for non-modal alternatives to tk_messageBoxsaitology9
  |    |`* Re: Looking for non-modal alternatives to tk_messageBoxAndreas Leitgeb
  |    | `- Re: Looking for non-modal alternatives to tk_messageBoxRich
  |    `- Re: Looking for non-modal alternatives to tk_messageBoxsaitology9
  +- Re: Looking for non-modal alternatives to tk_messageBoxjtyler
  `* Re: Looking for non-modal alternatives to tk_messageBoxsaitology9
   +- Re: Looking for non-modal alternatives to tk_messageBoxMichael Soyka
   `* Re: Looking for non-modal alternatives to tk_messageBoxAndreas Leitgeb
    `* Re: Looking for non-modal alternatives to tk_messageBoxMichael Soyka
     +- Re: Looking for non-modal alternatives to tk_messageBoxRobert Heller
     `* Re: Looking for non-modal alternatives to tk_messageBoxsaitology9
      `* Re: Looking for non-modal alternatives to tk_messageBoxjtyler
       `- Re: Looking for non-modal alternatives to tk_messageBoxSchelte

Pages:12
Subject: Re: Looking for non-modal alternatives to tk_messageBox
From: Andreas Leitgeb
Newsgroups: comp.lang.tcl
Organization: A noiseless patient Spider
Date: Mon, 18 Apr 2022 20:47 UTC
References: 1 2 3 4 5 6 7 8 9
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: avl...@logic.at (Andreas Leitgeb)
Newsgroups: comp.lang.tcl
Subject: Re: Looking for non-modal alternatives to tk_messageBox
Date: Mon, 18 Apr 2022 20:47:36 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 35
Message-ID: <slrnt5rjj8.10f1.avl@logic.at>
References: <10556088-a5a7-429c-80e7-81bf1ffaa3f6n@googlegroups.com>
<t3alak$6o6$1@gioia.aioe.org>
<b2e1d5fd-e709-4a2e-8330-417f5db860a2n@googlegroups.com>
<slrnt5jls6.10f1.avl@logic.at>
<YZydnRDrw9GYdMT_nZ2dnUU7-fPNnZ2d@giganews.com>
<9834d8ff-a9e8-4dee-bc9b-3d7466178e2an@googlegroups.com>
<t3k3i8$18qe$1@gioia.aioe.org> <nnd$29fb125c$57f62c37@5ee216bc46b01296>
<t3kd1o$1dcc$1@gioia.aioe.org>
Reply-To: avl@logic.at
Injection-Date: Mon, 18 Apr 2022 20:47:36 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="106e8a8e21fcbe5b5020558033533a89";
logging-data="7333"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX188+6zqhxDLGo3dJv1XGf/W"
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:ia4K3SffH2+wx48HfCBSgypDolU=
View all headers
saitology9@gmail.com <saitology9@gmail.com> wrote:
I am not sure I read you correctly.  Are you saying all other toplevels
are also locked due to the grab?  If so, I would be surprised as it is
contrary to my experience and to the documentation. The manual would
have to refer to the "application" and not the "window".

Also see the man page for grab.  You can set it as global meaning
application-wide, or local, meaning a single toplevel.

The "grabwindow" is really the start of the subtree that can still
receive events.

 From the man page:
DESCRIPTION
       When  a  grab  is set for a ***particular window***, Tk restricts all pointer
       events to the grab window and its descendants in Tk's window hierarchy.

I understood the phrase "X restricts Y to Z" such that that X causes Y
to be "allowed only with Z".

I can imagine that other people might read it entirely different,
thinking of "pointer events to Z" as the object of restriction, and
reading the object of restriction as a thing being forbidden...

And finally, there is a windows-specific behaviour: that applications
cannot just grab the whole screen exclusively.
So, on Windows, a global grad is (as far as I've read long ago) really
also just a local grab.

Otoh., a global grab on Linux has the power of locking the user's session
completely, e.g. like a screen-lock would be expected to do
Instead, a local grab just blocks the rest of the same application - that
is: all this application's toplevels, but would not interfere with a
switch to other applications.



Subject: Re: Looking for non-modal alternatives to tk_messageBox
From: Rich
Newsgroups: comp.lang.tcl
Organization: A noiseless patient Spider
Date: Mon, 18 Apr 2022 21:37 UTC
References: 1 2 3 4 5 6 7 8 9 10
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ric...@example.invalid (Rich)
Newsgroups: comp.lang.tcl
Subject: Re: Looking for non-modal alternatives to tk_messageBox
Date: Mon, 18 Apr 2022 21:37:30 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 28
Message-ID: <t3klmq$76a$1@dont-email.me>
References: <10556088-a5a7-429c-80e7-81bf1ffaa3f6n@googlegroups.com> <t3alak$6o6$1@gioia.aioe.org> <b2e1d5fd-e709-4a2e-8330-417f5db860a2n@googlegroups.com> <slrnt5jls6.10f1.avl@logic.at> <YZydnRDrw9GYdMT_nZ2dnUU7-fPNnZ2d@giganews.com> <9834d8ff-a9e8-4dee-bc9b-3d7466178e2an@googlegroups.com> <t3k3i8$18qe$1@gioia.aioe.org> <nnd$29fb125c$57f62c37@5ee216bc46b01296> <t3kd1o$1dcc$1@gioia.aioe.org> <slrnt5rjj8.10f1.avl@logic.at>
Injection-Date: Mon, 18 Apr 2022 21:37:30 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="11a8aff1d271d7cbfc6a4b5c0e145825";
logging-data="7370"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+YzYp44VWL/CgBFngXrDAY"
User-Agent: tin/2.0.1-20111224 ("Achenvoir") (UNIX) (Linux/3.10.17 (x86_64))
Cancel-Lock: sha1:XpFBf4NWKeTkS24FFXZbF37sSFA=
View all headers
Andreas Leitgeb <avl@logic.at> wrote:
saitology9@gmail.com <saitology9@gmail.com> wrote:
I am not sure I read you correctly.  Are you saying all other toplevels
are also locked due to the grab?  If so, I would be surprised as it is
contrary to my experience and to the documentation. The manual would
have to refer to the "application" and not the "window".

The "grabwindow" is really the start of the subtree that can still
receive events.

 From the man page:
DESCRIPTION
       When  a  grab  is set for a ***particular window***, Tk
       restricts all pointer events to the grab window and its
       descendants in Tk's window hierarchy.

I understood the phrase "X restricts Y to Z" such that that X causes Y
to be "allowed only with Z".

Your understanding is how a 'grab' is intended to function.

A language tweak to the grab man page to clear up the possible
ambiguity could be:

When a grab is set for a ***particular window***, Tk restricts all
pointer events to __be sent only to__ the grab window and its
descendants in Tk's window hierarchy.



Pages:12
rocksolid light 0.7.2
clearneti2ptor