Bug 60411 - CONFIGURATION: Active toolbars not remembered after reopening
Summary: CONFIGURATION: Active toolbars not remembered after reopening
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: needsDevEval, topicUI
: 101574 116033 127609 (view as bug list)
Depends on:
Blocks: Toolbars
  Show dependency treegraph
 
Reported: 2013-02-07 11:23 UTC by mrmister001
Modified: 2020-04-30 19:41 UTC (History)
8 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 mrmister001 2013-02-07 11:23:44 UTC
Problem description: 
If I go to View... Toolbar... and I select a toolbar, for example 3D settings, the toolbar is shown...
If I select the image toolbar it is show... but when I close writer and I open it again, it doesn't remember thouse toolbars and force me again to open them
this is annoying because if I normally work with pictures in the document, it is forcing me to open the toolbar everytime I open writer, which is a royal pain.

Steps to reproduce:
1. Go to Writer and open some toolbars, for example 3d settings and the image toolbar
2. Close Writer
3. Open Writer, you'll see the toolbar is not remembered and force you to configure again the toolbar to be shown

Current behavior:
Writer don't remember the toolbars I've selected to be shown

Expected behavior:
When I tell Writer to show a toolbar is because I like that toolbar and I expect Writer show it, and when it close, remember that toolbar to be shown next time
if I configure something is because I want that stay in that way and remember the configuration, that is the normal thing... but writer don't remember the configuration of the toolbars and even if you want to show them, it doesn't remember the toolbars you want to be shown next time

              
Operating System: Windows 7
Version: 4.1.0.0.alpha0+ Master
Comment 1 Jorendc 2013-02-07 16:37:34 UTC
Thanks for reporting. I can confirm this behavior using Linux Mint 14 x64. Because this is not yet a 'feature' I mark this as enhancement request.
Comment 2 Jorendc 2013-02-07 22:23:18 UTC
*** Bug 60436 has been marked as a duplicate of this bug. ***
Comment 3 Nisse Nordin 2013-02-08 08:08:15 UTC
I found a workaround for this regression, so I can at least *close* toolbars now  as explained in Bug 60436.

Workaround:
0. Create a new LibO Writer/Calc document.
1. Open some other toolbar that are docked to the window (like Find).
2. Close the window.
3. Create a new LibO Writer/Calc document.
4. Close the new toolbar and the Standard toolbar.
5. Close the window.
6. Create a new LibO document.
Comment 4 Michael Stahl (allotropia) 2013-08-29 15:36:00 UTC
So i've played around with Writer and the following
toolbars are remembered in all versions i've tried
(from OOo 3.3 to current master):

Align
Drawing
Find
Form Controls
Form Design
Formatting
Insert
Standard
Tools

not remembered in any version:

3D Settings
Bullets and Numbering
Drawing Object Properties
Fontwork
Form Navigation
Frame
Media Playback
OLE Object
Picture
Standard (Viewing Mode)
Table
Text Object
Formula

OOo 3.3 and 3.4beta used to have an additional HyperlinkBar (remembered).

LO 3.4.6 and later has an additional "Navigation";
in 3.4.6 it was remembered but not in 3.5.7.2 or later versions.

LO 4.0.5.2 and later has an additional "Logo" (not remembered).

so... this is mostly a pre-existing problem, except for:

- Navigation not remembered is a regression for which separate bug 64856 exists

- bug 60436 appears not at all a duplicate of this since the
  reporter claims it started in LO 4.0 (alas i can't reproduce it)

=> removing "regression"

i have a suspicion that a lot of the non-remembered toolbars
are somehow "context sensitive", e.g. you only see Table
if the cursor is actually in a table.

now, the question i have for our UX people is whether there are any
toolbars that should have their visibility state remembered but
currently don't?
Comment 5 Scott 2013-09-06 20:30:36 UTC
This doesn't appear to be fixed yet in 4.1.1.  Is there any ETA on the fix?
Comment 6 Norbert X 2014-10-04 11:59:08 UTC
I think I saw this bug in 4.3.2

I'll copy my comment from https://bugs.freedesktop.org/show_bug.cgi?id=81475#c23 here:

I think that dynamic appearance/disappearance of toolbars is not a good idea.

For me it is comfortable to place toolbars once and use them when I want to use them, not contextually (current object- or action- dependent).
But now in 4.3.2 toolbars disappear even if they have Lock Toolbar Position option checked. Please enable static toolbar positions. 

Popping toolbars may cause attention switch and may lower document author's productivity. Otherwise you will create another stupid, ugly, non-usable Ribbon/MFI. I think that many LibreOffice users would be happy with MS Office 2003-like interface.

Users do not need bells and whistles, they need comfortable and customizable interface. This interface should allow users to place and pin (lock) toolbars as they want and use keyboard shortcuts for more productivity (for example, the fastest way to add Cross-Reference is to press <Alt-i><e>).
Comment 7 Scott 2015-08-07 17:24:44 UTC
Still a bug in 5.0.0.5.  Any status update on when a fix will happen?
Comment 8 Yousuf Philips (jay) (retired) 2015-08-09 18:44:47 UTC
(In reply to Norbert X from comment #6)
> I think that dynamic appearance/disappearance of toolbars is not a good idea.

There isnt another toolbar means of accessing functions for contextual content than with contextual toolbars, but its important to try and reduce the need of the contextual toolbars from changing the appearance of the document view if possible.

> For me it is comfortable to place toolbars once and use them when I want to
> use them, not contextually (current object- or action- dependent).

Yes that maybe a useful option for advanced users, but not for basic users. Advanced users in the QA team have mentioned that they disable the appearance of contextual toolbars like the table toolbar.

> But now in 4.3.2 toolbars disappear even if they have Lock Toolbar Position
> option checked. Please enable static toolbar positions. 

Locking a toolbar position is different that disabling it from being context sensitive. I checked 3.6.7 and it acts no different.

> Popping toolbars may cause attention switch and may lower document author's
> productivity. Otherwise you will create another stupid, ugly, non-usable
> Ribbon/MFI. I think that many LibreOffice users would be happy with MS
> Office 2003-like interface.

Yes one of the reasons why MS created the ribbon was due to the ever increasing number of toolbars and the toolbars popping up all over the UI, so users had to go to multiple areas of the UI to access functions. Didnt quite follow when you mentioned that users wouls like an MSO 2003-like interface, as that is what LO has.

> Users do not need bells and whistles, they need comfortable and customizable
> interface. This interface should allow users to place and pin (lock)
> toolbars as they want and use keyboard shortcuts for more productivity (for
> example, the fastest way to add Cross-Reference is to press <Alt-i><e>).

I would suggest that you submit a new enhancement report for being able to disable contextual behaviour of toolbars if a user chooses. This should be possible as the xcu window state files have entries like.

<prop oor:name="ContextSensitive" oor:type="xs:boolean">
  <value>true</value>
</prop>
Comment 9 Robinson Tryon (qubit) 2015-12-14 06:09:46 UTC Comment hidden (obsolete)
Comment 10 Buovjaga 2016-09-17 21:02:07 UTC
*** Bug 101574 has been marked as a duplicate of this bug. ***
Comment 11 Buovjaga 2018-03-08 14:24:17 UTC
*** Bug 116033 has been marked as a duplicate of this bug. ***
Comment 12 Xisco Faulí 2020-03-09 13:29:02 UTC
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
Comment 13 Buovjaga 2020-04-30 19:41:58 UTC
*** Bug 127609 has been marked as a duplicate of this bug. ***