From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#28189: 26.0.50; Emacs uses deprecated function gtk_window_parse_geometry Date: Tue, 19 Sep 2017 15:35:10 +0000 Message-ID: References: <599D40CB.1090100@gmx.at> <599D80D1.6090508@gmx.at> <59A13F90.5080804@gmx.at> <59ABEC4A.3050209@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1140f7b06c250405598c9b9b" X-Trace: blaine.gmane.org 1505835383 18426 195.159.176.226 (19 Sep 2017 15:36:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 19 Sep 2017 15:36:23 +0000 (UTC) To: martin rudalics , 28189@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 19 17:36:16 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1duKZK-0004KJ-Hd for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 Sep 2017 17:36:14 +0200 Original-Received: from localhost ([::1]:43609 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1duKZR-00046U-Ff for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 Sep 2017 11:36:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45711) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1duKZC-00043V-QE for bug-gnu-emacs@gnu.org; Tue, 19 Sep 2017 11:36:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1duKZ8-0002dQ-AM for bug-gnu-emacs@gnu.org; Tue, 19 Sep 2017 11:36:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39750) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1duKZ8-0002dD-61 for bug-gnu-emacs@gnu.org; Tue, 19 Sep 2017 11:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1duKZ7-0005Kl-T6 for bug-gnu-emacs@gnu.org; Tue, 19 Sep 2017 11:36:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Sep 2017 15:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28189 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28189-submit@debbugs.gnu.org id=B28189.150583534520473 (code B ref 28189); Tue, 19 Sep 2017 15:36:01 +0000 Original-Received: (at 28189) by debbugs.gnu.org; 19 Sep 2017 15:35:45 +0000 Original-Received: from localhost ([127.0.0.1]:48431 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1duKYq-0005K6-Ub for submit@debbugs.gnu.org; Tue, 19 Sep 2017 11:35:45 -0400 Original-Received: from mail-io0-f169.google.com ([209.85.223.169]:43948) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1duKYo-0005Jo-3C for 28189@debbugs.gnu.org; Tue, 19 Sep 2017 11:35:43 -0400 Original-Received: by mail-io0-f169.google.com with SMTP id k101so230iod.0 for <28189@debbugs.gnu.org>; Tue, 19 Sep 2017 08:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=UfhAddAs8ONtVQaCX3Jr755xOL3yYFexlJRiY9gZYQ8=; b=N7BB0LtzWc8QuqzWmVrd6FBEfy4fAed0fnBHjJ//2ojeBhlZwjoy7vrjtBvgkATiq7 wfSkAnAhkUcrB5Y1Go+Ks2M1weKgW6Bc0yO2MDQ038Tvzj03OR/OSM39lx2BuSh6WEvA M/raGbZzJk0v82t3e45r4cJ+Bjed0An5FrpRdLQzjifsyDMD9G99t45a17eCOyilJjee Gc7eKIWTLP5/bG5Uzi8IeCvx2Zw8nlz1/TFALNz4oPjJOqxDDsSFL9g2chRaDYCeIJin 46EAkQptEt1oANH6XS4xXNPSlrMfllXnZj6WNIg8E+huRCW3iS3nbbZfLBcxrxET8IbY whjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=UfhAddAs8ONtVQaCX3Jr755xOL3yYFexlJRiY9gZYQ8=; b=Jx0y7d8lP3+IP3Clz1+IHoCBymY9xyOdcsMlcSs7saTsxrAJd0jELw6LfwUMKB7tPy rD6wah5bSmZa9N7AEvvbKQ0QPPSUlgGLzyLq0VM4zR3yf98Tm+thZ0+i132jnWJeMgSM o8ka34GM5WQvISnO5QiCU73DjayToaznx8HMGKL2zYqwVpw2bI+pOoUBZxM4DuvQCXtH vL3dmWiHG2Qdbyqn2i7jtvJQioJcuABESPaGaBlnrf8FC/FvftF+dag55XPu00hf64pd WfZaiidhLWsRW4Je2DHa2qTVQd3h629nz5LD66t1Vpwm4AYC6XolRUThGNHzCi+QaO3e wBpA== X-Gm-Message-State: AHPjjUhVjH1jeR3y/NS1rUYgg9OkuY8ScpD3KGyuQ0d7WxwrWQIO99EK 2hdRkOBgUrgVRYrL0CEkk08y6z1B/9tWi0WyhwI= X-Google-Smtp-Source: AOwi7QCFuMqCRuEeUPtVsUJZtAYEV6spvboZl6fF4YF43meaOfG+xxGqQrKpION/Ntd4mm95PmKFtjdN6uIRGe/J8Eg= X-Received: by 10.202.102.194 with SMTP id m63mr546768oik.296.1505835321401; Tue, 19 Sep 2017 08:35:21 -0700 (PDT) In-Reply-To: <59ABEC4A.3050209@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:137126 Archived-At: --001a1140f7b06c250405598c9b9b Content-Type: text/plain; charset="UTF-8" martin rudalics 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. --001a1140f7b06c250405598c9b9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


martin= rudalics <rudalics@gmx.at> sc= hrieb am So., 3. Sep. 2017 um 13:49=C2=A0Uhr:
=C2=A0> OK, I've pushed all the "simple" change= s for now.

Belated thanks.=C2=A0 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)?=C2=A0 T= his is
one of our few clients with GTK 3.22, sadly building from Emacs 25 only.

I haven't seen these warnings eith= er with or without the patch.
=C2=A0
=C2=A0>> This one
=C2=A0>>
=C2=A0>> +#if GTK_CHECK_VERSION (3, 16, 0)
=C2=A0>> +=C2=A0 =C2=A0 =C2=A0 emacs_abort ();
=C2=A0>> +#else
=C2=A0>>
=C2=A0>> looks a bit harsh and the corresponding logic appears quite = contrived.
=C2=A0>> Maybe the entire function should be rewritten.
=C2=A0>>
=C2=A0>
=C2=A0> The underlying issue here is that GTK no longer seems to have a = concept of
=C2=A0> a "background color", but Emacs still assumes that con= cept exists.

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

If you only talk about code restructur= ing, then sure. But if we want to emulate (instead of just disable) backgro= und colors, then some more work is needed.
=C2=A0

=C2=A0>> Removing the gtk_adjustment_changed calls should be tested A= SAP.
=C2=A0>
=C2=A0>
=C2=A0> 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 th= e delay.
=C2=A0

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

I have no ideas of the implications of such an approach and whether it'= s
feasible.=C2=A0 We would first have to find all instances where we use an X=
solution instead of a GTK one and fix them.=C2=A0 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.=C2=A0 Daniel Colascione has proposed to "go GTK-only" a cou= ple 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 (probabl= y in a background thread like w32term.c) and then go from there, without li= nking 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.=C2=A0
--001a1140f7b06c250405598c9b9b--