[Top][All Lists]

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

Re: Emacs's set-frame-size can not work well with gnome-shell?

From: Dmitry Gutov
Subject: Re: Emacs's set-frame-size can not work well with gnome-shell?
Date: Sun, 26 Jan 2020 14:59:31 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 25.01.2020 15:10, martin rudalics wrote:
 > The first experiment: moving the frame by mode-line is smooth.

And it's slow with child frames so we have a major difference here.

It's a very murky story.

I rebuilt with toolkit=lucid, tried the experiment

  => dragging by mode-line was choppy

Changed the scaling factor of the desktop to 100% (everything became tiny on my monitor), restarted Emacs.

  => dragging by mode-line was smooth

BUT dragging the borders to resize had the same problem I reported previously, so it's likely not HiDPI related.

Then I changed scaling back to 200%, restarted Emacs.

  => dragging by mode-line was still smooth (normal frame).

Then tried the child-frame example.

=> dragging was choppy. But it resizes smoothly enough when dragged by the bottom or right edges. And, more importantly, resizes correctly. When dragged by top-left, it resizes choppily, but still correctly.

In the same session, I applied your default-frame-alist change and created a second "normal" frame. Dragging it by mode-line was choppy again. And resizing it was broken in the same sense I described before (and will again clarify below).

So, in the same session, a child frame and a normal frame have a different resizing behavior. A normal frame can move smoothly *sometimes*, a child frame always moves choppily.

 > After that: I tried resizing the dragging the border.

Which border(s)?

Any of them. But:

When I drag top-left, the bottom-right corner seems to exhibit a more gradual drift top-left. When I drag bottom-right, I moves top-left a lot more quickly (even if I drag it in the bottom-right direction).

Please note: in most of my experiments I dragged by the corner (top-left or bottom-right), and moved in circular-ish, random trajectories. This triggers the bug most prominently. But if I just grab one border and move the mouse in a straight line, that makes the border move in the desired direction, albeit not exactly following the mouse cursor (hence the effect, probably).

E.g. if I drag the right border right, it moves after the mouse, but more slowly than the mouse. If I move it left, it moves *faster* than the mouse. Same with the bottom border. Top and left seem to have a similar effect, but less pronounced. Also dragging the top border seems to have an effect on the position of the bottom edge (it moves up). In all cases, resizing is not smooth.

 > Apparently, it
 > doesn't account for window scaling, so it resizes to wrong size, and
 > the window generally shrinked. After that, moving became choppy as
 > well. Including after I deleted the resized frame and created new
 > one(s).

This sounds interesting.  Does scaling work at all with the Lucid build?

Seems so. Aside from the toolbar icons which are not scaled. The context menu appears where it should.

Also, the GTK3 build seems to have the same problem, and it has had quite a few HiDPI patches applied recently.

So maybe scaling is not the actual issue (or the jumps would be sharper, this just occurred to me).

 > In the meantime, resizing the first, "normal" frame works okay. Moving
 > too (by the title bar).

How comes the first frame has a title bar with this specification

Err, it never occurred to me to put this form in the init script.

I launch Emacs, then evaluate this in scratch in the first frame, and then press 'C-x 5 2' and experiment with the second frame.

(setq default-frame-alist
       '((minibuffer . nil) (undecorated . t) (drag-with-mode-line . t)
    (border-width . 0) (internal-border-width . 8) (drag-internal-border . t)
     (menu-bar-lines . 0) (tool-bar-lines . 0)))

 > GTK:
 > Actually, similar story with resizing.

You mean similar to the Lucid resizing behavior?

Yes (!!). Very similar (maybe exactly the same even).

The differences are: child frames do not resize. And dragging them by mode-line looks the same as dragging normal ones: move smoothly enough, with some drift.

 > Moving seems smooth enough before and after, with gradual drift toward
 > top-left (because of the other bug we've mentioned before, probably).

Bug#38452, I presume.


reply via email to

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