GNU bug report logs - #28189
26.0.50; Emacs uses deprecated function gtk_window_parse_geometry

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28189 in the body.
You can then email your comments to 28189 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philipp <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.50; Emacs uses deprecated function gtk_window_parse_geometry
Date: Tue, 22 Aug 2017 22:22:14 +0200

Code in src/gtkutil.c calls gtk_window_parse_geometry, which is
deprecated
(https://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-parse-geometry)
and has been removed in unstable
(https://git.gnome.org/browse/gtk+/diff/gtk/gtkwindow.h?id=c2125e80a345af13d5d886d4ae56fba2926dc267).
Emacs needs to stop using this function.


In GNU Emacs 26.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.10.8)
 of 2017-08-22 built on unknown
Repository revision: 4309d1574ae86244751600171b605b2b2eca4697
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description:	Ubuntu 14.04.5 LTS

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
scroll-up-command: End of buffer

Configured using:
 'configure --with-modules --without-pop --with-mailutils
 --enable-checking --enable-check-lisp-object-type --enable-gcc-warnings
 'CFLAGS=-ggdb3 -O0''

Configured features:
XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 94687 11372)
 (symbols 48 20136 1)
 (miscs 40 43 144)
 (strings 32 28611 1366)
 (string-bytes 1 762371)
 (vectors 16 13988)
 (vector-slots 8 488130 14278)
 (floats 8 48 68)
 (intervals 56 207 0)
 (buffers 992 11)
 (heap 1024 18489 1000))

Message #10 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Philipp <p.stephani2 <at> gmail.com>, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Wed, 23 Aug 2017 10:46:03 +0200

