bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

In 16.10, things worked as normal, but in Ubuntu 17.04 Emacs starts in
fullscreen mode.  That is, emacs -Q says:

(frame-parameter nil 'fullscreen)
maximized

If I say "emacs -geometry 20x20 -Q", then Emacs isn't fullscreen, but
instead starts with a frame that is approximately 84 characters by 46
characters.

This is on a HiDPI screen:

larsi@mouse:~$ dconf read /com/ubuntu/user-interface/scale-factor
{'eDP1': 11, 'eDP-1': 12}

Emacs 25 appears to behave the same as git Emacs, so whatever's going on
isn't a new bug, I think.

I tried grepping through the Emacs source code to find out what sets the
`maximized' value, and it's perhaps the get_current_wm_state thing?  I'm
not sure.

I also note that Emacs has a gaggle of options to switch fullscreen mode
on, but apparently none to switch it off?  


In GNU Emacs 26.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.14.5)
 of 2017-06-07 built on stories
Repository revision: 62523863780d3894c92f84dd474278eeddc4a0e0
Windowing system distributor 'The X.Org Foundation', version 11.0.11903000
System Description:	Debian GNU/Linux 8.7 (jessie)


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[martin rudalics]

 > In 16.10, things worked as normal, but in Ubuntu 17.04 Emacs starts in
 > fullscreen mode.  That is, emacs -Q says:
 >
 > (frame-parameter nil 'fullscreen)
 > maximized

Does this match the state of the window manager maximized button?  What
happens when you click it?

 > If I say "emacs -geometry 20x20 -Q", then Emacs isn't fullscreen, but
 > instead starts with a frame that is approximately 84 characters by 46
 > characters.
 >
 > This is on a HiDPI screen:
 >
 > larsi@mouse:~$ dconf read /com/ubuntu/user-interface/scale-factor
 > {'eDP1': 11, 'eDP-1': 12}

Can you try without scaling?

 > Emacs 25 appears to behave the same as git Emacs, so whatever's going on
 > isn't a new bug, I think.
 >
 > I tried grepping through the Emacs source code to find out what sets the
 > `maximized' value, and it's perhaps the get_current_wm_state thing?  I'm
 > not sure.

It should be.  Can you get a backtrace from there?

 > I also note that Emacs has a gaggle of options to switch fullscreen mode
 > on, but apparently none to switch it off?

(set-frame-parameter nil 'fullscreen nil)

or ‘toggle-frame-maximized’.

martin

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

>> In 16.10, things worked as normal, but in Ubuntu 17.04 Emacs starts in
>> fullscreen mode.  That is, emacs -Q says:
>>
>> (frame-parameter nil 'fullscreen)
>> maximized
>
> Does this match the state of the window manager maximized button?  What
> happens when you click it?

The window manager is Unity, and there's no button as such.  But there
is an "unmaximize" menu option, which works as it's supposed to.

>> If I say "emacs -geometry 20x20 -Q", then Emacs isn't fullscreen, but
>> instead starts with a frame that is approximately 84 characters by 46
>> characters.
>>
>> This is on a HiDPI screen:
>>
>> larsi@mouse:~$ dconf read /com/ubuntu/user-interface/scale-factor
>> {'eDP1': 11, 'eDP-1': 12}
>
> Can you try without scaling?

I don't know how to alter it.

>> I tried grepping through the Emacs source code to find out what sets the
>> `maximized' value, and it's perhaps the get_current_wm_state thing?  I'm
>> not sure.
>
> It should be.  Can you get a backtrace from there?

I'll try later.

>> I also note that Emacs has a gaggle of options to switch fullscreen mode
>> on, but apparently none to switch it off?
>
> (set-frame-parameter nil 'fullscreen nil)
>
> or ‘toggle-frame-maximized’.

I meant command line options.  There's --maximized and --fullwidth and
--fullscreen and --fullheight, but no "no, I don't want anything maxed".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 14 Jun 2017 18:38:48 +0200
> Cc: 27357@debbugs.gnu.org
> 
> > (set-frame-parameter nil 'fullscreen nil)
> >
> > or ‘toggle-frame-maximized’.
> 
> I meant command line options.  There's --maximized and --fullwidth and
> --fullscreen and --fullheight, but no "no, I don't want anything maxed".

There's also no "no, I don't want only black-and-white colors", and no
"no, I don't want any of my scroll bars disappear".

Command-line options are there to change the default behavior, which
maximized frames isn't.  We don't have options to get back the default
behavior, because that behavior should be there, err, by default.

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> There's also no "no, I don't want only black-and-white colors", and no
> "no, I don't want any of my scroll bars disappear".

--color=never

:-)

But I get your point. 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[martin rudalics]

 >> Does this match the state of the window manager maximized button?  What
 >> happens when you click it?
 >
 > The window manager is Unity, and there's no button as such.  But there
 > is an "unmaximize" menu option, which works as it's supposed to.

Which menu?  And what is the frame's size after "unmaximizing" it?

 > I meant command line options.  There's --maximized and --fullwidth and
 > --fullscreen and --fullheight, but no "no, I don't want anything maxed".

If your window manager decides that the frame sould be maxed, Emacs
won't resist.

martin

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

>>> Does this match the state of the window manager maximized button?  What
>>> happens when you click it?
>>
>> The window manager is Unity, and there's no button as such.  But there
>> is an "unmaximize" menu option, which works as it's supposed to.
>
> Which menu?  And what is the frame's size after "unmaximizing" it?

You get a menu when you right-click the title bar.  The frame's size is
the size of the screen after unmaximizing it, but you can then pull the
edges and make it smaller.

>> I meant command line options.  There's --maximized and --fullwidth and
>> --fullscreen and --fullheight, but no "no, I don't want anything maxed".
>
> If your window manager decides that the frame sould be maxed, Emacs
> won't resist.

No other windows except Emacs are maximized, so I don't think the window
manager has decided this.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[martin rudalics]

 >> If your window manager decides that the frame sould be maxed, Emacs
 >> won't resist.
 >
 > No other windows except Emacs are maximized, so I don't think the window
 > manager has decided this.

Did you try starting any other application with a "way too large"
initial window size?

martin

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

I'm having a hard time making sense of the code flow in xterm.c.  But
what seems to be happening is that Emacs first comes up with a frame in
proper size, and then it's rescaled to be fullsize.

Looking at get_current_wm_state, in that loop there, a matches both
dpyinfo->Xatom_net_wm_state_maximized_horz and
dpyinfo->Xatom_net_wm_state_maximized_vert, which explains why Emacs
gets maximized.

But I'm having no luck in understanding why those fields are being set,
or where...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

Instead of looking around in the source code, I found out how to change
the DPI settings.  dconf-editor is apparently the thing to use.

The default settings are

{'eDP1': 11, 'eDP-1': 12}

If I change this to

{'eDP1': 11, 'eDP-1': 11}

or anything less than 12, then all the Emacs frame sizes are correct:
Maximization doesn't happen, and --geometry works as expected.  But if I
change that to

{'eDP1': 11, 'eDP-1': 12}

then all my Emacs frames gets maximized.

Could there be a math error somewhere?  And if so, where?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[martin rudalics]

 > Instead of looking around in the source code, I found out how to change
 > the DPI settings.  dconf-editor is apparently the thing to use.
 >
 > The default settings are
 >
 > {'eDP1': 11, 'eDP-1': 12}
 >
 > If I change this to
 >
 > {'eDP1': 11, 'eDP-1': 11}
 >
 > or anything less than 12, then all the Emacs frame sizes are correct:
 > Maximization doesn't happen, and --geometry works as expected.

Can you change those settings on a per application basis?

 > But if I
 > change that to
 >
 > {'eDP1': 11, 'eDP-1': 12}
 >
 > then all my Emacs frames gets maximized.

Does the window manager constrain the frame size to the screen?  WOW, if
you specifiy an initial frame larger than your screen, do you get it
that way?

 > Could there be a math error somewhere?  And if so, where?

IIRC GTK Emacs supports scaling only partially.  Could you try with
another toolkit?  Also, ISTR that people complained about mispositioned
scroll bars, menus and tooltips, sometimes alos about misplaced
underlinings and the like.  Do you see any of those effects too?

martin

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

>> If I change this to
>>
>> {'eDP1': 11, 'eDP-1': 11}
>>
>> or anything less than 12, then all the Emacs frame sizes are correct:
>> Maximization doesn't happen, and --geometry works as expected.
>
> Can you change those settings on a per application basis?

Not that I know.  In any case, this seems like it's an Emacs bug, and
shouldn't we fix that?

> Does the window manager constrain the frame size to the screen?  WOW, if
> you specifiy an initial frame larger than your screen, do you get it
> that way?

If I say "xterm -geometry 800x20", then it seems to be constrained to
the screen size.

>> Could there be a math error somewhere?  And if so, where?
>
> IIRC GTK Emacs supports scaling only partially.  Could you try with
> another toolkit?

Well, this isn't about fixing my frames -- I can do that with a couple
of lines of Emacs Lisp.  But Emacs seems to be buggy here, and it would
be nice to fix that bug.

> Also, ISTR that people complained about mispositioned
> scroll bars, menus and tooltips, sometimes alos about misplaced
> underlinings and the like.  Do you see any of those effects too?

Nope.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

If I say "xterm -geometry 800x700" (which is larger than the screen),
Unity will open the screen in "maximized" mode.  Perhaps this means that
Emacs is just miscomputing the size of the frame leading to a
way-too-big window, and then the window manager is snapping it back to
maximized?

So where's the frame size computed, anyway?  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[martin rudalics]

 > If I say "xterm -geometry 800x700" (which is larger than the screen),
 > Unity will open the screen in "maximized" mode.  Perhaps this means that
 > Emacs is just miscomputing the size of the frame leading to a
 > way-too-big window, and then the window manager is snapping it back to
 > maximized?

Precisely what I expected and why I asked you to conduct this
experiment.  Some window managers do that when mapping a window.

To continue the experiment: I suppose that once your frame has become
visible, you can make it 800x700 characters large.  What happens when
you iconify that frame and make it visible again?

 > So where's the frame size computed, anyway?  :-)

Who knows?  Uusually, I say here that one of Emacs' original sins is to
request a frame size based on that frame's default character size.

martin

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

Man, this stuff is difficult to figure out...

I think I've found the call that resizes the frame erroneously.

I'm running under gdb with

(gdb) run -Q -geometry 80x20

to get a smallish frame.

change_frame_size is called a lot of times, but eventually with the
correct size:

#0  0x00000000004272f9 in adjust_frame_size (f=0x133ec30 <bss_sbrk_buffer+6645648>, new_width=1040, new_height=520, inhibit=0, pretend=true, parameter=XIL(0xd800)) at frame.c:546
#1  0x000000000053b497 in Fx_create_frame (parms=XIL(0x1151c43))
    at xfns.c:3996

So everything is OK up till now: Emacs has popped up a frame, and it has
the right size.

Then shenanigans start, and they are all seemingly triggered from inside
gtk:

0  0x0000000000424bf8 in change_frame_size (f=0x133ec30 <bss_sbrk_buffer+6645648>, new_width=2112, new_height=1040, pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5546
#1  0x000000000054de1d in xg_frame_resized (f=0x133ec30 <bss_sbrk_buffer+6645648>, pixelwidth=2144, pixelheight=1040) at gtkutil.c:886
#2  0x000000000052a10c in handle_one_xevent (dpyinfo=0x2f8a540, event=0x7fffffffb280, finish=0xc6dc14 <current_finish>, hold_quit=0x7fffffffb550)
    at xterm.c:8676
#3  0x000000000052785f in event_handler_gdk (gxev=0x7fffffffb280, ev=0x2d6d3d0, data=0x0) at xterm.c:7538
#4  0x00007ffff66f4c81 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#5  0x00007ffff66f4f39 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#6  0x00007ffff66bf259 in gdk_display_get_event ()
    at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#7  0x00007ffff66f4cf2 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#8  0x00007ffff5653377 in g_main_context_dispatch ()
    at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x00007ffff56535e0 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff565368c in g_main_context_iteration ()

xg_frame_resized has apparently now decided that the frame should be
2112x1040 instead of 1040x520, which is the real target size.  So...
twice as high, and slightly less as wide.

And then:

#0  0x0000000000424bf8 in change_frame_size (f=0x133ec30 <bss_sbrk_buffer+6645648>, new_width=2528, new_height=1264, pretend=false, delay=true, safe=false, pixelwise=true) at dispnew.c:5546
#1  0x000000000054de1d in xg_frame_resized (f=0x133ec30 <bss_sbrk_buffer+6645648>, pixelwidth=2560, pixelheight=1264) at gtkutil.c:886
#2  0x000000000052a10c in handle_one_xevent (dpyinfo=0x2e75b70, event=0x7fffffff90b0, finish=0xc6dc14 <current_finish>, hold_quit=0x7fffffff9380)
    at xterm.c:8676
#3  0x000000000052785f in event_handler_gdk (gxev=0x7fffffff90b0, ev=0x2d6d6f0, data=0x0) at xterm.c:7538
#4  0x00007ffff66f4c81 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#5  0x00007ffff66f4f39 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#6  0x00007ffff66bf259 in gdk_display_get_event ()
    at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#7  0x00007ffff66f4cf2 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#8  0x00007ffff5653377 in g_main_context_dispatch ()
    at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x00007ffff56535e0 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff565368c in g_main_context_iteration ()
    at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007ffff6bc2275 in gtk_main_iteration ()
    at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#12 0x000000000052ade8 in XTread_socket (terminal=0x1275e40 <bss_sbrk_buffer+5

So now gtk decided that the size should be 2528x1264 (which is the max
size and makes Emacs maximized).

So what could be the cause of these xg_frame_resized events?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

Oh, all this is inside Emacs.  I thought it was part of the gtk stuff
somehow.

Anyway, this is from handle_one_xevent, and this is the first of these
calls that expands the size (erroneously):

      if (!f
          && (f = any)
          && configureEvent.xconfigure.window == FRAME_X_WINDOW (f))
        {
          block_input ();
          if (FRAME_X_DOUBLE_BUFFERED_P (f))
            font_drop_xrender_surfaces (f);
          unblock_input ();
          xg_frame_resized (f, configureEvent.xconfigure.width,
                            configureEvent.xconfigure.height);

So something sets configureEvent.xconfigure.width...  And this happens
when the initial basic fonts are realised.

The call sequence here isn't completely obvious.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[martin rudalics]

 > So something sets configureEvent.xconfigure.width...  And this happens
 > when the initial basic fonts are realised.
 >
 > The call sequence here isn't completely obvious.  :-)

Did you try tracing the ‘adjust_frame_size’ call on line 9930 of
‘x_new_font’?

martin

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

I just noticed something amusing: If I put the mouse over the mode line
things that pop up tooltips, they're all displayed approximately 2x from
the position they're supposed to:

https://youtu.be/oWjmL-8leVo

This is with the current git Emacs, with -Q on Ubuntu 17.04 (with a
HiDPI display).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[martin rudalics]

 > I just noticed something amusing: If I put the mouse over the mode line
 > things that pop up tooltips, they're all displayed approximately 2x from
 > the position they're supposed to:
 >
 > https://youtu.be/oWjmL-8leVo
 >
 > This is with the current git Emacs, with -Q on Ubuntu 17.04 (with a
 > HiDPI display).

See bug#18429, bug#20619, bug#21348, bug#21469 ...

martin

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

>> I just noticed something amusing: If I put the mouse over the mode line
>> things that pop up tooltips, they're all displayed approximately 2x from
>> the position they're supposed to:
>>
>> https://youtu.be/oWjmL-8leVo
>>
>> This is with the current git Emacs, with -Q on Ubuntu 17.04 (with a
>> HiDPI display).
>
> See bug#18429, bug#20619, bug#21348, bug#21469 ...

Oh, wow, so this has been a known problem, apparently related to gtk3
with HiDPI, for almost a couple of years, but nobody has been able to
track down just exactly where Emacs is doubling the sizes?

I spent a few hours on this a few days ago, but I was unable to follow
the call chain logic (which is somewhat asynchronous).  And some of the
effects seem to be timing related, somehow...

I've read through the emails in question, but the patch posted didn't
seem very promising since it only handled tooltip placement and not
window sizing...

Do you have any ideas for where I should be poking around to see where
these bogus doubled values come from?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

I found the place where the tooltips are positions, and that seemed like
an easy place to experiment, so I did.

If I divide root_x and root_y by 2, the positioning is exactly as it's
supposed to be.

So the wrong calculations here seem to be completely internal to gtk.
To verify, I did the following:

diff --git a/src/gtkutil.c b/src/gtkutil.c
index 2d4abefa96..050433d5c3 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -724,7 +724,10 @@ xg_show_tooltip (struct frame *f, int root_x, int root_y)
   if (x->ttip_window)
     {
       block_input ();
-      gtk_window_move (x->ttip_window, root_x, root_y);
+      printf("Input x %d, y %d\n", root_x, root_y);
+      gtk_window_move (x->ttip_window, root_x/2, root_y/2);
+      gtk_window_get_position (x->ttip_window, &root_x, &root_y);
+      printf("Output x %d, y %d\n", root_x, root_y);
       gtk_widget_show_all (GTK_WIDGET (x->ttip_window));
       unblock_input ();
     }

The output is:

Input x 725, y 464
Output x 362, y 232

So gtk seems to think that we're living in a world where the pixels
passed in are supposed to be doubled from what Emacs is passing it: That
is, that if you send in (2, 2), the physical pixel being addressed is
(4, 4).

Perhaps there's a way to tell gtk to stop doing that?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

GDK_SCALE=1 ./emacs

will make tooltips appear in the correct place in Emacs, and makes
"emacs -Q" window sizes correct!

So that's the culprit.  But what's the fix?  Since Emacs isn't
scale-aware, should emacs just set that on startup?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

I see that others have been struggling with the same thing and come up
with the same "solution":

https://www.reddit.com/r/emacs/comments/51wm7d/emacs_on_hidpi_displays/

"This makes GTK widgets (icons, scrollbars, etc) render small, but their
placement is correct."

So...  to fix this properly, we have to find all places where we call
gtk positioning/sizing functions and apply the proper scaling?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[martin rudalics]

 > So...  to fix this properly, we have to find all places where we call
 > gtk positioning/sizing functions and apply the proper scaling?

And disentangle them from the non-GTK builds which, unfortunately, seems
the greater problem.  Note that the GTK build still uses X functions in
many places.

martin

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

>> So...  to fix this properly, we have to find all places where we call
>> gtk positioning/sizing functions and apply the proper scaling?
>
> And disentangle them from the non-GTK builds which, unfortunately, seems
> the greater problem.  Note that the GTK build still uses X functions in
> many places.

I've confirmed that Ryan Prior's patch fixes the problem for tooltip
positioning, so now I guess we just have to find all the other places
where we call gtk position/sizing functions...  :-)

Does Ryan have copyright papers on file?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[martin rudalics]

 > I've confirmed that Ryan Prior's patch fixes the problem for tooltip
 > positioning,

Didn't he also fix the menu popups?

 > so now I guess we just have to find all the other places
 > where we call gtk position/sizing functions...  :-)
 >
 > Does Ryan have copyright papers on file?

I'm glad you are the first to test his patch after almost two years.
People were not very friendly at that time.  Maybe you could try to
contact him?

martin

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

>> I've confirmed that Ryan Prior's patch fixes the problem for tooltip
>> positioning,
>
> Didn't he also fix the menu popups?

Yes, those seem to work fine, too..

> I'm glad you are the first to test his patch after almost two years.
> People were not very friendly at that time.  Maybe you could try to
> contact him?

That might be a good idea, but I'm not sure where the previous people
who were working on scaling were going with their work.

Amusingly enough, the 

      int scale = xg_get_gdk_scale ();

stuff that's sprinkled around just seems to get in the way of fixing
this stuff.  It explicitly looks at the GDK_SCALE environment variable,
which is (by default) not set.  So while some bits of Emacs is using
that variable to determine some things, querying GTK in the proper way
(with gtk_widget_get_scale_factor) will get another answer.

Hm...  perhaps I should just start a branch, try to clean stuff up and
see what happens...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

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

Wow.

After getting rid of the GDK_SCALE stuff (well, replacing it by querying
GTK for what scaling it's using), and doing the same with the
positioning as Ryan did (I ended up writing my own version to make it
fit better with the call conventions of the old GDK_SCALE stuff)...

Things just work.

That is, my Emacs opens with the right size window, unmaximized, and
everything is hunky dory.  I think.

Let's see...

Here's "emacs -Q":


[-- Attachment #2: emacs-q.png --]
[-- Type: image/png, Size: 60972 bytes --]

[-- Attachment #3: Type: text/plain, Size: 243 bytes --]


That looks totally normal, doesn't it?  (I've forgotten how it's
supposed to look like after living with it opening in the wrong size for
some weeks.  :-))

It looks identical with "GDK_SCALE=1 emacs -Q".

What about "GDK_SCALE=2 emacs -Q"?


[-- Attachment #4: emacs-q-2.png --]
[-- Type: image/png, Size: 68710 bytes --]

[-- Attachment #5: Type: text/plain, Size: 388 bytes --]


Hm...  the only thing that happened was that the menu bar font is twice
as large?  Hm...  Is that's what's supposed to happen?

If I say set the scale to 4, then the frame is twice as wide, and the
font is even huger.

Hm...  I feel like this isn't making total sense...  Or is it?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

Anyway, if somebody else could test out the scratch/hidpi branch and see
whether it breaks something, that would be really nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Dmitry Gutov]

On 7/16/17 6:09 PM, Lars Ingebrigtsen wrote:
> Anyway, if somebody else could test out the scratch/hidpi branch and see
> whether it breaks something, that would be really nice.

Briefly tried it out, and it fixes the menu positioning on my machine as 
well. Thanks!

Not sure what else I could test, specifically.

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 7/16/17 6:09 PM, Lars Ingebrigtsen wrote:
>> Anyway, if somebody else could test out the scratch/hidpi branch and see
>> whether it breaks something, that would be really nice.
>
> Briefly tried it out, and it fixes the menu positioning on my machine
> as well. Thanks!
>
> Not sure what else I could test, specifically.

Just to hear that there are no obvious regressions is nice.  :-)

If nobody else sees any adverse effects of this tweak, I'll merge the
branch into master tomorrow...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Robert Pluim]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> On 7/16/17 6:09 PM, Lars Ingebrigtsen wrote:
>>> Anyway, if somebody else could test out the scratch/hidpi branch and see
>>> whether it breaks something, that would be really nice.
>>
>> Briefly tried it out, and it fixes the menu positioning on my machine
>> as well. Thanks!
>>
>> Not sure what else I could test, specifically.
>
> Just to hear that there are no obvious regressions is nice.  :-)
>
> If nobody else sees any adverse effects of this tweak, I'll merge the
> branch into master tomorrow...

I had a quick test of it under Gnome, where it works very
well. Merge away as far as I'm concerned.

Regards

Robert

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> I had a quick test of it under Gnome, where it works very
> well. Merge away as far as I'm concerned.

Merged and pushed.

Now to close all the bugs that this covers...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Merged and pushed.

Hm...  should I put something in NEWS?  I mean, it's a bug fix, but this
has been an issue for so long that there's Reddit pages about how to
work around it, so perhaps it's NEWS-worthy?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

Jan, I think you were the one that added the GDK_SCALE thing to Emacs?
I've been chasing down some HiDPI issues:

Lars Ingebrigtsen <larsi@gnus.org> writes:

> That might be a good idea, but I'm not sure where the previous people
> who were working on scaling were going with their work.
>
> Amusingly enough, the 
>
>       int scale = xg_get_gdk_scale ();
>
> stuff that's sprinkled around just seems to get in the way of fixing
> this stuff.  It explicitly looks at the GDK_SCALE environment variable,
> which is (by default) not set.  So while some bits of Emacs is using
> that variable to determine some things, querying GTK in the proper way
> (with gtk_widget_get_scale_factor) will get another answer.

Is there a drawback to looking at gtk_widget_get_scale_factor instead of
the GDK_SCALE variable?

Reworking this (on the scratch/hidpi branch) to not look at that
variable seems to fix all my HiDPI issues.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

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

What I said about the screenshots wasn't totally accurate.

Here's -Q:


[-- Attachment #2: emacs-q.png --]
[-- Type: image/png, Size: 60972 bytes --]

[-- Attachment #3: Type: text/plain, Size: 22 bytes --]


Here's GDK_SCALE=1:


[-- Attachment #4: emacs-q-1.png --]
[-- Type: image/png, Size: 49658 bytes --]

[-- Attachment #5: Type: text/plain, Size: 63 bytes --]


As you can see, the toolbar icons are smaller.

GDK_SCALE=2:


[-- Attachment #6: emacs-q-2.png --]
[-- Type: image/png, Size: 68710 bytes --]

[-- Attachment #7: Type: text/plain, Size: 388 bytes --]


It's identical to just "-Q", which is to be expected, since the default
scale is 2.  Except that the menu texts are twice as large, which is not
expected.

So the menu bar font thing is somehow relying on the environment
variable, even if there are no checks for it any more?  Urr.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[martin rudalics]

 > So the menu bar font thing is somehow relying on the environment
 > variable, even if there are no checks for it any more?  Urr.

Some parts are theme dependent.  I would also have a more intimate look
at the scroll bars.  In your non-GDK_SCALE=1 imaages the scroll bar
seems to shadow the right fringe.  OTOH in the GDK_SCALE=1 image there
appears a scroll bar in the echo area which is usually suppressed on GTK
builds.

martin

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 16 Jul 2017 15:59:36 +0200
> Cc: 27357@debbugs.gnu.org
> 
> Does Ryan have copyright papers on file?

No.

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[Lars Ingebrigtsen]

I also notice functions like

static int
xg_get_gdk_scale (void)
{
  const char *sscale = getenv ("GDK_SCALE");

  if (sscale)
    {
      long scale = atol (sscale);
      if (0 < scale)
	return min (scale, INT_MAX);
    }

  return 1;
}

that are used while figuring out font sizes, while probably
gtk_widget_get_scale_factor should be used instead?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[martin rudalics]

 > GDK_SCALE=1 ./emacs
 >
 > will make tooltips appear in the correct place in Emacs, and makes
 > "emacs -Q" window sizes correct!
 >
 > So that's the culprit.  But what's the fix?  Since Emacs isn't
 > scale-aware, should emacs just set that on startup?

It has been recommended to do that, yes.  But I have no idea which
issues it fixes and whether it does so in most or all environments.

Maybe all people who reported these bugs just live happily with this
workaround and never bothered to comment on how well it works.

martin

bug#27357: 26.0.50; Emacs starts fullscreen in Ubuntu 17.04

[martin rudalics]

 >> Can you change those settings on a per application basis?
 >
 > Not that I know.  In any case, this seems like it's an Emacs bug, and
 > shouldn't we fix that?

If it's an Emacs bug we should try to fix it.

 >> IIRC GTK Emacs supports scaling only partially.  Could you try with
 >> another toolkit?
 >
 > Well, this isn't about fixing my frames -- I can do that with a couple
 > of lines of Emacs Lisp.  But Emacs seems to be buggy here, and it would
 > be nice to fix that bug.

The question is whether GTK Emacs is buggy here.  If say, a Lucid build
behaves better, then we would have isolated a possible bug here.

 >> Also, ISTR that people complained about mispositioned
 >> scroll bars, menus and tooltips, sometimes alos about misplaced
 >> underlinings and the like.  Do you see any of those effects too?
 >
 > Nope.

Probably because you did not set GDK_SCALE.

martin