53430 - can't switch themes in Mail or Composer

Status: VERIFIED WONTFIX

(SeaMonkey :: UI Design, defect, P2)

Description

[Kathleen :Brade]

I want to switch themes from Mail or Composer (especially right now while each 
theme has its own set of bugs which affect how usable a component is).  
Unfortunately the View | Apply Theme menu is not available in the menus in either 
Mail or Composer.

Because Themes is a cross-product feature and is in the Appearance (general) 
category in the Preferences window, it seems like the View menu for every 
component should allow for switching themes (consistency!).  I personally find it 
very confusing that I can't switch themes from the View menu in Mail and Composer 
(I thought it was a bug until I asked around).

Is there a good reason for not having this functionality in other components or 
is it just a lack of time?

Comment 1

[hangas]

Nominating for RTM++.  Theme switching is an important feature that currently is 
only visible from the browser menu.  It should really be available from every 
window.

Comment 2

[johng]

nav triage team:
we agree with hangas, want to say rtm+ but can't under new rules until we get
the patch, so marking RTM NEED INFO

Comment 3

[verah (gone)]

Nav triage team: Because of other really bad bugs, we don't want people to 
change themes from Mail or Composer windows. RTM-

Comment 4

[Joe Hewitt (gone)]

Not really a themes bug, re-assigning to xp apps

Comment 5

[Blake Ross]

taking...

Comment 6

[sairuh (rarely reading bugmail)]

wouldn't this be more appropriate in skinability...? or is it something as
simple as adding the feature to the menus?

cc'ing mail folx who might be interested...

Comment 7

[Blake Ross]

Should I wait on this until the major editor skinability problems are fixed?

Comment 8

[Blake Ross]

Attachment: [patch] here's the fix when we want it (just code shuffling)

Comment 9

[Blake Ross]

cc timeless/alec for r/sr

Comment 10

[timeless]

wrong license. use boilerplate mpl for new files.
\ No newline at end of file
column limit: 80 *exceeded*
applyThemeOverlay.dtd has no consistency for data column.

then there's the very important issue of do we want this in 
chrome://communicator/ or chrome://toolkit/ or chrome://global/, I suspect we 
want it in global.

The actual content looks fine. And i'll verify that when i grab a verification 
build.

Comment 11

[Blake Ross]

I will fix the whitespace stuff.

cc'ing frank re: license.

We want this in communicator because it's only useful to Communicator, and 
useful to the apps in the suite.  Global is for files that are useful to third-
party developers, but this is very specific to Mozilla (not to mention the fact 
that this new overlay depends on code in utilityOverlay.js, which rightfully 
lives in communicator).

Comment 12

[timeless]

I thought the whole point of themes was that people could write their own apps 
and theme them.

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

OK. I originally requested that this not be added to the menu structure of these 
other apps for a reason: to avoid adding extra complexity to an already crowded 
menu hierachy. My point remains.

Can someone explain why skin switching is high-impact enough to warrant 
menuitems in mail3-pane and composer?

Comment 14

[scottputterman]

One other thing to consider is that theme switching isn't very safe in mailnews
and mail compose yet. Currently we lose whatever data existed in these windows.
We have bugs out to fix this, but we might not want to encourage the switching
until these bugs get fixed. See bug 54397 for details.

Comment 15

[Matthew T (active 1999-2002)]

Since theme switching will only be done about once or twice a year by a typical 
user, if that, no way does it belong in the menus.

Comment 16

[Alec Flett]

Coolness.
I'm thinking global or communicator is fine, I think ben should have the final
say. 'applyThemeOverlay' seems like too narrow of a focus to justify a seperate
overlay. it seems like we either need a themesOverlay which inclues any other
themes-related stuff (like what? I don't know) or we need to roll this into
utilityOverlay or a related file.

Comment 17

[Blake Ross]

ben: I'm fine with not including the menu in editor or mail (although that's 
those teams' call), but if we're not going to include it there, I think we need 
to remove it from Navigator also (as Matthew suggested).  How is such a menu 
justified just for the browser, but not for mail or editor?  They're separate 
apps; you can't assume the user's going to have the browser open if they're 
checking their email.

putterman: that's what I asked in my 1/20 comment.

alec: thanks for taking a look, but I don't think we'll be doing this after all.

So, our options here are:

(1) Add the menu to the other apps.
(2) Leave things the way they are, close this bug.
(3) Remove the menu from navigator.

2 seems awkward to me, but I'm okay with any of them.  Let me know.

Comment 18

[Alec Flett]

I think that eventually other apps will want to do this, so we should still move
it into an overlay, but only put the menuitem in navigator for now.

Comment 19

[Ben Goodger (use ben at mozilla dot org for email)]

I'd go for communicator, if you want to do this (although I can think of many 
things that your time would be better spent doing ;) This implementation of 
theme switching is specific to communicator and is of no use to other apps. 

