Closed
Bug 79682
Opened 23 years ago
Closed 12 years ago
need to land ibmbidi navigator.xul/js
Categories
(SeaMonkey :: Preferences, defect)
SeaMonkey
Preferences
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: ftang, Unassigned)
References
Details
(Whiteboard: [2012 Fall Equinox][Extension Fodder])
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
image/png
|
Details |
author is simon@softel.co.il
Reporter | ||
Comment 1•23 years ago
|
||
Reporter | ||
Comment 2•23 years ago
|
||
ben- need code review
Status: NEW → ASSIGNED
Whiteboard: need code review
Reporter | ||
Updated•23 years ago
|
Whiteboard: need code review → need code review2001-05-09 06:29
Comment 3•23 years ago
|
||
Copying german.
Frank, I want to apply this patch and generate some screenshots. I'll get back
to you here.
Comment 4•23 years ago
|
||
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)
Comment 5•23 years ago
|
||
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?
Comment 6•23 years ago
|
||
I meant "attach a screenshot" instead of "attach a patch". oops.
Reporter | ||
Comment 7•23 years ago
|
||
>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
Reporter | ||
Comment 8•23 years ago
|
||
ben- download the bidi build from
ftp://ftp.software.ibm.com/ps/products/warpzilla/bidi-win32-rel-11-13.zip
or
ftp://ftp.software.ibm.com/ps/products/warpzilla/bidi-win32-rel-12-08.zip
and you can look at the "View" menu to see it.
see http://www.langbox.com/AraMosaic/mozilla/
for discussion
Comment 9•23 years ago
|
||
Thanks, Frank I'll check this out this afternoon.
Comment 10•23 years ago
|
||
Comment 11•23 years ago
|
||
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?
Comment 12•23 years ago
|
||
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.
Reporter | ||
Comment 13•23 years ago
|
||
ok, there are some UI disagreement here.
Simon and mkaply- can you folks address UI design issue?
Assignee: ftang → simon
Status: ASSIGNED → NEW
Reporter | ||
Comment 14•23 years ago
|
||
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 ?
Comment 15•23 years ago
|
||
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)
Comment 16•23 years ago
|
||
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.
-
Comment 17•23 years ago
|
||
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.
Comment 18•23 years ago
|
||
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.
Comment 19•23 years ago
|
||
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...
Comment 20•23 years ago
|
||
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.
Comment 21•23 years ago
|
||
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
Reporter | ||
Comment 22•23 years ago
|
||
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?
Comment 23•23 years ago
|
||
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
Comment 24•23 years ago
|
||
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.
Reporter | ||
Comment 25•23 years ago
|
||
>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.
Comment 26•23 years ago
|
||
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.
Comment 27•23 years ago
|
||
I wrote something about 5 in n.p.m.i18n. Should I paste it here?
Comment 29•23 years ago
|
||
mkaply, is this bug still valid?
Comment 30•23 years ago
|
||
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.
Comment 31•21 years ago
|
||
>We probably need to open up the discussion again.
We should, as two years have past since the last comment here.
Comment 32•20 years ago
|
||
Simon, as the creator of the original patch, what is your take on the issues
raised in comment #30?
Prog.
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 33•20 years ago
|
||
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).
Comment 34•20 years ago
|
||
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.
Comment 35•20 years ago
|
||
(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.
Comment 36•20 years ago
|
||
(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.
Comment 37•20 years ago
|
||
> 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?!
Comment 38•20 years ago
|
||
(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...
Comment 39•20 years ago
|
||
> 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
Comment 40•20 years ago
|
||
(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).
Updated•16 years ago
|
Assignee: mozilla → nobody
QA Contact: bugzilla → prefs
Comment 41•12 years ago
|
||
Is this request still actual?
Whiteboard: need code review2001-05-09 06:29 → [2012 Fall Equinox]
Comment 42•12 years ago
|
||
I think this is extension fodder.
Whiteboard: [2012 Fall Equinox] → [2012 Fall Equinox][Extension Fodder]
Comment 43•12 years ago
|
||
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.
Description
•