GTK 4 support

[cheywood]

Hey Maximilian,

I've gotten around to massaging my GTK 4 changes in with some GTK 3 support for this first draft changeset.

As planned this drops Python 2 and GTK 2 support.

Mixed notes:

• GTK 4 menu changes necessitate building menus from the model as done in the PR
• I believe removed signals in GTK 4 result in the GestureClick usage to repopulate suggestions in the menu (and update the current word mark)
• I looked into using a menu model to populate the menu for GTK 3 but this didn't appear to be possible
• Initially I had a few separate methods for GTK 3 and 4 but have combined those to be more like what you had before for separating functionality for GTK 2/3 and Python 2/3. I'm not sure if it's more readable, but it's a starting point.
• In my initial quick changes branch I had some other changes that I've removed here: I'd changed menu item Ignore All to Ignore and Add <word> to Dictionary to Add to Dictionary. I still like this simpler wording (which follows the interaction set in one of the first GTK4 apps to have spell checking - Text Editor), but presumed you'd rather not change it.
• On that theme there are a couple of changes in place for GTK 4 though, up for discussion: the separator between the suggestions and following items isn't there, and the "(no suggestions)" menu item isn't added. The later is at least in part due to the fact that it's not possible to do italic formatting on in the menu with GTK 4, and again, copies what was in gnome-text-editor. All up for discussion.
• I looked at not inheriting from GObject but I believe that's necessary for the PropertyAction, which provides the language selection menu its state behaviour
• It should be possible to detect whether the GestureClick is occurring on a popup-generating button using gdk_event_triggers_context_menu but haven't yet been able to get a hold on the sequence or yet determine the root cause of why I can't (sorry, time lack). At the moment it's matching to button 3, which might be fine for now, but there's at least a TODO to remove. Perhaps you have some better GTK input handling debugging skills and might be able to solve this :slightly_smiling_face:
• Removed Gtk module renaming as no longer needed
• _replace_word has been changed to build the old word from the mark instead of passing it in (which works better with the GTK 4 action-based interaction). Do you see any issue with this?
• I haven't looked at whether the property changes (or inheritance?) will impact Python 3 w/ GTK 3 API compatibility

Hopefully a reasonable starting point 😀

[koehlma]

Hey Chris,

Thank you very much for this PR. Your changes look already very good and nicely polished.

• I cannot say that I fully understand the intricacies of the new way to build menus with GTK 4 but your changes make sense to me. So let's just roll with them. They also do not impact the public API, which means that we can still change things later if it turns out that there is a better way of building the menu.
• Indeed, I prefer “Ignore All” over “Ignore” because it does not ignore a single occurrence but all occurrences.
• Regarding the separator and “(no suggestions)”. I prefer if the UI is a bit more explicit, but ultimately this is a matter of taste and I also see the advantages of reduced clutter. :) So, this is totally fine. I guess it's also okay to change the appearance slightly when switching to GTK 4 as the overall look and feel of GTK applications also changes with the evolution of the toolkit and what is considered modern design.
• Regarding the popup menu: As I see it, the old version also used to match for button 3. ;) We can still change this later, so for now this seems totally sufficient, although using gdk_event_triggers_context_menu would be nice. Presumably, my GTK debugging skills are much worse than yours because I haven't used it for anything productive for a while.
• _replace_word Looks good!
• The changes in inheritance and properties may technically be breaking changes but I doubt that they will have any breaking effects in practice and we will likely increase to major version anyway – so this is fine.

It would be great if you could address/respond to my comments. Afterwards, we should be good to go!

[cheywood]

Thanks Maximilian, that all sounds good. I think I've made all the changes you raised. All your reasoning in the comment below makes sense to me too :+1: I think that's sensible for the major version bump with the considerable changes to supported Python and GTK versions, plus it will help with the minor API differences.

Perhaps there are remaining documentation changes to make? It would be good to note that importing the GTK version you want to use before importing the module will result in the GTK version selection. Perhaps you already have that noted somewhere for the old detection? I haven't checked.

Once we get this in I can work on the other two smaller PRs.

[koehlma]

Perfect! 👍

Yes, indeed some minor changes to the documentation (doc/source/index.rst) are necessary. However, this is also something I can do after merging this PR. If you want, you can also do the changes yourself. Just let me know, otherwise, I am ready to merge this PR.

[cheywood]

I'm happy to leave that in your capable hands if you have the time :slightly_smiling_face:

I'll squash the commits pre-merge?

[koehlma]

I think I am able to somehow squeeze this into my schedule.

You do not need to squash the commits—GitHub will take care of that when merging.

Thanks again for making this happen. 🙏

[cheywood]

My pleasure!

[cheywood]

You do not need to squash the commits—GitHub will take care of that when merging.

That it does. I hadn't used the GitHub mechanism for it before. FWIW there's a tiny downside in that the author name also gets squashed (to GitHub username).

[koehlma]

Oh, sorry, I did not know that this would happen. I hope this is not too much of an issue.

I wonder whether this would also happen if you had your name associated with your GitHub account?

Anyway, we can use another procedure next time. :)

[cheywood]

Oh, sorry, I did not know that this would happen. I hope this is not too much of an issue.

No, not a big issue

I wonder whether this would also happen if you had your name associated with your GitHub account?

Oh huh, good point, I didn't know this wasn't set. You're probably onto something there :slightly_smiling_face: