Bug 56301 - Allow user to edit document with Special Characters dialog open (convert to non-modal)
Summary: Allow user to edit document with Special Characters dialog open (convert to n...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 139796 159300 (view as bug list)
Depends on:
Blocks: Special-Character
  Show dependency treegraph
 
Reported: 2012-10-22 22:34 UTC by Linus Drumbler
Modified: 2024-01-20 19:40 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Linus Drumbler 2012-10-22 22:34:04 UTC
I'm a recent convert from Word, and I love most of the features of LO. However, I would like to request some changes to the "Insert Special Character" dialog.

In Word a character isn't entered until the user double-clicks (which I like for the sake of confirmation), and furthermore the user can click off the window, continue editing the document, and insert a special character in a completely different location. I don't like having to open the dialog every time I need a new character, which can happen a lot in my case. At least, could the user be given the power to edit the characters they are inserting freely, rather than just deleting them all at once?
Comment 1 Linus Drumbler 2013-03-03 20:37:46 UTC
A more organized request:
- Allow user to edit the document with the dialog open.
- Allow user to change only some of the characters they want to insert, instead of deleting them all.

Can I have someone else's thoughts on this?
Comment 2 Heiko Tietze 2015-04-12 20:15:49 UTC
Dialogs are deliberately modal in Libreoffice, but we have the sidebar. Actually your feature request is to get better access to special characters, and not a particular solution. Does our idea for an improved dialog along with quick access meets your requirements? 

#34882 with the referenced blog post
Comment 3 Volga 2015-11-16 15:15:33 UTC
I think keep Special Character dialog in the front is a good solution.
Comment 4 V Stuart Foote 2016-06-30 17:35:39 UTC
@Samuel, Tomaž

So, this seems like a really straight forward proposal. Can the Special Character dialog be adjusted to remain open but not linked to the edit cursor on the document canvas? Then reread edit cursor location when activated with a character pick?
Comment 5 Heiko Tietze 2016-06-30 17:59:04 UTC
The special character was discussed together with a toolbar feature here http://user-prompt.com/de/libreoffice-design-session-special-character/

Making the dialog amodal is not a good solution. Feature-wise it might work but not when consistency and familiarity is relevant.
Comment 6 Volga 2017-08-27 10:28:29 UTC
(In reply to Heiko Tietze from comment #5)
> The special character was discussed together with a toolbar feature here
> http://user-prompt.com/de/libreoffice-design-session-special-character/
> 
> Making the dialog amodal is not a good solution. Feature-wise it might work
> but not when consistency and familiarity is relevant.

So we have to use BabelMap or similar app instead in this case, isn’t it?
Comment 7 Heiko Tietze 2017-08-27 17:03:33 UTC
(In reply to Volga from comment #6)
> So we have to use BabelMap or similar app instead in this case, isn’t it?

There is no "you have to". Depending on operating system and use case, Babelmap could be a versatile tool for you.
Comment 8 Xisco Faulí 2019-11-29 13:28:18 UTC
Changing priority back to 'medium' since the number of duplicates is lower than 5
Comment 9 Xisco Faulí 2020-03-09 13:27:47 UTC
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
Comment 10 romain2boss 2022-02-16 22:51:37 UTC
Hi, I second this need for a better way to add special characters at different places without having to open/close a dialog. Could be by moving the dialog to a sidebar if needed. As a short term solution it can also be to turn the window as 'non modal' and 'always on top'. But I would definitely love to have a smoother way to add special characters.

My workaround is to add the characters I need in the document next to each others and then to move/dupplicate them but it's not very efficient.

By the way the user-prompt link is not working anymore.
Comment 11 Heiko Tietze 2022-02-17 09:32:49 UTC
(In reply to romain2boss from comment #10)
> Could be by moving the dialog to a sidebar

I'd support the list of recently used characters in the sidebar but not the full widget.

> By the way the user-prompt link is not working anymore.

Resurrected at https://design.blog.documentfoundation.org/2015/03/26/libreoffice-design-session-special-character/
Comment 12 Mike Kaganski 2022-08-08 11:04:27 UTC
(In reply to Heiko Tietze from comment #5)
> Making the dialog amodal is not a good solution. Feature-wise it might work
> but not when consistency and familiarity is relevant.

Absolutely puzzling statement.

Consistency: we have several non-modal dialogs, without anything problematic for users. One is Find & Replace; another is Insert Field.

Familiarity: unless you refer to "existing users are accustomed to modal Special Characters dialog, and their workflow will be badly damaged by changing it to non-modal" (which would need some proof): the most used office application (MS Office) has its Character dialog non-modal in Word.

I would say: by all means, do implement this proposal. It will improve UX, make it more familiar, will match expectations better, and will not have a single downside.
Comment 13 Mike Kaganski 2022-08-08 11:16:17 UTC
*** Bug 139796 has been marked as a duplicate of this bug. ***
Comment 14 Mike Kaganski 2022-08-08 11:29:15 UTC
Additionally:
https://ask.libreoffice.org/t/80349/4
https://ask.libreoffice.org/t/2052
Comment 15 coduibhin 2022-08-08 11:51:32 UTC
I agree with the request to keep the window for inserting special characters open when returning to the document, and also maintaining a list of recently inserted characters.  It is disappointing to see this most useful behaviour in Word ("Insert Symbol") for over 20 years but not in LO.

One way to improve on Word's Insert Symbol, when a sequence of characters is to be inserted, would be to accumulate the clicked characters in a buffer and only put them in the document when the user clicks "Insert". (Double-clicking a character could continue to insert each character immediately as it is typed.)
Comment 16 Mike Kaganski 2022-08-08 11:59:45 UTC
(In reply to coduibhin from comment #15)

That is a separate tdf#115477.
Comment 17 V Stuart Foote 2022-08-08 14:57:38 UTC
As noted dupe bug 139796 making SCD modeless in its current state is limited by its collapsed Unicode tables, and removal of its edit buffer (bug 115477).

Given that, equally appropriate would be to make the SCD's split button holding favorites and recents picks detachable and modeless. With tweak for user control over the number of glyphs held (bug 120753) to improve its usefulness for polyglot text users.
Comment 18 Mike Kaganski 2022-08-08 15:07:54 UTC
(In reply to V Stuart Foote from comment #17)
> making SCD modeless in its current state is limited
> by its collapsed Unicode tables, and removal of its edit buffer

No, what is limited by those is perceived usefulness of the dialog itself, not its modality. And given that users want it, other improvements of the dialog are completely orthogonal to this request.

(By the way, please elaborate on "collapsed Unicode tables" - best by referencing respective bug report.)
Comment 19 V Stuart Foote 2022-08-08 18:04:19 UTC
(In reply to Mike Kaganski from comment #18)
> (By the way, please elaborate on "collapsed Unicode tables" - best by
> referencing respective bug report.)

Any substantive work with Unicode is facilitated by visual feedback of the 16 column table space. Empty (undefined glyphs omitted by font designer) and Unicode reserved blocks on the tables for the planes the font supports (bug 141319). Giving user a direct read of Unicode for each cell with a glyph or equally without.

Look at the very functional chart implemented in BableMap [1], where visual scaning of the Unicode charts provides coverage details--and a radio button toggle between composite font and single font's coverage.  An easy way to identify when a font selection needs to be changed.

In fact the SCD has retained a 16 column chart from inception. Though we've always packed. But, rather than packing the font (loosing any Unicode context) the ask is to render the charts with fidelity to Unicode.

=-ref-=
[1] https://www.babelstone.co.uk/Software/BabelMap.html
Comment 20 V Stuart Foote 2024-01-20 19:40:57 UTC
*** Bug 159300 has been marked as a duplicate of this bug. ***