Description: Currently in the Styles sidebar you have to constantly switch between "Custom Styles" and "Applied Styles" particularly when doing a lot of documents, it is an extremely unsatisfactory arrangement. Even when you create a new style to immediately use you actually have to switch view to use it. Without altering the existing options can I highly recommend an extra choice of "Custom and Applied Styles" which people can choose to have them coalesced as one. Unless a document has a lot of custom styles I imagine most people would tend to use this option by default. Steps to Reproduce: (View the styles sidebar, click the droplist at the bottom) Actual Results: . Expected Results: . Reproducible: Always User Profile Reset: No Additional Info: .
I agree on this one. I also felt that. UX Team -- please take a look at this enhancement. Thanks!
+1 an additional list view, combining 'Applied' styles with user's 'Custom' styles, would be reasonable style filtering for efficient authoring.
(In reply to DM from comment #0) > ...constantly switch between "Custom Styles" and "Applied Styles" I'm a bit hesitant to add another filter option, in particular one that kind of replaces an existing. And I guess we cannot just remove the existing options when adding the merged one. So could you please elaborate a bit on the use case first?
So basically unlike most of the items in All Styles, Custom styles are ones you actually plan to apply or are likely to apply, so you want them listed in one single list with the applieds, and you can simply have a narrow edge column indicating by a symbol whether each style in that list is actually applied or not. For that matter for the same reason there's separate buttons for paragraph and character styles, and you currently have to constantly hop around between those two. A list combining Custom and Applied should therefore also have the different types together in a single unified list, and you can have a narrow edge column indicating style type. The present situation of constantly having to switch types and drop the style list to switch between Applied and Custom styles has little benefit except where there are a very large number of styles, but is both extremely inefficient and given it's something that doesn't have to be that way also very irritating. If you are working on a lot of small documents there is no end to this switching you have to do just to do very basic formatting. Even just to apply "No character style" can take five clicks: change to character style, pull up style group selector, choose applied style, double-click "No character style" - it's far too much. When you create a new style to use, it just disappears and can't be used so you have to click the style group selector, custom style, then double-click the style you created just in order then to apply it - again quite unnecessary. By contrast having a combined list choice that can be left open at the side for clicking on and using with no switching about is much more practical.
(In reply to DM from comment #4) > Custom styles are ones you actually plan to apply or are likely to apply... 'Custom Styles' are a proper subset of 'Applied Styles' (besides it doesn't work correctly in all scenarios). I'm rather seeking for something like this: "I create a PS "Address" that I use in letters and another PS "Summary" for publications. All are stored in a template and loaded for new documents. Now I want to check whether my document has the proper styles applied, which are not the default because my co-worker sometimes uses the shipped style "Sender" instead of "Address"." PS = paragraph style
In terms of GUI presentation I think the matter can be achieved as follows - Add a "Applied & Custom Styles" group to the pop-list at the bottom of the style pane. When chosen it indicates Applieds and Customs, of all types, with the side symbol column mentioned to indicate InUse or not. Now if you choose one of the style type buttons at the top of the pane (such as Character etc) it filters to that style. Click that style type button again (that's the active filter) and it toggles off to the fuller list. Ctrl-Clicking those buttons should allow multiple to be on at the same time. So the type buttons at the top should be multi-select using the standard method of multi-selection and breaking out of multi-selection (much as with ctrl-selecting thumbnails in a file viewer), and this could happen with all poplist groups. Multiple type buttons being chosen should trigger a column symbol for type against the listed styles. I think this would give plenty of control to the user to present things in the way that is helpful to them.
I'm still not convinced about the use case. My doubts are mostly that Custom Styles are always a subset of Applied Styles. The general ides about Styles management was outlined in https://design.blog.documentfoundation.org/2019/11/05/proposal-to-conveniently-highlight-and-inspect-styles-in-libreoffice-writer/ and implemented mostly meanwhile. I would keep the functionality of a filter as clear as possible (and made the "Hidden" option a checkbox in the mockup therefore). We may of course do the same for applied styles but it feels wrong to me (and consequently requires to remove this option from the filter).
The use case is basically that the current setup is a result of designing a thing from a perfect theoretical standpoint but not from a practical productivity one. Can I highlight the first two comments made at the top by other users that bear this out.
I apply custom styles, but also existing styles. If I move to Custom styles I will not see other styles, in order to apply them. If I go to Applied styles, I can loose some if for the moment I don't have used some of the styles yet, but they are in Custom styles.
@Heiko, the use case is pretty clear. "Custom" styles are user defined and are portable/reusable when saved out to template. They can be opened back into a current document, and are there ready to select without having to have been "Applied". While authoring, having the ability to see a listing of styles already "Applied" combined with the users preferred/necessary "Custom" styles (that can be prepared and refined external to the current document) further facilitates text entry with well styled formatting. Think of authoring and making use of publisher or design specific paragraph or character styling. Very quickly the "Custom" styles would duplicate to the "Applied" listing, but until well into a document user is forced to change between the listings.
In fact I was wrong with my subset argument. Creating a style as children of Addressee, for example, does not add it automatically (and falsely) to the Applied Styles. In this case there are plenty of obvious use cases. So my concerns are then the combination of two filters. No strong objection to a checkbox, besides the necessary space.
We discussed the topic in the design meeting. The request is an OR combination of two existing filters, while the idea to provide the "[ ] Applied Styles Only" option as checkbox would be and AND combination. Since users might want more or less arbitrary combinations of those filters, for example Text and List Styles is not too far-fetched, we suggest to turn the drop down list into a checkbox list. The top-level item "[ ] All Styles" toggles all items on and becomes indetermined if individual options are unchecked. Clicking the "[x] All Styles" checkbox when checked turns all items off. However, the "Hierarchical" and "Hidden" options should not remain a filter but become a checkbox (part of the discussion on bug 143987).
(In reply to Heiko Tietze from comment #12) Let me elaborate a bit on a few points from the discussion... > users might want more or less arbitrary combinations of > those filters The request here is for a disjunction: "Custom OR Applied". Heiko mentiond the possibility of making filters into checkboxes, which would provide conjunction functionality (e.g. "Applied AND Text Style"). It seems that multiple conjunctions, and also multiple disjunctions, have non-far-fetched and perhaps even somewhat common use cases; at least, it seems that way to me. So, I was not thrilled about adding one specific combination to the list. I would instead rather see a somewhat more comprehensive solution. Possibilities: * a toggle for each filter, and another two-state control for choosing between disjunction and conjunction. * A three-state control for each filter: Disengaged, for-filtering, for-basis, so that the overall is a conjunction of filters applied to a disjunction of sets.
As long as I can see Custom and Applied together as one list the exact choice of how seems secondary to me because having to endlessly switch between Custom and Applied is the existing nightmare. Checkboxes do however have an advantage and benefit from being also used for types (Paragraph, Character etc) In the checkboxes setup it would be good to have accelerator keys/user-definable shortcuts so they can be called from the keyboard. And the option of shift-clicking (or similar modified-click) so that a checkbox is forced on with the others of the kind all turn off - so if you shift-click Paragraph type then it is forced on with Character etc turned off), if you shift-click Custom it is on with Applied etc turned off...
Here is a working work in progress patch for this: https://gerrit.libreoffice.org/c/core/+/203150 I have been struggling with how to handle the StyleList::m_nActFilter variable that was used to store the style filter index selected in the drop down list which is replaced in the patch by a popover with a checkable filter list. It is also for persistence purpose and perhaps other things. The patch makes it the index of the topmost filter selected. Possibly it can just be removed.
Created attachment 206496 [details] Demo of WIP patch
(In reply to Jim Raykowski from comment #16) > Created attachment 206496 [details] > Demo of WIP patch Like it! Since they are all by check-box, any means to provide a single "clear" back to some default set (e.g. either just Applied, or All & Hierarchical)? Also, any perf impact on/with Spotlight enabled? (In reply to Jim Raykowski from comment #15) > I have been struggling with how to handle the StyleList::m_nActFilter > variable that was used to store the style filter index selected in the drop > down list which is replaced in the patch by a popover with a checkable > filter list. It is also for persistence purpose and perhaps other things. > The patch makes it the index of the topmost filter selected. Possibly it can > just be removed. I am not clearly understanding that. Our status quo with the drop down shows just a single selection from the list. And that persists between openings of the deck. Would this mean that on restore/opening the deck, the popover will show with only a single check-box? Loosing the full mixed set of cb selections user had made? That might be jarring. Is it needed for persistence? Or, should we instead allow user to set their default prefs, and could use a "Styles" panel in Tools -> Options to do so? Users would set their defaults to apply to a new/reopening of a document, and for when opening/reopening the Styles deck. They would change as they like while the Styles deck remains open, but back to their user's defaults for next opening of the Stylist?
Phrasing the title a little more generall. That is, "checkboxes" are just widgets used in implementing the functionality.
Related topics are: Bug 90646 (Sidebar-Styles-Improvements) - Improving the "Style & Formatting" sidebar tab Bug 143987 - Stylist: Merge PS and CS into one Text Styles view In https://design.blog.documentfoundation.org/2019/11/05/proposal-to-conveniently-highlight-and-inspect-styles-in-libreoffice-writer/ we suggested to separate the filter from the view mode (tree vs. list). From looking at the demo I suggest to * move Hierarchy out of the filter into an extra checkbox or radiobutton * make All Styles a total switch that toggles all other on/off and becomes indetermined on individual settings (ie. only List Styles, for example) * consider Hidden and Applied as extra checkboxes as these apply to all style families * if the amount of options makes the sidebar too heavy resp. leaves not enough space for the list/tree view we could place it in an expander Some work has been done for bug 143987 in a GSoC project at https://gerrit.libreoffice.org/c/core/+/119834 (and other).
*** Bug 171656 has been marked as a duplicate of this bug. ***
(In reply to V Stuart Foote from comment #17) > (In reply to Jim Raykowski from comment #16) > > Created attachment 206496 [details] > > Demo of WIP patch > > Like it! > > Since they are all by check-box, any means to provide a single "clear" back > to some default set (e.g. either just Applied, or All & Hierarchical)? In PS2, unchecking 'All Styles' when it is checked clears all check boxes except Hierarchical. > Also, any perf impact on/with Spotlight enabled? None that I know of. > > (In reply to Jim Raykowski from comment #15) > > > I have been struggling with how to handle the StyleList::m_nActFilter > > variable that was used to store the style filter index selected in the drop > > down list which is replaced in the patch by a popover with a checkable > > filter list. It is also for persistence purpose and perhaps other things. > > > The patch makes it the index of the topmost filter selected. Possibly it can > > just be removed. > > I am not clearly understanding that. Our status quo with the drop down shows > just a single selection from the list. And that persists between openings of > the deck. > > Would this mean that on restore/opening the deck, the popover will show with > only a single check-box? Loosing the full mixed set of cb selections user > had made? That might be jarring. Yes that is what it means. > Is it needed for persistence? Or, should we instead allow user to set their > default prefs, and could use a "Styles" panel in Tools -> Options to do so? > Users would set their defaults to apply to a new/reopening of a document, > and for when opening/reopening the Styles deck. It seems the selected filter persists not by document but by module. See: https://opengrok.libreoffice.org/xref/core/officecfg/registry/schema/org/openoffice/Setup.xcs?r=aadde5364767445a3ff539d6673a0201912d49db#186 oor:type="xs:int" only allows one filter index to be stored. Perhaps this can be made oor:type="xs:string" to allow for more than one index to be stored. WIP
Created attachment 206686 [details] Demo 2 of WIP In this second demo, the Hierarchical checkbox is moved out of the filters list and the All Styles performs the suggested total switch that toggles all other on/off and becomes indeterminate on individual settings. Not shown in the demo is an addition of persistence of all selected filters, not just the topmost selected filter as previously mentioned.
(In reply to Jim Raykowski from comment #22) > Created attachment 206686 [details] > Demo 2 of WIP > > In this second demo, the Hierarchical checkbox is moved out of the filters > list and the All Styles performs the suggested total switch that toggles all > other on/off and becomes indeterminate on individual settings. Not shown in > the demo is an addition of persistence of all selected filters, not just the > topmost selected filter as previously mentioned. Jim, this looks sooooo goood!!!! I think a lot of bugs from Sidebar will be closed by this change. Great!
(In reply to Jim Raykowski from comment #22) > Created attachment 206686 [details] Awesome! What happens if the hierarchy contains filtered out items. Something like "Heading 1" used but "Heading" not. At other places we show the actually filtered-out items but with a disabled appearance.
Also, there is another case when I choose Content 2 style and apply to a paragraph, and it also shows the Index style as being applied, but it is just a parent of Content 2. The whloe document has just 1 paragraph, one style applyed but is shows 2 styles. Maybe this change you do can solve also this bug.
(In reply to Jim Raykowski from comment #22) > Created attachment 206686 [details] > Demo 2 of WIP > > In this second demo, the Hierarchical checkbox is moved out of the filters > list and the All Styles performs the suggested total switch that toggles all > other on/off and becomes indeterminate on individual settings. Not shown in > the demo is an addition of persistence of all selected filters, not just the > topmost selected filter as previously mentioned. @Jim, looks *very* functional, thanks!
(In reply to Heiko Tietze from comment #24) > (In reply to Jim Raykowski from comment #22) > > Created attachment 206686 [details] > Awesome! What happens if the hierarchy contains filtered out items. > Something like "Heading 1" used but "Heading" not. At other places we show > the actually filtered-out items but with a disabled appearance. Here is the function that is called to determine if a style is used in a document. bool SwDoc::IsUsed( const sw::BroadcastingModify& rModify ) const { assert(lcl_isValidUsedStyle(&rModify)); // Check if we have dependent ContentNodes in the Nodes array // (also indirect ones for derived Formats) bool isUsed = false; sw::AutoFormatUsedHint aHint(isUsed, GetNodes()); rModify.CallSwClientNotify(aHint); return isUsed; } I think the comment says that the style is considered used if there are styles derived from the it that are used. Perhaps you are thinking about showing hidden styles as greyed out? The next PS does this for gen and qt VCL plugins.
(In reply to BogdanB from comment #25) > Also, there is another case when I choose Content 2 style and apply to a > paragraph, and it also shows the Index style as being applied, but it is > just a parent of Content 2. The whloe document has just 1 paragraph, one > style applyed but is shows 2 styles. Maybe this change you do can solve also > this bug. Maybe this is the same as Heiko's comment. As of yet I haven't been able to come up with something to determine if the derived from style (parent style) is really applied.
(In reply to Heiko Tietze from comment #24) > At other places we show the actually filtered-out items > but with a disabled appearance. Show the Stylist for PS filtered as Hierarchical and hide the style Heading. It should not be shown anymore but is needed for the tree appearance of all children and therefore shown like disabled. Since the same happens for styles with no children I guess there is no special routine and to detect the relation.
(In reply to Heiko Tietze from comment #29) > (In reply to Heiko Tietze from comment #24) > > At other places we show the actually filtered-out items > > but with a disabled appearance. > Show the Stylist for PS filtered as Hierarchical and hide the style Heading. > It should not be shown anymore but is needed for the tree appearance of all > children and therefore shown like disabled. Since the same happens for > styles with no children I guess there is no special routine and to detect > the relation. I think I'm tracking what you are saying. Seems it has to do with bug 119919. In PS11 hidden entries in the tree (flat or hierarchical) are shown using the style settings disabled color. These are included in the tree when the Hidden Styles filter is checked. When the Hidden Styles filter is not checked, hidden styles in selected filters are not shown. For example using PS11 and Index Styles filter with Index 3 hidden. When only the Index Styles filter is selected, Index 3 is not shown in the tree. When both Hidden Styles and Index Styles are selected, Index 3 shows in the tree with the style settings disabled color along will all other hidden styles which may not be what is wanted. Perhaps another checkbox is needed to show/hide hidden styles in selected filter styles instead of having to select the Hidden Styles filter which includes all hidden styles in the tree?
(In reply to Jim Raykowski from comment #30) > In PS11 hidden entries in the tree (flat or hierarchical) are shown using > the style settings disabled color. Tested the patch and the issue is obvious for Filter = Document Structure with "Heading" made hidden. If we expose "[x] Hierarchical" as a global option the tree must not miss the root node. (In reply to Jim Raykowski from comment #30) > In PS11 hidden entries in the tree (flat or hierarchical) are shown using > the style settings disabled color. Hiding hidden items breaks the tree. But you can also create a PS with category A and children with cat B and just do not show A. The result is a flat list. Thinking my considerations through I end up with Default PS always visible, for example. Not sure we want this. Users probably want to switch from All or Automatic to Applied and nothing else. And I see no reason to toggle between tree and list view. > Perhaps another checkbox is needed to show/hide hidden styles in selected > filter styles instead of having to select the Hidden Styles filter which > includes all hidden styles in the tree? IIRC this was included in the mockup. But it feels now like over-engineering. Maybe if we collapse all checkbox options? Besides, the "Filter" label uses a different font (size?) maybe as a consequence of the toolbar button. Looks weird.
(In reply to Heiko Tietze from comment #31) > > Perhaps another checkbox is needed to show/hide hidden styles in selected > > filter styles instead of having to select the Hidden Styles filter which > > includes all hidden styles in the tree? > IIRC this was included in the mockup. But it feels now like > over-engineering. Maybe if we collapse all checkbox options? PS12 adds a "ShowHidden" setting to show or not show hidden styles in a style filter. This can be set in the Expert Configuration dialog under org.openoffice.Office.Common - Styles and Formatting - ShowHidden. When set true, hidden styles in a style filter are shown using style settings disabled color. When set false, hidden styles in a style filter are not shown. The default setting is true to match the current behavior of showing hidden styles. > Besides, the "Filter" label uses a different font (size?) maybe as a > consequence of the toolbar button. Looks weird. I do not see a different font size used for the "Filter" label in any VCL plugin I am able to test (gtk3/4, gen, qt5/kf5)
Created attachment 206891 [details] WIP demo PS14 PS14 uses a new approach to show hidden styles in a filter that does not require using the Expert Configuration dialog. Hidden styles in selected filters are shown when the Hidden Styles filter also selected. When only the Hidden Styles filter is selected, all hidden styles are shown. PS14 renames the 'All Styles' filter to 'All Visible Styles'. Selecting the 'All Visible Styles' filter is treated the same as the other filters.
Jim, I am testing version 13 of this patch. Some notes: - it is beautiful, it is what I always wanted, to be able to group options, I always wanted to have Applied + Custom. But now we have more than that, more combinations, thanks for your work until now. It is already a goooood job!!! - one thing that I noticed until now: if I expand all arrows to see all the styles from my 3 main styles that I have in one specific document and click on Previews they close again, and I have to open them again. The same on Spotlight. - "Previews" I think it should be "Preview". Maybe the same on "Filters"->"Filter". It is just my opinion, maybe it is not the right one. - as the first time of using this new feature I found it hard to understand what I have to to after I click another filter, there is no OK button. But I remembered from the video that you clicked on Filters, or we can click anywhere outside the list. I supose we will get a lot of bugs that there is a missing Ok or Apply button there. Give someone who never seen your videos to test that Filter, to see a live reaction. - if Previews and Spotlight are activated, in my case numbers from the left of the styles are going from 8 to 0, from top to bottom. Is there a reason why they are not from 0 to 8 from top to bottom? Thanks again Jim!
(In reply to BogdanB from comment #34) > Jim, I am testing version 13 of this patch. > > Some notes: > - it is beautiful, it is what I always wanted, to be able to group options, > I always wanted to have Applied + Custom. But now we have more than that, > more combinations, thanks for your work until now. It is already a goooood > job!!! Thanks! > - one thing that I noticed until now: if I expand all arrows to see all the > styles from my 3 main styles that I have in one specific document and click > on Previews they close again, and I have to open them again. The same on > Spotlight. PS16 includes a fix for this. > - "Previews" I think it should be "Preview". Maybe the same on > "Filters"->"Filter". It is just my opinion, maybe it is not the right one. PS16 changes these to your suggestions. > - as the first time of using this new feature I found it hard to understand > what I have to to after I click another filter, there is no OK button. But I > remembered from the video that you clicked on Filters, or we can click > anywhere outside the list. I supose we will get a lot of bugs that there is > a missing Ok or Apply button there. Give someone who never seen your videos > to test that Filter, to see a live reaction. PS16 includes an OK button in the popover menu. > - if Previews and Spotlight are activated, in my case numbers from the left > of the styles are going from 8 to 0, from top to bottom. Is there a reason > why they are not from 0 to 8 from top to bottom? I also noticed this in earlier patch sets. Not sure what was changed since version 13 to make me not be able to repro it anymore. Please let me know if you test the latest version and the behavior is still the same for you. > > Thanks again Jim! Thank you BogdanB for the feedback!
Another testing on patch 16: - expanding: working well - renaming: ok - Ok button: ok - numbering is still reversed, from 8 to 0 in my document - and another thing: with number from 8 to 0 we feel like developers numbering from index 0. Should not begin with 1? and again I repeat, is more than we have dream of in the Styles sidebar.
I am playing more and more with this feature: - when I go to Character Styles in the sidebar and came back to Paragraph Styles, the Hierarchical structure does not remember to stay open. Or any other similar tab from there: Page style and so on. - also when a parent style is closed (the arrow is pointing to the right), all included styled from there are closed. So, when I need to open again, I have to open all one by one, even if I closed just the main one. For example, in a new document with all top checkboxes activated, open Body Text styles, then close Default Paragraph Style and reopen. Body Text is now closed. If I have 10 substyles I have to reopen them one by one. - from this one last ideea, a new ideea could be that all styles to be open by default. Now users that activate the filter will have just some styles that they use, and they want to be able to click as soon as possible. Not sure it is a good ideea. But is here.
I know how you made this to work: - when I am in a paragraph from Body text, and I am coming back from Character Styles, the substyle Body text is open, but all other substyles are closed. If I am in a Heading substyle with my cursor, and I am coming back from Character Styles, the Body text is closed and Heading is open. - If Body text is already opened, and I click in a Heading style, this Heading style will also open. But from my opinion, a normal person uses 3-15 styles per document, so, if all are open, he can see all of them on the same screen. For me, closing and opening subtitles are the last problem. It is already a big improvement in using styles from the sidebar.
(In reply to BogdanB from comment #36) > Another testing on patch 16: > - numbering is still reversed, from 8 to 0 in my document I can't repro this behavior any more. Please attach an example document that does this. > - and another thing: with number from 8 to 0 we feel like developers > numbering from index 0. Should not begin with 1? done in PS19
(In reply to BogdanB from comment #37) > - when I go to Character Styles in the sidebar and came back to Paragraph > Styles, the Hierarchical structure does not remember to stay open. Or any > other similar tab from there: Page style and so on. done in PS19 > - also when a parent style is closed (the arrow is pointing to the right), > all included styled from there are closed. So, when I need to open again, I > have to open all one by one, even if I closed just the main one. For > example, in a new document with all top checkboxes activated, open Body Text > styles, then close Default Paragraph Style and reopen. Body Text is now > closed. If I have 10 substyles I have to reopen them one by one. done in PS19 > - from this one last ideea, a new ideea could be that all styles to be open > by default. Now users that activate the filter will have just some styles > that they use, and they want to be able to click as soon as possible. Not > sure it is a good ideea. But is here. I think more input on this idea would be good.
Created attachment 206905 [details] screenshot
Created attachment 206906 [details] Demo document
I see only PS18 in gerrit.
Created attachment 206907 [details] demo document screen shot showing spotlight numbering Here is a screen shot of what I get for spotlight numbering with the demo document. PS19 should be available at gerrit now. https://gerrit.libreoffice.org/c/core/+/203150/19
I am using GTK3. I am running now a "make" with PS19, after that I will try more tests.
With GEN I get 1-4, but with KF5, GTK3, VLC I get 4-1.
Created attachment 206908 [details] video testing the bug also when a parent style is closed (the arrow is pointing to the right), all included styled from there are closed. So, when I need to open again, I have to open all one by one. VIDEO filmed with GEN environment
LGTM Possible follow-up topics: the checkbuttons take too much space and enlarge the sidebar, Preview receives too much attention, Spotlight is not a related filter and view option, hidden parents are not shown in hierarchy mode, the Done button makes the widget less effective in some scenarios, individual settings per style family)
(In reply to BogdanB from comment #46) > With GEN I get 1-4, but with KF5, GTK3, VLC I get 4-1. A fix for this is included in PS20. Probably better would be to make it a separate patch. Has to do with the way Gtk3 does treeview bulk insert - see: commit 50588a1583e3cc5dc647a35889e50478c7bfd033
Created attachment 206919 [details] demo that show how to show hidden styles in selected filters Selecting Hidden Styles along with other style filters shows hidden styles in the selected filters as greyed out for gen and qt5. For me, gtk3 does not show hidden styles as greyed out.
(In reply to Jim Raykowski from comment #50) > demo that show how to show hidden styles in selected filters It illustrates the issue: Code End belongs to Body Text with an intermediate Code style. Hiding this parent must not move the item somewhere else but ideally show the hidden style anyway.
(In reply to Jim Raykowski from comment #49) > (In reply to BogdanB from comment #46) > > With GEN I get 1-4, but with KF5, GTK3, VLC I get 4-1. > > A fix for this is included in PS20. Probably better would be to make it a > separate patch. Has to do with the way Gtk3 does treeview bulk insert - see: > commit 50588a1583e3cc5dc647a35889e50478c7bfd033 Thanks, Jim, working well for all. For me and from Heiko suggestion I would keep 2 remaining issues: - Hierarchical (not usable for me at the moment, closing even if we don't change to Character Style, but we click inside another paragraph with a different style). With Hierarchical option unchecked, I can use this new feature very well. - about names, I am thinking about some languages where this 4 terms could have long names, maybe an icon for some of them could be a better solution. @Heiko? @Heiko, I like Spotlight side by side to the options for Styles, it is not a filter, but is useful to be at hand up in the options. So, this patch could be a subject for the next Design meeting.
(In reply to BogdanB from comment #52) > So, this patch could be a subject for the next Design meeting. Submit early, submit often. Let's finish this topic and ponder over follow-up tickets.
Created attachment 206941 [details] Demo that shows hidden parents when there are visible children (In reply to Heiko Tietze from comment #51) > It illustrates the issue: Code End belongs to Body Text with an intermediate > Code style. Hiding this parent must not move the item somewhere else but > ideally show the hidden style anyway. PS21 always shows the hidden parent if there are visible children
(In reply to BogdanB from comment #52) > - Hierarchical (not usable for me at the moment, closing even if we don't > change to Character Style, but we click inside another paragraph with a > different style). I don't see this behavior anymore since PS20.
(In reply to Jim Raykowski from comment #54) > Demo that shows hidden parents when there are visible children Nice!
Created attachment 206948 [details] video testing the bug When I am in a body style, heading style are closing, and so on... Even not moving to Character style. The ideea is that when I am in a normal paragraph I need to create a heading 1, for example. So, in order to be already open, I would need to click on another heading that will make Heading category to be open. I tested with gen, gtk. I dont know why it is working for you and not for me.
(In reply to BogdanB from comment #57) > When I am in a body style, heading style are closing, and so on... Even not > moving to Character style. The ideea is that when I am in a normal paragraph > I need to create a heading 1, for example. So, in order to be already open, > I would need to click on another heading that will make Heading category to > be open. > > I tested with gen, gtk. I dont know why it is working for you and not for me. I must have changed the code that restores the hierarchical expand state and not tested it before uploading PS20. Sorry about that :(. PS22 aims to provide the behavior you expect. > comment 37 > - from this one last ideea, a new ideea could be that all styles to be open > by default. Now users that activate the filter will have just some styles > that they use, and they want to be able to click as soon as possible. Not > sure it is a good ideea. But is here. PS22 does this :)
Created attachment 206968 [details] video testing the bug Thanks, Jim. It is all I imagine for using styles in Writer! I notice a bug with GTK3, not GEN. See the video. With GTK3, when I choose a style and move up, when the list is longer usually, the same style appears twice. I reset the user profile, so there is no user profile corruption.
Created attachment 207036 [details] gtk3 drag and drop (In reply to BogdanB from comment #59) > With GTK3, when I choose a style and move up, when the list is longer > usually, the same style appears twice. I reset the user profile, so there is > no user profile corruption. Here's what it looks like for me when I test with GTK3. I tested with xorg and wayland and got the same results.
Jim, I upload patch 24. I have the same problem. What I suspect is that a style is missing top or bottom, you can see the scrollbar having a little bit of space to move up or bottom. Maybe the animation/changes are on styles without scrollbar, and the result is with sidebar. This sound plausible, because is a 1 style difference, exactly the style that is not visible in the sidebar. I have tested like this: make clean git fetch origin master && git reset --hard origin/master && git checkout master && git pull git fetch https://git.libreoffice.org/core refs/changes/50/203150/24 && git cherry-pick FETCH_HEAD make ./instdir/program/soffice then Reset to factory settings. then the video Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 66e03a8f2c0cae16df157f96b2a862d7ff90b091 CPU threads: 16; OS: Linux 6.17; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 207041 [details] video testing the bug
Created attachment 207042 [details] Demo document
I tested now with GEN, but I had to add another categories of styles, to have a scrollbar. But I don't reproduce. So, it seems a GTK3 issue. Seems like a refresh problem.
Jim, I want to mention, that I don't drag & drop like in your last video, I just scroll the styles from the sidebar, in order to find styles from top, or from the bottom of the available list. I don't move anything, sorry for the words used there, I just scroll. Please see again my videos.