Closed Bug 65018 Opened 24 years ago Closed 24 years ago

move the folder override ui into the folder properties dialog

Categories

(SeaMonkey :: MailNews: Message Display, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.8

People

(Reporter: sspitzer, Assigned: nhottanscp)

Details

(Keywords: intl)

Attachments

(1 file)

see bug #32714 sorry, nhotta, for not thinking of this earlier.
nhotta wrote: > I think having folder charset UI close to charset menu make it easier to be > discovered by the users who care about charset. > We can have folder charset items in folder property but we can also keep the > current UI. I think we should have multiple tabs in the folder properties dialog, and when you do "View | Folder Charset Coding..." it would bring up the folders properties dialog with the folder char set tab selected. doing "Edit | Properties" would bring up the dialog with the default tab selected. we don't need a new dialog.
I agree, that would be fine.
Keywords: intl
Status: NEW → ASSIGNED
Added myself to CC.
I attached a patch, could you review, Seth? I have a couple of questions. * The property dialog allows the user to rename the folder. But tThe rename is not implemented. Is there a bug for that? * After okay the dialog, what should be a folder selection? Should it keep the current selection and update the thread pane, or unselect folder like "Rename Folder..."?
> After okay the dialog, what should be a folder selection? The folder should remain selected. If renaming a folder deselects it as you say, please file that as a bug.
could you look into converting your file into an overlay instead of moving the contents into the other file?
timeless, what is a benefit of using overlay for this?
Target Milestone: --- → mozilla0.8
>I think we should have multiple tabs in the folder properties dialog, and when >you do "View | Folder Charset Coding..." it would bring up the folders >properties dialog with the folder char set tab selected. Is "View | Folder Charset Coding..." still needed as a separate menu item then if it is part of "Edit | Folder Properties"?
>Is "View | Folder Charset Coding..." still needed as a separate menu item then >if it is part of "Edit | Folder Properties"? See my quoted comment of 2001-01-11 10:38.
r=sspitzer nhotta, please remember to CVS remove the folderCharsetDialog.* files from the tree. timeless, no need to move this code into an overlay if it is only going to be used in one place.
Jennifer, could you look at this (either now or after it's checked in)? I'm a little worried that the wording of the UI is not very user friendly (very few users know what the heck MIME is, for example). sr=bienvenu
The wording came from the preference dialog, "Message Display -> Languages", so you also want to reivew it. Cc bobj and momoi for the wording issue.
The wording of that preferences panel is currently under review in bug 65492.
checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Using 3-05-01 builds on winme, mac and linux, what we have is: A menu item under View for Character coding which provides a pull-out list A tab in the Folder properties for Character coding. (2) separate accesses to character coding (If I read this bug correctly, we wanted to keep the access point in both places but the plan was to do this: "when you do "View | Folder Charset Coding..." it would bring up the folders properties dialog with the folder char set tab selected". This isn't implemented. Was the fix suppose to do this? Waiting to verify.
It is supposed to select the charset tab when it's invoked by "Folder Character Coding.." menu. I only have a debug build on my machine but it's working that way.
This is working as intended with 3/6/2001 Win32 build. The folder prop dialog comes with the Character Coding tab selected.
Now I see where I went wrong in asking the question above. I was mixing up "Folder Character Coding" (a separate menu item which was added) with "Character Coding" menu item which has always been there and is different. Now I see it works the as discussed in this bug. Verified.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: