79676 - land bidi pref ui xul and js files

Status: RESOLVED WONTFIX

(SeaMonkey :: Preferences, enhancement)

Description

[Frank Tang]

in the IBMBIDI work we creaet a new pref window for bidi control. We need to 
land the UI. This bug is for bidi-prefs.js and bidi-prefs.xul only. it depend on 
79675 for the dtd. We probably need to land 79675 first since we need to freeze 
L10N translation first.

Comment 1

[Frank Tang]

here is the xul and js change, this have to be land 
1. after we land 79675
2. after we turn on IBMBIDI as default

Comment 2

[Frank Tang]

Attachment: new files for mozilla\xpfe\components\prefwindow\content\pref-bidi.{xul,js}

Comment 3

[Frank Tang]

ben- can you also code review this one ?
The author is [e-mail]

Comment 4

[Frank Tang]

Attachment: also need to change the makefile.

Comment 5

[Simon Montagu :smontagu]

Attachment: correction to attachment

Comment 6

[Simon Montagu :smontagu]

There are some errors in
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=33668

Use http://bugzilla.mozilla.org/showattachment.cgi?attach_id=33676 instead.

Comment 7

[Frank Tang]

*** Bug 79679 has been marked as a duplicate of this bug. ***

Comment 8

[Frank Tang]

add better patch which merge with 79679 and have MANIFEST and other build stuff.

Comment 9

[Frank Tang]

Attachment: newest patch

Comment 10

[Frank Tang]

ben- can you review this- 

the discussion of the functionality of this patch could be found at 
http://www.langbox.com/AraMosaic/mozilla/

Comment 11

[Alec Flett]

this is the wrong approach to solving this problem. You should be using pref
observers, NOT registering ok handlers on the pref window - not to mention that
your change only affects the most recent window, and does not affect any other
windows.

Please look at nsIPrefBranch.addObserver() - there are examples in the tree,
such as in navigator.js, look for the "nsButtonPrefListener" - basically every
navigator window (and perhaps mail window too? maybe you want to integrate this
into the markupDocumentViewer object instead?) should act as an observer on the
pref that you'll be changing.. when the pref changes, you should examine the new
value, and set the value of viewer.bidiTextDirection.

Comment 12

[Frank Tang]

reassign back to simon to work on. 
jbetak- can you help?
simon- please work with [e-mail] together with this issue. jbetak 
work for me and know pref stuff pretty well.
when you guys get the new patch, reassign this bug to jbetak for check in. 
Thanks
I am not sure we still have enough time for moz0.9.1- it will be freeze at 5/22. 
we probably can still make it if we get the newest patch by Friday morning 5/18

Comment 13

[Frank Tang]

Attachment: screen shot of the BIDI pref UI

Comment 14

[Frank Tang]

so... here are the issues
1. the UI design of the BIDI pref
   I believe everyone agree with the design since it have been on the bidi build 
for a while- please open new bug if there are problem with the design
2. XUL structure
   I believe there are no problem with that - alecf does not mention any issue 
about the xul
3. JS file
   alecf said we need to 
   a. use pref observe instead of ok handler
   b. it should affect all the window but not just the most recent window.

Comment 15

[Frank Tang]

alecf- can we land the patch without prefwindow/resources/content/preftree.xul 
now and keep working on ? This will make sure the current ui design is in the 
tree and will be easier to work between people. We won't bring up the ui if we 
don't land the preftree.xul changes. 

Comment 16

[Blake Ross]

Here are some problems I see with the UI at a glance:

* Is this really Navigator-specific?  Why is it under Navigator?
* Everything in the Preferences dialog is an option.  We don't need to append 
"Options" to the category name.
* I suspect that many users aren't going to know what "Bidi" means.  But it 
looks as if not everything in this panel has to do with bidirectional text 
anyways.
* The panel doesn't fit (due in part to the overabundance of groupboxes and 
radiobuttons).
* Inconsistency in widget placement (Logical and Visual are sometimes the first 
two, sometimes the last two.)
* Inconsistency in capitalization ("Text Mode in Controls", "Text Mode in 
clipboard")

Feel free to check this UI into the tree as-is to facilitate work on it, but it 
cannot be turned on until these and other issues are addressed.  I'll file a new 
bug to cover them.

Comment 17

[Alec Flett]

Is there a UI designer working on a design for this? As blake pointed out, there
are many inconsistencies and the dialog is very complex. I'd like to see a new
patch and a new screenshot with a more consistent UI.

I also agree that:
1) "Bidirectional Text" should be used instead of "BiDi" wherever there is room.
2) This really seems to belong in Appearance, not Navigator, since it affects
mail and editor as well.

And so
1) no, please don't land the UI as-is
2) do NOT land any JS that makes use of registerOKCallbackFunc()

