Re: How about introducing a new frame parameter: topmost

Re: How about introducing a new frame parameter: topmost

[brianjiang]

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

> It needs to work under X11 as well before I'd consider integrating the
> feature.  BTW, another detail is: does this property mean "stay above
> every other GUI window", or "stay above the current Emacs frame", or
> "stay above all other frames owned by this Emacs process"?
>  
> The latter seems more useful.  The former is probably what your
> code does.  In X11, there's a feature which could do something like
> the 2nd option, which is to mark a frame as being "transient", in
which
> case most window managers will try to keep it "above its parent
window",
> at least if that transient window is sufficiently small.
>  
>  
>         Stefan
 
Yes, my code does the one "stay above every other GUI window". That is
the easiest way.
 
I did try to implement the 2nd option ("stay above the current Emacs
frame") too by using the existing frame parameter "parent-id". 
Something like:
 
  In proc w32_createwindow:
      if (f->output_data.w32->parent_desc != FRAME_X_DISPLAY_INFO
(f)->root_window)
        {
          long style;
          
          SetWindowLong (hwnd, GWL_HWNDPARENT,
(long)f->output_data.w32->parent_desc);
          style = GetWindowLong (hwnd, GWL_STYLE);
          style &= ~(WS_MINIMIZEBOX);
          SetWindowLong (hwnd, GWL_STYLE, style);
        }
  Comment out the following line in x-create-frame:
     /* f->output_data.w32->parent_desc = FRAME_W32_DISPLAY_INFO
(f)->root_window;*/
  And also something need to be taken care in Fdelete_frame.
 
It works. But sometimes it has problem in redisplaying the parent window
(parent window is not painted sometimes). And the child frame (window)
doesn't have icon/button in the windows taskbar too. 
 
In GTK+, there is a API to do the 2nd option:
gtk_window_set_transient_for. In Windows, this API actually is
implemented by calling SetWindowLong with GWL_HWNDPARENT too.
 
But the MSDN says:
   You must not call SetWindowLong with the GWL_HWNDPARENT index to
   change the parent of a child window. Instead, use the SetParent
   function. 
But SetParent is not what we need. 
 

Don't know a way to do the 3rd option ("stay above all other frames
owned by this Emacs process") yet :-(
 

 

[-- Attachment #2: Type: text/html, Size: 4255 bytes --]

Re: How about introducing a new frame parameter: topmost

[brianjiang]

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

> > If this parameter is true, the frame is shown as a TOPMOST window.
>               
> The tricky part is to coerce the window manager into agreeing
> with Emacs.   
>               
>               
>         Stefan

It is quit easy to implement it in Windows, simply calling WIN API
SetWindowPos.
Currently, I actually implement it by defining a DEFUN
w32-set-frame-topmost as follows. 
But I don't know whether we can implement the same thing in X-window
system and MAC 
system.
 
 
DEFUN("w32-set-frame-topmost", Fw32_set_frame_topmost, 
      Sw32_set_frame_topmost, 0, 2, 0,
      doc: /* update later */)
     (frame, notopmost)
     Lisp_Object frame, notopmost;
{
  FRAME_PTR f = check_x_frame (frame);
 
  HWND hWndInsertAfter;
 
  if (NILP(notopmost))
    {
      hWndInsertAfter = HWND_TOPMOST;
    }
  else
    {
      hWndInsertAfter = HWND_NOTOPMOST;
    }
  
  SetWindowPos(FRAME_W32_WINDOW(f), hWndInsertAfter, 0, 0, 0, 0,
               SWP_NOMOVE|SWP_NOSIZE);
  
  return Qnil;
}


[-- Attachment #2: Type: text/html, Size: 2757 bytes --]

Re: How about introducing a new frame parameter: topmost

[Stefan Monnier]

>> > If this parameter is true, the frame is shown as a TOPMOST window.
>> The tricky part is to coerce the window manager into agreeing
>> with Emacs.
> It is quit easy to implement it in Windows, simply calling WIN API
> SetWindowPos.

It needs to work under X11 as well before I'd consider integrating the
feature.  BTW, another detail is: does this property mean "stay above
every other GUI window", or "stay above the current Emacs frame", or
"stay above all other frames owned by this Emacs process"?

The latter seems more useful.  The former is probably what your
code does.  In X11, there's a feature which could do something like
the 2nd option, which is to mark a frame as being "transient", in which
case most window managers will try to keep it "above its parent window",
at least if that transient window is sufficiently small.


        Stefan

How about introducing a new frame parameter: topmost

[brianjiang]

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

How about introducing a new frame parameter: topmost . 
If this parameter is true, the frame is shown as a TOPMOST window.
 
It will be quite useful. e.g.,
 
1. During ediff, the small ediff frame can be set as TOPMOST frame. So
it will not be hiden when we need to edit the comparing file
termporarily.
 
2. Sometimes we may like to pop up a small information frame (e.g.,
*help*, sometimes we may prefer to pop up a new frame instead of
spltting the current frame/window), and at the same time, we can edit
file in another frame. The information frame is set as TOPMOST, so it
will not be coverred by the edit frame. And so we can easily refer to
the information when we are editing our file. It will be very nice.
 

[-- Attachment #2: Type: text/html, Size: 2398 bytes --]

Re: How about introducing a new frame parameter: topmost

[Stefan Monnier]

> If this parameter is true, the frame is shown as a TOPMOST window.
 
The tricky part is to coerce the window manager into agreeing
with Emacs.


        Stefan

Re: How about introducing a new frame parameter: topmost

[James Cloos]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> If this parameter is true, the frame is shown as a TOPMOST window.

Stefan> The tricky part is to coerce the window manager into agreeing
Stefan> with Emacs.

On X _WIN_LAYER is the CADRINAL icewm uses for layering.

Ice uses these values:

14 FullScreen
12 Menu
10 Above Dock
 8 Dock
 6 OnTop
 4 Normal
 2 Below
 0 Desktop

Ice's src has this comment, which also may be relevant to the full
screen thread:

/* ** from icewm-1.2.35/src/WinMgr.h **
 *
 * Window layer.
 * Windows with LAYER=WinLayerDock determine size of the Work Area
 * (WIN_WORKAREA). Windows below dock layer are resized to the size
 * of the work area when maximized. Windows above dock layer are
 * maximized to the entire screen space.
 *
 * The default can be set by application, but when window is mapped
 * only window manager can change this. If an application wants to change
 * the window layer it should send the ClientMessage to the root window
 * like this:
 *     xev.type = ClientMessage;
 *     xev.window = toplevel_window;
 *     xev.message_type = _XA_WIN_LAYER;
 *     xev.format = 32;
 *     xev.data.l[0] = layer;
 *     xev.data.l[1] = timeStamp;
 *     XSendEvent(display, root, False, SubstructureNotifyMask, (XEvent *) &xev);
 *
 */

AFAIK this is a cross-wm ATOM.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6