[Recommendation/Proposal] new API for gspell-4 (gspell for GTK4)

[otrocodigo]

Gspell (spelling correction library) is currently being migrated to GTK4

I am looking for suggestion to update the API. Currently there are the following classes:

• GspellChecker is a spell checker
• GspellCheckerDialog is a GtkDialog to spell check a document one word at a time. It uses a GspellNavigator
• GspellEntry extends the GtkEntry class with inline spell checking
• GspellEntryBuffer extends the GtkEntryBuffer class with spell checking support.
• GspellLanguage represents a language that can be used for the spell checking
• GspellLanguageChooserDialog is a GtkDialog for choosing a #GspellLanguage
• GspellNavigatorTextView is a GtkDialog for navigate through misspelled words, and correct the mistakes
• GspellTextBuffer spell checking support for GtkTextBuffer
• GspellTextView spell checking support for GtkTextView

Basically Gspell*Buffer takes care of highlighting wrong words with a red underline and Gspell*View takes care of adding an extra contextual menu to correct the words through suggestions.

currently to add the features to a GtkTextView (also works with a GtkSourceView) you have to use the following code:

gspell_view = gspell_text_view_get_from_gtk_text_view (gtk_text_view);
gspell_text_view_basic_setup (gspell_view);
/* gspell_text_view_get_checker (gspell_view) */

The above code doesn’t seem very intuitive to me. My proposal would be something like:

gspell_checker = gspell_checker_new (...);
gspell_text_view = gspell_text_view_new ();
gspell_text_view_set_checker (gspell_checker)
/* or gspell_text_view_new_from_checker (gspell_checker) */
gspell_text_view_attach_view (gtk_text_view)
/* and gspell_text_view_dettach_view (gtk_text_view) */

GspellEntry and GspellEntryBuffer they would be eliminated due to the difficulty in highlighting and and getting the position of the cursor on the widget. Besides, I don’t see much use for spell checking in this type of widget that is used for simple things.

Instead of a GtkEntry you could use a GtkText with a GtkTextBuffer for highlighting (you could pass a GspellTextBuffer as a buffer) but there would also be the problem of getting the cursor position on the widget.

Also don’t think it is necessary to include the GspellLanguageChooserDialog and GspellCheckerDialog widgets in the library and they would become examples to use the library.

---

I appreciate any new idea or correction to my proposal.
I also created a room in matrix.to in case they want to talk there: #gspell:matrix.org

[swilmet (Sébastien Wilmet)]

Thanks for sharing these ideas. (sorry for the long reply, planning a new major version can take some time )

In the gtk-doc for gspell-1 the classes are grouped in different categories. Starting with the Core Classes that depend only on GLib/GObject and Enchant.

When porting to GTK 4, I recommend porting class by class, starting with the basic ones (those that don’t depend on anything else), then “level by level”. In the build instructions, just compile the files that are already ported (plus the file being ported of course). I think / hope that gspell doesn’t have a spaghetti architecture

Then, it really depends if we want to keep the API as similar as possible to gspell-1 to ease porting apps. Or if we take the occasion to re-design some parts of the API. If we change everything, it adds more work for app developers, on top of the API breaks already present in GTK 3 → 4. So from my point of view, it’s better to at least have compatibility layers.

I wrote this document: gspell.next but some items in there would require too much work for “simply” porting to GTK 4.

But in gspell.next, there is an interesting thing to do that would be very useful: creating interfaces for the core classes. For example by having GspellChecker being an interface, and GspellCheckerSimple or GspellCheckerEnchant being the implementation.

So basically, let’s do things step by step.

Spell-checking for GtkEntry in GTK 3 is useful. Basically everywhere where you can type text, it’s useful to be able to check its spelling. A GtkEntry is for example used for a title: you don’t want to have a spelling mistaking in the title (my first example that comes to mind is writing a review in gnome-software).

Note that I don’t have much time during this week, unfortunately. So if me reviewing your work becomes a “bottleneck”, I know it’s frustrating. I don’t know what to recommend in that case. Look at the GitLab issues, what app developers have asked in the past for missing features, and what could be done better in gspell to address these issues (even if not implemented in gspell, allowing such an implementation in the app without rewriting basically the whole of gspell).

[otrocodigo]

Okay. It was my mistake. I understood that they wanted to change part of the public API.

And yes, Checker and Language became interfaces.