GNOME Bugzilla – Bug 765616
Allow viewing and removing words from the user's personal dictionary
Last modified: 2021-05-17 16:14:10 UTC
It's currently possibly to add words to the dictionary. It follows that users should be able to view the words that have been added, and potentially remove them. This is important if a word is mistakenly added, or if the user changes their mind about which words they have in the dictionary. A simple mockup for how this could look: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/spell-checking/spell-checking.png
Thank you for the mockup, it would indeed be useful.
Created attachment 342360 [details] [review] add remove and add to personnal methods and signals This is a first step to manage personal dictionaries. For now, i'm doing the widget in GNOME-builder because of specific needs, we'll see if you want to port it later to gsv.
Review of attachment 342360 [details] [review]: Looks good after a quick glance. But I wonder how you retrieve the list of words that are part of the personal dictionary. Enchant doesn't seem to provide such feature. Maybe hunspell or aspell have an API for that? The personal dictionary is anyway common for all applications, as long as the same dictionary engine is used (hunspell, aspell, …). If hunspell provides an API to get the list of words that are part of the personal dictionary, an idea is to use hunspell directly instead of using Enchant. See: https://wiki.gnome.org/Initiatives/SpellChecking This would also prevent some bugs from happening (differences between dictionary engines), see e.g. bug #772406.
i have write some methods to read the corresponding file
(In reply to sébastien lafargue from comment #2) > For now, i'm doing the widget in GNOME-builder because of specific needs, > we'll see if you want to port it later to gsv. BTW I don't like this mentality. If you look at the mockup, it's just a dialog window, it's really easy to make it reusable from day 1 and write it in gspell directly (provided that the backend provides the required functions). > if *you* want to port it later to gsv (emphasis is mine) (s/gsv/gspell/)
The thing is that i don't want a dialog at all but a custom widget integrated in the Builder UI style.
I already added the rewrite of the GspellCheckerDialog part as a specific widget for Builder and the Gspellnavigator/GspellNavigatorTextView part to add occurence's count for the current word and drawn selection bubble (things that can be ported of course if needed). I understand that you more want to provide a use-as-is API library but what i need is a toolkit. i hope we can find some convergence point to fit us all, avoiding me to rewrite a complete spellchecker API.
(In reply to sébastien lafargue from comment #4) > i have write some methods to read the corresponding file Which file? Does it support all Enchant backends? How do you know which backend is used by a certain GspellChecker, or for a certain GspellLanguage? Is the file location(s) part of the backend API?
~/.config/enchant/{lang_code}.dic but i haven't look yet in details if it's enough or not, the purpose is to have a first working implementation.
(In reply to sébastien lafargue from comment #7) > I already added the rewrite of the GspellCheckerDialog part as a specific > widget for Builder and the Gspellnavigator/GspellNavigatorTextView part to > add occurence's count for the current word and drawn selection bubble > (things that can be ported of course if needed). And another application that wants the same will re-invent the wheel? See bug #761923, having something better than GspellCheckerDialog makes perfect sense in gspell itself. > I understand that you more want to provide a use-as-is API library but what > i need is a toolkit. i hope we can find some convergence point to fit us > all, avoiding me to rewrite a complete spellchecker API. gspell tries to provide a convenient and high-level API, but the lower-level functions are available as well. If gspell fails to provide convenient high-level classes for a certain application, it should be fixed, if the code makes sense for several applications. What I want to avoid is each GTK+ application re-inventing the wheel.
(In reply to sébastien lafargue from comment #9) > ~/.config/enchant/{lang_code}.dic > > but i haven't look yet in details if it's enough or not, the purpose is to > have a first working implementation. OK. Assuming that those files are part of the Enchant API, what if the word "Abc" is added to the personal dictionary from Firefox or LibreOffice, which use hunspell directly (AFAIK), not from Enchant. If a GspellChecker uses Enchant -> hunspell, "Abc" will be marked as correctly spelled, even though it is not visible in the Enchant personal dictionary.
I have tried with LibreOffice, the user dictionaries are not stored by Hunspell but by LibreOffice itself, so unless you add applications support, you can't have a centralized user dictionary anyway. In a perfect world, the backend should store the user dictionaries and Enchant centralize all of them in a single file we can inspect.
Can hunspell store a personal dictionary? Is it part of its API? Maybe LibreOffice is an exception and doesn't use that hunspell feature. I haven't looked yet at the hunspell API, maybe it's only implemented by Enchant. (But is it implemented by aspell, etc? we come back to the problem of multiple backends working differently). gspell hides the fact that it uses Enchant, it is an implementation detail. So if you use gspell and look at the Enchant personal dictionary, your code can break in future gspell versions. That's why it's better to implement something complete and coherent in gspell instead of adding the minimal missing API. I would prefer that gspell provides a function to get the list of words present in the personal or session dictionary, if there is a correct implementation: (1) not relying on implementation details of an underlying library and (2) returning the correct list of words, the full personal dictionary: all the words marked as correctly spelled iff those words are marked as misspelled after a factory reset of the machine (if the dictionary for the language is still installed).
We agree about the fact of hiding that Gspell uses Enchant. My provided patch is here to evolve the current Gspell user dict support by adding the remove word feature in addition to the already existing add word (gspell_checker_add_word_to_session and gspell_checker_add_word_to_personal) About my get_words_list code in Builder, it have no vocation to stay here but to end-up in Gspell, it's just easier and faster to start this in Builder then port it later (i want to finish the spellchecker support in Builder and as many of us, i have limited free time for this) After a quick examination, i have collected the following informations: firefox: ~/.mozilla/firefox/{profile}/persdict.dat (end-line separated words list) LibreOffice Writer: ~/.config/libreoffice/4/user/wordbook/standard.dic (end-line separated words list with a header at top) So, Hunspell have a support for user dictionaries but no centralization, every application provide it a path for a dict to use.
so, what about my patch, accepted or rejected ?
It is not sufficient. If the word-removed signals are added to GspellChecker, other classes in gspell should listen to them (the classes that are already listening to the word-added signals). But even after that, gspell itself would not call the remove_word functions, so gspell would not really be "complete". I would prefer that gspell itself uses all of its backend features, to make sure that the backend features have a good API and can be used in a meaningful way, without relying on implementation details. It's fine for gspell itself to rely on its own implementation details, of course, but if gspell provides an incomplete API that can be used (externally) in a meaningful way only by relying on implementation details of gspell (for example the fact that Enchant is used), there is a problem. So I would prefer that everything is developed in gspell, to have a complete solution. AFAIK, it's the first time that a GNOME application tries to implement this feature, so it pushes the boundary a little forward, which is a good thing but it doesn't mean that it's simple ;) And I don't want to repeat history: gedit, like gnome-builder now, has implemented almost all its features by thinking that there is only gedit as the true and only GTK+ text editor. The gspell code comes from the gedit spell plugin, I needed to make its code re-usable first. By developing a library, it forces the developer to make the code re-usable, which leads to a better design IMHO, the code is better documented (it has an API), several apps can benefit from it so potentially more developers will care about fixing bugs and maintaining it. If a library is well written, it has a longer longevity than an application (look for example at Anjuta, a lot of features has been developed, but it is no longer actively maintained, so all that work will basically be lost, probably). Of course designing an API is more complicated, but I think it is worth it. And the API here should not be too complicated I think. Worst case the API needs to be redone for GTK+ 4.
I understand that and sort of agree with you but i'm not interested at all doing more patches for Gspell, what i need is just a quick and easy way to handle personal dictionary in Builder, even using an external private API and porting to a Public API later. I also think you have seen that the UI choices in Builder are somewhat different than what is proposed in the GNOME UIG and that we need more control of the spellchecker objects, doing the UI part in Builder itself (we don't use dialogs but panels, highlight in the view is different, etc...) I have no choice than skipping the Gspell API for now and using Enchant directly for now. thanks.
Instead of a GtkDialog, gspell can have a subclass of GtkGrid.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gspell/-/issues/23.