GNOME Bugzilla – Bug 751685
gedit cannot build againist pure wayland-gtk, compiles gedit-app-x11.c
Last modified: 2020-11-24 09:56:45 UTC
gtk-3.16.4 is able to build as below almost without a patch. See bugID-751625 ./configure --prefix=/usr --build=x86_64-linux-gnu --host=x86_64-linux-gnu --sysconfdir=/etc --localstatedir=/var --disable-schemas-compile --disable-x11-backend --disable-broadway-backend --disable-xinerama --disable-xrandr --disable-xfixes --disable-xcomposite --disable-xdamage --disable-glibtest --disable-cups --disable-papi --disable-cloudprint --without-x --disable-largefile --enable-wayland-backend So i done it. Then try to rebuild gedit againist it.But gedit pull from x11 unconditionally. So i get: Ugh! i cannot paste it. Because i am writing epiphany on weston now and copy/paste dont work properly.However i paste it.
make[2]: Entering directory '/home/me/gtk3/gedit/src/gedit-3.16.2' CC gedit/gedit_libx11_la-gedit-app-x11.lo gedit/gedit-app-x11.c: In function 'gedit_app_add_platform_data': gedit/gedit-app-x11.c:69:7: error: implicit declaration of function 'GDK_IS_X11_DISPLAY' [-Werror=implicit-function-declaration] GDK_IS_X11_DISPLAY (gdk_display_get_default ())) ^ gedit/gedit-app-x11.c:69:7: warning: nested extern declaration of 'GDK_IS_X11_DISPLAY' [-Wnested-externs] cc1: some warnings being treated as errors Makefile:2985: recipe for target 'gedit/gedit_libx11_la-gedit-app-x11.lo' failed
gtk able to detect x11/wayland automatically which in use at runtime. So there is no need to pull from BOTH of them, is there? Just rely on gtk.So codebase needs modernization to reflect this.
Created attachment 306501 [details] [review] a massive modernization and clean-up i tested it both on pure-x11 and pure-wayland(drm-without xwayland). it works like a charm.imo it dont breaks anythings. i hope that its accepted by you as is(almost) and shipped for 3.18. i cannot sent a better format(git-bz).Sorry for inconvienence. Even i try to rebase it for 3.17.1 but then i figure out its a bit expensive to me.So i gave up. it is based on TAG-3.16.2
-if test "$os_osx" = "no" && - test "$os_win32" = "no"; then - PKG_CHECK_MODULES(X11, [ NO.i dont intent to remove first two line except 'then'.thats my fault.
-GNOME_COMPILE_WARNINGS([maximum]) +#GNOME_COMPILE_WARNINGS([maximum]) - if [ ! grep "^# INTLTOOL_MAKEFILE$" "$1/Makefile.in" > /dev/null ]; then - AC_MSG_ERROR([$1/Makefile.in.in was not created by intltoolize.]) - fi + #if [ ! grep "^# INTLTOOL_MAKEFILE$" "$1/Makefile.in" > /dev/null ]; then + # AC_MSG_ERROR([$1/Makefile.in.in was not created by intltoolize.]) + #fi These ones most probably only for me. Because i ran 'autoreconf -if' locally from tarball.
(In reply to nick from comment #3) > Created attachment 306501 [details] [review] [review] > a massive modernization and clean-up Thanks for the patch! There seem to be some unwanted changes, like commenting the line + #GNOME_COMPILE_WARNINGS([maximum]) and also some whitespace issues, like in + *y = 0; (note the whitespace at the end of that line). Also, some stuff was commented out like these three lines: + #if [ ! grep "^# INTLTOOL_MAKEFILE$" "$1/Makefile.in" > /dev/null ]; then + # AC_MSG_ERROR([$1/Makefile.in.in was not created by intltoolize.]) + #fi If there's a reason to leave this code in the file, you might want to add a comment explaining when a developer wants to uncomment those three lines.
(In reply to André Klapper from comment #6) > (In reply to nick from comment #3) > > Created attachment 306501 [details] [review] [review] [review] > > a massive modernization and clean-up > > Thanks for the patch! > There seem to be some unwanted changes, like commenting the line... i mention that 2 part #5 comment. feel free to ignore them. thanks.
> a massive modernization and clean-up... Not so good. > and also some whitespace issues, like in > + *y = 0; right.
(In reply to nick from comment #3) > i cannot sent a better format(git-bz).Sorry for inconvienence. > > Even i try to rebase it for 3.17.1 but then i figure out its a bit > > expensive to me.So i gave up. it is based on TAG-3.16.2 For a patch to be accepted, it needs to be created with the 'git format-patch' command, or 'git bz' (if you plan to write more than – say – 10 patches). You need to work on the git master branch, with a tool like Jhbuild. And each commit should do only one thing, but do it well™. For a bug like this one, it's better to decompose the work into several well-defined steps. For each commit the code must be valid, it should compile and run correctly (if possible).
Created attachment 307042 [details] [review] v2 of previous attempt this time properly i already send it to gedit ML with a description.
(In reply to nick from comment #10) > Created attachment 307042 [details] [review] [review] > v2 of previous attempt this time properly > > i already send it to gedit ML with a description. The patch that i sent to ML malformed by mailserver. Furthermore v2 has some flaws. So i will send v3 soon.
Created attachment 307190 [details] [review] v3 of patch From the beginning: i didn't add a line of code.i just renamed as: gedit-app-x11.c --> gedit-app-inherit.c gedit-app-x11.h --> gedit-app-inherit.h replaced 'x11' with 'inherit' into this two file plus gedit.c and tweak configure.ac & Makefile.am according to above. Changes from commit e5118d68a30e2779738034ee204907e72bbe3832
i tested it. With this patch gedit was compiled and ran successfully in both case which are gdk_backends="wayland" and gdk_backends="x11 wayland" This is a trivial patch. Please someone review it.Thanks
this is result of my patch in case of gdk_backends="wayland : http://postimg.org/image/ehpblrthz/
i am a bit sad because there is no one who is interested in my patch. Hey; are everyone so busy or is my patch so ugly? Come on guys please.
There probably is interest, just nobody has found time to review it yet. People have real life, people take holidays iun July, etc. Sorry if this is demotivating. Is there a reason for the indentation changes in configure.ac? > i just renamed: Did you use "git mv" for renaming those files? (Just wondering why git isn't more intelligent when formatting that patch, seeing "new file mode 100644" there)
(In reply to André Klapper from comment #16) > There probably is interest, just nobody has found time to ... Ohh! Good news here, it is nice to hear that. > Is there a reason for the indentation changes in configure.ac? There is no reason.it is unintentional.Corrupted by mailserver or editor. I will fix it. > Did you use "git mv" for renaming those files? ... No. I will use 'git mv' then resend it as v4. Are there any other suggestions from you guys for v4? Thanks.
Created attachment 308602 [details] [review] v4 of my patch accordings to suggestions git format-patch used.
(In reply to nick from comment #17) > There is no reason.it is unintentional.Corrupted by mailserver or editor. From 'git format-patch' man page: >OPTIONS >... > >--stdout > Print all commits to the standard output in mbox format, instead of >creating a file for each one. it seems "mbox" formats corrups patches eg truncate long lines etc. So i think i it better to do not use '--stdout' switch as i done it for v4.
Fine, waiting for assignment.
Mass-closing of all gedit bugzilla tickets. Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.