Add function to make frame topmost?

Add function to make frame topmost?

[Lennart Borgman]

Could something like this please be added to w32fns.c?

DEFUN ("x-set-frame-topmost", Fx_set_frame_topmost,
Sx_set_frame_topmost, 1, 3, 0,
       doc: /* Make frame FRAME topmost if TOP, otherwise not topmost.
When ACTIVATE try to activate freme. */)
     (frame, top, activate)
     Lisp_Object frame, top, activate;
{
  FRAME_PTR f = check_x_frame (frame);
  HWND hwndInsertAfter = NILP (top) ? HWND_NOTOPMOST : HWND_TOPMOST;
  UINT swp_flags = SWP_NOMOVE | SWP_NOSIZE;
  if (NILP (activate)) swp_flags = swp_flags | SWP_NOACTIVATE;
  BLOCK_INPUT;
  /* non-zero success, 0 fail + use GetLastError. */
  SetWindowPos (FRAME_W32_WINDOW (f), hwndInsertAfter,
                0, 0, 0, 0,
                swp_flags);
  UNBLOCK_INPUT;
  return Qnil;
}

Re: Add function to make frame topmost?

[Stefan Monnier]

> Could something like this please be added to w32fns.c?

First, if it's w32-specific, its name should not start with "x-" but
with "w32-".  If it's not, then its name should start with neither and
the DEFUN should be in a system-independent file.

Finally, I don't know what means "topmost", so the docstring needs to
be improved.


        Stefan


PS: Yes, I know we don't currently follow those rules everywhere, that's
something we need to fix.

Re: Add function to make frame topmost?

[Lennart Borgman]

On Fri, Apr 30, 2010 at 3:06 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> Could something like this please be added to w32fns.c?
>
> First, if it's w32-specific, its name should not start with "x-" but
> with "w32-".  If it's not, then its name should start with neither and
> the DEFUN should be in a system-independent file.

This version is w32-specific, yes. It will only appear in an Emacs
compiled for w32.

Looking at w32fns.c it looks to me like this is how some functions
(for example x-show-tip) that must have different implemantations for
x and w32 are handled. But indeed that looks like a bad convention
since it makes it impossible to choose function according to the
display used.

So I will rename it to w32-set-frame-topmost. And I think some other
functions also should be renamed and integrated in the way I suggest
below.

Then there should of course be a similar function x-set-frame-topmost
for X windows, but I can't write that.

To tie this together I think something like

  (defun set-frame-topmost (frame top activate)
    (cond
     ((eq (display-type) 'x-windows) (x-set-frame-topmost frame top activate))
     ((eq (display-type) 'w32) (w32-set-frame-topmost frame top activate))))

is needed. The function `display-type' does not exist yet of course.

> Finally, I don't know what means "topmost", so the docstring needs to
> be improved.

Yes, "topmost" is what is used for tooltip etc to make that frame
window stay above other windows without having focus. On w32 (and I
guess on x) this also works across applications, ie a topmost frame
window stays above the active application.

My usecase for something like this is reminders that pops up at a
certain times. You may want to see them even if you are not in Emacs.
And you may prefer to not get interrupted when you type so directly
activating Emacs might not be a good thing.

Re: Add function to make frame topmost?

[Stefan Monnier]

>   (defun set-frame-topmost (frame top activate)
>     (cond
>      ((eq (display-type) 'x-windows) (x-set-frame-topmost frame top activate))
>      ((eq (display-type) 'w32) (w32-set-frame-topmost frame top activate))))

> is needed. The function `display-type' does not exist yet of course.

An alternative is to use the poor-man's OO system already in place and
just add a set_frame_topmost_hook to the terminal object.

>> Finally, I don't know what means "topmost", so the docstring needs to
>> be improved.
> Yes, "topmost" is what is used for tooltip etc to make that frame
> window stay above other windows without having focus. On w32 (and I
> guess on x) this also works across applications, ie a topmost frame
> window stays above the active application.
> My usecase for something like this is reminders that pops up at a
> certain times. You may want to see them even if you are not in Emacs.
> And you may prefer to not get interrupted when you type so directly
> activating Emacs might not be a good thing.

I see, thanks.  I don't know if there's a word for such things under X11
(I guess we should ask the freedesktop guys).


        Stefan

Re: Add function to make frame topmost?

[Jan Djärv]

30 apr 2010 kl. 22.54 skrev Stefan Monnier <monnier@IRO.UMontreal.CA>:

>
> I see, thanks.  I don't know if there's a word for such things under  
> X11
> (I guess we should ask the freedesktop guys).

You can tell the window manager that you would like to be topmost, but  
the window manager is free to ignore your request. You cant know for  
sure what will happen.

     Jan D.

Re: Add function to make frame topmost?

[Lennart Borgman]

On Sat, May 1, 2010 at 12:02 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
>
> 30 apr 2010 kl. 22.54 skrev Stefan Monnier <monnier@IRO.UMontreal.CA>:
>
>>
>> I see, thanks.  I don't know if there's a word for such things under X11
>> (I guess we should ask the freedesktop guys).
>
> You can tell the window manager that you would like to be topmost, but the
> window manager is free to ignore your request. You cant know for sure what
> will happen.


Thanks Jan. But how are tooltip frames handled on X by Emacs then?

On w32 you can say that a window (on a level corresponding to Emacs
frame) should be topmost. This is ortogonal to activating the app. And
the topmost property is per window, not per app.

Is this the same (sub)structure as on X?

Re: Add function to make frame topmost?

[Jan Djärv]

Lennart Borgman skrev 2010-05-01 00.13:
> On Sat, May 1, 2010 at 12:02 AM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>>
>>
>> 30 apr 2010 kl. 22.54 skrev Stefan Monnier<monnier@IRO.UMontreal.CA>:
>>
>>>
>>> I see, thanks.  I don't know if there's a word for such things under X11
>>> (I guess we should ask the freedesktop guys).
>>
>> You can tell the window manager that you would like to be topmost, but the
>> window manager is free to ignore your request. You cant know for sure what
>> will happen.
>
>
> Thanks Jan. But how are tooltip frames handled on X by Emacs then?

They have the flag override redirect set, that tells the window manager not to 
touch them at all.  This means that if they want to get mouse and keyboard 
events they have to grab the mouse and keyboard, as menus for example do.

If you have several override-redirect windows, the X stacking order determines 
who is topmost (XRaiseWindow and XLowerWindow functions).  Usually a override 
redirect window becomes topmost when it is created.

Windows that aren't override redirect windows are at the mercy of the window 
manager, it can choose to ignore XRaiseWindow/XLowerWindow done by windows.

>
> On w32 you can say that a window (on a level corresponding to Emacs
> frame) should be topmost. This is ortogonal to activating the app. And
> the topmost property is per window, not per app.
>
> Is this the same (sub)structure as on X?

Stacking order is per window.  In the extended window manager specification, 
there is a section on stacking, and what hints a window can have.  There is 
also an "Urgency" hint to indicate that this window is somehow urgent. 
Exactly what that means is up to the window manager.  From EWMH:

"Stacking order

To obtain good interoperability between different Desktop Environments, the 
following layered stacking order is recommended, from the bottom:

     * windows of type _NET_WM_TYPE_DESKTOP
     * windows having state _NET_WM_STATE_BELOW
     * windows not belonging in any other layer
     * windows of type _NET_WM_TYPE_DOCK (unless they have state 
_NET_WM_TYPE_BELOW) and windows having state _NET_WM_STATE_ABOVE
     * focused windows having state _NET_WM_STATE_FULLSCREEN

Windows that are transient for another window should be kept above this window.

The window manager may choose to put some windows in different stacking 
positions, for example to allow the user to bring currently a active window to 
the top and return it back when the window looses focus. "


	Jan D.

Re: Add function to make frame topmost?

[David De La Harpe Golden]

Stefan:
 >
 > I see, thanks.  I don't know if there's a word for such things
 > under X11 (I guess we should ask the freedesktop guys).

Not affiliated with freedesktop as such, just familiar with specs:

ITYM "Always on top" or "above other windows", or technically asking 
that _NET_WM_STATE include _NET_WM_STATE_ABOVE

N.B. For "normal" windows (such as ordinary emacs frames), this is 
something  usually configured by the user via the window manager's menu, 
setting it within emacs for normal frames would not be something I would 
particularly want or need to do, though possible (*** below), and 
setting it for special framey things is not AFAIK a good idea (following):

http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#STACKINGORDER

[lennart]
 > My use case for something like this is reminders that pops up at a
 > certain times.

Note that X11 apps (or more usually the gui toolkit the app uses) 
specify the purpose of the window in higher-level terms 
_NET_WM_WINDOW_TYPE, like "this is a tooltip", "this is a notification" 
_NET_WM_WINDOW_TYPE_TOOLTIP, _NET_WM_WINDOW_TYPE_NOTIFICATION
etc.

The window manager then places it in the appropriate stacking group, 
among other things:

"""
This property SHOULD be used by the window manager in determining the 
decoration, stacking position and other behavior of the window.
"""

The greater diversity in window management on X11 than windoze
makes observing such things pretty important -  "this is a notification" 
may make a whole lot more sense to a tiling wm than "above plz k thx".

Please note that abusing _NET_WM_STATE for attention purposes is 
specifically highlighted as a What Not To Do in the spec:

"""
_NET_WM_STATE_ABOVE and _NET_WM_STATE_BELOW are mainly meant for user 
preferences and should not be used by applications e.g. for drawing 
attention to their dialogs (the Urgency hint should be used in that 
case, see the section called “Urgency”).'
"""


***
One can certainly do this from within emacs as per the spec (note you
do this for mapped windows by sending a client message to the root 
window).  Note however, that window managers may refuse an app's request 
to be always on top.

(defun x-toggle-frame-always-on-top (&optional frame)
     (x-send-client-message
      frame 0 frame "_NET_WM_STATE" 32
      ;; _NET_WM_STATE_REMOVE = 0
      ;; _NET_WM_STATE_ADD = 1
      ;; _NET_WM_STATE_TOGGLE = 2
      '(2 "_NET_WM_STATE_ABOVE" 0 1)))

Re: Add function to make frame topmost?

[Lennart Borgman]

On Sat, May 1, 2010 at 12:32 AM, David De La Harpe Golden
<david@harpegolden.net> wrote:
> Stefan:
>>
>> I see, thanks.  I don't know if there's a word for such things
>> under X11 (I guess we should ask the freedesktop guys).
>
> Not affiliated with freedesktop as such, just familiar with specs:
>
> ITYM "Always on top" or "above other windows", or technically asking that
> _NET_WM_STATE include _NET_WM_STATE_ABOVE


Thanks.


> N.B. For "normal" windows (such as ordinary emacs frames), this is something
>  usually configured by the user via the window manager's menu, setting it
> within emacs for normal frames would not be something I would particularly
> want or need to do, though possible (*** below), and setting it for special
> framey things is not AFAIK a good idea (following):
>
> http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#STACKINGORDER
>
> [lennart]
>> My use case for something like this is reminders that pops up at a
>> certain times.
>
> Note that X11 apps (or more usually the gui toolkit the app uses) specify
> the purpose of the window in higher-level terms _NET_WM_WINDOW_TYPE, like
> "this is a tooltip", "this is a notification" _NET_WM_WINDOW_TYPE_TOOLTIP,
> _NET_WM_WINDOW_TYPE_NOTIFICATION
> etc.


Then maybe the appropriate abstraction level would be this.

As I understand it the tooltip frame we have in Emacs today is quite
specialized and not easy to extend. I guess the purpose of making it
that way has been ease of the specialized use and low resource
consumption.

The problem is that it is not powerful enough for things like menus of
the type used by for company-mode or completion-ui (see EmacsWiki). So
I am trying to make a quick implementation on w32 of the necessary
frame parts (leaving the other parts to those doing the completion
user interfaces). What is needed is

1) a frame which is topmost.
2) looks like a tooltip frame
3) can show different things
4) can be hidden
5) can be shown without becoming active
6) never becomes the active window
7) looses it topmost property when switching to another app.
8) regains it when switching back
9) has to be recognized as such a frame by Emacs

