If I am not mistaken I used to be able to Highlight some text, click in the font selection list, and then with the arrow keys navigate through the list and see the font in my text change with my selection, then, and only when I clicked outside of the font selection list did the arrow keys no longer apply to it. Now in the font list in the toolbar, as well as in the side pane, as soon as I select a font and hit an up or down arrow key, it immediately takes the focus off of the font list and deselects my text, with the cursor ending up after where the selection was. If I just click inside the list without selecting a font, then I can use the arrow keys to scroll through the list and see the font name change as it should, but then My selected text although it now stays highlighted, it remains the same, and does not change with the selection. The only way I can change fonts is to open the list, scroll down to a font, and select it, and do that over and over and over... and that is not at all productive, and kind of a must have feature. I filed this as normal in severity, but for me and my it's kind of critical. Thanks in advance for any help.
Operating System: EndeavourOS (Arch) KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.11 Kernel Version: 6.1.58-1-lts (64-bit) Graphics Platform: X11
But any reason not to simply use the 'Character...' dialog with its "instant" preview during font list perusal--against your selected text, sentence, or paragraph--to adjust the font? Provides the same workflow while direct formatting text, or when tweaking an applied style. With minimal impact on document canvas until you complete the action in the dialog. *** This bug has been marked as a duplicate of bug 112324 ***
(In reply to V Stuart Foote from comment #2) > But any reason not to simply use the 'Character...' dialog with its > "instant" preview during font list perusal--against your selected text, > sentence, or paragraph--to adjust the font? > > Provides the same workflow while direct formatting text, or when tweaking an > applied style. With minimal impact on document canvas until you complete > the action in the dialog. > > *** This bug has been marked as a duplicate of bug 112324 *** Because, it needs too many steps to get to, it's harder to see the impact on the document with whatever else is in there, it's not intuitive, and I can't remember doing it in LibreOffice any other way. So I am either loosing my mind, or it's broken! Why have any drop down selection menu not behave that way? Step selecting from within a font list and seeing the on canvas has pretty much been standard functionality in almost all rich text and graphics applications since the earliest GUI's, and still is! I can and have used the list in the side pane dialog > Properties > Character, the very same way before, but it is showing the same behavior now. BTW: That one should be called FONT, Not CHARACTER, since it's all the same as in the "FONT" toolbar (consistency?), and doesn't really apply to single characters; for that a "Special Character" dialog already exists which doesn't change whole fonts.
(In reply to V Stuart Foote from comment #2) > > *** This bug has been marked as a duplicate of bug 112324 *** That bug from way back when is actually asking for the opposite (and self defeating if you ask me): Asking for when selecting a font in the list, to not have it applied to the selected text when you do. So, according to that bug fix/enhancement asked for it worked the way I am suggesting it should, and that bug was deemed "Resolved" with "Will not change" with "WYSIWYG" (a very good thing) as a reason, and I agree! So why change it now to have less functionality all of a sudden?
IMHO this is a dupe, now asking to revisit of bug 112324. As with => WF decision there doing a WYSIWYG "preview" of the font change on the Writer document canvas is non-performant and Direct Formatting centric. Working with Paragraph or Character style with provided UI and apply style as needed. With DF the preview in the 'Character...' dialog suffices for selecting a font and pt size for some selection without the overhead of WYSIWYG thrash of responding to listbox cursor/mouseover or mouse wheel without a selection.
s/ without a selection./ without completing selection (<Enter>, m-click)./
Our Design Guideline Actions -- When the dropdown/combobox is on toolbars or sidebar, changes should not become effective until the user leaves the control or collapses the open widget. In particular, hoovering over the expanded dropdown or wheeling respectively navigating with arrow keys the closed control should not apply the selection on-the-fly. The change is made effective with tab and enter only. =-ref-= https://wiki.documentfoundation.org/Design/Guidelines/Selection
Caolan, is there a technical limitation to not apply the highlighted item rather than the selected? And if I leave the control (dropdown for example) without having selected any item the effective attribute would revert to the selected item. Cannot remember why it was decided like this, beyond simplicity.
Sorry for taking this long. Being a user not a developer, there's some stuff in here I don't understand, but this I do: (In reply to V Stuart Foote from comment #7) > Our Design Guideline > > Actions -- > > When the dropdown/combobox is on toolbars or sidebar, changes should not > become effective until the user leaves the control or collapses the open > widget. > > In particular, hoovering over the expanded dropdown or wheeling respectively > navigating with arrow keys the closed control should not apply the selection > on-the-fly. The change is made effective with tab and enter only. Well, it's right, and how it seems to work, but it still makes no sense nor can I see what purpose it serves to work that way. Following it, I first have to select a font in the dropdown which I can both with the up/down arrows, and wheel (So far so good), which works kike this: The combobox font changes, but the highlighted text does not change, so I cannot see my selection applied: Who needs to change the font in the list, but not in their document? What possible purpose does that serve? Even if once applied, you don't like your changes, the undo [Crtrl]+[Z] will fix it right quick. I still have to click, hit [Tab] or [Enter] on a font in the list to apply it, and as soon as I do, the focus is back in the text for click and [Enter], but for [Tab] it moves focuses to the right onto the font size dropdown. Now to see the next font I cannot just continue scrolling, I have to click in the box again, or in the case of having used [Tab] I will be changing the size, again only in the list. Livable if you only have like 10 fonts to choose from, but most of us have a whole lot more. Applying any change via click or [Enter] should not take the focus off of the the control and put it back onto the last cursor position in the document. For tab to move to the next control, does make sense as the next logical step, albeit you still see no changes to the selected text on scrolling until you click or hit [Enter] or [Tab]. All in all, needing to go through all that (Add that I have hundreds of fonts) just to see how font changes will look, exactly where you want to see them (in the actual document) is not in the true spirit of WYSIWYG! What I see change in a control selection I want to get on the selected text! I can scroll through the list and read pretty font names all day without even having anything selected in the document, but if I select something then of course I am doing so in order to do something with or to the selection. Guidelines are great, but only if they serve a real purpose and make sense, and as a user I really don't care what all they do for the developers, if it gives me the user no benefit. I care but what it means to me as to functionality and my workflow, and for that it is counter productive by adding a few unnecessary steps, and compounds them when you want to try many fonts to see which looks best. Seeing only the font name in it's appearance in that list is not sufficient to imagine it in the document itself, and to what is selected: I Want to see what I will get; WYSIWYG, and that totally makes sense, and is of course most likely why GIMP, Inkscape, and most, if not all programs that have selection controls do apply selections within scrolling through them in real time.
Hi, here's a suggestion. The style edition dialogue might be of great use here. Of course, you're using styles, aren't you? In the (paragraph or character) style edition dialogue (right click on the style name > Edit), you go to the 'Font' tab. There you may pick any font of your liking, then click 'Apply'. This updates the text accordingly and you may check the document changes in the background (note that as the dialogue is modal, you can't move in the background). If the change doesn't satisfy you, you pick the formerly selected font and get back. Et voilà ;-)
(In reply to Jean-Francois Nifenecker from comment #10) > Hi, > > here's a suggestion. > > The style edition dialogue might be of great use here. Of course, you're > using styles, aren't you? > > In the (paragraph or character) style edition dialogue (right click on the > style name > Edit), you go to the 'Font' tab. There you may pick any font of > your liking, then click 'Apply'. This updates the text accordingly and you > may check the document changes in the background (note that as the dialogue > is modal, you can't move in the background). If the change doesn't satisfy > you, you pick the formerly selected font and get back. > > Et voilà ;-) You mean in the side bar Styles>Character which should be Styles>Font, for consistency, and well a character isn't a whole font: It does the exact same thing as the font selection dropdown in the toolbar, so no it doesn't change anything but show that both are equally cumbersome, counter productive, and not truly WYSIWYG.
In the side bar, select the styles pane. There, choose the Paragraph styles category (top toolbar, 1st toolbutton on the left). The current paragraph style is pre-selected, right click it, and select 'Edit'. A new dialogue opens, allowing to change any setting in that paragraph style. Go to the 'Font' tab. There, select a font of interest in the fonts list, then click the 'Apply' button. You see the change immediately applied in the background. This is exactly what you're asking for, IMO.
(In reply to Jean-Francois Nifenecker from comment #12) > In the side bar, select the styles pane... > > This is exactly what you're asking for, IMO. No it's not at all what I want, that method involves even more steps, and the view of the font in the display is too small, and can't be resized. I believe the intended use for the styles pane is much finer control, with the intention on also applying it to the style and anything already using it, not just a single word, line of text... selection, and even saving the style for later use, which you may have no need to do. What I would like, and cannot see why others wouldn't rather have too: 1. Select text in the document; Doesn't have to be a whole paragraph, can be more than one paragraph, and more than one style. 2. Click in the font dropdown in the toolbar: It's always there and out of the way, and It's best use is for quick changes and instant results of very common things one changes, not fine control and a plethora of options. 3. Scroll the mouse wheel or use the up/down arrow keys, and watch the font of the selected text change in the document itself (the font names in the dropdown do not need to be the selected font, but all the same as the rest of the interface). May I even suggest it to also suspend the graphical highlight of the text until the choice is made, so you get the full effect of what it will look like in context if and when applied. Once applied the text Highlight in the document is turned back on for reference and show it's still active to be changed, and until the text is deselected. 4. Only on command should the dropdown lose focus. The commands should be as easy as clicking in any other control to focus it, or in the document window where you want the cursor. Pressing [Enter] also applies it and places the cursor in the document window, just where it was before you changed the font. [Tab] should indeed advance to the next control in the toolbar, because you are already adjusting the font, and it's size and what not matter too, so it's a good feature.
[Automated Action] NeedInfo-To-Unconfirmed
The use case makes a lot of sense, and the workflow is quite tedious. We should change the behavior and apply the highlighted list item on-the-fly (and revert if not selected) and revise the guideline. Sounds like a lot of effort.
This reminds me of QGIS, which has the option to "Live update" the canvas when layer styling is changed in the sidebar. Not exactly the same (QGIS only bypasses pressing the Apply button), but I think that if this is implemented, it should be optional. In particular for users sensitive to flashing/jumpy UIs and/or dependent on keyboard use. Noting that we have bug 37048 open (with 15 dupes) but bug 112324 (with 5 dupes) closed as "won't fix", which seems contradictory. There's obviously a lot of users wanting it.
Note that regression in bug 158320 is now fixed, which means font live-preview is available again in Calc, a feature that functions as requested here. So this enhancement is in a way also a request to make things consistent (even though Calc is the odd one out). For comparison, neither Office 365 (online) nor OnlyOffice do it (I tested font and size). And it seems easier to handle in Calc as changing the font of a cell doesn't impact the document layout. But I see the appeal in having it previewed instantly. Caolán, because you fixed the regression, and because Heiko asked in comment 8, any input? Or feel free to un-CC :)
The "This software dos/doesn't do it" is not valid argument to do or not do something, as the reason for it is more important: Did they even give it any thought, is it just too hard to do, is it on a to do list, or is there a bad reason for it or something? Why not just see the logical reasoning behind my suggestion; The Convenience of a live preview to better select a suitable font. Other than a few added mouse clicks or keystrokes, which may not even be needed, I cannot see any reason why it could ever be a bad thing in an app that is able to make great looking and functional documents. I think it would be a great thing to implement it, and have LO do something good M$ Office doesn't for a change, make it a first if no one else does, and with it add to the reasons someone may choose LO over M$ office. Something tells me that if you do implement it you will get way more thanks and praise for it, and very little flack, which if the latter will most likely be based on bad reasoning.
*** Bug 159673 has been marked as a duplicate of this bug. ***