When one deletes a style, the style side-bar refocus / rescrolls to the style of the currently selected object. This, even if one has scrolled away from it to delete a certain style. IMHO, this shouldn't happen, i.e. the sidebar should not refocus at all, if possible, or refocus/scroll up by 1 entry. Note: I'm not not talking about what the _selection_ in the sidebar is, only the scroll bar position . Rationale: * It's a jarring UI jump * It's not necessary, and can be effected by deselecting than selecting the object. * There is no obvious indication that what the user wants is to interact with the select object's style - as the deletion is independent of that style. * ... likely the user may want to delete or manipulate other styles in the vicinity of the deleted one (in hierarchical / alphabetical sort order at least).
(In reply to Eyal Rozenberg from comment #0) > Note: I'm not not talking about what the _selection_ in the sidebar is, only > the scroll bar position . In fact you do. The Stylist has an active and a selected item. If you delete the selected it becomes the same as active. And every automatic change in the data model should be reflected in the UI. Keeping the current view port means that you could scroll somewhere, switch from one paragraph with style A to another with style B and don't see that. => WF
(In reply to Heiko Tietze from comment #1) > (In reply to Eyal Rozenberg from comment #0) > > Note: I'm not not talking about what the _selection_ in the sidebar is, only > > the scroll bar position . > > In fact you do. The Stylist has an active and a selected item. If you delete > the selected it becomes the same as active. I think I may be getting the terms mixed up, or not following. What is the difference between the active and the selected item? I should mention that when I right-click and delete an item, it is not my intention to select it, though perhaps it is considered to be selected by virtue of the right-click. Or is it made active? > If you delete the selected it becomes the same as active. This sentence I don't understand. > And every automatic change in the data model should be reflected in the UI. But I'm not changing the style of the currently-focused object, I'm deleting a (typically) unused style. The UI reflects this by removing the style from the list. I just don't want it to jump to a far-away item, just because the currently-focused object's style is far-away from my current scroll position. I think I want to repoen this, but I don't quite get what you've told me so not touching it for now.
(In reply to Eyal Rozenberg from comment #2) > I think I may be getting the terms mixed up, or not following. What is the > difference between the active and the selected item? Some discussion in bug 94427. The tree has currently only one selection while the effective style might be different (and should be visible as such). I call this "active".
(In reply to Heiko Tietze from comment #3) Ok, so: "Active style" - style of focused object in the document pane of the window "Selected style" - selected item in the list of styles. Now I understand what you meant in comment #1, and can respond. > I'm not not talking about what the _selection_ in the sidebar is, only > the scroll bar position. > > In fact you do. So, maybe, but not necessarily. Because, in fact, the scroll bar position, the selected item, and the active item, are distinct. I can scroll away from the selected item as far as I like (and of course also scroll away from the active item). I did not open this bug about which item should be _selected_ after a deletion, but where the scroll bar should be positioned. > The Stylist has an active and a selected item. > If you delete the selected it becomes the same as active. My idea when opening this bug, and in the opening comment, is that even if the active item becomes selected - the scrollbar will not be repositioned to ensure it is visible. That's the ask. This will already be a significant improvement from the current state of affairs, because users - I claim - do not want the style list to jerk and tilt just because they deleted an item. A second idea would be to not just keep the current scroll bar position, but also _not_ select the active item; lose the selection entirely. This makes sense because in most contexts when you delete a selected item, you lose the selection: Even in LO - w.r.t. document content - selecting something, like some text or a drawing object, then deleting it, results in an empty selection (and no change in the position in the document, e.g. in the case of Writer). Now for your reason for WONTFIX'ing: > Keeping the current view port means that you could scroll somewhere, > switch from one paragraph with style A to another with style B and > don't see that. Nope, it doesn't mean that. If you switch from A to B - that is, take an element with style A and set its style to B - you have not deleted a style, and won't trigger the chosen behavior here. If, however, you delete style A while the focused/selected paragraph has style A, then - you will definitely see that A has lost its style. Yes, you won't see what style A now has, but - you know what that style, because deletion means the object will have the parent style. If we go with my original alternative, it will be just like having scrolled away from the selection of the parent style. My second alternative will not let you see what A's style is even by scrolling. But this is also not a problem, because this is what happens whenever you select a style on the list without double-clicking/applying it: The active item is not known, only the selected one. So you'll just have another action which gets you into this state. (Plus, if bug 94427 is addressed, you will still have a visual reminder of the parent style becoming active, when you scroll to that parent style).
The Stylist is a single-selection tree where one node is always selected. After deleting the selected node the currently active style becomes selected. And by default the tree scrolls to this position to give proper feedback. It's basic functionality coming from the widgetery. => NAB
(In reply to Heiko Tietze from comment #5) > The Stylist is a single-selection tree where one node is always selected. It doesn't have to have one node always selected. It could be a single-selection tree in which _at most_ one node is selected. Also, that's only one of two options for resolving this bug. > After deleting the selected node the currently active style becomes > selected. And by default the tree scrolls to this position to give proper > feedback. How is that feedback in any way proper? Typically, the focused element's style has not even changed, and the selected item before the deletion was not the active one. So how is such feedback in any way related to what the user has just done? No, this is _improper_ feedback. Wrong feedback. A bug.
(In reply to Eyal Rozenberg from comment #0) > When one deletes a style, the style side-bar refocus / rescrolls to the > style of the currently selected object. This, even if one has scrolled away > from it to delete a certain style. Not sure, what the your use case is, but my use case is that I want to delete somme styles (for example "Contents" 1 to "Contents 10"). I can select them all but can't delete them at once. So deleting each style separetely is very time consuming, if scrollbar always jumps to the active style. Eyal, if you have a similar use case in mind, wouldn't it a solution to have the possibility to delete all selected styles at once (at least, if they are not i use)?