I am not sure about this list, please comment. What about having a
function make-tooltip-type-frame?

As I understand what you write here much of this is easily available
on X with _NET_WM_WINDOW_TYPE_TOOLTIP. How about point 2 above? 4 and
5? 6? 7 and 8?

w32:
- For 4 and 5 on w32 I have just added the bug report
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6068
- And I just sent the function w32-set-frame-topmost here. This is
needed, of course.
- The w32 window style has to be modified for 2. (Just wrote this.)
- Same for 6.
- 7 and 8 are a bit more difficult (need to check WM_APPACTIVATE).
- 9 is not specific to w32. A bit has to be added to the frame struct.



> The window manager then places it in the appropriate stacking group, among
> other things:
>
> """
> This property SHOULD be used by the window manager in determining the
> decoration, stacking position and other behavior of the window.
> """
>
> The greater diversity in window management on X11 than windoze
> makes observing such things pretty important -  "this is a notification" may
> make a whole lot more sense to a tiling wm than "above plz k thx".
>
> Please note that abusing _NET_WM_STATE for attention purposes is
> specifically highlighted as a What Not To Do in the spec:
>
> """
> _NET_WM_STATE_ABOVE and _NET_WM_STATE_BELOW are mainly meant for user
> preferences and should not be used by applications e.g. for drawing
> attention to their dialogs (the Urgency hint should be used in that case,
> see the section called “Urgency”).'
> """


How does "Urgency" work? Is that appropriate for reminders? I would
prefer that to be a frame that pops up but does not get focus until
the user choosen it.


