Using both, Paragraph Styles (PS) and Character Styles (CS), at the same time is common practice. The current implementation of the Stylist makes it unnecessarily difficult and requires user to switch from one style family to another. So we should combine bot styles into one view with two tree elements. The implementation might cover larger parts of bug 90646.
Heiko, do you have some mockup for it?
It is part of this larger rework https://design.blog.documentfoundation.org/category/user-interface/ and actually WIP right now. Filed the ticket just for reference.
*** Bug 152443 has been marked as a duplicate of this bug. ***
A better solution IMO would be to use a customizable styles toolbar for the most frequently used styles. Combining style families into one sidebar panel would cause way too much scrolling for large numbers of styles.
I think that a sidebar with *all* style families implemented as default-collapsed panels with collapsed titles showing the current style name (so sidebar looking like a stack of "comboboxes" giving you a complete overview of all the styles active at the cursor), and each expanded panel would collapse all other panels (so only allowing one family expanded at a time) would be a reasonable and more useful replacement. Showing the titles like [+] Paragraph style: Foo [+] Character style: Bar [+] Page style: Baz [+] Frame style: None ... and when expanded, showing much the same view as we have now for any given family, like [+] Paragraph style: Foo [-] Character style: Bar =================== No Character Style Bullets Caption Characters ... [x] Show previews [Hierarchical][V] =================== [+] Page style: Baz [+] Frame style: None ... would make everything accessible, discoverable, and most useful information available on one dashboard.
Don't forget the table style. I struggle with the implicit need to show page and frame styles while editing text. That's why my take on it was to merge the _text related_ styles into one view.
(In reply to Mike Kaganski from comment #5) > would make everything accessible, discoverable, and most useful information > available on one dashboard. If there is a long list of styles, this requires one click to close a category (or else scroll way down) and another click to open the new one instead of just one click the way it is now.
If you have the expanded list auto-sized to fill the available height (minus the height of 4 other categories), then only a single click is needed.
(In reply to Mike Kaganski from comment #8) > If you have the expanded list auto-sized to fill the available height (minus > the height of 4 other categories), then only a single click is needed. Which also takes up additional space. I hope that at least a new design will be added as an optional panel for the sidebar and that the current one is not removed.
(In reply to David from comment #9) > Which also takes up additional space. Indeed. Note however, that this would be less than the original idea here - to have two style categories open at once. Plus, (or minus) you remove the top toolbar, so it will be less than full 5 categories height. > I hope that at least a new design will > be added as an optional panel for the sidebar and that the current one is > not removed. Let's implement it first ;) - if it would happen, I'd hope we'd not need to keep multiple choices.
(In reply to Mike Kaganski from comment #10) > Indeed. Note however, that this would be less than the original idea here - > to have two style categories open at once. That's what makes the Styles Formatting Toolbar such a powerful resource for accessing core styles.
(In reply to David from comment #11) > That's what makes the Styles Formatting Toolbar such a powerful resource for > accessing core styles. What's what makes the Styles Formatting Toolbar such a powerful resource? Your phrase is completely cryptic, making me wonder what does it mean, and not explaining anything.
(In reply to Mike Kaganski from comment #12) > (In reply to David from comment #11) > > That's what makes the Styles Formatting Toolbar such a powerful resource for > > accessing core styles. > > What's what makes the Styles Formatting Toolbar such a powerful resource? > Your phrase is completely cryptic, making me wonder what does it mean, and > not explaining anything. The ability to have a set of core styles on its own toolbar provides a very convenient way to have another place in which to select frequently used styles. I ditched the standard toolbar and don't miss it.
(In reply to David from comment #13) Hmm, I'm sorry how comments 11-13 relate to the problem discussed here, and wonder why have they appeared here: I presume, they intend to help decide on something?
(In reply to Mike Kaganski from comment #14) > (In reply to David from comment #13) > > Hmm, I'm sorry how comments 11-13 relate to the problem discussed here, and > wonder why have they appeared here: I presume, they intend to help decide on > something? The first paragraph of the original request described the difficulty switching between style categories The second paragraph of the request gave a proposed solution. My point is that the styles toolbar already gives the capability of displaying a customizable core subset of styles from multiple categories thereby possibly alleviating the need for the proposed solution, which if implemented might disrupt the workflow of others. Another solution would be to make the styles pane consistent with how the navigator pane already functions. The navigator can be an independent pane while also being in the sidebar. As an independent pane the styles pane could be docked below the sidebar or wherever the user chooses while still being included in the sidebar, just as the navigator currently operates. That would also have the added benefit of UI consistency.
(In reply to David from comment #15) IUUC, your comments then meant a vote for WONTFIX for the proposal here, based on existing solution for the stated problem that the proposal intended to solve. The toolbar in question is not a solution at all. It is unavailable in some UI configurations; it doesn't (and can't, because of limited space) have controls for all character styles (only some are represented there as buttons) - or it would then need even more space for page styles, frame styles, etc... The proposal in comment 5 is intended to provide the maximum usability for those who prefer a large window for the "active" style category, and at the same time, providing immediate display of *all* active style names in always-visible headings of collapsed categories. Indeed, this still requires switching between the categories, which original proposal intended to avoid; yet, comment 5 is expected to address the "current implementation of the Stylist makes it unnecessarily difficult" piece of original description. "How the navigator pane already functions" is not something that we can try to reproduce in new UI elements, because "how the navigator pane already functions" is just an artifact of transition from separate windows to sidebar, with the sidebar's current inability to undock separate panes - which, when Navigator was initially removed as a separate window, caused strong pushback, after which it was decided, that Navigator will be an exception *for the transitional period*, until the proper undocking will be implemented for sidebar panels - see bug 73151. So this curiosity is destined to be removed at some point (of course, it takes long, but this doesn't change things).
(In reply to Mike Kaganski from comment #16) > (In reply to David from comment #15) > "How the navigator pane already functions" is not something that we can try > to reproduce in new UI elements, because "how the navigator pane already > functions" is just an artifact of transition from separate windows to > sidebar, with the sidebar's current inability to undock separate panes - > which, when Navigator was initially removed as a separate window, caused > strong pushback, after which it was decided, that Navigator will be an > exception *for the transitional period*, until the proper undocking will be > implemented for sidebar panels - see bug 73151. So this curiosity is > destined to be removed at some point (of course, it takes long, but this > doesn't change things). I depend heavily on having the navigator as a independent pane. I hope it doesn't get removed. It saves me a tremendous amount of extra clicking.
(In reply to Mike Kaganski from comment #16) > (In reply to David from comment #15) > > > exception *for the transitional period*, until the proper undocking will be > implemented for sidebar panels - see bug 73151. I guess that means that if a pane would have the ability to be undocked from the sidebar then it wouldn't show as part of the sidebar until it was re-docked back into it? Am I understanding correctly?
(In reply to David from comment #18) > if a pane would have the ability to be undocked from the sidebar then it > wouldn't show as part of the sidebar until it was re-docked back into it? Exactly; and that means that there would be only a single instance of Navigator, just as it was the case before introduction of the sidebar. (Note that this discussion around Navigator and sidebar panels' undocking is off-topic here; it was mentioned only to describe why the current situation shouldn't be the model for other UI elements, and if a discussion is wanted, it should happen in bug 85905 or another related issue; thus, I mark the unrelated comments, including this my answer, as off-topic, to collapse them.)