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

Status: VERIFIED DUPLICATE of bug 127993

(SeaMonkey :: Themes, defect, P3)

Description

[akayser]

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)

Comment 1

[akayser]

Attachment: Patched with the 'type="radio"'

Comment 2

[Matthew T (active 1999-2002)]

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?

Comment 3

[Matthias Versen [:Matti]]

*** Bug 59889 has been marked as a duplicate of this bug. ***

Comment 4

[Fabian Guisset]

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.

Comment 5

[Matthew T (active 1999-2002)]

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

Comment 6

[Fabian Guisset]

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.

Comment 7

[Matthew T (active 1999-2002)]

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

[Fabian Guisset]

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. 

Comment 9

[sairuh (rarely reading bugmail)]

*** Bug 61524 has been marked as a duplicate of this bug. ***

Comment 10

[Matthew T (active 1999-2002)]

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.

Comment 11

[Blake Ross]

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.

Comment 12

[Matthew T (active 1999-2002)]

> 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

[Blake Ross]

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

[Peter "jag" Annema]

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

[Blake Ross]

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...

Comment 16

[akayser]

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).

Comment 17

[Matthew T (active 1999-2002)]

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

[Moses Lei]

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

Comment 19

[Zach Lipton [:zach]]

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...

Comment 20

[Asa Dotzler [:asa]]

updating to new owner. sorry for the spam.

Comment 21

[Kathleen :Brade]

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

[Jerry]

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 ***

Comment 23

[benc]

V/dupe.