bug#28189: 26.0.50; Emacs uses deprecated function gtk_window_parse_geometry

[Philipp Stephani <p.stephani2@gmail.com>]

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

martin rudalics <rudalics@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.

[-- Attachment #2: Type: text/html, Size: 4106 bytes --]