When both Asian and RTL-CTL languages are enabled, and the font selection dialog is opened, on one side it has two tabs, one for Asian and one for RTL-CTL. The thing is, even though I'm using a document with only Western and RTL content, and have not made any CJK-related settings to any of its styles, and my keyboard layouts don't include CJK - I still get the Asian tab visible by default and the RTL-CTL tab hidden. Instead, some kind of heuristic should be applied for choosing which tab is visible/selected when the window opens. * The tab choice could simply persist. * The keyboard layout could be taken into account. * The element to which the dialog relates could be checked for presence of RTL vs Asian content ... or some combination of the above.
The dialog layout was changed for bug 146928 to make it fit on small screens. No objections to put effort into storing user data.
I disagree. Enabling Asian support means user is interested in respective options/properties. So showing the properties should be independent on any file content / system configuration in this case. E.g., one could want to configure a template to be used in a team, and while the author could not have a configured input or Asian content, they may want to define the formatting that their Asian colleagues will use. If the shown elements confuse users, their placement need to be re-considered again, so that their presence would be OK.
(In reply to Heiko Tietze from comment #1) > The dialog layout was changed for bug 146928 to make it fit on small > screens. No objections to put effort into storing user data. So, you support using persistence for this? Do you believe it's better than the alternatives or are you just saying that it's an acceptable option? (In reply to Mike Kaganski from comment #2) > I disagree. Disagree with what part of what we said? :-( > Enabling Asian support means user is interested in respective > options/properties. So showing the properties should be independent on any > file content / system configuration in this case. Yes, but that's true for RTL-CTL as well. Is the user's interest in CJK always stronger than their interest in RTL-CTL? If the user enabled both, they will sometimes work on RTL-mostly documents, and will want to see the RTL font first and foremost; and sometime work on CJK-mostly documents and will want to see the CJK font first and foremost. > If the shown elements confuse users, their placement need to be > re-considered again, so that their presence would be OK. This bug is about convenience vs. hassle, not confusing vs clarity.
(In reply to Eyal Rozenberg from comment #3) > (In reply to Mike Kaganski from comment #2) > > I disagree. > > Disagree with what part of what we said? With the proposal from comment 0, given the absence of a specific reference, *obviously*. > > Enabling Asian support means user is interested in respective > > options/properties. So showing the properties should be independent on any > > file content / system configuration in this case. > > Yes, but that's true for RTL-CTL as well. Is the user's interest in CJK > always stronger than their interest in RTL-CTL? Given that we know each other, let me believe that your words were not an attempt to make me look bad, and you truly needed a "same for other groups" remark in my comment, which took your wording from comment 0 as an example... Still I don't believe that you couldn't guess that, so still clueless what was the purpose of this specific question. > If the user enabled both, > they will sometimes work on RTL-mostly documents, and will want to see the > RTL font first and foremost; and sometime work on CJK-mostly documents and > will want to see the CJK font first and foremost. Having something active is the usual approach when someone wants something "first and foremost", not hiding something else.
You know, just ignore me. It seems I can't read/comprehend. I better shut up, because you do not propose to remove anything, which was what I was disagreeing with.
(In reply to Eyal Rozenberg from comment #3) > So, you support using persistence for this? Do you believe it's better than > the alternatives or are you just saying that it's an acceptable option? To remember the last used state, at least during the current session, is acceptable and desirable. Besides, I don't think CTL + CJK is a frequent use case, we want to get rid of the trichotomy anyway, and last but not least heuristics that attempt to scry users activities is doomed.