Bug 143987 - Stylist: Merge PS and CS into one Text Styles view
Summary: Stylist: Merge PS and CS into one Text Styles view
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 152443 (view as bug list)
Depends on: Sidebar-Styles-Improvements 144079
Blocks: Sidebar-Styles
  Show dependency treegraph
 
Reported: 2021-08-21 06:21 UTC by Heiko Tietze
Modified: 2024-07-26 06:25 UTC (History)
9 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 Heiko Tietze 2021-08-21 06:21:20 UTC
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.
Comment 1 Roman Kuznetsov 2021-08-21 20:45:50 UTC
Heiko, do you have some mockup for it?
Comment 2 Heiko Tietze 2021-08-23 07:33:40 UTC
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.
Comment 3 Dieter 2022-12-14 08:41:23 UTC
*** Bug 152443 has been marked as a duplicate of this bug. ***
Comment 4 David 2022-12-19 10:33:20 UTC
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.
Comment 5 Mike Kaganski 2022-12-19 10:47:38 UTC
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.
Comment 6 Heiko Tietze 2022-12-19 13:44:47 UTC
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.
Comment 7 David 2022-12-21 23:46:44 UTC
(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.
Comment 8 Mike Kaganski 2022-12-22 04:11:22 UTC
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.
Comment 9 David 2022-12-22 18:54:48 UTC
(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.
Comment 10 Mike Kaganski 2022-12-22 20:09:02 UTC
(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.
Comment 11 David 2022-12-23 21:25:18 UTC
(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.
Comment 12 Mike Kaganski 2022-12-23 21:52:29 UTC
(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.
Comment 13 David 2022-12-23 23:43:14 UTC
(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.
Comment 14 Mike Kaganski 2022-12-24 04:23:15 UTC
(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?
Comment 15 David 2023-01-04 19:04:55 UTC

(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.
Comment 16 Mike Kaganski 2023-01-04 20:44:46 UTC
(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).
Comment 17 David 2023-01-04 21:35:33 UTC Comment hidden (off-topic)
Comment 18 David 2023-01-04 21:44:49 UTC Comment hidden (off-topic)
Comment 19 Mike Kaganski 2023-01-05 06:59:10 UTC Comment hidden (off-topic)
Comment 20 Kira Tubo 2024-07-26 01:29:20 UTC
@Heiko, I spoke to Ilmari about this one. Can you leave a comment with a list of what needs to be done, in relation to this patch: https://gerrit.libreoffice.org/c/core/+/119834

Thanks!
Comment 21 Heiko Tietze 2024-07-26 06:25:26 UTC
(In reply to Kira Tubo from comment #20)
> what needs to be done, in relation to this patch:
> https://gerrit.libreoffice.org/c/core/+/119834
Please check the comments on the patch. Skimming over the non-resolved it seems most are done, and you could flag it accordingly. Hope Mike is willing to continue mentoring on this project.

And eventually you may take a look at the UI what can be improved (will do this myself too).