wow, very nice. Can you share a screenshot of vim --clean -g ?

I think the GTK4 port of GVim should focus more on Wayland instead of X11, which is already deprecated and will be removed in GTK5. I suppose there are issues with keyboard layout detection, but there a much more users that have it working fine. Having a 2800 line file called "gui_gtk4_x11.c" does not feel right...

@chrisbra

Default GDK backend is x11

$ GDK_BACKEND=wayland GSK_RENDERER=cairo ./vim -gf

Currently the only X11 dependency in the GTK4 backend is XParseGeometry from <X11/Xutil.h>. By implementing our own geometry parser, we can remove the X11 dependency entirely and switch the default GDK_BACKEND to Wayland.

This also means we could rename gui_gtk4_x11.c to gui_gtk4.c since it would no longer have any X11 dependency.

Since I'm developing this on WSL2, I haven't been able to test the Broadway backend yet. If you have a native Linux environment, you should be able to run gvim in a browser:

1. Start broadwayd :5
2. Run GDK_BACKEND=broadway BROADWAY_DISPLAY=:5 ./vim -gf
3. Open http://localhost:8085 in your browser

You should see gvim running inside the browser. I'd appreciate it if someone could give it a try!

Hello,

Thanks for the information about broadway, I will take a look when possible.

I still can't really test it properly, but following the recent GTK4 updates, the --nofork issue is now resolved and it's not needed anymore, starts well by default without problems.

Small things that I quickly detect when I used it:

1. Empty WM_CLASS (X11)

When running in an X11 environment, the WM_CLASS attribute is empty. This prevents window managers (I use dwm) from correctly identifying the application, applying window rules etc..

Command: xprop

(gtk4)
Output: WM_CLASS(STRING) = "", ""

(gtk2, gtk3) already has this by default.
Expected: WM_CLASS(STRING) = "gvim", "Gvim" 

2. Crash when setting guioptions=k

Setting the k flag (Keep window size) in guioptions causes an immediate crash.

Steps to reproduce:

    Start gvim: gvim --clean

    Run: :set guioptions=k

Result: Segmented fault / Crash.

3. Ligatures are not rendering (works with gtk2, gktk3)

Even with a supported font and the guiligatures option set, symbols are not displayed as expected.

Steps to reproduce:

    :set guiligatures==!><

    Input text: != <= >=

Result: Characters are rendered individually rather than as a single ligature glyph.

