Bug 148432 - Navigator never presents an RTL tree for RTL documents
Summary: Navigator never presents an RTL tree for RTL documents
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.4.0
Keywords:
Depends on:
Blocks: Navigator RTL-UI
  Show dependency treegraph
 
Reported: 2022-04-06 22:05 UTC by Eyal Rozenberg
Modified: 2022-06-04 06:36 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
screenshot when the LANG is he_IL-UTF8 (159.50 KB, image/png)
2022-04-25 15:38 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2022-04-06 22:05:59 UTC
Navigator presents the trees for various categories, e.g. Headings, fully in LTR. This, even if the entire document is RTL: Default page style, Heading N styles, Default Paragraph Style, the works.

For "RTL documents" (defining that as one will), either the entire tree, or at least the subtrees of: Headings, References, Bookmarks, Tables, Indices, Comments, Footnotes and Endnotes - should be RTL.

Note that the effect of the current state of affairs is, that if your Navigator is not very wide, you are likely to not be able to see the numbers and the first several words of headings, bookmarks, etc. - which is exactly the content you _must_ see to understand what item this is.


This is somewhat similar to the issue of the Cross-Reference dialog hierarchy of items.
Comment 1 Dieter 2022-04-23 04:50:28 UTC
Eyal, thank you for the report. Looks like an enhancement request to me. Sounds reasonable to me. Heiko, Jim, what do you think?
Comment 2 Heiko Tietze 2022-04-25 09:37:56 UTC
Eyal, how do trees look like in other RTL applications? For example the file browser.
Comment 3 Eyal Rozenberg 2022-04-25 13:26:14 UTC
(In reply to Heiko Tietze from comment #2)
> Eyal, how do trees look like in other RTL applications? For example the file
> browser.

Can you clarify the question?

If you're asking how other applications behave with wholly-RTL documents, the answer is - I don't think I even use other applications which edit documents with a specific document-level directionality.

File browsers don't have some strong directionality of anything, certainly not an inherited one.
Comment 4 Heiko Tietze 2022-04-25 14:30:35 UTC
(In reply to Eyal Rozenberg from comment #3)
> Can you clarify the question?

I can imagine and agree that it would be desirable. Asked just out of curiosity how it looks.

Trees with a deep hierarchy are discouraged in general and for less complex layouts a list is recommended. So I wonder if the tree implementation support RTL anyway. Haven't found any example for Gtk.

The request is not limited to the Navigator but also relevant for the Stylist, for example.
Comment 5 Caolán McNamara 2022-04-25 15:38:43 UTC
Created attachment 179762 [details]
screenshot when the LANG is he_IL-UTF8

My understanding is that all those UI things follow the UI Language rather than the document language so for me with

LANG=he_IL.UTF-8

(and the hebrew langpack installed)

then I get the above, where for at least the gtk case I have an apparently RTL navigator treeview
Comment 6 Eyal Rozenberg 2022-04-25 17:48:48 UTC
(In reply to Caolán McNamara from comment #5)
> My understanding is that all those UI things follow the UI Language rather
> than the document language 

Yes. But - this becomes a problem when you fill up the UI with document content - which is what happens in Navigator. It also happens in the xref dialog (bug 131725). 

The worst part of it is how you get the ends of labels rather than the beginning of labels.
Comment 7 Caolán McNamara 2022-04-25 18:50:37 UTC
I'm not sure there is a general solution when using the LTR UI to get good outcomes in the dialogs with such lists of RTL text. It is possible to override the direction of individual widgets but in the general case the text that will appear in the list is arbitrary. One could try and bubble the "document language" around the place and override default direction based on that, but its a big amount of UI to attempt to try and tackle that widget by widget
Comment 8 Eyal Rozenberg 2022-04-25 19:40:44 UTC
(In reply to Caolán McNamara from comment #7)
> but its a big amount of UI to attempt to try and tackle that widget by
> widget

But almost no LO UI needs this. I currently know of two places. Maybe you can find another example or two.
Comment 9 QA Administrators 2022-04-26 03:41:24 UTC Comment hidden (obsolete)
Comment 10 Hossein 2022-04-26 08:06:53 UTC
(In reply to Heiko Tietze from comment #4)
> I can imagine and agree that it would be desirable. Asked just out of
> curiosity how it looks.
> 
> Trees with a deep hierarchy are discouraged in general and for less complex
> layouts a list is recommended. So I wonder if the tree implementation
> support RTL anyway. Haven't found any example for Gtk.
Gtk and Qt themselves provide support for RTL trees. Are you talking about VCL implementation?

For example, compile examples for GtkTreeView:
    https://docs.gtk.org/gtk3/treeview-tutorial.html

but add this line:
    gtk_widget_set_direction(view, GTK_TEXT_DIR_RTL);

> The request is not limited to the Navigator but also relevant for the
> Stylist, for example.
This is correct.

I think the RTL layout for the trees would be desirable, but the problem would be mixed LTR RTL contents that happens because of the untranslated English text.
For MS Word, even the style names are translated, so the output ins nice looking, but when the style names are English, the result is not always visually attractive.
Comment 11 Heiko Tietze 2022-04-26 08:25:13 UTC
As Caolan I expect RTL control when the UI language is set respectively.
Comment 12 Hossein 2022-04-26 11:42:04 UTC
An example from the other office suites, in Arabic:
https://answers.microsoft.com/en-us/msoffice/forum/all/word-2013-navigation-pane-for-arabic-headings/822a7ad2-9a94-48fa-90e7-15e034dec6a5

As you can see, "Heading 1" is translated into "عنوان 1".
Comment 13 Eyal Rozenberg 2022-04-26 17:32:03 UTC
(In reply to Hossein from comment #12)
> An example from the other office suites, in Arabic:

With LTR UI, the tree is partially-LTR, partially RTL:

* (LTRish) Expansion controls are on the left
* (RTLish) Alignment is to the right, extra space is to the left
* (RTLish) One sees the right part of the tree item text, with "..." on the left
Comment 14 Caolán McNamara 2022-04-28 18:53:37 UTC
wrt comment #8 if there was only two places where this was wanted I could see it as practicable to implement. Widget::set_direction exists to override the default UI direction for a widget so that capability exists. Possibly worth exploring.
Comment 15 Eyal Rozenberg 2022-04-28 19:32:58 UTC
(In reply to Caolán McNamara from comment #14)
> if there was only two places

You can check... the relevant criterion is inserting runs of text from the document into the UI. Obviously that's not done often.
Comment 16 Caolán McNamara 2022-04-28 19:55:09 UTC
Maybe table of contents dialog? and some bookmark/index selecting dialogs, not sure off the top of my head but presumably of lesser importance than the already mentioned cases.
Comment 17 Caolán McNamara 2022-04-29 15:17:09 UTC
well, we can give https://gerrit.libreoffice.org/c/core/+/133646 a shot which for the document in https://bugs.documentfoundation.org/show_bug.cgi?id=131725 would give a RTL treeview in an otherwise LTR UI which allows exploring that idea for a while at least.
Comment 18 Eyal Rozenberg 2022-04-29 16:44:51 UTC
(In reply to Caolán McNamara from comment #16)
> Maybe table of contents dialog? 

Nope, you don't get actual document content in there.

> some bookmark/index selecting dialogs,

Bookmark - that's the XRef dialog, isn't it? And index is the ToC dialog.
Comment 19 Commit Notification 2022-04-30 09:51:33 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/84ad4fe061ebfbbcdc0ffeec329e117250627157

tdf#148432 in LTR UI override the navigator treeview direction for RTL doc

It will be available in 7.4.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.
Comment 20 Caolán McNamara 2022-05-05 13:38:47 UTC
Now in a LTR UI if the document is RTL (where I decided to use the direction of the first page style to determine that) the navigator content list is RTL (the cross reference dialog also does similar now)