On Thursday, September 22, 2022 1:09:04 AM MST Rene Engelhard wrote: > >This being the case, I think it would be better to use a file location more > >like /usr/share/chromium-dict, and, if packaged separately, a package name > >like chromium-dict-en-us. > > And what about other qtwebengine using stuff? I just did some testing, and manually adding a .bdic into the ~/.config/ chromium/Dictionaries directory does not make it automatically appear in the list of available languages in Chromium’s settings. Meaning that Chromium doesn’t scan the directory to see what is available, but that there is some config file somewhere that must be populated with the dictionaries that Chromium expects to use. I noticed that Chromium already has a directory at /usr/share/chromium. If we follow the same structure as the user directories, probably the best place to put the dictionaries would be /usr/share/chromium/Dictionaries. Assuming we can find a way to update whatever config file is used to inform Chromium about the installed dictionaries, it should be possible to use that location as a system-wide setting. Regarding Qt WebEngine, instead of patching it to look in a new location (which possibly might involve maintenance effort if the internal structure changes in the future) what if we instead create symlinks from /usr/share/qt*/ qtwebengine_dictionaries to /usr/share/chromium/Dictionaries? For example, libqt5webenginecore5 and libqt6webenginecore6 might be good packages to handle these symlinks. I just did some testing and, if the symlink points to a non-existent directory, programs built on QtWebEngine that are looking for a dictionary file don’t mind. They just go about their business without spellchecking enabled. Meaning that, if no Hunspell dictionary package is installed and the directory doesn’t exist, creating the symlink won’t cause any problems. -- Soren Stoutner soren@stoutner.com
Attachment:
signature.asc
Description: This is a digitally signed message part.