4. X11 Feature missing in :version (maybe it's correct)

The :version output shows -X11. While this is a GTK4 build, it is unclear if certain X11-specific integrations (like clipboard) are intentionally disabled or if this is an expecting setting in the build as you said before (no X11 deps).

Thank you, this looks promising!

Improved the toolbar appearance by using flat style buttons, which removes the raised/bordered look.

@gonzaru Thank you for the detailed report! The three issues you reported have been fixed:

1. WM_CLASS empty — Added g_set_prgname("gvim") so WM_CLASS is set correctly on X11.
2. Crash on set guioptions=k — Fixed infinite recursion in gui_mch_newfont().
3. Ligatures not rendering — Ported the ligature rendering logic from GTK3 to GTK4.

Regarding -X11 in :version: this is intentional. This GTK4 port removes direct X11 dependencies. gvim no longer depends on X11 directly. It still works on X11 servers, but only through GTK4's GDK backend abstraction, not via direct X11 API calls.

@gonzaru Thank you for the detailed report! The three issues you reported have been fixed:

1. **WM_CLASS empty** — Added `g_set_prgname("gvim")` so WM_CLASS is set correctly on X11.

2. **Crash on `set guioptions=k`** — Fixed infinite recursion in `gui_mch_newfont()`.

3. **Ligatures not rendering** — Ported the ligature rendering logic from GTK3 to GTK4.

Regarding -X11 in :version: this is intentional. This GTK4 port removes direct X11 dependencies. gvim no longer depends on X11 directly. It still works on X11 servers, but only through GTK4's GDK backend abstraction, not via direct X11 API calls.

I can confirm that 2. and 3 are resolved. The crash is fixed and the ligatures work!

About 1. the WM_CLASS now reports:

WM_CLASS(STRING) = "gvim", "gvim"

Needs to be:

WM_CLASS(STRING) = "gvim", "Gvim"

This is how gtk2 and gkt3 also report it, as the class name (the second field) the standard is to capitalize it.

The spec states that WM_CLASS must contain two consecutive null-terminated strings:

Instance Name (gvim): Identifies the specific instance (used for specific resource lookups).

Class Name (Gvim): Identifies the general class of the application (used for grouping and general rules).

(4.1.2.5. WM_CLASS Property)
https://tronche.com/gui/x/icccm/sec-4.html

I will try to check more things this weekend and report it if necessary.

Regards

@gonzaru Thanks for the clarification on WM_CLASS.

WM_CLASS is an X11-specific property that GTK4 no longer sets directly. The correct way to handle this in GTK4 is through the StartupWMClass field in the desktop entry file. Added StartupWMClass=Gvim to runtime/gvim.desktop.

@mattn Yes I understand to do not focus on x11 specific for now and those things can be talked latelly. As you said, the .desktop way can helps to this as it will add the correct class name on the fly for Gvim..

Just in case, another small bug:

(crash on console dialogs)

1. gvim --clean
2. :set guioptions+=c
3. :set confirm
4. write anything in the buffer
5. :q

It will show a console dialog, but the gvim freeze an does not respond anymore.

With the gui dialog: (with :set guioptions-=c)

1. gvim --clean
2. :set confirm
3. write anyting in the buffer
4. :q

Works, but the text of the dialog are not labeled correctly and can be confusing. (especially on vs no)

--

About ligatures support, there is already a present bug in gtk2/gtk3 (also gtk4) versions, so maybe now can also be fixed:

(normal mode)

(insert mode)

Ticket: #12901

@gonzaru Thank you for the detailed reports! The following two issues have been fixed and pushed:

1. Console dialog freeze (guioptions+=c + confirm + :q) — The GTK4-specific exiting check in gui_mch_wait_for_chars() caused it to bail out immediately without waiting for key input. Removed to match GTK3 behavior.

2. GUI dialog button labels corrupted ("on" / "no" instead of "Yes" / "No") — The button label strings were used after the backing buffer was freed (use-after-free). Fixed the lifetime management.

Regarding the ligature issue at cursor position (#12901): this is a pre-existing bug that affects GTK2/GTK3 as well, not specific to GTK4. The cursor is drawn with gui_screenchar() which renders only a single character, breaking the ligature context that Pango needs. This will be addressed separately.

@mattn Confirmed both (gui and non-gui dialogs) fixed. Thanks!
I agree to focus more in gtk4 now in this PR than fix old gtk2/gtk3 know bugs.

Here a few more small ones that I've just found:

(1) Font completion (:set guifont=<TAB>)

1. gvim --clean
2. :set guifont=<TAB> (does nothing)

In other gtks it shows a popup to select the gui font.

--

This can be considered more cosmetic than a real bug.

(2) Menu greying (disabled items)

The gtk4 version treats all menu items as active, so even if there is no copy/cut/paste etc, it does not show the menu as "empty/grey" like in gtk3.

(gtk3)

(gtk4)

--

(3) (:winpos always returns 0)

:winpos

The winpos command can be useful for sessions with :set sessionoptions+=winpos etc and in the previous gtk's it returns the correct window position.

@gonzaru The remaining three items from your latest report have been fixed and pushed:

1. Font completion — :set guifont=\<TAB> now lists monospace font families from Pango, matching GTK3 behavior.

2. Menu greying — Disabled menu items (Copy/Paste etc.) are now greyed out using g_simple_action_set_enabled(). Also fixed the popover menu not closing after selecting an item.

3. :winpos — Unfortunately, GTK4 does not provide a window position API (removed by design for Wayland compatibility). gui_mch_get_winpos() now returns FAIL instead of reporting a misleading 0,0.

I added a native print dialog for :hardcopy on GTK4 GUI, similar to how Windows GUI shows a print dialog. When the GUI is not running, the existing PostScript path is used as before. If this is not desired, I can drop the implementation — for now it can be disabled via #ifdef FEAT_GUI_GTK_PRINT.