Closed Bug 79682 Opened 23 years ago Closed 12 years ago

need to land ibmbidi navigator.xul/js

Categories

(SeaMonkey :: Preferences, defect)

Product:
SeaMonkey
Component:
Preferences
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: ftang, Unassigned)

References

Details

(Whiteboard: [2012 Fall Equinox][Extension Fodder])

Attachments

(2 files)

change to xpfe/browser/resources/content/navigator.js and xpfe/browser/resources/content/navigatorOverlay.xu
7.29 KB, patch
Details | Diff | Splinter Review
part of this feature
10.98 KB, image/png
Details 
author is simon@softel.co.il
Depends on: 79680
Blocks: 79684
ben- need code review
Status: NEW → ASSIGNED
Whiteboard: need code review
Whiteboard: need code review → need code review2001-05-09 06:29
Copying german. 

Frank, I want to apply this patch and generate some screenshots. I'll get back 
to you here. 
Actually I can't attach the patch because there aren't any strings. Frank, can 
you provide a screenshot or a ASCII art drawing of what this looks like? (I'd 
also like to see the text strings that are used)
oh my. i suggest a better UI than complicating our already over-complicated menus 
with more stuff the normal user never will care about.

how about 1 pref panel to set all this stuff, and then be done with it?

I meant "attach a screenshot" instead of "attach a patch". oops.
>how about 1 pref panel to set all this stuff, and then be done with it?
see 79676

>there aren't any strings.
the dtd have been landed as in 79684
Thanks, Frank I'll check this out this afternoon. 
Sorry, I can't approve this modification to the Navigator UI. The view menu is 
cluttered enough as it is. Can't this stay in the preferences UI? 
Come on people -- this is basic, basic stuff. It's spelt out very clearly in 
the UI guidelines for Windows ...

    Minimize the number of levels for any given menu item, ideally limiting
    your design to a single submenu.

                   <http://msdn.microsoft.com/library/books/winguide/ch08b.htm>

... and for Mac.

    Never use more than *one level* of submenus. A submenu at the second
    level would be buried too deep in the interface and would unnecessarily
    create another level of complexity. Also, it takes more time for the
    user to use and peruse a hierarchical menu than a pull-down menu. It is
    physically difficult to use a second level of submenus without slipping
    off the first submenu ... Don't even *think* of doing this.

    <http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-90.html>

