135572 - remove Theme Preferences from the View > Apply Theme submenu

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[sairuh (rarely reading bugmail)]

we should remove Theme Preferences from the View > Apply Theme submenu, because
it only brings up the themes prefs panel anyhow. this would be in line with the
removal of other menu items whose only (not so useful) function was to bring up
the prefs window.

Comment 1

[jglick]

I agree. Esp since the only thing you can really do with the theme prefs is 
change themes or get new themes, both of which the menus already provide.

Comment 2

[sairuh (rarely reading bugmail)]

over to steve

Comment 3

[Peter Trudelle]

nsbeta1+/adt3 per Nav triage team.

Comment 4

[Peter Trudelle]

Mass moving nsbeta1+/adt3 bugs assigned to Navigator team engineers out to
target milestone 1.0.1.  Please confine your attentions to driving down our list
of TM 1.0 bugs for beta.  Better to help, debug, or test one of them than fix
one of these.

Comment 5

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 6

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 7

[Gervase Markham [:gerv]]

Hmm. No non-Netscape people on this bug at all :-( Still, for what it's worth,
Pixeljockeys say this menu item should go, so if someone wants to make the
one-line patch to nuke it, that would be great.

Gerv

Comment 8

[Gervase Markham [:gerv]]

Scratch that. We decided to nuke the "Change Themes" menu altogether.

Gerv

Comment 9

[Stephen P. Morse]

reassign to component owner

Comment 10

[Mike Kowalski]

Attachment: fix

Comment 11

[timeless]

r=timeless

Comment 12

[Blake Ross]

"Some group decided to nuke this" is not enough rationale to justify anything in
a public bug.  I thought you of all people would be sensitive to that, Gerv...
if pixeljockeys is going to call the shots then it's responsible for providing
the minutes or thought process of the meeting to everyone, right here, as a
public record.  As far as the menu spec
(http://www.mozilla.org/mailnews/specs/proposals/MenuFrame.html) is concerned,
furthermore, no such decision was ever made.

In any event, I don't think there's any reason to jump into this.  The advantage
is nuking one menuitem in a menu that's already pretty short.  The disadvantage
is that it's a safe bet that anyone who enjoys themes will assume we removed them.

Comment 13

[Gervase Markham [:gerv]]

Yep, fair point. Don't know what I was thinking.

The original subject of this bug is still, IMO, fair game - the menu item which
just brings up a particular prefs panel. 

Gerv

Comment 14

[jglick]

The rational/thought process for this decision from pixeljockies:

We had/have a several menu items whose sole purpose was/is to bring up the Prefs 
dialog with a specific panel already selected. It was felt that in general, this 
wasn't good design and added unnecessary menu items. We would keep 
the Edit:Preferences menu item as the main way to access prefs and get rid of 
the duplicate Pref access menu items. 

In this specific case, the Themes pref panel allows users to:
1. Select a theme (already a View: Get Themes menu item)
2. Get new themes (already a View: Get Themes menu item)
3. Uninstall themes

Comment 15

[Blake Ross]

jglick: sure, I totally agree with that.  But this bug morphed into remembering
the entire Apply Theme submenu -- what was the rationale for *that*?

Comment 16

[Blake Ross]

jglick: sure, I totally agree with that.  But this bug morphed into removing the
entire Apply Theme submenu -- what was the rationale for *that*?

Comment 17

[jglick]

>jglick: sure, I totally agree with that.  But this bug morphed into removing 
>the entire Apply Theme submenu -- what was the rationale for *that*?

Ah, didn't catch the 'remove the whole menu' part. Sorry.

OK, looking back at my notes, I believe the removing the whole theme menu was 
suggested because switching themes on the fly doesn't work. Hence the logic was, 
if "Theme Prefs" was removed and on the fly theme switching didn't work, the 
only menu item left was "Get New Themes". But that was suggested back in April. 
If theme switching on the fly can be fixed, I think i'd much rather see the menu 
remain at this point.

Comment 18

[Mike Kowalski]

Attachment: patch

This patch gets rid of the Theme Preferences menuitem. If it's decided that the
Apply Theme submenu will be kept, use this patch, otherwise use the first
patch.

Comment 19

[Doron Rosenberg (IBM)]

Comment on attachment 92270 [details] [diff] [review]
patch

r=doron

Comment 20

[Jesse Ruderman]

Removing the entire submenu is (also?) bug 141331.

Comment 21

[Mike Kowalski]

Changing back to original summary. There's another bug for removing the submenu.
Even if we don't nuke the submenu, this menu item has got to go.

Comment 22

[jag (Peter Annema)]

Comment on attachment 92270 [details] [diff] [review]
patch

sr=jag

Comment 23

[Mike Kowalski]

fixed

Comment 24

[sairuh (rarely reading bugmail)]

vrfy'd fixed with 2002.09.19.08 comm trunk builds. Theme Preferences is no
longer in the Apply Theme submenu.