Checklist
Is your feature request related to a problem?
I need to be able to query for text direction given the current user's locale, to express visual hierarchy in a way that is intuitive to the user. I know that RTL text support is ongoing, based on #90 being in an open state, so this might already be in the works and just not released yet.
I'm opening a separate issue because this isn't specifically about text layout, but more general visual layout that is informed by text direction. The specific use-case in mind is using the CustomPaddedLayout to indent a set of elements to show a visual hierarchy. In that case, text direction dictates to which side that padding should be applied to conform to reader expectations.
Is it possible to construct a solution with the existing API?
It's possible to get the current locale string, but Fyne doesn't provide a means to query the text direction that locale implies. The solution remaining is for the application to maintain a set of Locale (base) strings for known/supported RTL languages, and check against that. It seems like this is something that will already be needed internally for RTL support in Fyne, so I wanted to bring it up as an additional facet of a planned feature set so applications can react to it when making layout choices outside of text layout too.
Describe the solution you'd like to see.
It seems like there are at least a couple different solutions. The preferred solution would be adding a method to Locale that returns an enum value indicating text direction. This would encourage a consistent source for locale dependent decisions and seems consistent with existing conventions.
Looking at x/text/unicode/bidi for prior representation, it looks like LeftToRight and RightToLeft are defined, and a couple more that are dependent on a given text string. Since the expected text direction for a given Locale isn't dependent on specific text, it makes the most sense to me - for this case - to just define LeftToRight and RightToLeft. It looks like these values could live alongside the other text enums (TextAlign, TextTruncation, TextWrap) as a new TextDirection type in the base fyne package for ease of discovery without risk of import cycles.
Since mixed direction support is called out in the RTL support issue, it seems like there are at least two distinct cases for understanding text direction: locale default direction and text dependent direction. This might lead us to conclude that a single type should describe both cases, but I think that could lead to some ambiguity/confusion about the range of values that a method like Locale.TextDirection() could return. It seems like this is a case where the answer depends on the specific question being asked, and it might be better to express these concepts separately as distinct enums. Maybe something like TextDirection and TextLocaleDirection to be clear about what is being described. The former could describe text direction derived from text, while the latter could be the expected text direction derived from the Locale.
Checklist
Is your feature request related to a problem?
I need to be able to query for text direction given the current user's locale, to express visual hierarchy in a way that is intuitive to the user. I know that RTL text support is ongoing, based on #90 being in an open state, so this might already be in the works and just not released yet.
I'm opening a separate issue because this isn't specifically about text layout, but more general visual layout that is informed by text direction. The specific use-case in mind is using the CustomPaddedLayout to indent a set of elements to show a visual hierarchy. In that case, text direction dictates to which side that padding should be applied to conform to reader expectations.
Is it possible to construct a solution with the existing API?
It's possible to get the current locale string, but Fyne doesn't provide a means to query the text direction that locale implies. The solution remaining is for the application to maintain a set of
Locale(base) strings for known/supported RTL languages, and check against that. It seems like this is something that will already be needed internally for RTL support in Fyne, so I wanted to bring it up as an additional facet of a planned feature set so applications can react to it when making layout choices outside of text layout too.Describe the solution you'd like to see.
It seems like there are at least a couple different solutions. The preferred solution would be adding a method to
Localethat returns an enum value indicating text direction. This would encourage a consistent source for locale dependent decisions and seems consistent with existing conventions.Looking at x/text/unicode/bidi for prior representation, it looks like
LeftToRightandRightToLeftare defined, and a couple more that are dependent on a given text string. Since the expected text direction for a givenLocaleisn't dependent on specific text, it makes the most sense to me - for this case - to just defineLeftToRightandRightToLeft. It looks like these values could live alongside the other text enums (TextAlign,TextTruncation,TextWrap) as a newTextDirectiontype in the basefynepackage for ease of discovery without risk of import cycles.Since mixed direction support is called out in the RTL support issue, it seems like there are at least two distinct cases for understanding text direction: locale default direction and text dependent direction. This might lead us to conclude that a single type should describe both cases, but I think that could lead to some ambiguity/confusion about the range of values that a method like
Locale.TextDirection()could return. It seems like this is a case where the answer depends on the specific question being asked, and it might be better to express these concepts separately as distinct enums. Maybe something likeTextDirectionandTextLocaleDirectionto be clear about what is being described. The former could describe text direction derived from text, while the latter could be the expected text direction derived from the Locale.