> Code in src/gtkutil.c calls gtk_window_parse_geometry, which is
> deprecated
> (https://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-parse-geometry)
> and has been removed in unstable
> (https://git.gnome.org/browse/gtk+/diff/gtk/gtkwindow.h?id=c2125e80a345af13d5d886d4ae56fba2926dc267).
> Emacs needs to stop using this function.

By default we don't call gtk_window_parse_geometry any more so this
should not be grave.  The more annoying aspect is that they apparently
removed gtk_window_set_geometry_hints as well and we now have to either
use gdk_window_set_geometry_hints (which has a different signature) or
copy the old definition of gtk_window_set_geometry_hints to our sources.

Can you build with unstable?

martin

Message #13 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Wed, 23 Aug 2017 10:38:22 +0000

[Message part 1 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> schrieb am Mi., 23. Aug. 2017 um
10:46 Uhr:

>  > Code in src/gtkutil.c calls gtk_window_parse_geometry, which is
>  > deprecated
>  > (
> https://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-parse-geometry
> )
>  > and has been removed in unstable
>  > (
> https://git.gnome.org/browse/gtk+/diff/gtk/gtkwindow.h?id=c2125e80a345af13d5d886d4ae56fba2926dc267
> ).
>  > Emacs needs to stop using this function.
>
> By default we don't call gtk_window_parse_geometry any more so this
> should not be grave.


But doesn't removing the declaration break the build even if the function
isn't called?


> Can you build with unstable?
>

Haven't tried that (GTK appears to use a quite idiosyncratic build system),
but the Emacs build already breaks on Debian testing when configuring with
'--enable-gcc-warnings --enable-gtk-deprecation-warnings' (there are a few
more deprecated functions that Emacs uses).

[Message part 2 (text/html, inline)]

Message #16 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Philipp Stephani <p.stephani2 <at> gmail.com>, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Wed, 23 Aug 2017 15:19:13 +0200

> But doesn't removing the declaration break the build even if the function
> isn't called?

Sure.  We can either remove x_gtk_use_window_move and call
gtk_window_move unconditionally or leave x_gtk_use_window_move alone and
call gtk_window_parse_geometry only if GTK_CHECK_VERSION permits it.

>> Can you build with unstable?
>>
>
> Haven't tried that (GTK appears to use a quite idiosyncratic build system),
> but the Emacs build already breaks on Debian testing when configuring with
> '--enable-gcc-warnings --enable-gtk-deprecation-warnings' (there are a few
> more deprecated functions that Emacs uses).

Have these already been deprecated with GTK 3.10.8?  I'm using 3.4.2
here.  In any case please post a list of these functions here (unless
you intend to take care of them by yourself).

Thanks, martin

Message #19 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Wed, 23 Aug 2017 23:26:41 +0000

[Message part 1 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> schrieb am Mi., 23. Aug. 2017 um
15:19 Uhr:

>  > But doesn't removing the declaration break the build even if the
> function
>  > isn't called?
>
> Sure.  We can either remove x_gtk_use_window_move and call
> gtk_window_move unconditionally
>

Would there be any downsides of that?


>
>  >> Can you build with unstable?
>  >>
>  >
>  > Haven't tried that (GTK appears to use a quite idiosyncratic build
> system),
>  > but the Emacs build already breaks on Debian testing when configuring
> with
>  > '--enable-gcc-warnings --enable-gtk-deprecation-warnings' (there are a
> few
>  > more deprecated functions that Emacs uses).
>
> Have these already been deprecated with GTK 3.10.8?  I'm using 3.4.2
> here.  In any case please post a list of these functions here (unless
> you intend to take care of them by yourself).
>
>
I've attached the compilation log including all GTK-related error messages.

[Message part 2 (text/html, inline)]

[gtk-compile.txt (text/plain, attachment)]

Message #22 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Philipp Stephani <p.stephani2 <at> gmail.com>, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Thu, 24 Aug 2017 11:37:44 +0200

>> Sure.  We can either remove x_gtk_use_window_move and call
>> gtk_window_move unconditionally
>>
>
> Would there be any downsides of that?

Currently, x_gtk_use_window_move is a backdoor to get the earlier
behavior that was based on calling gtk_window_parse_geometry.  I'never
been able to understand why Jan did the latter.  I suppose it's because
he wanted to position a window at an offset from the bottom right corner
of the screen.  However, for showing a window for the first time, this
never could have worked because gtk was not able to determine the size
of a yet unfinished window.  But maybe I'm all wrong.

In either case, Emacs doesn't use gtk_window_parse_geometry by default
for a couple of months already and I did not receive any complaints so
far.  Hence there should not be any downsides calling gtk_window_move
unconditionally.

> I've attached the compilation log including all GTK-related error messages.

Thanks.  I'm still puzzled by the fact that they apparently never
deprecated gtk_window_set_geometry_hints and yet removed it in 3.91.2.
Also, gdk_window_set_override_redirect seems to have been removed
without former deprecation.  That's annoying, at least.  And I have no
idea yet whether gdk_window_process_all_updates is essential and, if so,
how to replace it.

martin

Message #25 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Fri, 25 Aug 2017 09:28:35 +0000

[Message part 1 (text/plain, inline)]

Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Do., 24. Aug. 2017 um
01:26 Uhr:

>
> I've attached the compilation log including all GTK-related error messages.
>

I've attached a patch that fixes all deprecation warnings. It's not
intended to be installed as-is, more as a baseline for discussion. Some of
the functions have straightforward replacements, others are harder to
replace, yet others have vanished altogether.

[Message part 2 (text/html, inline)]

[0001-Fix-all-GDK-GTK-warnings.txt (text/plain, attachment)]

Message #28 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Philipp Stephani <p.stephani2 <at> gmail.com>, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Sat, 26 Aug 2017 11:29:52 +0200

> I've attached a patch that fixes all deprecation warnings. It's not
> intended to be installed as-is, more as a baseline for discussion. Some of
> the functions have straightforward replacements, others are harder to
> replace, yet others have vanished altogether.

I think you should install most of it right now so we have enough time
to test it before a release.  There are people who build with GTK 3.22
and could tell us whether it breaks anything (substantially, at least).
The sooner we know the better.

This one

+#if GTK_CHECK_VERSION (3, 16, 0)
+      emacs_abort ();
+#else

looks a bit harsh and the corresponding logic appears quite contrived.
Maybe the entire function should be rewritten.

Removing the gtk_adjustment_changed calls should be tested ASAP.  The
changes where an alternative is provided like this one

+#if GTK_CHECK_VERSION (3, 20, 0)
+      GdkDevice *gdev
+        = gdk_seat_get_pointer (gdk_display_get_default_seat (gdpy));
+#else
       GdkDevice *gdev = gdk_device_manager_get_client_pointer
         (gdk_display_get_device_manager (gdpy));
+#endif

should be installed in any case and this one

+#if GTK_CHECK_VERSION (3, 20, 0)
+  gtk_widget_set_focus_on_click (wb, FALSE);
+#else
   gtk_button_set_focus_on_click (GTK_BUTTON (wb), FALSE);
+#endif

obviously too.  This one

+#if GTK_CHECK_VERSION (3, 16, 0)
+  g_object_set (settings,
+                "gtk-menu-bar-accel", EMACS_CLASS,
+                "gtk-key-theme-name", "Emacs",
+                NULL);
+#else
   /* Remove F10 as a menu accelerator, it does not mix well with Emacs key
      bindings.  It doesn't seem to be any way to remove properties,
      so we set it to "" which in means "no key".  */
@@ -5243,6 +5283,7 @@ xg_initialize (void)
                                     "gtk-key-theme-name",
                                     "Emacs",
                                     EMACS_CLASS);
+#endif

looks good too.  All monitor/screen related changes seem harmless to me
and should be provided as well.  I'm not sure what you mean here

+  /* FIXME: This function assumes that GdkMonitor objects are never
+   * destroyed, even if the monitor is unplugged.  That’s probably the
+   * case, but should be verified.  */

If this is a problem it is a problem already now.  Or am I missing
something?

Maybe the menu related changes (although self-contained) should be done
in a separate fix.  In particular this

-      /* Adjust coordinates to be root-window-relative.  */
+      /* Adjust coordinates to be root-window-relative, but not for
+       * GTK+ 3.22, where the menu position is frame-relative.  */

and the subsequent

+#if GTK_CHECK_VERSION (3, 22, 0)
+  /* FIXME: We should pass the GDK event to this function instead of
+   * synthesizing it.  */

(I think you might want to get this from event_handler_gdk) look more
complicated and at least warrant larger comments.

I have no idea about the cairo related change.  But the XSync change
looks definitely good too.

Thanks, martin

Message #31 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Sun, 27 Aug 2017 13:34:14 +0000

[Message part 1 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> schrieb am Sa., 26. Aug. 2017 um
11:29 Uhr:

>  > I've attached a patch that fixes all deprecation warnings. It's not
>  > intended to be installed as-is, more as a baseline for discussion. Some
> of
>  > the functions have straightforward replacements, others are harder to
>  > replace, yet others have vanished altogether.
>
> I think you should install most of it right now so we have enough time
> to test it before a release.  There are people who build with GTK 3.22
> and could tell us whether it breaks anything (substantially, at least).
> The sooner we know the better.
>

OK, I've pushed all the "simple" changes for now.


>
> This one
>
> +#if GTK_CHECK_VERSION (3, 16, 0)
> +      emacs_abort ();
> +#else
>
> looks a bit harsh and the corresponding logic appears quite contrived.
> Maybe the entire function should be rewritten.
>

The underlying issue here is that GTK no longer seems to have a concept of
a "background color", but Emacs still assumes that concept exists.


>
> Removing the gtk_adjustment_changed calls should be tested ASAP.


How could that be tested?



> +  /* FIXME: This function assumes that GdkMonitor objects are never
> +   * destroyed, even if the monitor is unplugged.  That’s probably the
> +   * case, but should be verified.  */
>
> If this is a problem it is a problem already now.  Or am I missing
> something?
>

I think you're right, I've removed the comment. I was concerned about the
lifetime of the monitor objects, but I can't imagine this being an issue.


>
> +#if GTK_CHECK_VERSION (3, 22, 0)
> +  /* FIXME: We should pass the GDK event to this function instead of
> +   * synthesizing it.  */
>
> (I think you might want to get this from event_handler_gdk)
>

I don't think that's possible, because the filter is run before the GTK
event is even created, so it has no access to it. In fact, Emacs appears to
swallow most X events before they are translated to GTK events.
This should be fixed "for real" by creating a gtk3term, which doesn't use
any X functions. It appears to me that the current "X with a bit of GTK
sprinkled on top" can't work any more.


>
> I have no idea about the cairo related change.


That's only used for the visible bell, which still works after the change.

[Message part 2 (text/html, inline)]

Message #34 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Philipp Stephani <p.stephani2 <at> gmail.com>, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Sun, 03 Sep 2017 13:49:30 +0200

> OK, I've pushed all the "simple" changes for now.

Belated thanks.  Do you think the warnings cited in

bug#26855: 25.2; Menus off screen, gtk errors

are handled by your changes (I've been too lazy to check that)?  This is
one of our few clients with GTK 3.22, sadly building from Emacs 25 only.

>> This one
>>
>> +#if GTK_CHECK_VERSION (3, 16, 0)
>> +      emacs_abort ();
>> +#else
>>
>> looks a bit harsh and the corresponding logic appears quite contrived.
>> Maybe the entire function should be rewritten.
>>
>
> The underlying issue here is that GTK no longer seems to have a concept of
> a "background color", but Emacs still assumes that concept exists.

I understand.  But can't we catch that in a less intimidating way?

>> Removing the gtk_adjustment_changed calls should be tested ASAP.
>
>
> How could that be tested?

By removing these calls as you proposed and waiting till someone with
GTK 3.22 hollers.

>> +#if GTK_CHECK_VERSION (3, 22, 0)
>> +  /* FIXME: We should pass the GDK event to this function instead of
>> +   * synthesizing it.  */
>>
>> (I think you might want to get this from event_handler_gdk)
>>
>
> I don't think that's possible, because the filter is run before the GTK
> event is even created, so it has no access to it. In fact, Emacs appears to
> swallow most X events before they are translated to GTK events.
> This should be fixed "for real" by creating a gtk3term, which doesn't use
> any X functions. It appears to me that the current "X with a bit of GTK
> sprinkled on top" can't work any more.

I have no ideas of the implications of such an approach and whether it's
feasible.  We would first have to find all instances where we use an X
solution instead of a GTK one and fix them.  After that we would have to
decide whether the cases where no adequate GTK solution was found can be
simply removed or ignored for GTK built Emacsen.

Unless you are prepared to do that, I see no-one here to tackle such a
task.  Daniel Colascione has proposed to "go GTK-only" a couple of
months ago but seems to keep a low profile since then (like all others
involved in that thread).

Thanks again for all the work, martin

Message #37 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Tue, 19 Sep 2017 15:35:10 +0000

[Message part 1 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> schrieb am So., 3. Sep. 2017 um 13:49 Uhr:

>  > OK, I've pushed all the "simple" changes for now.
>
> Belated thanks.  Do you think the warnings cited in
>
> bug#26855: 25.2; Menus off screen, gtk errors
>
> are handled by your changes (I've been too lazy to check that)?  This is
> one of our few clients with GTK 3.22, sadly building from Emacs 25 only.
>
>
I haven't seen these warnings either with or without the patch.


>  >> This one
>  >>
>  >> +#if GTK_CHECK_VERSION (3, 16, 0)
>  >> +      emacs_abort ();
>  >> +#else
>  >>
>  >> looks a bit harsh and the corresponding logic appears quite contrived.
>  >> Maybe the entire function should be rewritten.
>  >>
>  >
>  > The underlying issue here is that GTK no longer seems to have a concept
> of
>  > a "background color", but Emacs still assumes that concept exists.
>
> I understand.  But can't we catch that in a less intimidating way?
>

If you only talk about code restructuring, then sure. But if we want to
emulate (instead of just disable) background colors, then some more work is
needed.


>
>  >> Removing the gtk_adjustment_changed calls should be tested ASAP.
>  >
>  >
>  > How could that be tested?
>
> By removing these calls as you proposed and waiting till someone with
> GTK 3.22 hollers.
>

Will do, sorry for the delay.


>
>  >> +#if GTK_CHECK_VERSION (3, 22, 0)
>  >> +  /* FIXME: We should pass the GDK event to this function instead of
>  >> +   * synthesizing it.  */
>  >>
>  >> (I think you might want to get this from event_handler_gdk)
>  >>
>  >
>  > I don't think that's possible, because the filter is run before the GTK
>  > event is even created, so it has no access to it. In fact, Emacs
> appears to
>  > swallow most X events before they are translated to GTK events.
>  > This should be fixed "for real" by creating a gtk3term, which doesn't
> use
>  > any X functions. It appears to me that the current "X with a bit of GTK
>  > sprinkled on top" can't work any more.
>
> I have no ideas of the implications of such an approach and whether it's
> feasible.  We would first have to find all instances where we use an X
> solution instead of a GTK one and fix them.  After that we would have to
> decide whether the cases where no adequate GTK solution was found can be
> simply removed or ignored for GTK built Emacsen.
>
> Unless you are prepared to do that, I see no-one here to tackle such a
> task.  Daniel Colascione has proposed to "go GTK-only" a couple of
> months ago but seems to keep a low profile since then (like all others
> involved in that thread).
>
>
This is indeed a huge amount of work. If at all, I'd start from zero by
building up a GTK event loop (probably in a background thread like
w32term.c) and then go from there, without linking against any X libraries,
and see what breaks. It's unlikely that I find the time for this in the
near future, but at some point it needs to happen.

[Message part 2 (text/html, inline)]

Message #40 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Tue, 19 Sep 2017 16:38:47 +0000

[Message part 1 (text/plain, inline)]

Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Di., 19. Sep. 2017 um
17:35 Uhr:

> martin rudalics <rudalics <at> gmx.at> schrieb am So., 3. Sep. 2017 um
> 13:49 Uhr:
>
>>
>>  > The underlying issue here is that GTK no longer seems to have a
>> concept of
>>  > a "background color", but Emacs still assumes that concept exists.
>>
>> I understand.  But can't we catch that in a less intimidating way?
>>
>
> If you only talk about code restructuring, then sure. But if we want to
> emulate (instead of just disable) background colors, then some more work is
> needed.
>
>

At least setting the background color should be doable in a non-deprecated
way using a custom CSS provider, see attached patch.

[Message part 2 (text/html, inline)]

[0001-GTK-Use-a-style-provider-instead-of-deprecated-functio.txt (text/plain, attachment)]

Message #43 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Sat, 23 Sep 2017 11:22:42 +0000

[Message part 1 (text/plain, inline)]

Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am So., 27. Aug. 2017 um
15:34 Uhr:

> martin rudalics <rudalics <at> gmx.at> schrieb am Sa., 26. Aug. 2017 um
> 11:29 Uhr:
>
>>  > I've attached a patch that fixes all deprecation warnings. It's not
>>  > intended to be installed as-is, more as a baseline for discussion.
>> Some of
>>  > the functions have straightforward replacements, others are harder to
>>  > replace, yet others have vanished altogether.
>>
>> I think you should install most of it right now so we have enough time
>> to test it before a release.  There are people who build with GTK 3.22
>> and could tell us whether it breaks anything (substantially, at least).
>> The sooner we know the better.
>>
>
> OK, I've pushed all the "simple" changes for now.
>
>

I've now pushed the remaining changes as well, except for the popup menu
change. With that change, the menus seem to get positioned incorrectly
along the vertical axis, but I can't figure out how to fix it. I could push
the changes nevertheless and hope that somebody else might find a fix. WDYT?

[Message part 2 (text/html, inline)]

Message #46 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Philipp Stephani <p.stephani2 <at> gmail.com>, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Sat, 23 Sep 2017 15:21:53 +0200

> I've now pushed the remaining changes as well,

Thanks.  At least for the background color fix your decision to push to
master was probably right.  But we really should consider backporting
your changes to the release branch if after a few weeks no problems
arise.  From recent bug reports it's quite evident that most people
remained on master and the release branch is hardly tested at all.  So
I'm quite confident that your changes are already getting tested.

> except for the popup menu
> change. With that change, the menus seem to get positioned incorrectly
> along the vertical axis, but I can't figure out how to fix it. I could push
> the changes nevertheless and hope that somebody else might find a fix. WDYT?

Please post this patch separately and explicitly ask people to try it.
The GTK menu bug reports (25064, 26130, 26855, 27131, 27667, 28511) -
though most of them by the same author but yet all with GTK 3.22 -
abandon and really should get treatment before the release.  Virtually
any patch might give us some insight here.  So please send the patch to
the thread with most of the reports (25064, 26130, 26855, 27131) merged
in and let's see whether it at least eliminates some warnings.  Maybe
we're lucky.

And again many thanks for your efforts, martin

Message #49 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: p.stephani2 <at> gmail.com, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Sat, 23 Sep 2017 16:28:52 +0300

> Date: Sat, 23 Sep 2017 15:21:53 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > I've now pushed the remaining changes as well,
> 
> Thanks.  At least for the background color fix your decision to push to
> master was probably right.  But we really should consider backporting
> your changes to the release branch if after a few weeks no problems
> arise.

Actually, the fix should have been pushed to the release branch to
begin with, since this bug is on the list of Emacs 26.1 release
blockers.

Thanks.

Message #52 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, martin rudalics <rudalics <at> gmx.at>
Cc: 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Sat, 23 Sep 2017 16:32:54 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am Sa., 23. Sep. 2017 um 15:29 Uhr:

> > Date: Sat, 23 Sep 2017 15:21:53 +0200
> > From: martin rudalics <rudalics <at> gmx.at>
> >
> >  > I've now pushed the remaining changes as well,
> >
> > Thanks.  At least for the background color fix your decision to push to
> > master was probably right.  But we really should consider backporting
> > your changes to the release branch if after a few weeks no problems
> > arise.
>
> Actually, the fix should have been pushed to the release branch to
> begin with, since this bug is on the list of Emacs 26.1 release
> blockers.
>
>
I'm not sure to what extent these patches should be called "fixes": Sure,
they get rid of warnings, but generally only by no longer calling the
"offending" functions, without much testing whether anything might be
broken.

[Message part 2 (text/html, inline)]

Message #55 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Sat, 23 Sep 2017 16:36:42 +0000

[Message part 1 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> schrieb am Sa., 23. Sep. 2017 um
15:21 Uhr:

>
>  > except for the popup menu
>  > change. With that change, the menus seem to get positioned incorrectly
>  > along the vertical axis, but I can't figure out how to fix it. I could
> push
>  > the changes nevertheless and hope that somebody else might find a fix.
> WDYT?
>
> Please post this patch separately and explicitly ask people to try it.
> The GTK menu bug reports (25064, 26130, 26855, 27131, 27667, 28511) -
> though most of them by the same author but yet all with GTK 3.22 -
> abandon and really should get treatment before the release.  Virtually
> any patch might give us some insight here.  So please send the patch to
> the thread with most of the reports (25064, 26130, 26855, 27131) merged
> in and let's see whether it at least eliminates some warnings.  Maybe
> we're lucky.
>
>
What thread exactly are you referring to? Most of these bug reports haven't
seen any discussion so far, but maybe I missed a thread.
Also aren't these bugs about the menu par? My patch is for popup menus, it
doesn't touch the menu bar code at all.

[Message part 2 (text/html, inline)]

Message #58 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: rudalics <at> gmx.at, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Sat, 23 Sep 2017 19:48:30 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Sat, 23 Sep 2017 16:32:54 +0000
> Cc: 28189 <at> debbugs.gnu.org
> 
>  Actually, the fix should have been pushed to the release branch to
>  begin with, since this bug is on the list of Emacs 26.1 release
>  blockers.
> 
> I'm not sure to what extent these patches should be called "fixes": Sure, they get rid of warnings, but generally
> only by no longer calling the "offending" functions, without much testing whether anything might be broken. 

Emacs 26.1 didn't even see its first pretest.  There's ample time to
test these changes until the release.

I'm also okay with removing the bug from the list of blockers, if
that's what you recommend.

Message #61 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: p.stephani2 <at> gmail.com, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Sat, 23 Sep 2017 20:28:03 +0200

> Actually, the fix should have been pushed to the release branch to
> begin with, since this bug is on the list of Emacs 26.1 release
> blockers.

Which bug is this?

martin

Message #64 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Philipp Stephani <p.stephani2 <at> gmail.com>, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Sat, 23 Sep 2017 20:29:01 +0200

> What thread exactly are you referring to? Most of these bug reports haven't
> seen any discussion so far, but maybe I missed a thread.
> Also aren't these bugs about the menu par? My patch is for popup menus, it
> doesn't touch the menu bar code at all.

AFAICT it's about menus popped up either from the menu bar or via mouse
clicks.  The thread starts with

bug#25064: 25.1; Menus are off-screen

where the poster doesn't tell much about the kind of menus.  For
bug#26139 which was merged with the former the poster says

  The problem is that all menus and pop ups are never visible. Pop ups
  show a narrow line at the top left of the screen, so I'm assuming that
  all of them may be off screen.

For bug#26855, merged as well, the poster says

  Menus (e.g. from the menubar) are appearing off screen.

And for bug#27131 (also merged) the poster says:

  Could be gtk problem. When running emacs on Fedora 25 with either
  cygwin X or vcxsrv as the x-server running on Windows 10 or Windows 7,
  menus appear off screen.

I have no idea whether this is a scaling issue or some principal
Emacs/GTK 3.22 incompatibility.  And I had no idea what to tell the
posters so there was no discussion.  Bug#27667 which looks similar seems
to be related to scaling.  That one mentions a tiny rectangle which also
made it into bug#28375.  Both built with GTK 3.22 as well.

martin

Message #67 received at 28189 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: p.stephani2 <at> gmail.com, 28189 <at> debbugs.gnu.org
Subject: Re: bug#28189: 26.0.50;
 Emacs uses deprecated function gtk_window_parse_geometry
Date: Sat, 23 Sep 2017 21:31:26 +0300

> Date: Sat, 23 Sep 2017 20:28:03 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: p.stephani2 <at> gmail.com, 28189 <at> debbugs.gnu.org
> 
> > Actually, the fix should have been pushed to the release branch to
> > begin with, since this bug is on the list of Emacs 26.1 release
> > blockers.
> 
> Which bug is this?

The one we are discussing here, 28189.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.