Comment 18

[Marek Z. Jeziorek]

TM to 0.9.2 per PDT triage (it's OK to check it in by Friday or after 0.9.1
branch is made).

Comment 19

[[e-mail] (away - not reading bugmail)]

alecf,

just trying to clarify - would simon target navigator.js for inclusion of his 
pref observers? I agree that markupDocumentViewer seems like an even more 
natural choice, which would imply nsDocumentViewer.cpp, right?

Comment 20

[Simon Montagu :smontagu]

Sorry, I don't begin to understand alecf's recommendation concerning pref 
observers. I am especially confused about what should be in .js and what should 
be in .cpp

jbetak, it looks as if I'm going to need *lots* of help on this. Thanks in 
advance.

Comment 21

[Alec Flett]

ok, the issue is that your fix causes a change only to the most recent window,
and only when changed from the preference UI. Why is this bad?
1) Preferences are a global option - if you change a preference, it should
affect the entire product. If what you are changing is per-window, then it's not
a preference.
2) There are multiple ways to change preferences, beyond just the Preference UI
- you should NEVER depend on the ok button callback to update preferences.
Instead, you should be registering with the backend preference code to be
notified whenever a particular pref changes.

So, in order to solve this, you need to add an object that acts as an observer
to preferences changing. Look at nsIPrefBranchInternal.addObserver(). By using
this method, you gaurantee that no matter how a preference is changed (via the
UI, via some backend method, etc) your object will be notified.

Your object(s) can be written in JS or C++, your choice - since the object that
is affected seems to be the markupDocumentViewer, I personally would simply
reuse that object by making it implement the nsIObserver interface. That way,
every instance of that object is an observer, and thus every window will be
affected when you make this change.

Comment 22

[[e-mail] (away - not reading bugmail)]

simon,

I've been looking for some examples for the things alecf pointed out and my 
current belief is that the pref observer should be added to 
nsDocumentViewer.cpp. Luckily, there is some code we could use as a reference 
in nsCacheService.cpp. Here are links to the points of particular interest:

http://lxr.mozilla.org/seamonkey/source/netwerk/cache/src/nsCacheService.cpp#49
http://lxr.mozilla.org/seamonkey/source/netwerk/cache/src/nsCacheService.cpp#131
http://lxr.mozilla.org/seamonkey/source/netwerk/cache/src/nsCacheService.cpp#231

Seems like there are two preference values of interest 
(browser.cache.disk.enable, browser.cache.enable), but they are not really 
exposed to the UI in the release builds. 

I'm working on some urgent UI changes for language/content packs, but I might 
have some free cycles next week to help with the implementation or any other 
changes necessary.

Comment 23

[Alec Flett]

the one thing I want to add about the pref observer stuff which just bit me
elsewhere, is that prefs holds onto a strong reference to your object, so make
sure that you don't create a cycle by making sure you unregister yourself as an
observer someone OTHER than the destructor of that object...

Comment 24

[Frank Tang]

I have the following question
1. who should we work with for the UI design/redesign ? what is the process? Who 
can make the decision?
2. Where should we put under pref tree? blake said we should not put under 
navigator, should we put under "Apperance" ?
3. what should the title of the pref be ? should it be "Bi-Directional Text" ?
4. Should all the setting in the pref? 
5. What kind of widget should we use? currently it use radio, should we use 
PopUp instead to save some space?
6. What should be the langauge used in the pref. The sentance/langauge in the 
pref currently is hard to understand. 
7. How freqent the user may change the pref? Switch depend on the page ? Depend 
on the OS ? We should have answer for each setting.

Here is the documentation I can find:
http://lxr.mozilla.org/seamonkey/source/docshell/base/nsIMarkupDocumentViewer.id
l#148

 82   /**
 83    * Options for Bidi presentation.
 84    *
 85    * Use these attributes to access the individual Bidi options.
 86    */
 87 
 88   /**
 89    * bidiTextDirection: the default direction for the layout of 
bidirectional text.
 90    *                    1 - left to right
 91    *                    2 - right to left
 92    */
 93   attribute octet bidiTextDirection;
 94   
 95   /**
 96    * bidiTextType: the ordering of bidirectional text. This may be either 
"logical"
 97    * or "visual". Logical text will be reordered for presentation using the 
Unicode
 98    * Bidi Algorithm. Visual text will be displayed without reordering. 
 99    *               1 - the default order for the charset
100    *               2 - logical order
101    *               3 - visual order
102    */
103   attribute octet bidiTextType;
104 
105   /**
106    * bidiControlsTextMode: the order of bidirectional text in form controls.
107    *                       1 - logical
108    *                       2 - visual
109    *                       3 - like the containing document
110    */
111   attribute octet bidiControlsTextMode;
112 
113   /**
114    * bidiClipboardTextMode: the order in which text is transferred to the 
clipboard.
115    *                        1 - logical
116    *                        2 - visual
117    *                        3 - as source (unchanged)
118    */
119   attribute octet bidiClipboardTextMode;
120 
121   /**
122    * bidiNumeral: the type of numerals to display. 
123    *              1 - depending on context, default is Arabic numerals
124    *              2 - depending on context, default is Hindi numerals
125    *              3 - Arabic numerals
126    *              4 - Hindi numerals
127    */
128   attribute octet bidiNumeral;
129 
130   /**
131    * bidiSupport: whether to use platform bidi support or Mozilla's bidi 
support
132    *              1 - Use Mozilla's bidi support
133    *              2 - Use the platform bidi support
134    *              3 - Disable bidi support
135    */
136   attribute octet bidiSupport;
137 
138   /**
139    * bidiCharacterSet: whether to force the user's character set
140    *                   1 - use the document character set
141    *                   2 - use the character set chosen by the user
142    */
143   attribute octet bidiCharacterSet;  
144   
145   /**
146    * Use this attribute to access all the Bidi options in one operation
147    */
148   attribute PRUint32 bidiOptions;

