Geany 4.0, the GTK4 edition (and more)

[elextr]

There are a number of probably big changes being examined or coming in the future.

The point of this discussion is to record and discuss them. Blue sky thinking is encouraged, but implementability is key.
The things I can think of ATM are:

1. GTK4, its gotta happen at some stage if Geany is to not stagnate. IIUC from people who know GTK more than I do that there are parts of GTK that are used in Geanys UI that are not available in GTK4, so it may be a UI revolution, not an evolution.
2. Plugin functionality revolution, move all language specifics into plugins, so more can be specialised per language with less maintenance to core.
3. Use above to move TM to plugins, perhaps with LSP like API, see here

The point of course is that these are all likely to be breaking (if not smashing) to the UI and the plugin API etc.

[kugel-]

Can we have threads here? I would like to separate GTK4 and LSP discussions.

[techee]

Regarding GTK4 I think the biggest problem is the non-GTK4 Scintilla:

https://sourceforge.net/p/scintilla/feature-requests/1433/

I'm not sure if there has been any progress in that respect.

[elextr]

So maybe it won't be Scintilla, that would shatter the API ;-P

[iahung3]

I suggested supporting GtkSourceView. But after I see your answer in #3695, I think you should maintain your own downstream fork of Scintilla and add GTK4 support yourself. Or, you could rewrite Geany in Qt and use QScintilla since you are so attached to Scintilla.

[iahung3]

BTW, I really don't see the need to switch to GTK4. So, you could reserve version 4.0 for GTK4 but please make a version 3.0 that is still using GTK3. I'm more interested in your point 2 and 3. Geany plugins should be more powerful and LSP support is a must.

[elextr]

At some point GTK3 support will go away and it will rust, indications are after release of GTK5. So GTK4 will be needed at some point. As @techee said we need someone to move Scintilla since Neil is not volunteering (why would he? IIUC the GTK4 drawing model is different and may require unknown changes to Scintilla, and supporting both during a transition may be a nightmare).

[techee]

I also think that lots of things here

https://docs.gtk.org/gtk4/migrating-3to4.html

are of the "proper porting to GTK3" nature and still GTK3-compatible and could be done regardless of whether/when we really switch to GTK4.

[kugel-]

Use above to move TM to plugins, perhaps with LSP like API, see #3571 (comment)

I think we always need something like TM to have an in-process cache for symbols/tags. We're still a lightweight IDE so a my requirement would be to not exchange megabytes of json text on every keystroke.

I call it TM2 because it doesn't necessarily need to be API-compatible to the current TM.

So I think my idea would be to keep TM2 in the core and call out to the ctags-server on some suitable opportunities, then cache the response and move forward.

Would have to make sure that TM2 is also compatible with other major language servers.

Question: How does a language server get access to the documents? Does it have to be saved on disk so that the server can open() it? If yes, how can LSP possible act on unsaved buffers? If no, do we have to constantly send the entire document via IPC or network?

[techee]

I think we always need something like TM to have an in-process cache for symbols/tags. We're still a lightweight IDE so a my requirement would be to not exchange megabytes of json text on every keystroke.

It's definitely not megabytes. If you are curious about how typical communication looks like, you can try the geany-lsp plugin and set rpc_log in configuration to some file - you will get the full JSON RPC communication.

Question: How does a language server get access to the documents? Does it have to be saved on disk so that the server can open() it?

Basically, one first sends

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#initialize

where one can specify either a single project directory or multiple workspace directories. And then there are the document synchronization notifications informing about what is happening:

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_synchronization

If no, do we have to constantly send the entire document via IPC or network?

Only deltas (if servers support it, but all those I tried do, otherwise one would indeed have to send the whole document), see

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_didChange

I was slightly worried if documents don't get de-synchronized but it was quite easy to implement using Scintilla SCN_MODIFIED notifications and seems to work well.

[eht16]

I hope GTK3 will be still supported for a long time.
GTK4 is more than a revolution IMO. It feels more like another toolkit which is using glib by accident as well.

From a user point of view, here is my personal shitlist for GTK4:

• no icons on menu items
• no classic file menu
• no window positioning
• only CSD
• popup menus require compositing (https://gitlab.gnome.org/GNOME/gtk/-/issues/4815)

Fancy, modern interface experts might like this on their tiny exotic devices.
I remember I had similar reservations from GTK2 to 3 but from 3 to 4 is even a way bigger step.

I think we will loose quite some features with GTK4 and need to think about the user interface aside from the technical aspects.

Disclaimer: the above is my personal opinion and does not claim to be correct or a good direction for the future.

[rdipardo]

I hope GTK3 will be still supported for a long time.

You're not alone, so keep hoping!

The GTK 3 ABI is finally a stable target, and it’s still pre-installed in most distributions because lots of built-in apps haven’t upgraded yet. If we can get a sufficient number of binary apps depending on it, distributions will be forced to maintain it and even pre-install it “forever”, the same way Microsoft maintains the Win32 API “forever”.

https://ludocode.com/blog/flatpak-is-not-the-future#the-gtk-problem

[elextr]

The problem with GTK3 is that on Wayland it depends on the compositor, Mutter, a Gnome component. At some point Mutter will break/remove something GTK3 needs, ok it could maybe be synthesised in GTK3, but nobody at Gnome is going to want to be bothered, they have GTK4/5/6 ...

[elextr]

Maybe we could wait for another complex UI application like Gimp to move to GTK4 and then copy all the widgets it re-implements, in fact they could be made into a toolkit library, the Gimp ToolKit maybe ... oh yeah right ok, GTK² 😄

PS

1. despite the joke it is a serious suggestion to see what some other UI intensive apps do.
2. apparently my GTK squared was too subtle, "square" as in "to be old-fashioned or boringly conventional"

[iahung3]

Let's rewrite Geany in Qt5 😄

[elextr]

@iahung3 conventionally suggestions to re-write Geany in various non-GTK toolkits are only made on April 1, patience, less than a month 😁

previous suggestions

• qeany - qt
• feany - fltk
• eeany - enlightenment or electron
• meany - minimal Geany (tty)
• teany - rewrite in typescript
• etc etc