Bug 156093 - Option for RTL and LTR toggling
Summary: Option for RTL and LTR toggling
Status: RESOLVED FIXED
Alias: None
Product: kate
Classification: Applications
Component: kwrite (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: Diego Iastrubni
URL:
Keywords: rtl
Depends on:
Blocks:
 
Reported: 2008-01-18 12:22 UTC by Zayed Al-Saidi
Modified: 2012-10-26 12:36 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Kate with Hebrew UI, displayind a source code (75.52 KB, image/png)
2008-01-25 18:24 UTC, Diego Iastrubni
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zayed Al-Saidi 2008-01-18 12:22:14 UTC
Version:            (using KDE 4.0.0)
Installed from:    SuSE RPMs
OS:                Linux

After using kwrite (in kde 4.0) for a while, I miss the auto detecting for BiDi direction in Kedit. It so simple just write in Arabic and the direction will be RTL and write in English and the direction will be LTR whatever your language setting.  Now, the Kwrite substitutes the Kedit officially. Therefore I face a little difficulties in writing mixed RTL and LTR texts. 
I wish there will be a button in the toolbar to switch between RTL and LTR.
Comment 1 Diego Iastrubni 2008-01-25 17:11:32 UTC
Ahalan Zayed,

I have just commited a patch to Kate (it will be part of KDE 4.1) which forces the line number widget to be on the left. 

The next step will be determinate the LayoutDirection of each line, automagically (more LTR chars the line will have direction=ltr, more RTL chars, the line will have direction=rtl).
Then I will continue and draw RTL lines aligned to the right.
Finnally I will give the user an option to change the layout direction. 

If have ideas about the implementation, please append them to this bug. 

One thing I don't understand is where to put the line numbers widget. I do not want to put it on the right for RTL desktops, because it will mean that when editing code your head will explode! :)
Changing the location of the widget according to the direction of the current line, is not ideal, since on document with lines that have different direction, this will cause the widget to move from the right, to the left too much.
Comment 2 Diego Iastrubni 2008-01-25 18:24:29 UTC
Created attachment 23273 [details]
Kate with Hebrew UI, displayind a source code

As you can see, each line has a RTL direction which causes the application to
be unusable for editing code. This is my first priority.
Comment 3 Zayed Al-Saidi 2008-01-26 09:48:07 UTC
hi Diego

The idea to let the handling of text (i.e at least BiDi staff) is independent of the main window.  

The line numbers widget should be always in the left side. So yes you did the right thing thank you. 
Comment 4 Diego Iastrubni 2008-08-12 22:51:37 UTC
ok, lets make it better now -

My idea is:
1) if paragraph starts with ‎ -> it's LTR for sure
2) if paragraph starts with ‏ -> it's RTL for sure
3) If you press control+shift, you are sure you want to set the direction, and you should put that char in the beginning of that line/paragraph. If a previous direction has been set - kill it.
4) If no direction has been set (see 1,2), guess it by testing the amount of chars in that line (already implemented in KDE 4.1 and above). 

This will render the text the same in notepad/gedit and Kate. However, it feel a little ugly, as we manipulate the document in invisible ways. We should also consider the GtkSourceView guys to implement somthing similar, otherwise passing text documents around is a mess.

What do you think Zayed?
Comment 5 Zayed Al-Saidi 2008-08-13 15:15:17 UTC
Ok, let look to this issue form another angle. Let discuss this case: I use kwrite   to write an article which is in Arabic but consists some English word. Since it is in Arabic, it should be RTL mode even if I write English word in the beginning the line. Sometimes, I want to put a long English quotation about one paragraph in the article, so it nice if I can change the mode of that paragraph to LTR. After that I want resume in RTL mode. 
There for I suggest this solution:

1-The default setting is depending on the file itself. If Latin words are more  than 80%, then set the mode to LTR, else set the mode to RTL.

2-Give the user an option to change the mode of the paragraph (I prefer button and keyboard keys ) 
Comment 6 Diego Iastrubni 2008-08-16 01:08:53 UTC
You only mentioned (4) out of my list. That's ok and implemented. My question is what to do when you say "ok dear kate, I know you think it's LTR, but trust me, it's RTL".

My proposal is:
Use presses control+left_shift. The kateParts adds to the paragraph the &RLO; char.