>
> ***
> One can certainly do this from within emacs as per the spec (note you
> do this for mapped windows by sending a client message to the root window).
>  Note however, that window managers may refuse an app's request to be always
> on top.
>
> (defun x-toggle-frame-always-on-top (&optional frame)
>    (x-send-client-message
>     frame 0 frame "_NET_WM_STATE" 32
>     ;; _NET_WM_STATE_REMOVE = 0
>     ;; _NET_WM_STATE_ADD = 1
>     ;; _NET_WM_STATE_TOGGLE = 2
>     '(2 "_NET_WM_STATE_ABOVE" 0 1)))


Does this work already?

Re: Add function to make frame topmost?

[David De La Harpe Golden]

>> ***
>> One can certainly do this from within emacs as per the spec (note you
>> do this for mapped windows by sending a client message to the root window).
>>  Note however, that window managers may refuse an app's request to be always
>> on top.
>>
>> (defun x-toggle-frame-always-on-top (&optional frame)
>>    (x-send-client-message
>>     frame 0 frame "_NET_WM_STATE" 32
>>     ;; _NET_WM_STATE_REMOVE = 0
>>     ;; _NET_WM_STATE_ADD = 1
>>     ;; _NET_WM_STATE_TOGGLE = 2
>>     '(2 "_NET_WM_STATE_ABOVE" 0 1)))
> 
> 
> Does this work already?

Yes, that's working code, on window managers that honour it.  But I 
don't actually recommend it for the purposes you wanted it for.

Would however be vaguely okay for people who don't want to reach for the 
mouse to use the relevant window manager menu.  If it were to be 
included in emacs it would make more sense to treat it as a frame 
parameter at the elisp api level, similar to the handling of several 
other similar existing parameters, i.e. so one could write

(set-frame-parameter frame 'always-on-top t)

(I think this was what Stefan was saying, pretty much)

Re: Add function to make frame topmost?

[Lennart Borgman]

On Sat, May 1, 2010 at 3:48 AM, David De La Harpe Golden
<david@harpegolden.net> wrote:
>>> ***
>>> One can certainly do this from within emacs as per the spec (note you
>>> do this for mapped windows by sending a client message to the root
>>> window).
>>>  Note however, that window managers may refuse an app's request to be
>>> always
>>> on top.
>>>
>>> (defun x-toggle-frame-always-on-top (&optional frame)
>>>   (x-send-client-message
>>>    frame 0 frame "_NET_WM_STATE" 32
>>>    ;; _NET_WM_STATE_REMOVE = 0
>>>    ;; _NET_WM_STATE_ADD = 1
>>>    ;; _NET_WM_STATE_TOGGLE = 2
>>>    '(2 "_NET_WM_STATE_ABOVE" 0 1)))
>>
>>
>> Does this work already?
>
> Yes, that's working code, on window managers that honour it.  But I don't
> actually recommend it for the purposes you wanted it for.

Thanks.

> Would however be vaguely okay for people who don't want to reach for the
> mouse to use the relevant window manager menu.  If it were to be included in
> emacs it would make more sense to treat it as a frame parameter at the elisp
> api level, similar to the handling of several other similar existing
> parameters, i.e. so one could write
>
> (set-frame-parameter frame 'always-on-top t)
>
> (I think this was what Stefan was saying, pretty much)


Do you mean this which I have not tried to dechiffer yet:

SM> An alternative is to use the poor-man's OO system already in place and
SM> just add a set_frame_topmost_hook to the terminal object.

Re: Add function to make frame topmost?

[Stefan Monnier]

SM> An alternative is to use the poor-man's OO system already in place and
SM> just add a set_frame_topmost_hook to the terminal object.

Check src/termhooks.h where "struct terminal" is defined.


        Stefan "who though it would be obvious"

Re: Add function to make frame topmost?

[David De La Harpe Golden]

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

Stefan Monnier wrote:
> SM> An alternative is to use the poor-man's OO system already in place and
> SM> just add a set_frame_topmost_hook to the terminal object.
> 
> Check src/termhooks.h where "struct terminal" is defined.
> 
> 
>         Stefan "who though it would be obvious"
> 

I'm wasn't sure why you say terminal rather than frame, though either
way it's a poor-man's OO system dealie.  Futzing with 
_NET_WM_STATE_ABOVE is closely analogous to futzing with 
_NET_WM_STATE_STICKY from within emacs, so adding it to frame_parm_table 
makes most sense to me.

I guess there is a danger that if it is added it might be abused, but 
FWIW, a patch that adds 'stacking-layer (and 'shaded, which I just 
thought I'd do while I was there) frame parameters for X11 by analogy 
with 'sticky is straightforward and attached, it might be independently 
vaguely useful for some users?  But don't expect me to argue strongly 
for its inclusion.

Implementation of a w32 x_set_stacking_layer toggling TOPMOST
should be straightforward (though I don't see a BOTTOMMOST, so I guess 
they have a layer less than us).  I have found that there are add-ons 
for windows that do use TOPMOST to produce an "Always on top" setting 
very much akin to a typical X11 window manager:
http://www.ghacks.net/2008/09/12/window-always-on-top-with-power-menu/
so perhaps it's about as valid a thing to add on w32 as the x11 
stacking-layer support is on x11.




















[-- Attachment #2: abovebelowshaded_r1.diff.gz --]
[-- Type: application/x-gzip, Size: 2254 bytes --]

RE: Add function to make frame topmost?

[Drew Adams]

> > Check src/termhooks.h where "struct terminal" is defined.
> 
> I'm wasn't sure why you say terminal rather than frame, though either
> way it's a poor-man's OO system dealie.  Futzing with 
> _NET_WM_STATE_ABOVE is closely analogous to futzing with 
> _NET_WM_STATE_STICKY from within emacs, so adding it to 
> frame_parm_table makes most sense to me.
> 
> I guess there is a danger that if it is added it might be abused, but 
> FWIW, a patch that adds 'stacking-layer (and 'shaded, which I just 
> thought I'd do while I was there) frame parameters for X11 by analogy 
> with 'sticky is straightforward and attached, it might be 
> independently vaguely useful for some users?  But don't expect
> me to argue strongly for its inclusion.
> 
> Implementation of a w32 x_set_stacking_layer toggling TOPMOST
> should be straightforward (though I don't see a BOTTOMMOST, 
> so I guess they have a layer less than us).  I have found
> that there are add-ons for windows that do use TOPMOST to
> produce an "Always on top" setting very much akin to a
> typical X11 window manager:
> http://www.ghacks.net/2008/09/12/window-always-on-top-with-power-menu/
> so perhaps it's about as valid a thing to add on w32 as the x11 
> stacking-layer support is on x11.

Would enhancement request (bug) #4476 (#3464) be relevant here?

(I'm not following this discussion much.)

Re: Add function to make frame topmost?

[David De La Harpe Golden]

Drew Adams wrote:


> Would enhancement request (bug) #4476 (#3464) be relevant here?
> 

That's about actual fine-grained stacking order/z-order. That's trickier.

The stacking-layer patch I sent is _not_ that: some window systems 
divide the basic stack into three or so layers (apparently two in w32) 
and allow the user to assert that a particular window should remain 
stacked somewhere in one of those layers e.g. looking "side-on" to the stack

   ---     T  always-on-top  (topmost in w32 speak)
       --  |
  ----     T  nil  (normal windows)
   -----   |
   ----    T  always-below

As a happy side effect, the stacking layer a frame is has been put in is 
saved/restored with the patch applied (it's just another frame 
parameter), which might be good reason to apply the patch, but no, the 
patch does not save/restore the precise z-order: most of the time all 
frames will be in the "normal windows" layer, unless the user actually 
selected "always on top" in their window manager for one of them.

Re: Add function to make frame topmost?

[David De La Harpe Golden]

David De La Harpe Golden wrote:
> Drew Adams wrote:
> 
> 
>> Would enhancement request (bug) #4476 (#3464) be relevant here?
>>
> 
> That's about actual fine-grained stacking order/z-order. That's trickier.
> 
> The stacking-layer patch I sent is _not_ that: some window systems 
> divide the basic stack into three or so layers (apparently two in w32)

[that should say "some window managers", the layer division is something 
a wm synthesises, not primitive]

RE: Add function to make frame topmost?

[Drew Adams]

> > Would enhancement request (bug) #4476 (#3464) be relevant here?
> 
> That's about actual fine-grained stacking order/z-order. 
> That's trickier. The stacking-layer patch I sent is _not_ that...

I see; thanks for explaining.

Not to divert the discussion from your patch, but wouldn't we anyway need
something like what bug #4476 suggests in order to save & restore frame configs?
If we are intending to be let users persistently save the state of their windows
and frames, then won't we need to record and restore (or at least request
restoration of) the fine-grained stacking order/z-order?

[Again, we don't need to discuss doing that in this thread. I just want to
better understand stacking order as it relates to recording and restoring frame
parameters and frame configs, since there is currently a (separate) discussion
about that.]

Re: Add function to make frame topmost?

[David De La Harpe Golden]

Drew Adams wrote:

> Not to divert the discussion from your patch, but wouldn't we anyway need
> something like what bug #4476 suggests in order to save & restore frame configs?
> If we are intending to be let users persistently save the state of their windows
> and frames, then won't we need to record and restore (or at least request
> restoration of) the fine-grained stacking order/z-order?


Maybe. Apart from leaving the z-order alone:

One could try to restore something as close as possible to a saved 
absolute z-order, but users might be surprised by that since  non-emacs 
windows may well have come and gone in the meantime, and it would mean 
restoring a frame configuration might bury and interleave frames behind 
non-emacs windows. It might all seem a bit random.

Restoring the relative z-order of emacs frames, but restoring them
contiguous in the stack and maybe at the top (not always-on-top, I just 
mean in front) on restoration, might be a better option. Except when the 
user is saving and restoring in rapid succession in the one session, as 
I imagine most people's typical use of 
frame-configuration-to-register/jump-to-register is. Then it might be 
the surprising/annoyingly-raisey option, and leaving
the z-order as-is might be best.

Or could punt and make it an option as to which of the three happens
and/or which of the three happens in which context (same-session
set-frame-configuration from a "live" frame configuration object
vs. from a deserialized "undead" frame configuration object)

Probably need coding up and testing for a real assessment.

stack-order (z-order) parameter for frames [was: Add function to make frame topmost?]

[Drew Adams]

(Changed the subject line, so as not to interfere with the `topmost'
discussion.)

> Restoring the relative z-order of emacs frames, but restoring them
> contiguous in the stack and maybe at the top (not always-on-top,
> I just mean in front) on restoration, might be a better option. 

That is what I meant: record and restore the relative z-order of Emacs frames
(not of all window-mgr windows), and restore them contiguously in the overall
window-mgr stack. IOW, restore Emacs frames as they were, as much as possible,
including wrt their relative z-order.

> Except when the user is saving and restoring in rapid succession
> in the one session, as I imagine most people's typical use of 
> frame-configuration-to-register/jump-to-register is. Then it might be 
> the surprising/annoyingly-raisey option, and leaving
> the z-order as-is might be best.

Yes, I was referring to persistent save, and restoration from a persistent
record. My bringing this up here was meant to be in the context of the
discussion about persistently saving/restoring frames and frame configs.

However, I would like to see each frame have a frame parameter that records -
and hopefully controls (as much as is possible), its z-order. That's independent
of persistent save/restore.

Use of such a parameter could be to raise/lower individual frames (e.g.
incrementally, by users), and that would be relative to other _Emacs_ frames,
certainly. We could also perhaps let it be used optionally (under Lisp control),
to raise/lower relative to non-Emacs window-mgr windows (e.g. move a frame
topmost among all window-mgr windows).

In addition, the frame parameter would be used by persistent save of frame
configs and their restoration. IOW, the same frame parameter would be used for
both (a) live control (checking where a frame is in the stack and moving it
up/down the stack) and (b) save/restore of frame configs.

For restoration of a frame config, the Lisp code in question would know whether
or not it is restoring from a persistent store, and it could decide whether or
not to respect the `z-order' parameter. No hard-and-fast rule about that should
be hard-coded into the frame-config representation or the basic frame-config
save/restore code. As much control as possible should be available to Emacs-Lisp
code.

Re: Add function to make frame topmost?

[Lennart Borgman]

On Sat, May 1, 2010 at 8:03 PM, David De La Harpe Golden
<david@harpegolden.net> wrote:
> Stefan Monnier wrote:
>>
>> SM> An alternative is to use the poor-man's OO system already in place and
>> SM> just add a set_frame_topmost_hook to the terminal object.
>>
>> Check src/termhooks.h where "struct terminal" is defined.
>>
>>
>>        Stefan "who though it would be obvious"
>>
>
> I'm wasn't sure why you say terminal rather than frame, though either
> way it's a poor-man's OO system dealie.  Futzing with _NET_WM_STATE_ABOVE is
> closely analogous to futzing with _NET_WM_STATE_STICKY from within emacs, so
> adding it to frame_parm_table makes most sense to me.
>
> I guess there is a danger that if it is added it might be abused, but FWIW,
> a patch that adds 'stacking-layer (and 'shaded, which I just thought I'd do
> while I was there) frame parameters for X11 by analogy with 'sticky is
> straightforward and attached, it might be independently vaguely useful for
> some users?  But don't expect me to argue strongly for its inclusion.
>
> Implementation of a w32 x_set_stacking_layer toggling TOPMOST
> should be straightforward (though I don't see a BOTTOMMOST, so I guess they
> have a layer less than us).  I have found that there are add-ons for windows
> that do use TOPMOST to produce an "Always on top" setting very much akin to
> a typical X11 window manager:
> http://www.ghacks.net/2008/09/12/window-always-on-top-with-power-menu/
> so perhaps it's about as valid a thing to add on w32 as the x11
> stacking-layer support is on x11.


Thanks. Yes, it looks easy to add the w32 part. (And there is no BOTTOMMOST.)

I think this is useful for reminders/appointments, log tail buffers etc.

Re: Add function to make frame topmost?

[David De La Harpe Golden]

Lennart Borgman wrote:

> Thanks. Yes, it looks easy to add the w32 part. (And there is no BOTTOMMOST.)
> 
> I think this is useful for reminders/appointments, log tail buffers etc.

Uhm.

If, say, the _user wanted_ an emacs frame showing a log tail buffer 
always visible, setting always-on-top on the emacs frame might be 
something the user might choose to do (which might be what you meant by 
"useful for log tail buffers", granted).

A frame showing a log tail buffer in particular that has just spat out 
some output might use the simple demands-attention* to draw some mild 
attention to itself, without being so presumptuous as to request 
activation or raise-frame itself (or worse always-on-top itself).

Come to think of it, ringing the bell should probably demands-attention, 
so that something (beep)ing in a frame that's not visible isn't missed.

*
On my system, the interpretation of demands-attention for a frame that's 
not immediately visible is that its task bar entry is bolded and starts 
gently pulsing blue. demands attention? :

"""
_NET_WM_STATE_DEMANDS_ATTENTION indicates that some action in or with 
the window happened. For example, it may be set by the Window Manager if 
the window requested activation but the Window Manager refused it, or 
the application may set it if it finished some work. This state may be 
set by both the Client and the Window Manager. It should be unset by the 
Window Manager when it decides the window got the required attention 
(usually, that it got activated).
"""

;; could be recast as a frame parameter if introduced,
;; just a test function.
(defun x-set-frame-wants-love (&optional frame)
     (x-send-client-message
      frame 0 frame "_NET_WM_STATE" 32
      '(1 "_NET_WM_STATE_DEMANDS_ATTENTION" 0 1)))

(progn
   (sleep-for 10)
   (x-set-frame-wants-love))

C-x C-e
<minimise frame, wait 10 secs>

Re: Add function to make frame topmost?

[Jan Djärv]

David De La Harpe Golden skrev 2010-05-02 03.18:
> Come to think of it, ringing the bell should probably demands-attention,
> so that something (beep)ing in a frame that's not visible isn't missed.
>
> *
> On my system, the interpretation of demands-attention for a frame that's
> not immediately visible is that its task bar entry is bolded and starts
> gently pulsing blue. demands attention? :

That sounds like Compiz.  On KDE, the task bar entry gets a blue border that 
blinks three times, but then is solid blue.

But looking in to the future, how is this handeled for tabs?  It may be 
another tab that wants attention.  I haven't tested it, but I guess the 
application would have to deal with that on its own.

	Jan D.

Re: Add function to make frame topmost?

[David De La Harpe Golden]

Jan Djärv wrote:
> 
> But looking in to the future, how is this handeled for tabs?  It may be 
> another tab that wants attention.  I haven't tested it, but I guess the 
> application would have to deal with that on its own.
> 

Yes, afaik the application would have to handle individual tabs,
though it could demand-attention for the toplevel window containing the 
tab in question.

Some tabbed terminal emulators' tabs do change color if they're not 
frontmost and the shell makes output, I haven't really looked into how 
they do it.

Re: Add function to make frame topmost?

[Jan Djärv]

[-- Attachment #1: Type: text/plain, Size: 690 bytes --]



Lennart Borgman skrev 2010-05-02 00.44:

> I think this is useful for reminders/appointments, log tail buffers etc.

I don't get it.  Why insist that the window should be topmost?  For a log tail 
buffer, I'd hate if it was topmost, that is just a waste of screen space.  If 
you can set a window topmost by _NET_WM_STATE_ABOVE, then there is a menu for 
it anyway.  Why not let the user use that?
Forcing behaviour like this sounds wrong.

For reminders I'd rather see the kind of windows gnome uses for this, see 
screen shot.  They are indeed topmost, but not transient for.
An general API to create this kind of windows could use platform specific 
methods where available.

	Jan D.


[-- Attachment #2: notice.png --]
[-- Type: image/png, Size: 145978 bytes --]

Re: Add function to make frame topmost?

[Stephen J. Turnbull]

Jan Djärv writes:
 > Lennart Borgman skrev 2010-05-02 00.44:
 > 
 > > I think this is useful for reminders/appointments, log tail buffers etc.
 > 
 > I don't get it.

"Programmer knows best."  Why users put up with it, I don't know.

 > For reminders I'd rather see the kind of windows gnome uses for this, see 
 > screen shot.  They are indeed topmost, but not transient for.

That's a pretty good try, but it's still more obtrusive than it need
be.  Why a close box?  *Any* click it such a window should dismiss it.

Re: Add function to make frame topmost?

[Jan Djärv]

2010-05-02 14:27, Stephen J. Turnbull skrev:
> Jan Djärv writes:
>
>   >  For reminders I'd rather see the kind of windows gnome uses for this, see
>   >  screen shot.  They are indeed topmost, but not transient for.
>
> That's a pretty good try, but it's still more obtrusive than it need
> be.  Why a close box?  *Any* click it such a window should dismiss it.

That is in fact my main problem with those notification areas, you have to hit 
the close box.  They are also too big.

	Jan D.

Re: Add function to make frame topmost?

[David De La Harpe Golden]

Jan Djärv wrote:

> That is in fact my main problem with those notification areas, 

[Be careful, "notification area" is microsoftese for the systray, not
the popups]

> you have  to hit the close box.  They are also too big.

That may be a function of your desktop environment/theme to some extent.
On my system, they have a cosmetic close box, but you can click anywhere
on them.

Re: Add function to make frame topmost?

[Stephen J. Turnbull]

David De La Harpe Golden writes:

 > > you have  to hit the close box.  They are also too big.
 > 
 > That may be a function of your desktop environment/theme to some extent.
 > On my system, they have a cosmetic close box, but you can click anywhere
 > on them.

Cool!  Thanks for the correction!

Re: Add function to make frame topmost?

[David De La Harpe Golden]

[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]

Stephen J. Turnbull wrote:
> Jan Djärv writes:
>  > Lennart Borgman skrev 2010-05-02 00.44:
>  > 
>  > > I think this is useful for reminders/appointments, log tail buffers etc.
>  > 
>  > I don't get it.
> 
> "Programmer knows best."  Why users put up with it, I don't know.
> 
>  > For reminders I'd rather see the kind of windows gnome uses for this, see 
>  > screen shot.  They are indeed topmost, but not transient for.
> 
> That's a pretty good try, but it's still more obtrusive than it need
> be.  Why a close box?  *Any* click it such a window should dismiss it.
> 

FWIW, on my system, notifications popups via libnotify [1] have close 
buttons but they're cosmetic/affordances, clicking on them anywhere 
dismisses them. Using libnotify means the desktop environment's uniform 
notifications are used. I use XFCE, their appearance and behaviour is 
configured via xfce4-notifyd-config, which allows changing graphical 
theme, position, timeout and opacity of them. (I found a tip on the arch 
linux wiki saying gnome users can edit the registry^Wgconf key 
/apps/notification-daemon/ to configure them on GNOME)

Try the following from the shell:

aptitude install libnotify-bin
notify-send  "Hello, World" "<b>I am a Fish.</b> On $(date)"

Results shown in the attached screenshot.

Linking emacs, at least x11/gtk emacs, against libnotify and supporting 
a (notify-send ...) or something usable from within emacs would probably 
be quite doable. Maybe the elisp api could be wrapped around the other 
platforms' native similar facilities on non-x11.

This approach wouldn't allow the notification popup to be an emacs frame 
with arbitrary contents, obviously you're limited to what the 
notification kinda-sorta-spec allows.

[1]
A bit different and more complex than the systray spec balloon message 
api I previously mentioned, allowing fancier notifications.

http://www.galago-project.org/docs/index.php
http://www.galago-project.org/specs/notification/0.9/index.html
http://manishtech.wordpress.com/2009/03/29/working-with-libnotify/

[-- Attachment #2: notifyeg.png --]
[-- Type: image/png, Size: 28575 bytes --]

Re: Add function to make frame topmost?

[Lennart Borgman]

On Sun, May 2, 2010 at 4:43 PM, David De La Harpe Golden
<david@harpegolden.net> wrote:
>
> Linking emacs, at least x11/gtk emacs, against libnotify and supporting a
> (notify-send ...) or something usable from within emacs would probably be
> quite doable. Maybe the elisp api could be wrapped around the other
> platforms' native similar facilities on non-x11.


Would that allow opening/raising an Emacs frame when clicking on the
notification popup?


> This approach wouldn't allow the notification popup to be an emacs frame
> with arbitrary contents, obviously you're limited to what the notification
> kinda-sorta-spec allows.
>
> [1]
> A bit different and more complex than the systray spec balloon message api I
> previously mentioned, allowing fancier notifications.
>
> http://www.galago-project.org/docs/index.php
> http://www.galago-project.org/specs/notification/0.9/index.html
> http://manishtech.wordpress.com/2009/03/29/working-with-libnotify/
>

Re: Add function to make frame topmost?

[David De La Harpe Golden]

Lennart Borgman wrote:

> 
> Would that allow opening/raising an Emacs frame when clicking on the
> notification popup?

I believe so, effectively, though haven't tried it (the command line
tool doesn't seem to have provision for it, the C api does):

http://library.gnome.org/devel/libnotify/0.4/NotifyNotification.html#notify-notification-add-action

"""
Adds an action to a notification. When the action is invoked, the 
specified callback function will be called, along with the value passed 
to user_data.
"""

Re: Add function to make frame topmost?

[David De La Harpe Golden]

David De La Harpe Golden wrote:
> arch linux wiki

[Yes, GNU+Linux, my bad.]

Re: Add function to make frame topmost?

[Jan Djärv]

[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]

2010-05-02 16:43, David De La Harpe Golden skrev:

> FWIW, on my system, notifications popups via libnotify [1] have close
> buttons but they're cosmetic/affordances, clicking on them anywhere
> dismisses them. Using libnotify means the desktop environment's uniform
> notifications are used. I use XFCE, their appearance and behaviour is
> configured via xfce4-notifyd-config, which allows changing graphical
> theme, position, timeout and opacity of them. (I found a tip on the arch
> linux wiki saying gnome users can edit the registry^Wgconf key
> /apps/notification-daemon/ to configure them on GNOME)
>
> Try the following from the shell:
>
> aptitude install libnotify-bin
> notify-send "Hello, World" "<b>I am a Fish.</b> On $(date)"
>
> Results shown in the attached screenshot.

On my system, there is no close box, and a click does not dismiss it, but 
mouse over makes it very transparent.  As you said, probably a theme thing.
It times out after a while.

> Linking emacs, at least x11/gtk emacs, against libnotify and supporting
> a (notify-send ...) or something usable from within emacs would probably
> be quite doable. Maybe the elisp api could be wrapped around the other
> platforms' native similar facilities on non-x11.
>

This is a good idea.

	Jan D.

[-- Attachment #2: norify1.png --]
[-- Type: image/png, Size: 25855 bytes --]

[-- Attachment #3: notify2.png --]
[-- Type: image/png, Size: 14485 bytes --]

Desktop bubble notifications [Was: Re: Add function to make frame topmost?]

[David De La Harpe Golden]

Jan Djärv wrote:


> 
>> Linking emacs, at least x11/gtk emacs, against libnotify and supporting
>> a (notify-send ...) or something usable from within emacs would probably
>> be quite doable. Maybe the elisp api could be wrapped around the other
>> platforms' native similar facilities on non-x11.
>>
> 
> This is a good idea.
> 

Hmm. The "other platforms" thing was worrying me, particularly given the 
build-from-scratch angle Lennart came in on, so I searched the internet 
outside my usual haunts:

*** Growl, snarl, libnotify. mumbles:

Macosx seems to have a third-party add-on called "growl" [1] for 
notifications that seems to be popular bordering on de-facto standard 
and appears to have a conceptually similar (though ObjC) api to 
libnotify, as well as a similar command line client.

Growl is probably acceptably licensed [2], so maybe depending on growl 
on macosx for notifications is an option.

There's a "growl for windows" [3], and similar system called "snarl". 
[4] (haven't found their licenses)

And another project called "mumbles" on fd.o systems [5] (and KDE has 
KNotify), though as emacs is a gtk+ app for the purposes of the 
discussion, libnotify is probably the thing to use.

*** Existing Emacs support for libnotify, growl and snarl (!)

So, um. Turns out, someone (one Jonathan Arkell) has actually written 
some basic support of growl-like systems for emacs, including libnotify, 
called (somewhat cryptically) "todochiku.el".  It is simply using the 
command-line clients for the respective notification systems on the 
various platforms (like the one I used) rather than the more versatile 
C/ObjC/C++ apis. [6][7].

IMNHO core emacs support should probably be by library bindings (or wire 
protocol) rather than commmand line callout as used by the existing 
todochiku.el though - generally more powerful for all systems, 
especially on fd.o.

[1] http://growl.info/
[2] http://growl.googlecode.com/hg/License.txt
[3] http://www.growlforwindows.com/gfw/default.aspx
[4] http://www.fullphat.net/index.php
[5] http://www.mumbles-project.org/

[6]
http://justinsboringpage.blogspot.com/2009/09/making-emacs-growl.html
[7]
http://www.emacswiki.org/emacs/todochiku.el

Re: Desktop bubble notifications [Was: Re: Add function to make frame topmost?]

[Lennart Borgman]

On Sun, May 2, 2010 at 11:32 PM, David De La Harpe Golden
<david@harpegolden.net> wrote:
> Jan Djärv wrote:
>
>
>>
>>> Linking emacs, at least x11/gtk emacs, against libnotify and supporting
>>> a (notify-send ...) or something usable from within emacs would probably
>>> be quite doable. Maybe the elisp api could be wrapped around the other
>>> platforms' native similar facilities on non-x11.
>>>
>>
>> This is a good idea.
>>
>
> Hmm. The "other platforms" thing was worrying me, particularly given the
> build-from-scratch angle Lennart came in on, so I searched the internet
> outside my usual haunts:


I was not really suggesting that... - but some Emacs specific way of
notification popup would be good too.


> *** Growl, snarl, libnotify. mumbles:
>
...
> So, um. Turns out, someone (one Jonathan Arkell) has actually written some
> basic support of growl-like systems for emacs, including libnotify, called
> (somewhat cryptically) "todochiku.el".  It is simply using the command-line
> clients for the respective notification systems on the various platforms
> (like the one I used) rather than the more versatile C/ObjC/C++ apis.
> [6][7].


I took a quick look at Growl for Windows. It has a command line
program, growlnotify.exe, which todochiku.el uses.

Unfortunately growlnotify.exe can't wait for the user click on the
notification popup. That is too bad, because if it could it would
perhaps be easy to integrate with Emacs in a more useful way. Then
sentinentals could be used for callbacks.

I sent a mail to the growl mailing list and asked for a /wait switch.


> IMNHO core emacs support should probably be by library bindings (or wire
> protocol) rather than commmand line callout as used by the existing
> todochiku.el though - generally more powerful for all systems, especially on
> fd.o.


What more could be done that way than would be possible if
growlnotify.exe had a /wait switch?

Re: Desktop bubble notifications [Was: Re: Add function to make frame topmost?]

[David De La Harpe Golden]

Lennart Borgman wrote:

> What more could be done that way than would be possible if
> growlnotify.exe had a /wait switch?

Remembering that I'm not familiar with growl-for-windows, but in the api 
docs it looks like there's the possibility to just register callbacks 
directly (surely handier?), set custom attributes, and get fine-grained 
errors back.

I did say "especially on fd.o": libnotify has a lot of stuff not exposed 
through its notify-send, like multiple actions ( "Chat|Ignore"), 
possibility for association with specific applications widgets and 
systray icons, and support for updating the message of the 
notification*. (growl-for-windows doesn't currently do several of those 
in the first place as far as I can see (could well be wrong)).

[debian package python-notify has a bunch of examples in 
/usr/share/doc/python-notify/examples ]


*
import pynotify
import time

pynotify.init("Countdown")
n = pynotify.Notification("Uh oh","...")
n.show()
for i in range(10,0,-1):
     time.sleep(1)
     n.update("Uh oh", "%s..." % i)
     n.show()
n.update("Oh No!", "<b>BANG</b>")
n.show()

Re: Desktop bubble notifications [Was: Re: Add function to make frame topmost?]

[Stephen Eilert]

I can't see it mentioned anywhere, so forgive-me if it was discussed already.

I have been using for quite some time todochiku.el, which provides
notification for Windows, Linux (via notify-send) and OSX (using
Growl).

--Stephen

programmer, n:
        A red eyed, mumbling mammal capable of conversing with
inanimate monsters.



On Sun, May 2, 2010 at 11:29 PM, David De La Harpe Golden
<david@harpegolden.net> wrote:
> Lennart Borgman wrote:
>
>> What more could be done that way than would be possible if
>> growlnotify.exe had a /wait switch?
>
> Remembering that I'm not familiar with growl-for-windows, but in the api
> docs it looks like there's the possibility to just register callbacks
> directly (surely handier?), set custom attributes, and get fine-grained
> errors back.
>
> I did say "especially on fd.o": libnotify has a lot of stuff not exposed
> through its notify-send, like multiple actions ( "Chat|Ignore"), possibility
> for association with specific applications widgets and systray icons, and
> support for updating the message of the notification*. (growl-for-windows
> doesn't currently do several of those in the first place as far as I can see
> (could well be wrong)).
>
> [debian package python-notify has a bunch of examples in
> /usr/share/doc/python-notify/examples ]
>
>
> *
> import pynotify
> import time
>
> pynotify.init("Countdown")
> n = pynotify.Notification("Uh oh","...")
> n.show()
> for i in range(10,0,-1):
>    time.sleep(1)
>    n.update("Uh oh", "%s..." % i)
>    n.show()
> n.update("Oh No!", "<b>BANG</b>")
> n.show()
>
>
>
>

Re: Desktop bubble notifications [Was: Re: Add function to make frame topmost?]

[Lennart Borgman]

On Mon, May 3, 2010 at 9:46 PM, Stephen Eilert <spedrosa@gmail.com> wrote:
> I can't see it mentioned anywhere, so forgive-me if it was discussed already.
>
> I have been using for quite some time todochiku.el, which provides
> notification for Windows, Linux (via notify-send) and OSX (using
> Growl).
>
> --Stephen


Hi Stephen, thanks and yes we have seen it. The /wait switch for
growlnotify that I have suggested at the Growl discussion group is
meant for such a solution.

See here for the suggestion:

http://groups.google.com/group/growldiscuss/browse_thread/thread/486fc7fe089f9ed8/87504a7a822e14a9?show_docid=87504a7a822e14a9


> On Sun, May 2, 2010 at 11:29 PM, David De La Harpe Golden
> <david@harpegolden.net> wrote:
>> Lennart Borgman wrote:
>>
>>> What more could be done that way than would be possible if
>>> growlnotify.exe had a /wait switch?
>>
>> Remembering that I'm not familiar with growl-for-windows, but in the api
>> docs it looks like there's the possibility to just register callbacks
>> directly (surely handier?), set custom attributes, and get fine-grained
>> errors back.
>>
>> I did say "especially on fd.o": libnotify has a lot of stuff not exposed
>> through its notify-send, like multiple actions ( "Chat|Ignore"), possibility
>> for association with specific applications widgets and systray icons, and
>> support for updating the message of the notification*. (growl-for-windows
>> doesn't currently do several of those in the first place as far as I can see
>> (could well be wrong)).
>>
>> [debian package python-notify has a bunch of examples in
>> /usr/share/doc/python-notify/examples ]
>>
>>
>> *
>> import pynotify
>> import time
>>
>> pynotify.init("Countdown")
>> n = pynotify.Notification("Uh oh","...")
>> n.show()
>> for i in range(10,0,-1):
>>    time.sleep(1)
>>    n.update("Uh oh", "%s..." % i)
>>    n.show()
>> n.update("Oh No!", "<b>BANG</b>")
>> n.show()
>>
>>
>>
>>
>

Re: Desktop bubble notifications

[Bastien]

David De La Harpe Golden <david@harpegolden.net> writes:

> *** Existing Emacs support for libnotify, growl and snarl (!)
>
> So, um. Turns out, someone (one Jonathan Arkell) has actually written
> some basic support of growl-like systems for emacs, including libnotify,
> called (somewhat cryptically) "todochiku.el".  It is simply using the
> command-line clients for the respective notification systems on the
> various platforms (like the one I used) rather than the more versatile
> C/ObjC/C++ apis. [6][7].

FWIW, Org uses the "notify-send" program if it exists.

See `org-show-notification'.

org-mac-message.el also contains references to growl.

-- 
 Bastien

Re: Add function to make frame topmost?

[chad]

*Chad

On 2 May 2010, at 13:27, "Stephen J. Turnbull" <stephen@xemacs.org>  
wrote:

> That's a pretty good try, but it's still more obtrusive than it need
> be.  Why a close box?  *Any* click it such a window should dismiss it.

Cut/copy and paste from such sources are useful more often than you  
might think. 

Re: Add function to make frame topmost?

[Stephen J. Turnbull]

chad writes:
 > On 2 May 2010, at 13:27, "Stephen J. Turnbull" <stephen@xemacs.org>  
 > wrote:
 > 
 > > That's a pretty good try, but it's still more obtrusive than it need
 > > be.  Why a close box?  *Any* click it such a window should dismiss it.
 > 
 > Cut/copy and paste from such sources are useful more often than you  
 > might think. 

No, I thought about that.  Carefully.  Should have known somebody
would call me on it (out of context, yet).

Seriously, now, for battery usage notifications?  Come on, we can do
better than that, and should.  Yes, for some use-cases, selectability
is a good idea.  But these notifications, log windows, and tooltips
that Lennart seems to suggest could be unified should not be unified,
precisely because they are different in this respect (and others).

I have nothing against unification of implementation, but the high-
level APIs and especially their documentation should distinguish these
use cases.

RE: Add function to make frame topmost?

[Drew Adams]

> > I think this is useful for reminders/appointments, log tail 
> > buffers etc.
> 
> I don't get it.  Why insist that the window should be 
> topmost?  For a log tail buffer, I'd hate if it was topmost,
> that is just a waste of screen space.

Giving Emacs (hopefully through Lisp) an ability to control (or request)
always-on-top behavior for a frame is not bad.

But any use Emacs itself would make of this feature, and hopefully any use an
Emacs-Lisp programmer would make of it, should give the user control over it. If
there is no way in Emacs Lisp to give the user control, then I would not be in
favor of this.

Re: Add function to make frame topmost?

[Lennart Borgman]

On Sun, May 2, 2010 at 4:01 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> Giving Emacs (hopefully through Lisp) an ability to control (or request)
> always-on-top behavior for a frame is not bad.
>
> But any use Emacs itself would make of this feature, and hopefully any use an
> Emacs-Lisp programmer would make of it, should give the user control over it. If
> there is no way in Emacs Lisp to give the user control, then I would not be in
> favor of this.

Yes, of course this should be under user control. I imagine there to
be a command `set-frame-topmost'.

For reminders I expect the elisp code normally would set topmost, but
it should be a user option.

Re: Add function to make frame topmost?

[Stephen J. Turnbull]

Lennart Borgman writes:

 > For reminders I expect the elisp code normally would set topmost,

What you expect is up to you, but I rather suspect that's not what I
would want in most cases.  Remember, IIUC, topmost means it sticks to
the glass and gets in the way of other things, and must be dismissed
(or worse, actively given a response) to get it out of the way.

By contrast, normally popup windows are put on top, but simply
selecting another window allows you to work in that window without
specifically dismissing the reminder.  That is the behavior I want for
something called "reminder".  On the one hand, I probably asked for
it, so it should start on top.  OTOH, now I've seen it, and even if I
focus attention elsewhere for now, I might want to keep it around for
later.  In that case it needs to be easy to get it out of the way
without dismissing it.

Re: Add function to make frame topmost?

[Lennart Borgman]

On Mon, May 3, 2010 at 5:43 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Lennart Borgman writes:
>
>  > For reminders I expect the elisp code normally would set topmost,
>
> What you expect is up to you, but I rather suspect that's not what I
> would want in most cases.  Remember, IIUC, topmost means it sticks to
> the glass and gets in the way of other things, and must be dismissed
> (or worse, actively given a response) to get it out of the way.
>
> By contrast, normally popup windows are put on top, but simply
> selecting another window allows you to work in that window without
> specifically dismissing the reminder.  That is the behavior I want for
> something called "reminder".  On the one hand, I probably asked for
> it, so it should start on top.  OTOH, now I've seen it, and even if I
> focus attention elsewhere for now, I might want to keep it around for
> later.  In that case it needs to be easy to get it out of the way
> without dismissing it.


Yes, but does not that mean that it should start as a topmost window?

A possibility for reminders using only Emacs then are:

1) they start topmost as Emacs frames
2) when selecting the frame the topmost property is removed

Implementing 2 above requires of course that Emacs is learned about
application activation (something I have suggested long ago since it
might be useful for other things too).


On the other hand if using Growl (as David De La Harpe Golden
suggested) then you have this capabilities there already I believe.

Re: Add function to make frame topmost?

[Stefan Monnier]

> Yes, but does not that mean that it should start as a topmost window?

No, it just means it has to start raised.


        Stefan

Re: Add function to make frame topmost?

[Lennart Borgman]

On Mon, May 3, 2010 at 7:21 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Yes, but does not that mean that it should start as a topmost window?
>
> No, it just means it has to start raised.

I am not sure, but would not that be more complicated if you are not in Emacs?

Re: Add function to make frame topmost?

[David De La Harpe Golden]

On 03/05/10 10:59, Lennart Borgman wrote:


> Yes, but does not that mean that it should start as a topmost window?
>

[I prefer always-on-top terminologically: It is very easy for a non-w32 
person to read (or write) topmost as "start as the instantaneously top 
window [in the window's current stack layer]", i.e. raised, the 
equivalent of w32 HWND_TOP, rather than "start as a window in the 
always-on-top stack layer", the w32 HWND_TOPMOST.]

> On the other hand if using Growl (as David De La Harpe Golden
> suggested) then you have this capabilities there already I believe.

While adding stacking-layer, override-redirect, disposition/type-hint, 
transient-for, no-decorations and more as elisp-exposed emacs frame 
parameters is obviously technically possible on x11 (well, some might 
only be settable at make-frame time and then read-only), I expect most 
users on x11 would prefer apps wanting to do bubble notifications use 
the relevant service, and I thought growl might be a close analogue 
available on w32/macosx.

IMO the notification popper-upper daemon is a special case that can "get 
away with" doing certain things rather than an example for emacs to 
follow, but I did go digging into current x11 practice for the 
notification daemon's windows - in the interests of full disclosure: 
gnome-notification-daemon and xfce4-notifyd both use windows of 
_TYPE_NOTIFICATION [1][2], but the former also makes it an override 
redirect window [3] and the latter a _STATE_ABOVE window [4] with no 
decorations (_MOTIF_WM_HINTS).

[1] 
http://git.xfce.org/apps/xfce4-notifyd/tree/xfce4-notifyd/xfce-notify-window.c#n224
[2] 
http://git.gnome.org/browse/notification-daemon/tree/src/themes/standard/theme.c#n611
[3] 
http://git.gnome.org/browse/notification-daemon/tree/src/themes/standard/theme.c#n596
[4] 
http://git.xfce.org/apps/xfce4-notifyd/tree/xfce4-notifyd/xfce-notify-window.c#n217

Re: Add function to make frame topmost?

[Stefan Monnier]

SM> An alternative is to use the poor-man's OO system already in place and
SM> just add a set_frame_topmost_hook to the terminal object.
>> Check src/termhooks.h where "struct terminal" is defined.
> I'm wasn't sure why you say terminal rather than frame, though either
> way it's a poor-man's OO system dealie.  Futzing with _NET_WM_STATE_ABOVE is
> closely analogous to futzing with _NET_WM_STATE_STICKY from within emacs, so
> adding it to frame_parm_table makes most sense to me.

frame_parm_table does not seem relevant since it doesn't dispatch on the
display type.


        Stefan

Re: Add function to make frame topmost?

[David De La Harpe Golden]

Stefan Monnier wrote:
> SM> An alternative is to use the poor-man's OO system already in place and
> SM> just add a set_frame_topmost_hook to the terminal object.
>>> Check src/termhooks.h where "struct terminal" is defined.
>> I'm wasn't sure why you say terminal rather than frame, though either
>> way it's a poor-man's OO system dealie.  Futzing with _NET_WM_STATE_ABOVE is
>> closely analogous to futzing with _NET_WM_STATE_STICKY from within emacs, so
>> adding it to frame_parm_table makes most sense to me.
> 
> frame_parm_table does not seem relevant since it doesn't dispatch on the
> display type.

Sorry, frame_parm_table itself just lists possible frame parameters.
xfns.c, w32fns.c and nsfns.m then setup their 
[x|w32|ns]_frame_parm_handlers supplying their implementations for some 
or all of the frame parameters, used as the value of the
FRAME_RIF(frame)->frame_parm_handlers

Anyhow, it's how other several similar parameters are already handled,
the patch was little more than a copy-paste of existing frame parameters.

Re: Add function to make frame topmost?

[David De La Harpe Golden]

Lennart Borgman wrote:

 >
 > How does "Urgency" work? Is that appropriate for reminders? I would
 > prefer that to be a frame that pops up but does not get focus until
 > the user choosen it.
 >

A reminder sounds more like a notification than an urgent window.   But
n.b. the window type might still be the wrong level, I'm now vaguely
wondering if you might be wanting system tray balloon notifications for 
which there are typically high-level apis.

http://standards.freedesktop.org/systemtray-spec/systemtray-spec-0.1.html#balloon

(note that gtk then has its implementation/wrapper for systray support, 
GtkStatusIcon, i.e. an even higher level might be appropriate for 
toolkit-using emacs)

Ading systray support to emacs was discussed in the context
of daemon mode a while back, maybe it's worth another look now.

Re: Add function to make frame topmost?

[Lennart Borgman]

On Sat, May 1, 2010 at 4:10 AM, David De La Harpe Golden
<david@harpegolden.net> wrote:
> Lennart Borgman wrote:
>
>>
>> How does "Urgency" work? Is that appropriate for reminders? I would
>> prefer that to be a frame that pops up but does not get focus until
>> the user choosen it.
>>
>
> A reminder sounds more like a notification than an urgent window.   But
> n.b. the window type might still be the wrong level, I'm now vaguely
> wondering if you might be wanting system tray balloon notifications for
> which there are typically high-level apis.
>
> http://standards.freedesktop.org/systemtray-spec/systemtray-spec-0.1.html#balloon


I am not sure that systray must be invovled here. Perhaps there are
some specification for just balloons as a notification style? That
could perhaps be integrated easier with Emacs frame, ie perhaps an
Emacs frame could look like a balloon.


> (note that gtk then has its implementation/wrapper for systray support,
> GtkStatusIcon, i.e. an even higher level might be appropriate for
> toolkit-using emacs)
>
> Ading systray support to emacs was discussed in the context
> of daemon mode a while back, maybe it's worth another look now.
>
>
>
>

Re: Add function to make frame topmost?

[Lennart Borgman]

On Sat, May 1, 2010 at 4:32 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
>
> I am not sure that systray must be invovled here. Perhaps there are
> some specification for just balloons as a notification style? That
> could perhaps be integrated easier with Emacs frame, ie perhaps an
> Emacs frame could look like a balloon.

Looks like a lot of work to make an Emacs frame has a balloon shape,
at least on w32. The code for it is hidden in a window class and is
probably not meant to be combined with some other window class.

Re: Add function to make frame topmost?

[Tom Tromey]

>>>>> "David" == David De La Harpe Golden <david@harpegolden.net> writes:

David> Ading systray support to emacs was discussed in the context
David> of daemon mode a while back, maybe it's worth another look now.

I sent a patch.  I didn't understand how to rewrite based on the
comments I got back, and I don't have any Emacs hacking time any more;
maybe someone else could take it up.

I do use a hacked zenity + some of my own elisp to add systray support
to various things in Emacs: ERC, calendar/diary, EMMS.  I find it
indispensable.

Tom

systray support [was: Re: Add function to make frame topmost?]

[Dan Nicolaescu]

Tom Tromey <tromey@redhat.com> writes:

>>>>>> "David" == David De La Harpe Golden <david@harpegolden.net> writes:
>
> David> Ading systray support to emacs was discussed in the context
> David> of daemon mode a while back, maybe it's worth another look now.
>
> I sent a patch.  I didn't understand how to rewrite based on the
> comments I got back, and I don't have any Emacs hacking time any more;
> maybe someone else could take it up.

You might want to send it again, and ask for exact suggestions, now
it's good time in the release cycle to integrate new features.

At least you could sent the patch to the bug tracker so that it does
not get completely lost.

Just my 2 cents...

     --dan

Re: Add function to make frame topmost?

[David De La Harpe Golden]

Lennart Borgman wrote:

> The problem is that it is not powerful enough for things like menus of
> the type used by for company-mode or completion-ui (see EmacsWiki).

I'm not too familiar with either. I think the tooltip type window hint 
is indeed also used or abused for completion panel display by some 
non-emacs X11 apps (so says xprop). I don't now want to give too much 
weight to it - what emacs puts in and does with an X11 window that it 
tells the window manager is a tooltip is still pretty much up to emacs 
(of course currently emacs might currently only be allowing display of a 
string...)

 > What about having a
> function make-tooltip-type-frame?
>

Hmm. It _might_ make sense to allow it as an elisp-exposed emacs frame 
parameter.  e.g. for argument's sake

(make-frame '((disposition . tooltip))
(make-frame '((disposition . utility)))
etc.

Not sure "disposition" is the right word...

It would probably then also prove necessary to be able to specify 
override-redirect and wm-transient-for at the lisp level as frame 
parameters (though maybe the former could be implied - you're hardly not 
going turn on override-redirect if you're making a tooltip) - the 
lisp-level wm-transient-for (or "master-frame") frame parameter could 
probably be limited to other emacs frames.

OTOH, that all might be getting a bit lowlevel to expose so directly at 
the elisp level:  The precedent from tooltips and popup menus is that 
there are special-purpose apis for them at the elisp level, maybe
there's an argument for some sort of  single-purpose
(inline-completion-panel-show <mumble>)
and (notification-show <mumble>)
functions by analogy with
(tooltip-show "blah") and (popup-menu 'blah).

such an approach has the advantage it might be coaxed into doing 
something vaguely useful on text terminals.

OTOTOH, maybe the extra frame parameters might become a lower level 
implementation detail of such an api.

Re: Add function to make frame topmost?

[Jan Djärv]

Lennart Borgman skrev 2010-05-01 01.22:

>
> 1) a frame which is topmost.
> 2) looks like a tooltip frame
> 3) can show different things
> 4) can be hidden
> 5) can be shown without becoming active
> 6) never becomes the active window
> 7) looses it topmost property when switching to another app.
> 8) regains it when switching back
> 9) has to be recognized as such a frame by Emacs

Except for 7, 8 and 9, this is a tooltip.  How does one dimiss such a window, 
by timer?  Or clicking on it?  This has impact on the type of window as well.

>
> I am not sure about this list, please comment. What about having a
> function make-tooltip-type-frame?
>
> As I understand what you write here much of this is easily available
> on X with _NET_WM_WINDOW_TYPE_TOOLTIP. How about point 2 above? 4 and
> 5? 6? 7 and 8?

Actually overrride-redirect is still needed, the specification recommends just 
using _NET_WM_WINDOW_TYPE_TOOLTIP for override-redirect windows.  You need 
override-redirect anyway, because of older window managers.

>
> w32:
> - For 4 and 5 on w32 I have just added the bug report
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6068
> - And I just sent the function w32-set-frame-topmost here. This is
> needed, of course.
> - The w32 window style has to be modified for 2. (Just wrote this.)
> - Same for 6.
> - 7 and 8 are a bit more difficult (need to check WM_APPACTIVATE).
> - 9 is not specific to w32. A bit has to be added to the frame struct.
>

7 and 8 on X must depend on input focus.  If emacs looses input focus it can 
be considered not active.  But this is a tricky question.  If we for example 
activate the system menu Emacs looses focus, but no other application has it 
either.  We do not now keep track of focus on a global Emacs application 
level, just per frame.

> How does "Urgency" work? Is that appropriate for reminders? I would
> prefer that to be a frame that pops up but does not get focus until
> the user choosen it.

Typically it is placed at the top.  But if it gets focus or not is up to the 
window manager.  You have to add code to handle focus switch to be sure.

>
>
>>
>> ***
>> One can certainly do this from within emacs as per the spec (note you
>> do this for mapped windows by sending a client message to the root window).
>>   Note however, that window managers may refuse an app's request to be always
>> on top.
>>
>> (defun x-toggle-frame-always-on-top (&optional frame)
>>     (x-send-client-message
>>      frame 0 frame "_NET_WM_STATE" 32
>>      ;; _NET_WM_STATE_REMOVE = 0
>>      ;; _NET_WM_STATE_ADD = 1
>>      ;; _NET_WM_STATE_TOGGLE = 2
>>      '(2 "_NET_WM_STATE_ABOVE" 0 1)))
>
>
> Does this work already?
>

In the sense that it makes that frame topmost for window managers that support 
it, yes.  But it might as well be a no-op on other window managers.
Anyway, it is not recommended to use STATE_ABOVE like this.
But if we are going to abuse the spec, we might as well use _NET_RESTACK_WINDOW.

	JanD.

Re: Add function to make frame topmost?

[David De La Harpe Golden]

Jan Djärv wrote:
> 
> 
> Lennart Borgman skrev 2010-05-01 01.22:
> 
>>
>> 1) a frame which is topmost.
>> 2) looks like a tooltip frame
>> 3) can show different things
>> 4) can be hidden
>> 5) can be shown without becoming active
>> 6) never becomes the active window
>> 7) looses it topmost property when switching to another app.
>> 8) regains it when switching back

> 7 and 8 on X must depend on input focus.  If emacs looses input focus it 
> can be considered not active.

I think 7 and 8 might have been groping towards transient-for, actually.

Rather than "topmost" lennart might really be looking for is 
transient-for (on windows I think called an "owned" window -
Given toplevel windows A and B, B might be transient-for A on x11
and B might be owned-by A on w32.  Then B always appears above
A in the stacking order)

Re: Add function to make frame topmost?

[Lennart Borgman]

On Sat, May 1, 2010 at 9:46 PM, David De La Harpe Golden
<david@harpegolden.net> wrote:
> Jan Djärv wrote:
>>
>>
>> Lennart Borgman skrev 2010-05-01 01.22:
>>
>>>
>>> 1) a frame which is topmost.
>>> 2) looks like a tooltip frame
>>> 3) can show different things
>>> 4) can be hidden
>>> 5) can be shown without becoming active
>>> 6) never becomes the active window
>>> 7) looses it topmost property when switching to another app.
>>> 8) regains it when switching back
>
>> 7 and 8 on X must depend on input focus.  If emacs looses input focus it
>> can be considered not active.
>
> I think 7 and 8 might have been groping towards transient-for, actually.
>
> Rather than "topmost" lennart might really be looking for is transient-for
> (on windows I think called an "owned" window -

Yes, you are right. I just tested. For this purpose "owned windows" on
w32 seems to fit very good.

> Given toplevel windows A and B, B might be transient-for A on x11
> and B might be owned-by A on w32.  Then B always appears above
> A in the stacking order)
>
>
>
>
>

