Make in the View/Apply Theme submenu the list of themes a radiobutton list. How to: In content/navigator/navigatorOverlay.xul, add 'type="radio"' to the menuitem for the applyTheme action, so that it reads: <menuitem type="radio" uri="..." value="rdf:http://www.mozilla.org/rdf/chrome#displayName" name="rdf:http://www.mozilla.org/rdf/chrome#name" oncommand="applyTheme(event.target)"/> (Build ID: 2000092608)
Ok, does this patch: * operate correctly when different themes are applied to different components (e.g. if Navigator is Modern and Messenger is Classic)? * show expected behavior (no radio button at all) when Mozilla has no windows open on Mac OS?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: PC → All
*** Bug 59889 has been marked as a duplicate of this bug. ***
I think simply adding type="radio" won't fix it. At least it doesn't, here. Why? Because yes, it creates a radio-type submenu. But how could it know what to check/uncheck? We would need to add a reference to the rdf that contains the skin that is used at the moment, and honestly I don't know where it is (but someone should know). Besides the menu item value is "Apply Theme" and thus a radio button would make no sense. The menu is to "apply a theme", not to "know what theme I am using". Eventually, we could disable the menu item for the theme that is being used, it would be a good compromise. This solution however would not work with Matthew's objections about multi-themed browser/mail/composer/etc. To further discuss ( I'm cc'ed on this bug ) Fabian.
Instead of disabling the current theme (!), we could just rename the submenu `Use Theme' -- like the existing `Use Style' radio-type submenu.
Fabian, I'm not a programmer and I don't have CVS, so I'm not the one to fix this. If you want to prepare a patch, that would be great. Bear in mind that this is still in the UI:DF component (and is likely to remain so until Hangas gets around to reading his e-mail in a few months), and I don't have the authority to make the decision, so it's not absolutely certain that Mozilla will end up having a radio menu here.
I have discussed this enhancement with Peter Annema and Ben Goodger, and it appeared that it is impossible to code this enhancement in the current state of the mozilla UI. The reason is technical, and it won't be available anytime soon. Too bad, I am thus marking this "wontfix". Thank mpt for discussing this anyway. Fabian.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WONTFIX
*** Bug 61524 has been marked as a duplicate of this bug. ***
That resolution was completely out of line. In this respect Mozilla's interface is not behaving how any user would expect it to behave (as evidenced by the usability testing described in bug 61524). Therefore it is a real bug, and it should not go forever unfixed. If you can't fix this bug `anytime soon', then don't assign it to yourself. If it is currently technically impossible to fix, then please file dependencies for the changes needed to make it possible.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
This is similar to bug 43284, which was marked WONTFIX because bits and pieces of a skin can be applied at one time (and this will probably become easier UI- wise in the future). So if this is going to stay open for discussion, that one should also. We probably *should* have some way to indicate the active theme, but it needs to be a good way. Checking off multiple themes or doing other complex things would probably be too confusing and not worth it.
> Checking off multiple themes or doing other complex things would probably be > too confusing and not worth it. Allowing a user (as opposed to a theme author) to mix and match bits of themes or do other complex things would probably be too confusing and not worth it. Of (A) a user wants to know which theme they're using, or (B) a user wants to mix bits from various themes, which situation is going to happen thousands of times more often than the other? (Hint: it's not (B).)
I understand that. I also understand that there will be people using parts of different themes, and we can't just abandon them to satisfy those who won't, even if they make up the majority.
I guess the majority of users will use one skin across apps, and they would benefit from having feedback on which skin is currently selected. The (few?) users who mix and match skins would however receive misleading information, which doesn't seem like a good thing. If not harmful, annoying. mpt, does "Apply Theme" really belong in the View menu?
Right. I believe that whatever solution we arrive at should be intended to satisfy the majority. But I don't think just ignoring people who have multiple skins (by checking off one of them) is a good idea, especially if this becomes easier to do in the future. The UI shouldn't lie to you...
From the 'reporter': A good way to fix would be to give each component (window) with its own theme configuration a 'View/Use Theme' menu entry, so that the menu entry shows the used theme for the window belonging to the menu (works for both Mac, windows, and linux menu systems). As long as the multi-theme is not supported, switching one 'View/Use Theme' will automatically switch theme for all components. In summary: the 'View/Use Theme' entry of the Navigator window should show the theme used for Navigator, and the 'View/Use Theme' entry in the Messenger window should show the theme used for Messenger. This scheme works for all types of users. Activating 'multi-theming' should be an option in 'preferences', so that the bulk of the users are not confused, but the advanced users can turn on multi-theming. The UI remains the same. (except that for 'single-theme' switching in one window the theme, switches all windows, and for 'multi-theme' switching in one window, will only switch the theme of that window). In other words, showing the current used theme of the current window is therefor important and evident (see View/Use Theme menu).
If the user happens to be using bits of multiple themes in Navigator, then fine, don't show a radio mark next to any of the items. But that shouldn't stop Navigator from showing a radio mark in the huge majority of cases where the user is using only one theme. If the user happens to be using a different theme in Messenger than they are using in Navigator, then so what? This is *Navigator*'s View menu, and it should show which theme you are using in *Navigator*. Other apps should be none of its concern. Jag: No, `Apply Theme' is not used nearly often enough (except for debugging and demonstration purposes by advanced users) to deserve its own menu item. But as you can see in bug 43546, I lost that particular argument to the shiny things brigade.
*** Bug 57532 has been marked as a duplicate of this bug. ***
Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
Status: REOPENED → NEW
Related to this bug, I see: bug #53712 (Changing themes shouldn't re-apply current theme) bug #53430 (can't switch themes in Mail or Composer)
bug 127993.is duplicated one. but it has been resolved. so mark this one as dup of 127993. *** This bug has been marked as a duplicate of 127993 ***
Status: NEW → RESOLVED
Last Resolved: 19 years ago → 17 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
Component: Browser-General → Themes
QA Contact: zach → benc
You need to log in before you can comment on or make changes to this bug.