Bug 120985 - Toolbar: Remove oleobjectbar.xml and use frameobjectbar.xml
Summary: Toolbar: Remove oleobjectbar.xml and use frameobjectbar.xml
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha1+
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Writer-Toolbars
  Show dependency treegraph
 
Reported: 2018-10-28 12:04 UTC by andreas_k
Modified: 2020-11-09 16:23 UTC (History)
5 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 andreas_k 2018-10-28 12:04:10 UTC
In Writer frame.xml is used for frames and image Toolbar menu and for OLE Objects there is an additional toolbar file oleobject.xml 

The difference between oleobjectbar.xml and frameobjectbar.xml are ChainFrames and  UnhainFrames. As frameobjectbar.xml is used also for graphic (where unChainFrames didn't work) I suggest to have ONLY ONE toolbare (frameobjectbar.xml) for graphic, frame and OLE.
Comment 1 Maxim Monastirsky 2018-10-28 13:47:01 UTC
Added Bug 87362 to 'See Also', as it wants the opposite. When we decide which one to follow, the other one should be probably closed as WONTFIX.

Also I wonder whether according to this bug we should do the same for context menus, as frame.xml and oleobject.xml are identical (except the additional separator at the bottom of oleobject.xml, but if needed I can add this separator from the code, instead of hard-coding it in the xml file)?
Comment 2 V Stuart Foote 2018-10-28 15:39:54 UTC
Wait, bug 83762 didn't really want the opposite. Rather just to consolidate the two separate toolbars for Image shell with the Frame shell, and to present images/graphics with just the single context toolbar as is done for OLE?

But as here if they all (Image/graphic, OLE, Frame) can be handled from a common contextual toolbar, assuming all appropriate controls remain, great! 

Whichever results in simpler code to maintain... right?
Comment 3 andreas_k 2018-10-28 18:10:27 UTC
When I'm finished with context toolbars (popupmenu) and toolbars I'd like to talk about what can be removed cause it's not really needed.

I'm always for as less code as possible.
Comment 4 Maxim Monastirsky 2018-10-28 19:51:24 UTC
(In reply to V Stuart Foote from comment #2)
> Wait, bug 83762 didn't really want the opposite.
It is, and I'll explain why:

> Rather just to consolidate
> the two separate toolbars for Image shell with the Frame shell, and to
> present images/graphics with just the single context toolbar as is done for
> OLE?
Right. While this bug wants to continue using the generic frame toolbar for images (which means also keeping the second image-specific toolbar, see below), and also do the same for ole objects by *removing* the dedicated ole toolbar. If that's not opposite, I don't know what it is.

> But as here if they all (Image/graphic, OLE, Frame) can be handled from a
> common contextual toolbar, assuming all appropriate controls remain, great! 
No they can't be handled from a common toolbar. You can't add image related commands to the generic frame toolbar, as it shows also when selecting a frame, so then it will be full of useless disabled items. So using the generic frame toolbar for images necessarily means keeping the second image-specific toolbar.
Comment 5 andreas_k 2018-10-28 20:05:42 UTC
The graphic specific toolbar as second toolbar is needed, yes. Only the first toolbar should be the same in ole, graphic and frame. as they are the same exclude the chain actions.
Comment 6 Heiko Tietze 2020-11-09 16:23:43 UTC
Resolving this request as WF as bug 87362 was implemented.