Re: use of special-event-map

Re: use of special-event-map

[Stefan Monnier]

> Trying this question again. I want behavior `foobar' to replace
> iconification when you click the window-manager "minimize" button.

I'm glad to see you can't.  I positively hate it when applications refuse to
react to window-manager commands.  What is that `foobar' you want to do?


        Stefan

RE: use of special-event-map

[Drew Adams]

    > I want behavior `foobar' to replace iconification when
    > you click the window-manager "minimize" button.

    I'm glad to see you can't.  I positively hate it when
    applications refuse to react to window-manager commands.

FYI: 1) Just experimenting/learning. 2) For my own use. 3) A user option -
even if only for this user.

No one suggested imposing such button behavior on anyone.

Re: use of special-event-map

[Stefan Monnier]

>     The `iconify-frame' event is just informing that the frame has
>     been iconified.

> That answers my question. The event indicates that iconification has
> occurred, not that the "minimize" button was clicked.

> That's the info I was missing - thanks for it. I didn't know at what point
> Emacs received a window-manager event for this. I found no explanation of
> special events like [iconify-frame] in such terms. I tried to follow the
> code that deals with this event (in parts of w32term.c, xterm.c, frame.c,
> and keyboard.c), but this wasn't clear to me.

Well, I'm just guessing.  But the reason why iconification should not be
overridable is that window managers with workspaces actually implement the
"workspaces" by iconifying/deiconifying windows as you move from one
workspace to another.


        Stefan

Re: use of special-event-map

[Thien-Thi Nguyen]

"Drew Adams" <drew.adams@oracle.com> writes:

> I didn't know at what point Emacs received a window-manager
> event for this. I found no explanation of special events like
> [iconify-frame] in such terms. I tried to follow the code that
> deals with this event (in parts of w32term.c, xterm.c, frame.c,
> and keyboard.c), but this wasn't clear to me.

generally, emacs' awareness of events happens after the event,
which happens after the window manager is through munging and/or
generating the event.

programmability of window manager behavior from elisp is only
possible if the window manager (1) is programmable; (2) provides
an interface that accepts hints from emacs on how to do its job;
and (3) honors those hints.