Now, when painting the katePart looks for the first char:
if it's &RLO; -> force the direction of the paragraph to RTL.
if it's &LRO; -> force the direction of the paragraph to LTR.
nothing? lets guess as we do now.

This is a "abuse" of the BiDi algorythm, and the file will open exactly the same under notepad and GEdit for example. 
Comment 7 Zayed Al-Saidi 2008-08-16 07:56:16 UTC
I get what you mean. My case I said "Give the user an option to change the mode of the paragraph" which means exactly what you propose !! 

Regarding BiDi algorithm,  as long as we fulfill our requirements I do not care about it.  
Comment 8 Dotan Cohen 2008-08-16 13:10:46 UTC
No matter which method is used to determine LTR / RTL for any particular line, there should be a button / keyboard shortcut that lets the user switch. Naturally, the keyboard shortcut should be consistent across KDE applications.

That said, I would actually prefer the direction to be determined on a document-by-document basis, not on a line-by-line basis. That prevents having portions of a document aligned to the left edge and other portions aligned to the right.

I am in favor of the first letter determining directions as opposed to % of content. Using % of content sounds like the direction will jump around while the user is typing. However, so long as the user can override the direction and set his own, any solution is fine.

Thanks!
Comment 9 Shai 2008-08-18 21:47:43 UTC
(In reply to comment #6)

Hi Diego,

> 
> My proposal is:
> Use presses control+left_shift. The kateParts adds to the paragraph the &RLO;
> char.
> 

The general idea sounds solid, but use ‏ (like you mentioned before) instead of &RLO;. The &RLO; character has two properties you do not want:

1) Its effect remains until the matching &PDF; character, so when you add &RLO; in this context you also need to add &PDF; at the end of the paragraph.

2) It works not at the paragraph level, but the character level: All characters between &RLO; and &PDF; are considered strong RTL chars, so any English or numbers in the range will appear reversed.

Comment 10 Diego Iastrubni 2008-10-11 01:37:36 UTC
I found a flaw in adding those BiDi control chars. Lets imagine the new editor control is added to lokalize.

Now, lets assume a user right alignes by force (instead of using the guess by the system). Now the control sets the text uppon saving to &rlo; + s  + &pdf; If the original string ended with \n, the new lokalized string will end with \n &pdf; which will bork the svn commit hooks (if msgid ends with \n, msgstr should end with \n as well). The user has now no control and no way of knowing why the basic tests fail.

Shai,
Adding ‏ will not add the side effect I described before, but will not officially set the direction of the pargraph. We can decide that if the paragraph starts with that char, our guess is RTL, but that is more hacky then what I wanted. 

I assume there is no better alternative.
Comment 11 Shai 2008-10-11 11:16:01 UTC
Diego,

Look at my previous message, again, specifically under "2)". If you use &RLO;, you will reverse any number in the localized text -- it is unacceptable long before you reach svn hooks. For the effects you want, you can use &RLE;/&PDF; instead.

Can you explain in more detail why "Adding ‏ [...] will not officially set the direction of the pargraph"? The way I see it, It will for any fully-standard-compliiant implementation, and it will for Kate if we make it.
Comment 12 Diego Iastrubni 2008-10-11 11:57:46 UTC
as far as I understand (from Shosh's presentation...) is that ‎ behaves like an invisible "א", it does not change the direction of the paragraph.
Comment 13 Shai 2008-10-11 12:43:05 UTC
Oh, yes. I keep thinking as if the whole world is plain text. If the app has set a direction for the document, a ‏ will not change the paragraph's direction, and Kate (being a part) needs to consider this also.

Oh well, then, it needs to be &RLE;. How hard is it to push the &PDF; before the \n instead of after it?

For the reference of anybody else interested, can you point to the relevant source(s)?
Comment 14 Shai 2011-03-19 12:21:28 UTC
Is this bug still a concern? I think somewhere between Qt4.6 and KDE SC 4.6 it died without anybody noticing...
Comment 15 Dominik Haumann 2012-10-26 12:36:13 UTC
Ok, according to Shai, this may work just fine.

Since I have no idea bout RTL languages, we are depending entirely on your feedback and patches. I'll close this report assuming it's fixed. If not, please reopen. Or even better, if parts of this report are fixed, maybe open a new report to keep the size of the bug reports small.