bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Thu, 16 Feb 2017 15:06:05 +0100

After checking out a commit previous to

Generate upcase and downcase tables from Unicode data (bug#24603)

I was able to build it.

2017-02-16 14:22 GMT+01:00 Arthur Miller <address@hidden>:
If they don't get focus when they pop-up, and not get focus via mouse and if they also
don't have decorations, what is considered as full functionality of "normal" frames?
That sounds to me a bit like a popup window. Do you give them focus by switching
with keyboard, like moving focus to "other window"?

"The concern is how to control
aspects like appearance, placement, focusing and stacking order of some
specific Emacs frames, without affecting the remaining frames."

As you yourself point out, certain WMs does allow you to create rules per windows.  On some
managers one can set rule based on window title bar, window class or class name, 
xid, role etc. I don't know if title bar property can be used if titlebar exist but is hidden.

Maybe a separate class name could be used for that kind of windows so one can set
appropriate hints for that frame. Or maybe you are already doing that? Just an idea,
I haven't looked at your patch to be honest.

I cloned code today from git and compilations is crashing on me, when dumping lisp code:
(without your patch applied):

Loading /home/arthur/emacs/lisp/international/characters.el (source)...
Wrong type argument: char-table-p, nil
make[1]: *** [Makefile:752: bootstrap-emacs] Error 255
make[1]: Leaving directory '/home/arthur/emacs/src'
make: *** [Makefile:409: src] Error 2

Will be interesting to test it once I manage to compile Emacs.


2017-02-16 9:04 GMT+01:00 martin rudalics <address@hidden>:
> That's great. Are you going to push your patch to git-repo?

After having resolved some remaining issues, yes.

> 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.

The concern here is not how to turn off decorations for all windows (or
maybe all windows of a certain application), something which themes most
likely already provide to some extent.  The concern is how to control
aspects like appearance, placement, focusing and stacking order of some
specific Emacs frames, without affecting the remaining frames.

Consider the need to display some explanatory information for the
editing activity you are about to accomplish.  If you don't want to pop
up a new "normal" window or frame for that purpose, you currently have
two possibilites: Use the echo area or the tooltip frame.  Both are
ephemeral and have to be shared with all other applications pursuing a
similar goal.

Hence the need for some sort of minor frames which are OT1H less
ephemeral and can be more easily replicated than tooltips or the echo
area and are OTOH visually and habitually less obtrusive than normal
frames or windows.

Some desirable properties of such minor frames are:

(1) Do not show any window manager decorations provided their visibility
    and placement can be controlled by the application.

(2) Do not show them on the taskbar.

(3) Do not focus them when they pop up.

(4) Do not give them focus via mouse movements, mouse wheel scrolling or
    accidental mouse clicks.

(5) Allow to attach them to some normal Emacs frame or window.  This
    means to automatically move, resize and stack them along with that
    frame/window without affecting the appearance of any other object on
    your display.  It may also mean to make them obscure as few as
    possible text of the frame they have been attached to.

(6) Apart from (1)--(5) give them the full functionality of "normal"
    Emacs frames.

Obviously, (6) is the most difficult part.  For example, displaying such
a frame without making it continuously vanish and reappear.

martin



reply via email to

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