Closed Bug 24029 Opened 26 years ago Closed 26 years ago

Charset Menu <More> area: reorder and group menu items

Categories

(Core :: Internationalization, defect, P3)

Product:
Core
Component:
Internationalization
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: cata, Assigned: cata)

Details

(Whiteboard: [PDT+])

Reordering and groupping of menu items in <More> area.
Status: NEW → ASSIGNED
Target Milestone: M14
Summary: Charset Menu <More> area → Charset Menu <More> area: reorder and group menu items
All ready, will be in the tree this afternoon. Now, the More menu still has the size problem. A workaround is to put as many charsets in <Static> as possible, as they will be substracted from <More>. Real solutions, we have two: - split the menu in submenus: ugly ugly ugly!!! - wait until scrullable menus are available (bug #11586) Votes?
How much work is it to split the menu? I think we need this now, so QA and others can start testing your code. If/when scrollable menus are enabled, we can go back to a single menu. Bug 11586 is marked M15, so it is currently considered post-Beta1. Do we need it fixed for Beta1?
A very dirty hack for splitting the menu could be done in 1 day. We need 11586 fixed asap: it is an usability issue on low resolutions. I don't know if it's for beta1, though, depends of our beta1 criateria.
Added beta1 because this is beta criteria.
Keywords: beta1
Done.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+]
I verified this in 2000020408 Linux and 2000020410 Win32 build. We have not received new Mac build, yet.
So, Cata, once all the UI names are assigned, under More there will be only one item? i.e. User-defined initially. Maybe there will be more later under there as new items get added...
Nope. UI names have nothing to do with which charsets are placed in the More menu. The charsets in that menu are the ones that do not have a place in the other menus/static/cache areas.
I spoke too soon. I looked at character set menu under More in 2000020408 Linux and 2000020410 Win32 build, the order of the menu is different. In Win32 build, ibm850 ibm852 ibm855 ibm857 ibm862 ibm864 User Defined x-viet-tcvn In linux, User Defined ibm850 ibm852 ibm855 ibm857 ibm862 ibm864 x-viet-tcvn The order should be alphabetical order. The order in linux is wrong. I need to reopen this. I found another problem in Mac. I will open new bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
So, you're saying that IBM encodings will stay under More... I guess that would be OK then until the single menu can be used. We migth want to move some like IBM866 to Cyrillic area, but then we run into a problem with what to do with IBM850 (Western). Unless we create Character Set IBM category, this iisue can't be resolved easily. I guess we'll leave IBM under More ..., then?
If we want to, we can move them anywhere: those extra split menus are configured in strings like: char cs1[] = { "iso-8859-1, iso-8859-15, iso-8859-2, iso-8859-3, iso-8859-4, iso-8859-7, iso-8859-9, iso-8859-10, iso-8859-13, iso-8859-14" }; char cs2[] = { "iso-2022-jp, shift_jis, euc-jp, big5, x-euc-tw, gb2312, euc-kr, utf-7, utf-8" }; char cs3[] = { "koi8-r, iso-8859-5, windows-1251, iso-ir-111, ibm866, x-mac-cyrillic, koi8-u, x-mac-ukrainian" }; char cs4[] = { "windows-1258, x-viet-tcvn5712, viscii, x-viet-vps, tis-620, armscii-8, iso-8859-6, windows-1256, iso-8859-8, windows-1255" }; char cs5[] = { "x-mac-roman, x-mac-ce, x-mac-turkish, x-mac-croatian, x-mac-romanian, x-mac-icelandic, x-mac-greek" }; char cs6[] = { "windows-1252, windows-1250, windows-1254, windows-1257, windows-1253" }; So we can change charsets and order and positions as we please. Just let me know.
Could it be that on Linux it is being sorted case-sensitive?
But why?! I am using the same collation method: aCollation->CompareString(kCollationStrengthDefault, *aItem1->mTitle, *aItem2->mTitle, &res); Naoki, any ideas?
It is possible the sort result not identical cross platform as we use system APIs. So which order is not correct specifically? We can try those strings in the messenger thread pane and compare the results.
I talked with Cata about re-organizing IBM encodings. We agreed that there need to be some items under More... so that people will try customizing these. So except for IBM-866 which has been under Cyrillic, all can stay under More.. including the Vietnamese one. If we move these to logical places, there will be only User-Defined left and that is not good for testing More... items. All the encodings under the "temporary" categories will be also customziable and they can move to the Static part. These should give us both practical usability and testability of what will be coming under More ... menu.
Also, all items should sort according to UI names. Once IBM encodings and others under More ... menu acquire UI names, they would all begin with an uppercase letter. Sorting probably would not be an issue for practical purposes. But we should still try to fix the underlying problem if possible.
Sorting under UI names apply to the More ... menu only. The temporary menus are hack, and would not sort but keep the old order found under the other temporary menus. Right, Cata?
Changed QA contact to amasri@netscape.com
QA Contact: teruko → amasri
In response to nhotta's comment: It is possible the sort result not identical cross platform as we use use system APIs. So which order is not correct specifically? We can try those strings in the messenger thread pane and compare the results. Include a mixture of upper- and lower- case strings.
cata, you're currently using an attribute kCollationStrengthDefault which is equal to kCollationCaseSensitive. In order to make it case sensitive, use kCollationCaseInSensitive instead.
>In order to make it case sensitive, use kCollationCaseInSensitive instead. Correction: In order to make it case insensitive, use kCollationCaseInSensitive.
Will follow suggestion and change to kCollationCaseInSensitive
Nhotta, Changing this to case insensitive will fix this problem, but do we need to log another bug about the different results across platforms for case sensitive collation?
Fixed.
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.