(1) is easy to arrange, (2) less so, (3) even less.  in any case
it is all very window manager specific unless you are willing to
add to emacs the rest of ICCCM (aside from the "Extended Segments
in X selections" support which is already in place, iiuc).  and
even then, to what extent ICCCM is supported by the window manager
as well as the (non-)expressiveness of ICCCM to implement the
desired behavior, remains uncertain.

thi

Re: use of special-event-map

[Stefan Monnier]

>> I want behavior `foobar' to replace iconification when
>> you click the window-manager "minimize" button.

>     I'm glad to see you can't.  I positively hate it when
>     applications refuse to react to window-manager commands.

> FYI: 1) Just experimenting/learning. 2) For my own use. 3) A user option -
> even if only for this user.

The `iconify-frame' event is just informing that the frame has
been iconified.  So it can't be used for what you want, and AFAIK there's no
way from elisp to do what you want.  Here's a solution: change your desire.
It's not like there aren't any other interesting experiment/learning
opportunities around.


        Stefan

RE: use of special-event-map

[Drew Adams]

    The `iconify-frame' event is just informing that the frame has
    been iconified.

That answers my question. The event indicates that iconification has
occurred, not that the "minimize" button was clicked.

That's the info I was missing - thanks for it. I didn't know at what point
Emacs received a window-manager event for this. I found no explanation of
special events like [iconify-frame] in such terms. I tried to follow the
code that deals with this event (in parts of w32term.c, xterm.c, frame.c,
and keyboard.c), but this wasn't clear to me.

Re: use of special-event-map

[Kevin Rodgers]

Drew Adams wrote:
>     The `iconify-frame' event is just informing that the frame has
>     been iconified.
> 
> That answers my question. The event indicates that iconification has
> occurred, not that the "minimize" button was clicked.
> 
> That's the info I was missing - thanks for it. I didn't know at what point
> Emacs received a window-manager event for this. I found no explanation of
> special events like [iconify-frame] in such terms. I tried to follow the
> code that deals with this event (in parts of w32term.c, xterm.c, frame.c,
> and keyboard.c), but this wasn't clear to me.

Again, see the Misc Events node (aka Miscellaneous Window System Events
section) of the Emacs Lisp manual.

-- 
Kevin Rodgers

Re: use of special-event-map

[Michael Cadilhac]

[-- Attachment #1.1: Type: text/plain, Size: 1321 bytes --]

"Drew Adams" <drew.adams@oracle.com> writes:

> Another question about use of `special-event-map' - consider this code:
>
> (define-key special-event-map [iconify-frame] 'toto)
>
> (defun foo ()
>   (interactive)
>   (let ((binding (lookup-key special-event-map [iconify-frame])))
>     (define-key special-event-map [iconify-frame] 'ignore-event)
>     (iconify-frame)
>     (define-key special-event-map [iconify-frame] binding)))
>
> (defun toto (event)
>   (interactive "e")
>   (message "TOTO"))
>
> When I try M-x foo, `toto' gets executed, even though `foo' tries to remove
> its binding. Same thing happens if I use `nil' instead of `ignore-event'.
>
> Explanation? Any way around this? That is, is there some way I can inhibit
> the binding of [iconify-frame] for the duration of command foo?

  Hi !

  Mhhh, don't know if it works in any case (using Ion, iconify doesn't
  make much sense), but, well... Try this:

(defun foo ()
  (interactive)
  (iconify-frame)
  (while (not (input-pending-p))
    (sit-for 1))
  (discard-input))

-- 
    Michael Cadilhac, a.k.a. Micha [mika] |
                    Epita/LRDE promo 2007 |  Please note that you should
  2 rue de la Convention | 01.46.70.90.75 |  s/-@t-/@/ my mail address.
94270 Le Kremlin Bicetre | 06.23.20.31.30 |

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

RE: use of special-event-map

[Drew Adams]

    > Another question about use of `special-event-map' - consider 
    this code:
    >
    > (define-key special-event-map [iconify-frame] 'toto)
    >
    > (defun foo ()
    >   (interactive)
    >   (let ((binding (lookup-key special-event-map [iconify-frame])))
    >     (define-key special-event-map [iconify-frame] 'ignore-event)
    >     (iconify-frame)
    >     (define-key special-event-map [iconify-frame] binding)))
    >
    > (defun toto (event)
    >   (interactive "e")
    >   (message "TOTO"))
    >
    > When I try M-x foo, `toto' gets executed, even though `foo' 
    tries to remove
    > its binding. Same thing happens if I use `nil' instead of 
    `ignore-event'.
    >
    > Explanation? Any way around this? That is, is there some way 
    I can inhibit
    > the binding of [iconify-frame] for the duration of command foo?
        
    (defun foo ()
      (interactive)
      (iconify-frame)
      (while (not (input-pending-p))
        (sit-for 1))
      (discard-input))
    
Very nice! Works like a charm. Merci. - Drew

use of special-event-map

[Drew Adams]

In a different thread, Stefan suggested:

  to catch the "press the delete button in the WM",
  ...change the binding for the delete-frame event
  in special-event-map (defaults to handle-delete-frame).

Cool. I didn't know about `special-event-map'.

I tried this:

  (defun foo-on-event (event)
    (interactive "e")
    (let ((frame (posn-window (event-start event))))
      (foobar frame)))

  (define-key special-event-map [iconify-frame] 'foo-on-event)

This works, in the sense that `foo-on-event' is executed whenever you click
the window-manager `iconify' (minimize) button.

However, `foo-on-event' is executed after the frame is in fact iconified (by
the window manager). I can deiconify the frame in the `foo-on-event' code,
but the result is that when you click the minimize button the frame is first
iconified, then deiconified, then the rest of the `foo-on-event' behavior
(foobar) occurs.

Suggestions? Any way to intercept (i.e. prevent) the window-manager's
minimization of the frame?

FYI - I'm using Windows XP, in case it's relevant.

RE: use of special-event-map

[Drew Adams]

Another question about use of `special-event-map' - consider this code:

(define-key special-event-map [iconify-frame] 'toto)

(defun foo ()
  (interactive)
  (let ((binding (lookup-key special-event-map [iconify-frame])))
    (define-key special-event-map [iconify-frame] 'ignore-event)
    (iconify-frame)
    (define-key special-event-map [iconify-frame] binding)))

(defun toto (event)
  (interactive "e")
  (message "TOTO"))

When I try M-x foo, `toto' gets executed, even though `foo' tries to remove
its binding. Same thing happens if I use `nil' instead of `ignore-event'.

Explanation? Any way around this? That is, is there some way I can inhibit
the binding of [iconify-frame] for the duration of command foo?

RE: use of special-event-map

[Drew Adams]

Trying this question again. I want behavior `foobar' to replace
iconification when you click the window-manager "minimize" button. This
almost does that:

      (defun foo-on-event (event)
        (interactive "e")
        (let ((frame (posn-window (event-start event))))
          (foobar frame)))

      (define-key special-event-map [iconify-frame] 'foo-on-event)

`foo-on-event' is executed whenever you click the window-manager `iconify'
(minimize) button, but it is executed after the frame is iconified by the
window manager. That is, I get a combination of iconification plus `foobar',
instead of just `foobar'.

I can deiconify the frame within the `foo-on-event' code, but the result is
of course that the frame is iconified, then deiconified, then foobar's
behavior occurs. I can't seem to get rid of the window-manager
iconification.

Suggestions? Any way to intercept (i.e. prevent) the window-manager's
minimization of the frame?