Sorry, I forgot mention the platform which is SuSE 12. Thanks!

In general it looks like dependency installation problem, since meld initial checks for Gtk and GtkSource are extremely similar. So the really strange thing is that Gtk's check succeeds but GtkSource's fails.


Was the all libraries built with /app/vbuild/SLED12-x86_64/ prefix or it was specified only during installation?


Also to investigate this I suggest running strace & grep tools:

> ~$ strace /path/to/python3 -c 'import gi; gi.require_version("Gtk", "3.0")' 2>&1 | grep Gtk

in my debian32 it outputs
> open("/usr/lib/i386-linux-gnu/girepository-1.0/Gtk-3.0.typelib", O_RDONLY|O_LARGEFILE) = 4

and the similar for
> ~$ strace /path/to/python3 -c 'import gi; gi.require_version("GtkSource", "3.0")' 2>&1 | grep Gtk
> open("/usr/lib/i386-linux-gnu/girepository-1.0/GtkSource-3.0.typelib", O_RDONLY|O_LARGEFILE) = 4

What is the output in your case?

The most interesting thing - which folder is used for loading Gtk-3.0.typelib

The other idea - check all directories possibly searched for GtkSource (the list would contain other dirs used by python, but not extremely long):

>~$ strace python3 -c 'import gi; gi.require_version("GtkSource", "3.0")' 2>&1 | grep O_DIRECTORY
>open("/usr/lib/python3.5/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>open("/usr/lib/python3.5/encodings", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>open("/usr/lib/python3.5", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>open("/usr/lib/python3.5/plat-i386-linux-gnu", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>open("/usr/local/lib/python3.5/dist-packages", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>open("/usr/lib/python3/dist-packages", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>open("/usr/lib/python3.5/lib-dynload", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>open("/usr/local/lib/python3.5/dist-packages", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>open("/usr/lib/python3/dist-packages", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>open("/home/user", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>open("/usr/lib/python3.5/collections", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>open("/usr/lib/python3.5/importlib", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>open("/usr/lib/python3/dist-packages/gi", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>open("/usr/lib/i386-linux-gnu/girepository-1.0", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
>open("/usr/lib/girepository-1.0", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3

Hi, 
I fixed the sourceview problem by reinstall gtk 3.20.0 with gobject-introspection 1.42.0 , but meld can't start yet due to X error.
Here is the error message.
esekilxv7345 [7:10] [/home/exindia] -> meld

(meld:20873): Gdk-ERROR **: The program 'meld' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 909 error_code 1 request_code 131 (XInputExtension) minor_code 45)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Trace/BPT trap

Could you help? Thank you!

According to the error it looks that X server doesn't support XInput 2 extension
R045 XInputExtension:GetClientPointer or some gtk/gdk issue in the initialization of extensions.

Is there some another gtk app (not using python) that works with libs built in in this prefix?


This extension was added to Xorg near 2007, so it present in all typical setups.

What type of X server is pointed by your DISPLAY environment variable? Local Xorg, Xwayland or something else?
Is X server redirection or some other remote access used?

I compiled gtk 3.20.0 in the different prefix .
Sorry, for your question about X server, I can't understand. I just start meld on the host which access from the other one using " ssh -X ... " . but I could start some other X windows applications.
Thank you!

I reinstalled meld 3.18.0 with gtk 3.20.0 installed in the same prefix, but it doesn't help .
Thank you!

I hope that I figured out what happening!

X11 ssh fowrarding can run on Trusted and non-Trusted modes.
The "-X" enables non-trusted forwarding that limits some functionality, like XInput extension. The "-Y" enables more functionality. When I start meld over non-trusted forwarding I get the 
> Xlib: extension "XInputExtension" missing on display "localhost:10.0".

(to complicate things more some distros makes -X alias to -Y). If your gtk build doesn't check for extension presence and tries to use it - it would issue an error like above.

So, try using "ssh -Y" instead of "ssh -X".

I tried "ssh -Y", but the error was the same.
Thank you!

What X server and OS is running on the machine where you are running ssh client?

(also, maybe before starting ssh -Y all other existing ssh connections to same machine should be closed).

The OS is SLED 11 platform . Sorry , I don't know how to check the X server ?
Thanks!

I looked that SLED 11 was released with XOrg 7.4 that is quite dated, so it really may lack an XInputExtension:GetClientPointer.

Maybe gtk3 assumes that this call present if xinput extension does present at all.

This leads to idea of a workaround: make gtk think that xinput extension is not available at all.

On modern ssh client this can be achieved by
ssh -o ForwardX11Trusted=no -X
or via uncommenting and setting 
ForwardX11Trusted no
in /etc/ssh/ssh_config 

I think that SLED 11 ssh client can support some of those methods too.

With this option gtk3 applications including meld log message about "Xlib:  extension "XInputExtension" missing on display ..." but continue working.

Unfortunately this also disables some other extensions and rendering becomes slow. It isn't completely unusable, but uncomfortable even with localhost connection.

I checked my SLED 11 host , there is Xorg 7.6 installed. I tried the command you told me but encountered the error below, and I can't changed the file ssh_config as I don't have root permission.  Thank you!

esekilxv7345 [5:42] [/home/exindia] -> meld
X Error of failed request:  BadAtom (invalid Atom parameter)
  Major opcode of failed request:  20 (X_GetProperty)
  Atom id in failed request:  0x17
  Serial number of failed request:  4
  Current serial number in output stream:  4

It looks that disabling all extensions doesn't work for your gtk build.

To be honest, I do not have enough knowledge in this area. So, generally it looks like gtk3+xserver combination problem, and probably  experts in those areas can have some ideas.

To check that the problem is not meld-specific - could you run any written-in-C gtk3 application via this ssh connection? gtk-demo and gedit are good candidates.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/meld/issues/145.