[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#25408: Remove Decorations Around Emacs Frame (Windows OS)

From: Arthur Miller
Subject: bug#25408: Remove Decorations Around Emacs Frame (Windows OS)
Date: Wed, 15 Feb 2017 20:49:24 +0100

That's great. Are you going to push your patch to git-repo?

When it comes to other platforms than Windows, I have no idea about OS X since I don't own any macs, but for X11, we have different means to controll decorations and their looks & behaviour. On X11 we have window managers that makes it easy to configure (or remove) borders, decorations etc, so in my humble opinion I don't think you have to spend countless time to make it work with every possible window manager etc. I didn't even thought of this on Linux, I only needed it for windows, to make Emacs behave more like it does on Linux.

2017-02-12 12:13 GMT+01:00 martin rudalics <address@hidden>:
> Thanks! The patch applied cleanly and everything compiled fine.

Thanks for testing.  Please tell me your build and window manager types.

> ✓, although if I create a frame with no-focus-on-map I then need a
> call to raise-frame to raise it — even if its z-group is 'above.
> Maybe when z-group is "above" the frame should be automatically
> raised?

Not so here (with a GTK 3.4.2 build on Debian running xfwm).  Evaluating

(make-frame '((no-focus-on-map . t) (z-group . above)))

makes a new frame on top of the existing one regardless of whether xfwm
is set up to use focus follows mouse or not.

We probably have to investigate that further.

> ✓, although it would be nice to automatically raise the frame when
> x-group is above.  I can call raise-frame, but it doesn't work
> correctly when the frame is invisible (and setting the visibility to t
> before raising the frame doesn't work either).

I mentioned that: When a frame is made invisible, its z-group is reset
to nil by the window system or manager.  x_set_z_group can't cope with
that because the last line of

x_set_z_group (struct frame *f, Lisp_Object new_value, Lisp_Object old_value)
  if (!EQ (new_value, old_value))

still assumes that the frame is "above".  For the moment try with

(set-frame-parameter frame 'z-group nil)
(set-frame-parameter frame 'z-group 'above)

as a workaround.  I'm not yet sure whether it's better to (1) have
x_make_frame_invisible and x_iconify_frame reset the z-group parameter
explicitly, (2) change x_set_z_group so it always issues a request to
the window system, or (3) remove the z-group parameter and make the
z-group setting an option of the `frame-restack' function.

Unfortunately, the z-group equivalents in X 11 are a complete mess: You
can put a window simultaneously in the ‘above’ and the ‘below’ groups
and it notwhere says what should prevail and what happens when you later
remove a window from one of these groups (I trioed to avoid this dilemma
with the z-group concept).  And restacking may probably remove a window
from these groups and maybe not allow to put it there and so on ...

And why not avoid z-groups at all?  Because you cannot simply restack a
frame on top of the "active" frame.  If you try (via a foucs-in-hooked
function) you will see that your window system uses up all available
resources because the window system wants to raise the active frame and
Emacs wants to raise the other one.  So to put a frame on top of the
"active" frame you have to put that frame in the ‘above’ group.

> * Creating a frame is rather slow; the following is an excerpt of a profile:
>                 - make-frame                                       442  29%
>                  - frame-creation-function                         440  29%
>                   - apply                                          440  29%
>                    - #<compiled 0x4862dd>                          440  29%
>                     - x-create-frame-with-faces                    440  29%
>                      - face-set-after-frame-default                307  20%
>                       - face-spec-recalc                           276  18%
>                        - make-face-x-resource-internal             217  14%
>                         - set-face-attributes-from-resources       213  14%
>                          - set-face-attribute-from-resource        190  12%
>                           - face-name                              126   8%
>                            + check-face                            118   7%
>                        + face-spec-reset-face                       44   2%
>                        + face-spec-set-2                             7   0%
>                         set-face-attribute                           8   0%
>                    normal-erase-is-backspace-setup-frame                  2   0%

But isn't that the problem I tried to tackle (for tooltip frames) with
the option ‘tooltip-reuse-hidden-frame’?  All this face-related stuff is
an ecological disaster IMHO.  Here, creating a tooltip frame caused up
to two GC cycles before I added that option.

So as a rule create your frames (lazily) once for each session and hide
them when you don't need them.

> * Frames with z-group set to 'above are not automatically raised when
> no-focus-on-map is set, so I need to call x-raise-frame on them; this
> doesn't work when they are invisible (instead it makes them visible
> without raising them, it seems).

I hope I described the problem and a workaround above.  I attach my
functions for testing attached frames so you can see how I handle this

> * Creating a frame / making it visible uses my WM's frame creating animation — is there a way to disable this (x-show-tip doesn't have it)?

No idea.  I can look into that (as a rule I turn off all animations
here).  Do you use GTK tooltips or Emacs' native ones?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]