(Fixing the submenu nightmare for encoding selection is bug 10999; fixing the 
submenu nightmare in the `Tasks' menu is bug 32502.)

Now, I'd like to know:
(1) how Internet Explorer can currently have bi-di support without any visible
    UI for this stuff, short of a direction toggle in their `View' > `Encoding'
    submenu (and no, I don't a blanket statement `we have better bi-di support
    than IE', I want details);
(2) what each of these menu items are supposed to do (the fact that I can't
    tell what they're for, just by looking at them, is troubling in itself);
(3) what effort, if any, has been put into code to set these options
    automatically so there does not need to be a UI for them at all.
ok, there are some UI disagreement here.
Simon and mkaply- can you folks address UI design issue?
Assignee: ftang → simon
Status: ASSIGNED → NEW
 Matthew Thomas (mpt) 
thanks for your comment- I will let bidi folks (simon@softe.co.il and 
mkaply@us.ibm.com) answer you
See  http://www.langbox.com/AraMosaic/mozilla/ for early discussion

simon-
How many of these menu items are used frequently by the users between pages? 
Which one should we only put inside the pref but not in the menu item ?
Would one long menu be better than the nested submenus? Or would it be better 
to open a dialog?

After discussions here we have decided to remove the character set option. This 
was needed when the options were originally designed, but has been obsoleted by 
other changes.

IE doesn't have the Numeral Shape option because it takes it from the regional 
settings on the Windows Control Panel. (Does anybody know what happens in the 
Mac version of IE?)

How IE manages without the other options is not my problem, luckily. The only 
way to change between visual and logical text is to change the encoding, which 
is fine if the encoding is ISO-8859-8, which exists in both logical and visual
forms, but problematical for UTF-8. I agree that visual text in UTF-8 is wrong, 
but not everybody knows that :-)

Visual textfields are necessary for gateway sites that provide a web interface 
to host systems with visual ordering. They are also useful for search engines, 
if you want to search for Bidi text which might be either on a visual or a 
logical site (with IE you have to reorder it in your head and type it in twice, 
once in each direction)


A long menu can be just as bad as a too nested menu, it all depends. I 
personally think it does not belong into the menu at all.
 
Neither in this discussion nor in any of the documents listed have I seen 
reasoning as to why this has to clutter the view menu. I'd like to know:
- what percentage of users out there does use this feature:
  - if only a relatively small percentage uses it should it be an optionally 
installable package instead of being in every install in the world?
- those users who need this feature, how do they use it?
  - if it's not used frequently it probably does not belong in the menu at all, 
especially not in all it's depth, the advanced prefs might be a much more 
suitable place for it
  - if it is used frequently you'd still do not want to spill out all the 
options of such a complex feature directly in the menu for all to see. Instead 
you could the menu to add *one* item as an access point to a dialog that lets 
you make bidi changes and can provide some assisting text.
  - 
Or what if this menu item was added dynamically on pages that have bidirectional
content? Then the x% of users that don't need the function would never see it.
That is an interesting idea, as it addresses the issue of not bothering the 
majority of users that do know what it is or do not need the feature. two 
points though:
- it doesn't answer whether a menu is the right choice at all (see my comments 
on frequency of usage)
- disappearing menu items are not always a good choice (especially on mac where 
things usually get greyed out), as you put the burden on the user to figure why 
the item is sometimes there and sometimes isn't. Also many users remember menu 
items' location by relative position, so disappearing menu items near the top 
or middle of a menu can throw off users.
Come to think of it, one place where menus do have dynamic context based 
content is contextual (ie right click) menus. Maybe that could be a way to do 
it, if settings for this feature need to be switched frequently, like from 
document to document.
There are accessibility issues with contextual menus though...
german, simon,

you might be interested to know that i18n already had a similar issue with 
charset customization. Originally, it was planned as an pref window and ended 
up as a menu item ("View->Character Coding->Customize...") for better 
accessibility. 

A similar route might be pursued with the Bidi options, they could be 
accessible both through the prefs and a browser menu item. Simon's pref XUL 
code could be used for both cases.

Adding a single menu item (and possibly context menu item, which will be 
neccessary because of embedding) is not too much IMHO. 
If someone were to summarise the different options necessary, and why and when 
they are necessary, it would make it easier to design a sensible UI for bidi.

We should certainly only enable whatever-it-is when bidi content is present. 
That's not hard.

Gerv
see bug 79676 for more documentation
Just want to clearify one thing. Who should be the UI designer for this and 
79676, who should we work with and who can make decision? What is the process?

so... we have the following setting, we need to consider put them into pref, 
menu, both, or none.
1. Default Direction
2. Text Type: Visual or Logical
3. Text Type for Text Field
4. Text Type for Clipboard
5. Numeral Shaping

I have the following opinion:
A. I think none of them need to be show up in the menu unless the page is 
Arabic/Hebew or UTF-8. 
B. I think Default Direction is a MUST in menu item for bidi pages (as A.)
C. I think Text Type is a MUST in menu item for bidi pages (as A.)
D. I doubt about 3,4, and 5. for MENU item. How many chances user need to switch 
them around? Will they switch it between web sites? IF not, then we should not 
put in the menu. If they will, the we need to ask how frequent wil they switch. 

For numeric shaping
Macintosh also have Arabic Numeric shaping control panel. I am not sure IE use 
it or not.
Should we listen to the OS control panel for Numerica shaping instead ? Why 
should we have this setting in our application instead of listen to the OS 
setting?

Frank - just to clarify: you are saying items 1-5 _must_ be set by the user and 
the correct setting cannot be calculated from the contents of the page itself 
(and/or Mozilla's current language setting)?

Obviously, the more things we can work out automatically, the better.

Gerv
Frank as for Netscape's UI on this feature you should talk to me, as for 
Mozilla UI I think probably in addition either mpt or Ben can advise you.
The Details:
- I would try to re-sue the OS settings wherever possible as starting 
defaults
- Infer as much as possible automatically from the document at hand
1. the word default already implies its something that belongs into prefs 
right? you want to set it as to default for future use
3. - 5. if you think they should be in prefs yourself, then they should 
probably not go into the menu. The menu is less scaleable for large 
number of items and overusing the menu for all settings makes the app 
look unapproachable for the beginning user. Pref also are not cluttering 
up the top level UI.
>Obviously, the more things we can work out automatically, the better.
Agree.
>Frank - just to clarify: you are saying items 1-5 _must_ be set by the user 
>and the correct setting cannot be calculated from the contents of the 
>page itself (and/or Mozilla's current language setting)?
no, that is NOT what I said. 
What I said is 
I think 1 and 2 is MUST to be set by the user in the per page basis- therefore, 
it is better to put under menu. (Again, I am not daily bidi users, I am not 100% 
sure about this. But that is my understanding)

I am not sure about 3,4 and 5. I am not bidi users. We need real bidi users to 
answer that question. 

ABOUT DEFAULT TEXT DIRECTION (or DIRECTION)
about using content to find out the setting, here is some info
in html 4.1 http://www.w3.org/TR/html4/struct/dirlang.html in sectoin "8.2 
Specifying the direction of text and tables: the dir attribute"

>User agents must not use the lang attribute to determine text directionality.

so we know we cannot use lang attribute to find out text directionality.

Basically, the "default direction" is the default value while dir attribute is 
not specified in any part of the html. in 
http://www.w3.org/TR/html4/struct/dirlang.html#h-8.2 it define the dir 
attribute. But there are no place in html 4.1 specify what is the default value 
of it while it is not there. 

Therefore, we must have to have a UI to allow user to set the default direction 
of the document while the content lack of such information. 

In IE, the text direction menu will only show up when user visiting 
Hebrew/Arabic or UTF8 pages.  We probably should do the same thing. 

ABOUT THE THREE TEXT TYPES (or should we call it DATA ORDER?)

I believe the main one is also needed. But the question is when do we need it?
Can we only show it while we are visiting Hebrew/Arabic/UTF8 pages ? 

Why IE do not have them? Can some Hebrew/Arabic user list some page which NEED 
this setting? List URL here, please.

Why we need the two other TEXT TYPE for form field and clipboard? Can BIDI users 
give me some user cases ? When do you need to use the form text filed text type 
? in which web application? Please list URLs. Are we trying to use with non BIDI 
web application - say English Netscape.net mail to read Hebrew mail?

When do we need to clipboard text type? Which application do we interact with? 
Why do we need them ? Are we interact with both bidi application and non-bidi 
application- say Netscape 4.x ?

Do we need these text type setting for all doucment, or just for 
Hebrew/Arabic/UTF8 pages ? Do we need to change the setting on per page basis?

Do user usually NEED to change the numeric shaping on per page basis. (My 
question is not "Can they change", but instead "Do they NEED to change" in 
average cases.



As I said in bug 79676, this discussion needs to take place in in n.p.m.ui and 
n.p.m.i18n. Bugzilla is a very poor medium in which to work out a UI design for 
such a technically complex feature.
I wrote something about 5 in n.p.m.i18n. Should I paste it here?

mkaply- please help to drive this one.
Assignee: simon → mkaply
mkaply, is this bug still valid?
We had some philosophical issues that kept this from getting done.

There were arguments as to whether Bidi options should be in prefs, menus, or 
both and whether the Bidi options should always be there (or be an overlay)

For this reason, I think this bug got put on hold. We probably need to open up 
the discussion again.
Blocks: 80130
>We probably need to open up the discussion again.

We should, as two years have past since the last comment here.
Simon, as the creator of the original patch, what is your take on the issues
raised in comment #30?

Prog.
Product: Browser → Seamonkey
Keywords: qawanted
Is it still the intention to land this change?

People from this list: 

http://wiki.mozilla.org/SeaMonkey:Supporters

I have added you to the CC list since now it's up to you to make the call rather
than the majority of people currently CCed. Feel free to remove yourself if you
find this a hassle, or just make the decision.

Non-Seamonkey people: Please remove yourself from the CC list if you're no
longer going to involve yourself in seamonkey-related decision making.

And now for my opinion on the matter:

- set document direction is already present as 'switch page direction' so we can
scrap it
- numeral shape, text mode in controls, text mode in clipboard - should be in
prefs only
- charset - I don't see what this does as opposed to the 'character encoding'
submenu
- text-type - this can stay, but doesn't it mean making the ISO-8859-8/-I
charsets the same charset, but with different logical/visual text type? Anyway,
this needs an access key even more than it does a menu item. And I would suspect
it would be used infrequently (unless the two charsets I mentioned get unified).

We wouldn't even consider adding a pref or menu option that only applied to Macs
to Windows and Unix builds. The same standard should apply here, Bidi support is
a localization problem, not a general browser problem. It should be handled at
that level.

(In reply to comment #34)

Why should this not be handled exactly like the "switch page direction" item
which now appears on my View menu? 

gShowBiDi = isBidiEnabled();
if (gShowBiDi) {
    document.getElementById("documentDirection-swap").hidden = false;
    document.getElementById("textfieldDirection-separator").hidden = false;
    document.getElementById("textfieldDirection-swap").hidden = false;
}

This way this addition to the view menu only appears on installations in which
it is relevant.
(In reply to comment #35)

For the same reason a Mac only item shouldn't be installed on a windows computer
and then hidden. You are using resources for something that is of no benifit to
the user.

That little bit of code increases the footprint and it has to be processed
resulting in a slighly less responsive piece of software. The general princple
should allways be don't install it if it isn't needed, and it isn't needed for
the vast majority of users.

This one small item by itself is no big deal, but small items add up as more and
more are included. You can't put everything that evryone might need in without
running into problems.

Very few people need Bidi, which is  why I think it should be handled at the
localization level so it only affects the people who need it. I simply can't see
a justification for placing code on a thousand computers when it is only needed
on one or two of them.

At most Bidi support should be an option in the installer that is off by default
so that people who don't need it don't have unnessacary code placed on thier system.

> Non-Seamonkey people: Please remove yourself from the CC list if you're no
> longer going to involve yourself in seamonkey-related decision making.

Not sure what does this exactly mean.  Are you asking people that are not in the
decision making process not to monitor bugs?!
(In reply to comment #36)
> At most Bidi support should be an option in the installer that is off by 
> default so that people who don't need it don't have unnessacary code placed on 
> their system.

But then what happens if someone adds BiDi support to his/her system? He/she
shouldn't have to reinstall seamonkey for that. Actually, it may be the case
that a person installs seamonkey just prior to configuring the BiDi support on
his/her system. And think of what would happen for seamonkey packages for Linux
distributions.

> Very few people need Bidi, which is  why I think it should be handled at the
> localization level so it only affects the people who need it. 

Also, having this only in localized builds is a problem for two reasons: 
- The localized builds usually also do a lot of things many people simply do not
tolerate, e.g. change the UI language to Hebrew, switch the menu bar and toolbar
button positions, etc. 
- A lot of the seamonkey users use nightlies, not releases (unlike ff/tb users,
but we don't care about them anymore right? ;-) ... )  ; they (we) would want
this built by default in nightlies (but perhaps not necessarily built by default
in localized-to-non-BiDi-locales builds).

A final option would be to go back to having all this UI as an extension once
seamonkey gets toolkitized. I wouldn't like it though...

(In reply to comment #37)
> Not sure what does this exactly mean.  Are you asking people that are not in 
> the decision making process not to monitor bugs?!

I was just saying that since this is a seamonkey-only bug, people who only
intend to focus on ff/tb QA work should not have to get all this spam and are
encouraged to remove themselves from the CC list. Of course whoever is
interested is most welcome to stay...
> For the same reason a Mac only item shouldn't be installed on a windows computer
> and then hidden. You are using resources for something that is of no benifit to
> the user.

This is faulty logic - we do this quite a bit currently; it's something CSS does
very well. And your estimates of those who need BiDi are somewhat low. Several
languages use it; other people may want to view it. 

If bidi is switched on, the BiDi options should be on the menu. Seems fairly
logical to me.

Gerv
(In reply to comment #34)
> We wouldn't even consider adding a pref or menu option that only applied to Macs
> to Windows and Unix builds. The same standard should apply here, Bidi support is
> a localization problem, not a general browser problem. It should be handled at
> that level.

This is just not true. Many users who need to view pages in bidirectional
languages have no interest in localized versions of the browser (Biblical
scholars for example).
Assignee: mozilla → nobody
QA Contact: bugzilla → prefs
Is this request still actual?
Whiteboard: need code review2001-05-09 06:29 → [2012 Fall Equinox]
I think this is extension fodder.
Whiteboard: [2012 Fall Equinox] → [2012 Fall Equinox][Extension Fodder]
We seem to have got on OK for the last 11 years without it. If something is still needed, a different bug would be more appropriate - start with a clean slate.

Gerv
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.

Attachment

General

Creator:
Created:
Updated:
Size: