Description: When we are in RTL direction, in tables icon for "Column after" and "Column before" is confusing and should be switch with the other one. Because in RTL direction, "Column after" will add a column to the left of current column and vice versa for "Column before". Steps to Reproduce: 1. Change direction to RTL 2. Add a table with on row and at least 3 cols 3. Click on Col 2 and click "Columns After" or "Columns Before" buttons Actual Results: 1. Change direction to RTL 2. Add a table with on row and at least 3 cols 3. Click on Col 2 and click "Columns After" or "Columns Before" buttons Expected Results: By clicking on "Columns After" it adds a column in left of current column and vice versa for "Columns Before". The function is true but the icons are wrong. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.3.4.2 Build ID: 30(Build:2) CPU threads: 4; OS: Linux 5.18; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 180978 [details] Screenshot of what is the case currently
Function commands for this icons are .uno:InsertColumnsBefore and .uno:InsertColumnsAfter. Once you click (and columns are added), does it matter if you later change from LTR to RTL? If the answer is NO (I know almost nothing about .uno commands, so, do not stone me if I ask something stupid): Why not change in the commands "Before" to "Leftward", and "After" to "Rightward"? Or add the commands .uno:InsertColumnsLeftward and .uno:InsertColumnsRightward, for macro backward compatibility. This way it works LTR and RTL, and there is no need to switch icons. (I wrote here yesterday, but it seems that I leaved without saving changes.) It is interesting to note that Amin wrote ..."Column after" and "Column before"... reflecting the RTL position.
As a user with Persian (Farsi) as native language, most of my documents are in RTL mode. So if I add a table in LTR mode within a RTL document makes a bad UX because all cursor movements will be reversed. I saw the Microsoft office word and it resolved this with a wise solution: Name of buttons are "Add to left" and "Add to right"; It handles the left and right wisely according to the direction. Left and Right always are understandable for user. I think this idea can make a better UX than everything else
Theoretically, we could mirror the icons horizontally. Is it worth the effort?
It is interesting that we have same problem with indentation buttons: 1. Increase indentation 2. Decrease indentation
(In reply to Amin from comment #3) > Name of buttons are "Add to left" and "Add to right"; It handles the left > and right wisely according to the direction. Left and Right always are > understandable for user. I think this idea can make a better UX than > everything else I support this suggestion.
Same issue in Calc, Draw, Impress (sometimes with slightly different labels). Changing Component to UI Note also that same label is used in context menu (e.g., in Writer, put cursor in table cell, right-click, choose Insert) => "Column to Left" for context label. In Draw/Impress -- Insert is used, but should be dropped in the context label, but maybe still appropriate for Table toolbar. (and maybe appropriate to add word "Insert" for Writer Table toolbar, and make "column" singular). Can use ContextLabel and TooltipLabel to get appropriate results. Calc looks slightly different.
Here is a proposed patch for Writer. https://gerrit.libreoffice.org/c/core/+/134359 Maybe it will give an idea to others for how to approach Draw/Impress (/core/officecfg/registry/data/org/openoffice/Office/UI/DrawImpressCommands.xcu) and Calc (/core/officecfg/registry/data/org/openoffice/Office/UI/CalcCommands.xcu).
I am marking this issue as "New", as I think this is a valid request, and is important for the users of the RTL languages. A detailed discussion on the bidirectional UI topic can be found in these links: Bidirectional Layouts in GTK+ http://behdad.org/download/Presentations/bidi-layouts/ Firefox-Photon-RTL-guidelines Public https://github.com/5y/Firefox-Photon-RTL-guidelines
(In reply to sdc.blanco from comment #7) > Note also that same label is used... I'm surprised that we got into the label-changing business when the request was about the icon. The idea of "Column/Row Before/After" was exactly to be independent from the direction. The icons, OTOH, have indicators coming from LTR reading direction. Don't see a generic solution via icon design (Rizal, please prove me wrong!). So it's rather a coding topic.
(In reply to Heiko Tietze from comment #10) > I'm surprised that we got into the label-changing business See comment 3. But after further experience, I now agree that "Before/After" should not be changed -- and understand that the solution requires either: (a) a redesign of the Before/After icons themselves so that they are direction-independent (if at all possible) and if not, then (b) a coding change to provide the correct icon to the "insert column" commands according to the "text direction" set in the table properties.
If mirroring is an acceptable solution, then this might work: https://gerrit.libreoffice.org/c/core/+/136818
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b0a3245c63a2f77ce761ebd11820b341969a48b4 tdf#149741 Mirror insert column icons for RTL tables It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Sorry I can not reproduce the issue in 7.3.4 nor 7.5.0 alpha. What's missing here? Could you please write up how to give me a more detailed steps how to "change direction to RTL"? Here's my steps: 1. Create a new Writer document 2. Go to Tools > Options > Language Settings > Language. In the Default Languages for Documents, I set Complex text layout to Arabic (Saudi Arabia) 3. Click Apply > Click OK 4. Click Right-to-Left (Ctrl+Shift+D) to switch to RTL Are these steps OK? (In reply to Amin from comment #0) > Steps to Reproduce: > 1. Change direction to RTL
(In reply to Rizal Muttaqin from comment #14) > Could you please write up how to give me a more detailed steps how to > "change direction to RTL"? You need to click Right-to-Left (Ctrl+Shift+D) *before* inserting the table, or for existing table - right click > Table Properties... > Text Direction.
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9030f2aa632633dd4014d41bd81cdb3c1aca4cb2 related: tdf#149741 improve tooltips for adding Table rows and columns It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The solution is what Maxim said in comment 15: https://bugs.documentfoundation.org/show_bug.cgi?id=149741#c15 (In reply to Rizal Muttaqin from comment #14) > Sorry I can not reproduce the issue in 7.3.4 nor 7.5.0 alpha. What's missing > here? Could you please write up how to give me a more detailed steps how to > "change direction to RTL"? Here's my steps: > 1. Create a new Writer document > 2. Go to Tools > Options > Language Settings > Language. In the Default > Languages for Documents, I set Complex text layout to Arabic (Saudi Arabia) > 3. Click Apply > Click OK > 4. Click Right-to-Left (Ctrl+Shift+D) to switch to RTL > > Are these steps OK? > > (In reply to Amin from comment #0) > > > Steps to Reproduce: > > 1. Change direction to RTL
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4fb8c0d14cb2468f7336438004f699b9eb7e7e4a tdf#149741 tdf#149956 Make flipping work also in the sidebar It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I can see no change in Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: c3b5eea4304ad6815b491f549fce008a9630c213 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded Icons are still wrong.
(In reply to Dieter from comment #19) > I can see no change in SVG icons? See Maxim's patch comment: "One unsolved problem is the appearance of flipped icons with svg themes..."
(In reply to Dieter from comment #19) > I can see no change in > > Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community > Build ID: c3b5eea4304ad6815b491f549fce008a9630c213 > CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: > win > Locale: de-DE (de_DE); UI: en-GB > Calc: CL threaded > > Icons are still wrong. Seems to work for me. Did you follow the steps from comment 15? Also note that all this is just for Writer, as other modules don't yet implement icon flipping. (In reply to Heiko Tietze from comment #20) > (In reply to Dieter from comment #19) > > I can see no change in > > SVG icons? See Maxim's patch comment: "One unsolved problem is the > appearance of flipped > icons with svg themes..." svg icons should work too, it just that their appearance in the sidebar with the gtk backend might be blurry.
(In reply to Maxim Monastirsky from comment #21) > Seems to work for me. Did you follow the steps from comment 15? Also note > that all this is just for Writer, as other modules don't yet implement icon > flipping. Thanks for asking. It works with steps from comment 15 (sorry, I haven't used them), but it still doesn't work with Format -> Page Style -> Text direction: RTL (That's what I've tried in comment 19).
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9080200713292a200f2c6283f9c3f438411fc7d4 tdf#149741 Handle also inherited direction It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Can I see the result up to now? May be I can propose a feedback on it, if you want ;)
I believe this is fixed now.
@Amin: try https://dev-builds.libreoffice.org/daily/master/current.html to see what the fix looks like and maybe add a screenshot to this bug here so it is visible to all interested in the change. If everything is fine, please change the bug to verified.
(In reply to steve from comment #26) > @Amin: try https://dev-builds.libreoffice.org/daily/master/current.html to > see what the fix looks like and maybe add a screenshot to this bug here so > it is visible to all interested in the change. If everything is fine, please > change the bug to verified. Unfortunately the page is not accessible. It shows "Server not found"
(In reply to Amin from comment #27) > Unfortunately the page is not accessible. It shows "Server not found" For me the link works.
(In reply to Maxim Monastirsky from comment #25) > I believe this is fixed now. Yes. VERIFIED FIXED in Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9cd0f4c2d25462feba0ffcbd906c199273821243 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded Maxim, thanks for fixing it!
(In reply to steve from comment #26) > @Amin: try https://dev-builds.libreoffice.org/daily/master/current.html to > see what the fix looks like and maybe add a screenshot to this bug here so > it is visible to all interested in the change. If everything is fine, please > change the bug to verified. I tried and everything is perfect and works properly Thanks