Re: Add function to make frame topmost?

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Fri, 30 Apr 2010 15:26:56 +0200
> Cc: Emacs-Devel devel <emacs-devel@gnu.org>
> 
> To tie this together I think something like
> 
>   (defun set-frame-topmost (frame top activate)
>     (cond
>      ((eq (display-type) 'x-windows) (x-set-frame-topmost frame top activate))
>      ((eq (display-type) 'w32) (w32-set-frame-topmost frame top activate))))
> 
> is needed. The function `display-type' does not exist yet of course.

I think it does, it's called window-system.  In this case, you need to
call it with `frame' as its argument (to cater to platforms that
support several different frame types in the same session).

Re: Add function to make frame topmost?

[Lennart Borgman]

On Fri, Apr 30, 2010 at 3:48 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> Could something like this please be added to w32fns.c?
>
> DEFUN ("x-set-frame-topmost", Fx_set_frame_topmost,
> Sx_set_frame_topmost, 1, 3, 0,
>       doc: /* Make frame FRAME topmost if TOP, otherwise not topmost.
> When ACTIVATE try to activate freme. */)
>     (frame, top, activate)
>     Lisp_Object frame, top, activate;
> {
>  FRAME_PTR f = check_x_frame (frame);
>  HWND hwndInsertAfter = NILP (top) ? HWND_NOTOPMOST : HWND_TOPMOST;
>  UINT swp_flags = SWP_NOMOVE | SWP_NOSIZE;
>  if (NILP (activate)) swp_flags = swp_flags | SWP_NOACTIVATE;
>  BLOCK_INPUT;
>  /* non-zero success, 0 fail + use GetLastError. */
>  SetWindowPos (FRAME_W32_WINDOW (f), hwndInsertAfter,
>                0, 0, 0, 0,
>                swp_flags);
>  UNBLOCK_INPUT;
>  return Qnil;
> }


The frame is not always redrawn as I expected. It looks like I need to
tell Emacs to redraw the frame after this. How do I do that?