Created attachment 54520 [details] Normal RTL UI When using an RTL UI the toolbar icons start from the right (e.g. the standard toolbar). But when inserting an LibO OLE object and editing it, the button order changes to the one of the LTR UI, although the menu line is still in the correct order. Notice the location of the help button on the standard toolbar in the screenshots attached (taken from writer). When in writer the button is on the left side (as the last button when started from the right, due to the RTL UI). But when in OLE (writer object inserted to draw), the help button is on the right side, as it is on LTR UI.
Created attachment 54521 [details] RTL UI when in OLE editing mode
[Reproducible] with "LibreOffice 3.4.5 RC1 - WIN7 Home Premium (64bit) Arabic UI [Build ID: OOO340m1 (Build:501)]" and with Parallel Dev-Installation of "LibreOffice 3.5.0 Beta1 - WIN7 Home Premium (64bit) Hebrew UI [Build-ID: 7362ca8-b5a8e65-af86909-d471f98-61464c4] Windows_Release_Configuration 11-Dec-2011 06:51" All toolbars switch from RTL to LTR view when edit mode for OLE object starts Steps to reproduce: 1. open attached Sample.odg with LibO RTL UI setting Observe icon sort order in toolbars 2. Double click Test OLE object in document Expected: Icon sort order in Toolbars remains RLT Actual: Icon sort order in Toolbars switches to LTR Of course you can continue work, but hat is a very ugly effect; I would nominate this bug as a "Most Annoying" one.
Even weirder behavior in OLE edit mode, is that floating toolbar movement is opposite. If I try to drag a floating toolbar left, it moves right (!). When it's dock to the right border, and I want undock it, dragging it left doesn't help only dragging it right does (de facto dragging it outside of the LibO window). Seems that something is very wrong with calculating the location of the toolbar.
DUP of "Bug 42577 - RTL UI [AR] toolbar view mirrored (docking and expand at the wrong side) when Insert Object Formula"?
Bug 42577 reports about the same problem in a different situation, but I wouldn't mark them as duplicate without know the problem comes from the same code.
Also happens in 3.5.4 (Debian, 64bit).
Abdulmajeed Al-Abaulrazzaq committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa61177f1d339422acb3322c8851962cd1ca7466 fdo#43901 & fdo#42577 RTL tollbars mirroring & fdo#56412 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified fix on a private build. I can't believe it's only a one line change.
Abdulmajeed Al-Abaulrazzaq committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b8a3c7d71255adc58cb254fca180ca374ae4b516&g=libreoffice-3-6 Resolves: fdo#43901 and fdo#42577 RTL tollbars mirroring It will be available in LibreOffice 3.6.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.