Done for bug 34882, GSOC 2017, and bug 111775, the Special Characters dialog and UI button support a maximum of 16 defined Favorite glyphs or 16 entered Recent glyphs.
While suitable for most Western script users, this is inadequate for needs of many CJK users and some set of CTL users.
Suggest two things: 1) that the counts of Favorites and Recents be expanded--at least 32, but probably 48; 2) that a mechanism of assigning the Favorites based on locale setting be implemented. Modify the locale DTD and incorporate the list of codepoints using XML for each locale--provided a default, but allow for l10n.
The split button UI should keep the 6 column format to keep width, but row count would grow for both.
(In reply to V Stuart Foote from comment #0)
> While suitable for most Western script users, this is inadequate for needs
> of many CJK users and some set of CTL users.
Please elaborate this. The favorites are not meant as a replacement to the full list of special characters but a shortcut to a few often used items.
> 1) that the counts of Favorites and Recents be
> expanded--at least 32, but probably 48;
Please not! It might help a few but hinders many using this widget. If really needed we could make this variable an option for the user.
> 2) that a mechanism of assigning the
> Favorites based on locale setting be implemented.
Don't get this. Fav's are assigned from what is picked above, why should there another algorithm?
Increase to 48 to meet the needs of heavy users.
(In reply to Heiko Tietze from comment #1)
This is an enhancement for localization support. The current stack limit of 16 is simply not sufficient for a large percentage of our users.
Rather than our usual UX-Advise participants, let's ask some of the other contributors from the CJK/CTL communities weigh in on the effectiveness of the current selection of western "Favorites" provided, and whether a stack of 16 glyphs offers any real usability to those locales.
There would not be an algorithm involved, rather would directly load a set of default Favorites from XML for the selected locale coupled with fonts by locale taken from VCL.xcu--effectively providing font and specific Unicode glyphs to load.
Only if absent an entry in the locale's XML would we load the current western defaults for favorites.
As to impacting the GUI--increasing the stack count from 16 would not present an issue for users assigned the current western default.
Expect the glyphs for the Split button would keep columns of 6, only the row count would increase from current three with different defaults--six for a stack of 32 or eight for 48. Impact on GUI is negligible.
And on the Special Character dialog, adding a second (for 32) or even third row (for 48) to the favorites and resents--while increasing screen height of the dialog would cause not great issue, and each row could be set to 24 glyphs to limit it to two each.
We talked about this request in the design meeting. While some users may need more items it would be bad usability for most other. The compromise is to make the number of rows for Recently Used and Favorite characters optional defaulting to 1 (as today) with a reasonable maximum (maybe 5).
We should also improve the usability of the special character dialog for CTL/CJK users by restoring the input buffer (bug 115477) and making the predefined list of favorites localizable (bug 120899). Furthermore we have to figure out the missing requirements and add some kind of views (aka tabs) to the special character dialog to support all users.
First draft of redesign for discussion at https://nextcloud.documentfoundation.org/s/asdc9Km2AamqDg6
*** Bug 139796 has been marked as a duplicate of this bug. ***
*** Bug 143024 has been marked as a duplicate of this bug. ***
*** Bug 150143 has been marked as a duplicate of this bug. ***
Modified title essentially to add prefix EDITING: to make it easier to find.
(Already 3 duplicates)
My use case is 24 special characters (4 modes of 6 vowels of pinyin).
Currently special characters is the only option with the keyboard configurations already available with my locale.
(An alternative is to define a custom keyboard configuration.)
I would like to thumbs up increasing the number of favorites. as for potential usability issues, i can se no obstacle to increasing the number of favorites as long as they can easily be deleted (as it is already the case). *maybe* increasing to a too large number (hard limit, yak! how much is "too large"?) the "recently used" might get *some* users (which users? what user profiles?), the favorites list is something that every user can chose and edit at any time.
Speaking of edit, imo the favorites list should have been designed with the possibility of moving the items around, maybe this feature can also be added?