Preferences->Appearance->Themes remains a global access point, and the effort 
required to reach it reflects the frequency of its use. 

Comment 20

[Matthew T (active 1999-2002)]

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

Comment 21

[Stephen Walker]

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

Comment 22

[Blake Ross]

We can move this stuff out into an overlay when it becomes necessary.  Closing 
this for now.

Comment 23

[timeless]

don't do that.

Comment 24

[Blake Ross]

What on earth do you mean `don't do that'?  Do you scour bugzilla looking for 
ways to piss people off?  I'm closing this bug because there's no reason for it 
to remain open.  If this needs to be in an overlay in the future, the patch 
will always be here.  We'd be wasting a lot of precious time and pollute the 
codebase if we tried to plan ahead for every possible scenario.

If you reopen this again, you can also explain why you deserve to have 
priviledges to make changes to bugs.

Comment 25

[Eric Vaandering (no email)]

Don't know what timeless is thinking, but this bug exists. The patch may not be
the right way to fix it, but it should be fixed in some manner. Why not leave
this bug open to collect those looking for the fix?

Comment 26

[Blake Ross]

Because we have the fix already, it's attached.  It was a design decision, not 
an inability to implement it.

Comment 27

[timeless]

it was a design decission to implement it. you made a decission to not 
implement it _now_ which is equivalent to reassign to nobody and/or 
milestone future.

The attached patch bitrotted, i'll take this bug now.

Comment 28

[timeless]

taking bug.  I will try to get approval for the architecture portion of this 
bug. Whether the title portion is actually committed we can fight over later.

Comment 29

[Blake Ross]

So here's the deal:

* No `design decission' [sic] was ever made to implement this at some point, 
and I'd say any claim to the contrary is a blatant lie.

* I don't know who you intend on getting final approval from, but it would have 
to come from either Ben (UI owner), Matthew (UI Design component owner), or 
myself (the former owner of this bug, the current XPApps: GUI owner, where this 
bug rightfully belongs, and the original implementor of this menu).  Ben and 
Matthew have both expressed their discontent with this idea earlier; if I 
didn't, I'm doing it now.

Closing this bug again.  If you feel that strongly about this, please start a 
thread in n.p.m.ui to garner support for it.  In the interim, please let 
sleeping dogs lie -- and this patch is not to be checked in (yes, even 
the "arch" portion; why are you going to add another file and overlay another 
file onto Navigator when the odds are that this menu will be removed altogether 
in the future?).

[un-cc'ing Alec, since I just cc'd him for sr, and I know how much he hates 
spam.  If I'm mistaken, feel free to readd yourself -- thanks!]

Comment 30

[timeless]

Attachment: updated patch

Comment 31

[Hixie (not reading bugmail)]

VERIFIED WONTFIX per comments from mpt, Ben and Blake.

Comment 32

[Stephen Walker]

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

Comment 33

[Peter Lairo]

This bug is an important evangelism issue - novice users shuld be able to easily
ee and use this feature. It may not make complete sense from a vulcan
standpoint, but it make a lot of sense from a "coolness" standpoint. I can just
see someone showing his friends how easy it is to make Mozilla look all kinds of
different ways. This "coolness" factor should not be underestimated, especially
since it will draw a lot of attention from "semi-novices" who want quick access
to cool features (and aren't bothered by prefs settings). Also persons who
only/mainly use Mail/News would be duly impressed.

Please reopen this bug.

Comment 34

[Alex Bishop]

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

Comment 35

[Not interested in Mozilla any more]

When I use Mozilla I have it open straight into the mail system. I only open the
browser window when I need it, which is fairly occasionally. I was quite
supprised to see that there was a change theme menu item on the browser window.
Having found this I was attempting to demonstrate it to another user and
couldn't find it, it was then I realised it was not on the mail window. It
should be on all windows or none. My personal preference is for all.

Comment 36

[Gilles Durys]

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

Comment 37

[R.K.Aa.]

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

Comment 38

[Mark Bitterling]

Bug 90638 and Bug 135022 have both also been marked as duplicates of this bug