If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

In View/Apply Theme submenu, mark active Theme by a checkmark

VERIFIED DUPLICATE of bug 127993

Status

SeaMonkey
Themes
P3
minor
VERIFIED DUPLICATE of bug 127993
17 years ago
9 years ago

People

(Reporter: akayser, Assigned: Matthew Paul Thomas)

Tracking

({polish})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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)
(Reporter)

Comment 1

17 years ago
Created attachment 15822 [details] [diff] [review]
Patched with the 'type="radio"'
(Assignee)

Comment 2

17 years ago
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. ***

Comment 4

17 years ago
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.
(Assignee)

Comment 5

17 years ago
Instead of disabling the current theme (!), we could just rename the submenu
`Use Theme' -- like the existing `Use Style' radio-type submenu.

Comment 6

17 years ago
Looks good to me. mpt, have you got time for this, or do you want me to do it?
The fact is that I'm begining in XUL/javascript and this could be a good project
for me, but it would probably take me a lot more time than it would for you
(I assume). So it's up to you. If you've got better things to do, i'll take a
look at the use-stylesheet submenu code and i'll try to make it work for this
submenu.
Fabian.
(Assignee)

Comment 7

17 years ago
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.

Comment 8

17 years ago
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: 17 years ago
Resolution: --- → WONTFIX
*** Bug 61524 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 10

17 years ago
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 → ---

Comment 11

17 years ago
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.
(Assignee)

Comment 12

17 years ago
> 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).)

Comment 13

17 years ago
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.

Comment 14

17 years ago
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? 

Comment 15

17 years ago
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...
(Reporter)

Comment 16

17 years ago
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).
(Assignee)

Comment 17

17 years ago
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.

Comment 18

17 years ago
*** Bug 57532 has been marked as a duplicate of this bug. ***

Comment 19

17 years ago
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

Comment 20

17 years ago
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
Status: REOPENED → NEW

Comment 21

17 years ago
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)

Comment 22

16 years ago
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: 17 years ago16 years ago
Resolution: --- → DUPLICATE

Updated

16 years ago
Keywords: polish

Updated

15 years ago
Component: User Interface Design → Browser-General

Comment 23

14 years ago
V/dupe.
Status: RESOLVED → VERIFIED
Component: Browser-General → Themes
QA Contact: zach → benc
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.