KateStatusBar: Add dictionary button
Needs ReviewPublic

Authored by loh.tar on Wed, Jan 9, 3:24 PM.

Details

Reviewers
None
Group Reviewers
KTextEditor
Summary

...to indicate the current dictionary and for the handy access to the
spell check menu, which is enhanced to offer the user preferred
dictionaries

Test Plan

From shot to shot is only the cursor moved. The dictionaries was set previously.

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped
loh.tar created this revision.Wed, Jan 9, 3:24 PM
Restricted Application added projects: Kate, Frameworks. · View Herald TranscriptWed, Jan 9, 3:24 PM
Restricted Application added subscribers: kde-frameworks-devel, kwrite-devel. · View Herald Transcript
loh.tar requested review of this revision.Wed, Jan 9, 3:24 PM

The shown dictionary is sometimes "wrong"

  • Mark a word by double-click and choose a dictionary different from the default for that word
  • Click/move into the word -> The shown dictionary fit
  • Double-Click that word again -> The shown dictionary is the default one

Due to the way how the dictionary is reported is it correct. It's always right from the cursor position and when the word will selected is the cursor at the end of the word. (To talk about it, helps! Add a check for selection and ask right from cursor in cursorPositionChanged() may fix that)

The language/dictionary code is sometimes a little long, e.g. "en_US-wo_accents".

  • How about to cut all and only keep "en_US"? But I have no idea how such codes may look. Always like "xx_YY" or may that differ?
  • How about to show a flag/ensign instead of the code? Is there some stuff in KDE which may helpful?
  • Sure, then we have a less precise info there, but will someone use different variants of the same language at a time?

Currently is a "special" dictionary not added to the menu. Mainly because it fit not into the "Preferred" section (and secondarily the needed member variable does right now not exist). To have more than one group need some effort to handle. To rename the group may a way, but how?

Isn't en_US too cryptic? I suggest to use the just added KLanguageName (see D10446). With this, you can get a nice name like "English (USA)". Alternatively, you may use QLocale("en_US").nativeLanguageName(), but I did not test this, so it may be incorrect code.

Besides that, some other questions:

  • What if you have multiple views of the same document, does it still show the correct language, even if the language is changed in one view?
  • What if you have multiple mainwindows (View > New Window), since then you have multiple StatusBars. Will that still all correctly work?

Isn't en_US too cryptic?

Well, yes.

I suggest to use the just added KLanguageName (see D10446). With this, you can get a nice name like "English (USA)". Alternatively, you may use QLocale("en_US").nativeLanguageName(), but I did not test this, so it may be incorrect code.

I have not chose that name to keep it short as possible. I think your suggest is used by Sonnet and you see it in the menu.
For me is that sufficient. All you need in the bar is a hint that the dict is somehow set/changed, or not. For details, click the button.
How about to cut it even more, just "en" or "US"? Ideas to the flag suggestion?

  • What if you have multiple views of the same document, does it still show the correct language, even if the language is changed in one view?
  • What if you have multiple mainwindows (View > New Window), since then you have multiple StatusBars. Will that still all correctly work?

Quick tested, behave a little strange.
Shows sometimes a dummy text, e.g. after a fresh "New Window", or when you have two views and you change in one view the document the first time to the new created test file.

Als long as only one dict is in use is no update done. Move you to some text with a different dict the button is updated. Changing the dict (on the first Window) updates the button too.

Ideas? Which signals are to catch?

loh.tar updated this revision to Diff 49099.Wed, Jan 9, 7:45 PM
  • Add missing signals to watch dict changes
  • Ensure button is set on first show

Looks fixed, give it a try.

If we stay with en_US, I'd like to see a label so people know what it is. Otherwise, we should use the long name, because then it becomes obvious. So here are the two options I would approve of:

  • Dictionary: en_US v
  • American English v

I'm very much against such a label, and against the full name.
"UTF-8" has also no label and that's good. The only stuff where a description label is needed are these line/column/word hints. Without a label are you almost lost to know which is what.

However, in some later change is planed to add a couple of options to customize the bar. So if someone insists on this label it will be then one option more. If
Dominik's suggest is realized that the bar will become "smart to hide obsolete stuff when the space is scarce", I guess such a label will go as one of the first.

As said, I like to shorten it even more and cut at least these "extra stuff".
I have only a few dict installed, so any help is appreciated if there are other county codes possible than "xx_YY-zzzz". I like to modify it to prefer "YY" and fall back to "xx"

  • "en_GB-ize-w_accents" -> GB
  • "en-variant_0" -> en
  • "en" -> en
qDebug() << Sonnet::Speller().availableLanguages();

"de_AT", "de_BE", "de_CH", "de_DE", "de_LI", "de_LU", "en", "en-variant_0", 
"en-variant_1", "en-variant_2", "en-w_accents", "en-wo_accents", "en_AU", 
"en_AU-variant_0", "en_AU-variant_1", "en_AU-w_accents", "en_AU-wo_accents", 
"en_CA", "en_CA-variant_0", "en_CA-variant_1", "en_CA-w_accents", 
"en_CA-wo_accents", "en_GB", "en_GB-ise", "en_GB-ise-w_accents", 
"en_GB-ise-wo_accents", "en_GB-ize", "en_GB-ize-w_accents", 
"en_GB-ize-wo_accents", "en_GB-variant_0", "en_GB-variant_1", "en_GB-w_accents", 
"en_GB-wo_accents", "en_PH", "en_US", "en_US-large", "en_US-variant_0", 
"en_US-variant_1", "en_US-w_accents", "en_US-wo_accents", "he"

@cullmann @dhaumann A short not how to progress would be nice.

  • Keep codes as they are
  • Shorten codes as suggested
  • Replace codes by flags/ensign (no idea how)
  • Add (unneeded) label
  • Show (unneeded long) full name

The latter two consume to much space for my taste and give only the very new user a benefit, once seen/clicked it's clear.

Here a shot from an attempt to address some issues:

  • No "Preferred Dictionaries" header at the separator to not confuse when user has a non preferred dict in use (add dict to menu is todo)
  • Change order of entries with the intend to make more often used stuff accessible more easy (still experimental)
  • Removed "Spellcheck Selection...". I would like remove that from the main menu too and modify the normal "Spelling..." action to behave "smart" as many other actions