Writer persists the user's choice of active sidebar deck, between app sessions. If you: 1. Choose the Find deck in Writer 2. Close LibreOffice entirely 3. Start Writer you'll get an empty document with the Find sidebar deck. That is silly and not useful to the user. If a new document is created, and Find is the persisted SB deck choice - we should revert to something else (Properties? Styles?)
Confirm the behavior, but don't agree that persistence between launches is incorrect. At one point we'd requested a default launch opening to the Styles deck (bug 65361) rather than Properties. That we now persist was UX requested by users as for bug 67770 where active Sidebar state is recorded to user profile as "LastActiveDeck" since the 5.1.0 release, tweaked at 6.0.0 I don't think we'd gain anything by blocking a restore of the SB 'Find' deck, and users certainly have a preference to either 'Properties' or 'Styles' depending on their workflows. IMHO => WF
(In reply to V Stuart Foote from comment #1) > Confirm the behavior, but don't agree that persistence between launches is > incorrect. Persistence in general is fine, but not _this_ persistence. It is a safe assumption that the user does not want a Find sidebar in an empty document. > I don't think we'd gain anything by blocking a restore of the SB 'Find' > deck, We would gain something - because this is an example of "application mocks user by doing something it knows they don't want" - and when that happens, the user develops a bit of resentment towards the app, and the project. On the other hand, selecting a different sidebar deck would not have that effect; and, in fact, we may also want to consider simply collapsing the sidebar in such cases.
(In reply to Eyal Rozenberg from comment #2) > (In reply to V Stuart Foote from comment #1) > > Confirm the behavior, but don't agree that persistence between launches is > > incorrect. > > Persistence in general is fine, but not _this_ persistence. It is a safe > assumption that the user does not want a Find sidebar in an empty document. > Yes an empty Find SB deck on opening a new document could probably be avoided, simple check if new then default to Properties deck. But what of folks who open and close a document repeatedly as they work on something else. Their work flow is well served with restore of the SB Find deck, and honnoring the "LastActiveDeck" > > I don't think we'd gain anything by blocking a restore of the SB 'Find' > > deck, > > We would gain something - because this is an example of "application mocks > user by doing something it knows they don't want" - and when that happens, > the user develops a bit of resentment towards the app, and the project. > BS! > On the other hand, selecting a different sidebar deck would not have that > effect; and, in fact, we may also want to consider simply collapsing the > sidebar in such cases. Sidebar already collapses if that was that state it was closed in. Whole purpose of bug 67770 was to make the SB Deck stateful per user profile, so as to not end up on the Properties deck. Simple for a user to toggle to a different deck of their preference before closing the module--we provide kb accelerators and GUI to do so.
(In reply to V Stuart Foote from comment #3) > Yes an empty Find SB deck on opening a new document could probably be > avoided, simple check if new then default to Properties deck. > > But what of folks who open and close a document repeatedly as they work on > something else. Their work flow is well served with restore of the SB Find > deck, and honnoring the "LastActiveDeck" And that work flow should indeed be respected. How would that contradict the suggestion above? Now, you could ask me "what about when a person alternates between opening an existing document and creating a new one?". To that I'll say: * If they expect persistence of SB deck choice across sessions of using the LO module, then they wouldn't mind, because they also expect the exception to that persistence, which is not insisting on Find for an empty document; * and if they expect persistence of the SB deck choice across editing sessions of the _same document_ - that would be an interesting feature request, but IIANM, is not something we support right now. > > We would gain something - because this is an example of "application mocks > > user by doing something it knows they don't want" - and when that happens, > > the user develops a bit of resentment towards the app, and the project. > > > > BS! Wow, very convincing argument, why didn't I think of that?
(In reply to Eyal Rozenberg from comment #2) > It is a safe assumption that the user does not want a Find sidebar... Still an assumption and not so safe, IMO. Open Writer, paste text, check if <Foo> exists, close - and repeat. Or start Writer, open MRU #1 (alt+F+U+1), and continue the previous task. Why only switch for Find, wouldn't the Style Inspector be irrelevant for new documents too? Or the a11y checker?
(In reply to Heiko Tietze from comment #5) > Why only switch for Find, wouldn't the Style Inspector be irrelevant for new > documents too? Or the a11y checker? Well, TBH I filed this bug because I noticed this happening with the Find deck. But - there is a difference. The Find bar doesn't become interesting until you have enough content in the document to not fit in the viewport; but the a11y checker and the Style inspector are usable and useful already when you have a few words or lines on the page. So, it is not safe to assume that the user has no need for them when creating a new document.
I reported this bug some years ago and was closed as not a bug.
(In reply to BogdanB from comment #7) > I reported this bug some years ago and was closed as not a bug. 1. Link? 2. You could have reopened it and/or asked other people to weigh in on the matter and/or marked it needUXAdvice to have it come up in a design meeting... that's what I do when people close my bugs without a decent justification.
This bug: https://bugs.documentfoundation.org/show_bug.cgi?id=126554
I can live with this bug, others are more annoying. For other users this can be a useful thing: when you have hundreds of documents and need to replace a term in each one, is very useful to have the Quick find available and use it.
(In reply to BogdanB from comment #7) > I reported this bug some years ago and was closed as not a bug. Did you mean the Find Bar issue of bug 126554? If so, completely different part of the code. SB has its own control framework, different to normal TB behavior like the Find bar. Issue here is about what was implemented, correctly I'll repeat, for bug 67770 with each SB deck eligible to receive the controlling "LastActiveDeck" assignment recorded to user profile. Enhancement of additional control logic (for opening a new empty document) is possible, but it otherwise functions as designed/implemented.
(In reply to V Stuart Foote from comment #11) > Enhancement of additional control logic (for opening a new empty document) > is possible, but it otherwise functions as designed/implemented. "As designed" can still be a bug: A bug in the design. But on this one, if someone believes strongly that this is more of an enhancement request than a bug, I won't argue over the designation. I did mark this as "trivial" after all.
(In reply to BogdanB from comment #9) > https://bugs.documentfoundation.org/show_bug.cgi?id=126554 So, that one was about the Ctrl+F search bar, while this is about the sidebar deck choice. Those are related naturally, but the persistence considerations are kind of different IMNSHO. > For other users this can be a useful thing: when you have hundreds of > documents and need to replace a term in each one, is very useful to have the > Quick find available and use it. Let's talk about that usage scenario; perhaps I've neglected to think about something. So, suppose I have those hundreds of documents. If I open one of them, use the Find bar, close it, and open the next - then of course the Find sidebar deck can be restored on document open. But - can you explain why it would help if the Find sidebar also persisted when creating a new document?