Based on the documentation, I believe we need the following in the pref
1. Default Direction
2. Numeral Shape
3. Text Type
4. Text Mode in Control
5. Text Mode in Clipboard

We should NOT include "Character Set" neither BidiSupport (which currently not) 
in the pref. the "Character Set" one should be covered by our Forced character 
scheme for all characters set- this is not bidi-specific.

In term of numeral shape, I wonder what does that mean to other locale. Will 
people want a Thai numeral shape in the future? What should we deal with them?

I will propose that we use popup for all these setting. OF course, once we find 
THE UI designer  I will let him/her decide that.

Comment 25

[Frank Tang]

see my comment about numerica shaping in 79682. We may want to simply listen to 
OS control panel instead.

Comment 26

[Frank Tang]

Attachment: hacky html (table/form) to demo look and feel of using popup. We should really use xul instead.

Comment 27

[Frank Tang]

Attach a hacky prototype by using HTML. We should really use XUL to implement 
it. This is just a quick and dirty way to demostrate the look and feel. Notice 
that if you use Netscape6 to view it, the Numeric shap will show you Hindi 
(which is the non ASCII digits) in the options. 
As I mention before, we may or may not want to have preference for Numeric 
Shape. We may want to listen to OS control panel instead. 

If we want to add Add Numeric Shape, then we need to consider 
1. how about Persian?
2. how about other unicode digits- such as Thai, Devanagari, etc

How fine is the OS control panel setting for Numeric Shape? Do they have the 
same 4 options on Mac and Windows? how about Linux/Solaris?

Comment 28

[Simon Montagu :smontagu]

There's a problem with showing examples (1,2, 3, etc.) in the pop-up for Numeric
shaping: the current pref will be applied to the examples, so they may end up
looking both the same. Is using image files an option?

Comment 29

[Matthew T (active 1999-2002)]

> 1. who should we work with for the UI design/redesign ?

Blake Ross, Ben Goodger, myself, and the others subscribed to n.p.m.ui and 
n.p.m.i18n.

>                                                         what is the process?

Post a message to n.p.m.ui and n.p.m.i18n explaining exactly what each of these 
options do, why it is that these options are necessary at all in Mozilla when 
most of them are not present in Internet Explorer, and how these options 
interact with OS settings for the same thing. Then respond to questions and 
suggested designs from the UI people, until a final design is reached. Provided 
messages are responded to promptly, this process should take less than a week.

> Who can make the decision?

Blake Ross (owner of XP Apps: GUI), Ben Goodger (owner of Navigator UI), and 
myself (owner of UI Design).

> 2. Where should we put under pref tree?

