Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: 1. Try to call setOrientation on a StyledText widget on MacOS. 2. Observe that nothing happens. 3. Step into code and find org.eclipse.swt.internal.BiDiUtil, which stubs out all attempts at BiDi on MacOS. 4. Fail to build presentable Hebrew/Arabic app for use on MacOS. More information:
SWT.RIGHT_TO_LEFT is used in SWT to mirror a control. Mac, as far as I know, doesn't support mirrored UI.
Mac applications in general support writing direction. I'm not asking for MIRRORING, just RIGHT_TO_LEFT and LEFT_TO_WRITE. Even the TextEdit application has it.
I know. I'm just telling you what RIGHT_TO_LEFT means in SWT. On platforms where RIGHT_TO_LEFT is implemented you get mirrored and RTL writing direction. We don't have a API that only changes the writing direction.
Hmm. Here's what I thought I was asking for with SWT.RIGHT_TO_LEFT in StyledText: 1) Initial Unicode Bidi context RTL. 2) Ragged-right text. This does involve any mirroring of coordinates, of course. Am I missing some existing way to achieve this state of affairs in a StyledText control? I could fake #1 with a RTL forcing character, but it's going to be painful to deal with the cursor implications of that, and I suppose that #2 is just plain SWT.RIGHT?
see StyledText#addBidiSegmentListener try to set the orientation to SWT.RIGHT_TO_LEFT and use the entire line as one big segnment. for #2 try SWT.RIGHT, note that only works when wrap is on. Let me know if it works.
I don't see how your prescription can work. In StyledText.setOrientation, there are no side effects that I can see if BidiUtil.setOrientation returns false, which it does. This seems odd, considering the following function: /** * Temporary until SWT provides this */ boolean isBidi() { return IS_GTK || IS_CARBON || BidiUtil.isBidiPlatform() || isMirrored; } The code in setOrientation sort of seems to be trying to distinguish isMirrored from RIGHT_TO_LEFT, but all the other style management code agrees with your analysis. e.g.: public int getStyle() { int style = super.getStyle(); style &= ~(SWT.LEFT_TO_RIGHT | SWT.RIGHT_TO_LEFT | SWT.MIRRORED); if (isMirrored()) { style |= SWT.RIGHT_TO_LEFT | SWT.MIRRORED; } else { style |= SWT.LEFT_TO_RIGHT; } return style; } I'm not seeing how I can make a BiDiSegmentListener do what I need here. I don't want to disassemble the line into separately reordered segments, I just want to change the 'outermost context' to be RTL. There isn't an 'orientation' in the event object, at least not in 3.4. I'm a bit surprised to hear that RIGHT is ignore without WRAP. Even without BiDi, why not support ragged-left text when not wrapping? People do use it for some things. I could turn on WRAP, I suppose, it won't hurt anything much.
i'm sorry, you are right. I should have tested the idea myself before posting it. I'm busy today. The way bidi segment is implemented it would insert the bidi control character for you. I afraid you will have to surrond your text with RTO and PDF yourself. see 135638 also (about alignment problems)
SWT.RIGHT|SWT.WRAP plus RLE/PDO is doing the job for me as of now. Since I'm currently read-only, it's not too awful. It would be pretty hard to keep this right in an editor with modifications happening. The question is, where do 'we' go from here? I quote 'we' because I'm not sure that I qualify here to have an opinion, let alone to submit a credible patch. On good old Windows, mirroring is completely distinct from text directionality. Mirroring has a special API, it is not for the faint of hear. Mirroring only effects coordinates, and directionality does nothing except alignment plus bidi context. In fact, Windows goes to a lot of trouble to avoid unwanted 'Leonardo daVinci' behavior with mirroring in GDI (Actually writing text backwards). Given that StyledText does not deal in coordinates, I wonder if the hard link between the two could be broken without horrible incompatibility? Alternatively, would it make sense to leave Orientation alone as referring to mirroring, and add a new style that asks for RTL initial context? This would have to be consistently handled in ordinary Text boxes. As a final cheap suggestion, a new interface on the Bidi listener that would allow the listener to specify the initial directionality for each identified segment? I'd make a patch for that if you felt that it would have some reasonable probability of being smiled upon.
(In reply to comment #8) > On good old Windows, mirroring is completely distinct from text directionality. Not true. Try setting WS_EX_LAYOUTRTL in control, a button or a label for example. Notice how the default paragraph direction is also changed right-to-left. As far as I know, you can't separate mirroring and text direction in win32 (without bidi control chars that is). Worse, try to draw text in a window with WS_EX_LAYOUTRTL set using a hDC without LAYOUT_RTL set. The other way around is also problematic. See Bug 64413
It's been over a year since I was immersed in SetProcessDefaultLayout. If the LAYOUTRTL style does the same thing that it does, then I'm just wrong. I'm used to thinking about mirrored coordinate management as distinct from RTL text direction. Which leaves the question: what model of RTL could SWT have that can map out to Mac?
(In reply to comment #10) > Which leaves the question: what model of RTL could SWT have that can map out to > Mac? On Mac, our current requeriment is to handle bidi text. The default paragraph direction on Mac is always left-to-right. I think what you need is Bug 64413, new API to set only the default paragrah direction (no mirroring with it). It was long time ago, but from what I remember it was quite hard to implement it on all platforms.
*** Bug 277449 has been marked as a duplicate of this bug. ***
Fixed in HEAD > 20091204 RIGHT_TO_LEFT on mac only changes the default paragraph level to 1, but it does not mirror the control.
In I20091207-1800/Cocoa, I can see the swapped orientation when I pass RIGHT_TO_LEFT in the constructor of StyledText, but setOrientation(..) doesn't change anything (with both directions).
(In reply to comment #14) > but setOrientation(..) doesn't change anything (with both directions). setOrientation only works on windows (this holds true for StyledText/Text/Combo).
