Closed Bug 79676 Opened 19 years ago Closed 12 years ago
land bidi pref ui xul and js files
14.33 KB, patch
|Details | Diff | Splinter Review|
2.57 KB, patch
|Details | Diff | Splinter Review|
14.32 KB, patch
|Details | Diff | Splinter Review|
19.17 KB, patch
|Details | Diff | Splinter Review|
50.56 KB, image/jpeg
1.21 KB, text/html
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.
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
Whiteboard: need code review → need code review2001-05-09 06:29
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.
*** Bug 79679 has been marked as a duplicate of this bug. ***
add better patch which merge with 79679 and have MANIFEST and other build stuff.
ben- can you review this- the discussion of the functionality of this patch could be found at http://www.langbox.com/AraMosaic/mozilla/
Whiteboard: need code review2001-05-09 06:29 → new patch need review 2001-05-15 17:02
Target Milestone: --- → mozilla0.9.1
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.
reassign back to simon to work on. jbetak- can you help? simon- please work with firstname.lastname@example.org 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
Assignee: ftang → simon
Status: ASSIGNED → NEW
Whiteboard: new patch need review 2001-05-15 17:02 → patch disapproved by sr. need to work on new js code.
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.
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.
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.
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()
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).
Target Milestone: mozilla0.9.1 → mozilla0.9.2
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?
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.
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.
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.
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...
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.
see my comment about numerica shaping in 79682. We may want to simply listen to OS control panel instead.
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?
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?
> 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.
>>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.
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.
Andreas, please reassign QA contact to the proper person.
Switching qa contact to email@example.com and cc to firstname.lastname@example.org
QA Contact: teruko → giladehven
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.
QA Contact: giladehven → mahar
mkaply- please help to drive this one.
Assignee: simon → mkaply
This isn't going to happen for 0.9.3. Moving out.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Michael - Is this gonna happen for 0.9.4? If not, please move it out to 0.9.6 or later.
Moving out. adding helpwanted keyword
Target Milestone: mozilla0.9.4 → mozilla0.9.6
Sorry all. Moving this out to 0.9.8 for now.
Target Milestone: mozilla0.9.6 → mozilla0.9.8
answer to comment #24: about Thai number. YES, we need it :) Thai number/digit is widely use in all Thai government agencies/army/royal.
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?
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.
Target Milestone: mozilla0.9.8 → mozilla1.0.1
email@example.com is no longer in Arabic bugs, so I have removed her from the CC list and added myself instead firstname.lastname@example.org. This comment is to inform you of this new status. Thank you.
Kindly be informed that Ahmad A. Abu-Taha (email@example.com) from IBM Egypt is replacing Maha Abou El-Rous (firstname.lastname@example.org) in monitoring and receiving notifications of Mozilla bugs regarding Arabic.
Target Milestone: mozilla1.0.1 → Future
Assignee: mkaply → daniel
Target Milestone: Future → ---
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, email@example.com, 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.
Yeah, I should not be the assignee here. Feel free to reassign.
Neil should weigh in, as XP Apps owner (jag too, cc'ing him). /be
Assignee: daniel → neil.parkwaycc.co.uk
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..).
trim "except of (and even this..)." from the end :-)
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.)
Assignee: neil → nobody
QA Contact: mahar → prefs
Is there any value in this bug still or can we just WONTFIX it?
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.