Judging by my (admittedly incomplete) understanding of what these options do, 
and the discussion in this bug, the answer is probably `nowhere'. But that can 
be worked out in the newsgroup discussion.

Comment 30

[german]

>>who can make the decision?

>Blake Ross (owner of XP Apps: GUI), Ben Goodger (owner of Navigator UI), and 
>myself (owner of UI Design)

Frank:
I don't think that the aforementioned individuals 'can make the decision'. 
While mpt is the owner of "design feedback", and Blake and Ben or very valuable 
contributors to Browser and overall front-end pieces of Mozilla, they don't 
represent the decsion making process alone.
As for commercial Netscape builds the Netscape UI group is the design owner, 
represented here by Jennifer Glick for Messenger, myself for Navigator and the 
overall UI framework and a number of other folks in our group. Keep in mind 
that we are the original creators of the Mozilla UI and participate actively in 
its design process.
It also my opinion that when it comes to international and localization issues 
there are individuals and companies participating in Mozilla (albeit a bit more 
quietly) with signicantly more expertise then the aformentioned folks.

Comment 31

[Ben Goodger (use ben at mozilla dot org for email)]

None of us want to be sole 'decision maker' of the UI design and implementation 
process, for reasons of knowledge, time, etc. Where UI is necessary to 
accomplish a feature useful to a subset of users, it is my role (as appointed) 
to /arbitrate/ the design and implementation of this UI such that a) the 
majority is not affected in a negative way and b) the needs of the subset are 
fulfilled. 

Expertise in the field of knowledge of international customers is fantastic, 
however, one must also temper that knowledge with knowledge of the core 
audience. I've not yet taken the opportunity to familiarize myself with the 
specifics of this bug, so everything I have said thus far are generalities. 

Comment 32

[Teruko Kobayashi]

Andreas, please reassign QA contact to the proper person.

Comment 33

[Andreas Becker]

Switching qa contact to [e-mail] and cc to [e-mail]

Comment 34

[Katsuhiko Momoi]

I think it might be better to have mahar do the
QA for this particular bug because she is most familiar
with the UI options at this point.

Comment 35

[Frank Tang]

mkaply- please help to drive this one.

Comment 36

[Mike Kaply [:mkaply]]

This isn't going to happen for 0.9.3. Moving out.

Comment 37

[Jaime Rodriguez, Jr.]

Michael - Is this gonna happen for 0.9.4? If not, please move it out to 0.9.6 or
later.

Comment 38

[Mike Kaply [:mkaply]]

Moving out. adding helpwanted keyword

Comment 39

[Mike Kaply [:mkaply]]

Sorry all. Moving this out to 0.9.8 for now.

Comment 40

[Arthit Suriyawongkul]

answer to comment #24:

about Thai number.
YES, we need it :)
Thai number/digit is widely use in all Thai government agencies/army/royal.

Comment 41

[Shoshannah Forbes]

The target milesotone says above 0.9.8
We don't have this for 0.9.9 yet.
I know the hebrew l10n people want this bug fixed...
so- what is going on?

Comment 42

[Mike Kaply [:mkaply]]

I don't think this is going to make it for 1.0.

We still need to get a consensus on where to put the Bidi UI, especially with 
the new menus.

Comment 43

[Ahmad A. Abu-Taha]

[e-mail] is no longer in Arabic bugs, so I have removed her from the CC 
list and added myself instead [e-mail]. This comment is to inform you 
of this new status. Thank you.

Comment 44

[Ahmad A. Abu-Taha]

Kindly be informed that Ahmad A. Abu-Taha ([e-mail]) from IBM Egypt is 
replacing Maha Abou El-Rous ([e-mail]) in monitoring and receiving 
notifications of Mozilla bugs regarding Arabic.

Comment 45

[Samir Gehani]

adt: nsbeta1-

Comment 46

[Vedran Miletic]

retargeting

Comment 47

[timeless]

.

Comment 48

[Prognathous]

Michael Kaply wrote:

> We still need to get a consensus on where to put the Bidi UI, especially with 
> the new menus.

More than a year has gone by since this last comment. The discussion has pretty
much stalled, so I really can't see anything that'll get us this much elusive
consensus.

How about adding the BiDi UI as a (popup) settings window? Instead of dedicating
a whole panel, add a Bidirectional Settings button under the Navigator/Languages
panel. We already have the pref for Default Character Coding there, so another
button probably won't cause much confusion or clutter.

BTW, [e-mail], is there any reason why this bug is assigned to Daniel
Glazman? to the best of my knowledge, he hasn't been involved in it, nor is he
the owner of Browser/Preferences. Could this be an error?

Prog.

Comment 49

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Yeah, I should not be the assignee here. Feel free to reassign.

Comment 50

[Brendan Eich [:brendan]]

Neil should weigh in, as XP Apps owner (jag too, cc'ing him).

/be

Comment 51

[Asaf Romano (gone)]

As a BiDi user, (except of the numeral shapes option, maybe), I don't see
anything that we need from the attached screenshot, except of (and even this..).

Comment 52

[Asaf Romano (gone)]

trim "except of (and even this..)." from the end :-)

Comment 53

[Tony Mechelynck [:tonymec]]

No comment and hardly any activity in more than 3 years. In the meantime, the prefs UI is being moved to a new backend which didn't exist in Sm 1.x or Mozilla.

Resetting A+QA on the assumption that they aren't current anymore. (Neil, if you still want this, go ahead and re-accept it of course.)

Comment 54

[Robert Kaiser]

Is there any value in this bug still or can we just WONTFIX it?

Comment 55

[Simon Montagu :smontagu]

I think the bidi prefs are fine as hidden prefs in about:config. If we decide we need UI for any of them we can open new bugs.