Closed Bug 73766 Opened 25 years ago Closed 18 years ago

UI problem: Can't uninstall bundled themes

Categories

(SeaMonkey :: Themes, defect, P3)

Product:
SeaMonkey
Component:
Themes
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
mozilla1.2alpha

People

(Reporter: gerv, Assigned: samir_bugzilla)

Details

You can't "Uninstall Theme" the themes that come with Mozilla. When selecting them, the "Uninstall Theme" button is greyed out. This confuses people. We could either: a) Add a text note to that pref panel b) re-enable the button but pop up a dialog (ugly) c) remove the button completely from the layout d) Change the button text to "[No Uninstall]" or similar. Gerv
D seems like the best of the four.
D's text needs a rewrite. I don't understand what's so wrong w/ E) leave it as it is. Perhaps A) 'It is recommended that you not uninstall this theme' or something...
But it's not "recommended", it's plain not possible.
you can't do it by editting installed-chrome.txt?
I don't think so. You can only uninstall themes that get installed to the user's profile directory, not the bin directory. See bug 71194.
The question is: how does a user tell the difference? To them, a theme is a theme is a theme. The problem is that the Prefs UI is prefs-specific (well, obviously :-) and these themes are available to all users. However, in the most common single-user case, a user doesn't give two hoots where the theme maker chose to install it. They'll just be annoyed if they can't remove it. <sigh> Perhaps we could uninstall these themes if _no_ profile is using them? But how to tell? Gerv
Well, really, we shouldn't allow any theme to be installed into the bin directory. All themes should be forced to be installed into the user's directory, except the two pre-packaged themes.
if you remove the default theme and then they create a new profile, the profile won't start (i think) == _BAD_ Not to mention the fact that only moz owner can delete global themes. IMO a clean approach is to mark themes a user can't remove in italics and not show the button at all.
That sounds good to me. /In absentia/ mpt, shall we go with that? Can we do italics on a per-line basis in that list box thing? Gerv
I think we can do that. I'll try and flag down mpt on irc and see if he has any comments.Keep the CC list clean...
The last question, then, is that: how do we do the italicisation? I've got the button disappearing correctly no problem, but I'm not sure if what we want here is possible. I know they do it in mailnews with bold, but it seems very complex, and they have C++ support for it. Gerv
| Category: Appearance ::::::::::::::::::::::::::::::::: | | +-------------------+ | | |=Navigator=========| ( ) Use my _system appearance | | | Identity | (*) Use a different _theme | | | Connection | _Available themes: Preview: | | | Helper Apps | +----------------+-+ +-----------------+ | | | Start Pages | |Aqua::::::::::::|A| | /( )\ /v\ /`| | | | History | |Lopburi Flat |:| | \( )/ \^/ \_| | | | Temporary Files | |Modern |V| |Back Fwrd Stop Up| | | |::Appearance:::::::| +----------------+-+ +-----------------+ | | | System | ( De_lete ) ( _Other ... ) | | |=Display===========| [/] Allow _highlighting of buttons and other | | | | controls when the cursor is over them | | | | | | +-------------------+ :::::::::::::::::::::::::::::::::::::::::::: | Where `my system appearance' is the Classic theme (but users don't need to know it's a theme, since it looks like the rest of the OS). So the user can delete any theme in the list, but they can't delete Classic because it doesn't appear in the list.
Wow... OK, well, I'm happy to implement it, but is there any chance of the patch actually getting accepted? That is to say, who need to sign off on this for it to be checked in? Changing the semantics of Classic to have some special status is quite a controversial move... Does Classic have a better platform-specific look than the other themes, then? What's this "Allow highlighting" business? Gerv
Why is Appearance under Navigator if themes aren't Navigator-specific? Why not under Display? Or am I misinterpreting your ASCII art?
The raison d'être of Classic (according to Ben) is to provide a contemporary system-compliant look and feel, yes. The `Allow highlighting' is another bug (bug 17639), nothing to do with this bug. :-) `Display' is to do with the display of content (e.g. text/html, text/xml, text/plain, message/rfc-822, */*), which themes are not part of. My placement of `Appearance' in the `Navigator' branch is based on earlier comments from the Theme People that different Mozilla apps would be able to use different themes. Note that I did not address the problem of themes which you couldn't delete because they were part of the root installation of Mozilla. For that, I think all that would be necessary would be to disable the `Delete' button.
A few points: Where you currently have "Use my system appearance," I would like to see that become the radio button for the default, unremovable theme. This UI doesn't work for vendors that choose to make classic optional, or not available at all. Why no description field for the theme? I'd like to see that come back. For /bin/ installed themes, when you choose to remove them, it should just be from the list, rather than from the entire product. This is because another profile may be using that theme. If you don't want to see it in your list, make it possible. If you really want to uninstall it, use the uninstaller that you used to install it. Third, I think it's time to end the dream of per app themes. I know we have the support for it, but I would tend to think that it's a terrible thing to support. Comments?h
> Where you currently have "Use my system appearance," I would like to see that > become the radio button for the default, unremovable theme. Sure. If distributors customized the selection of themes, they would have to change this text string too. > For /bin/ installed themes, when you choose to remove them, it should just be > from the list, rather than from the entire product. Yes. So whereas the alert for deleting a user-installed theme would be | | Are you sure you want to delete the selected theme? |, the alert for deleting a root-installed theme would be | | The selected theme cannot be deleted, because it is part of the Mozilla | installation and you do not have permission to change those files. Would you | like to hide the item in your list of themes instead? > Why no description field for the theme? Because the prefs dialog is too big (pixel-wise), and there's no point in providing an inevitably-corny description when you have a graphical preview available. > Third, I think it's time to end the dream of per app themes. Especially for the Mozilla app. :-| Designing UI for this sort of stuff is a pain.
--> Prefs
Assignee: mpt → sgehani
Component: User Interface Design → Preferences
OS: Windows 95 → All
QA Contact: zach → sairuh
Hardware: PC → All
->hewitt, for themes work here.
Assignee: sgehani → hewitt
QA Contact: sairuh → pmac
the themes pref panel doesn't belong to me
Assignee: hewitt → sgehani
QA Contact: pmac → sairuh
hmm, then i don't know/recall who does own the themes panel... blake? ben? someone else?
Component: Preferences → Themes
Priority: -- → P3
Target Milestone: --- → mozilla0.9.7
Moving to mozilla0.9.8.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Moving to milestone after mozilla0.9.9 (mozilla1.0 for now).
Keywords: nsbeta1+
Target Milestone: mozilla0.9.8 → mozilla1.0
Keywords: nsbeta1+
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
Life has moved on quite some way since this bug. Gerv
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.