Closed Bug 84882 Opened 23 years ago Closed 23 years ago

Need turbo mode setting in browser prefs

Categories

(SeaMonkey :: Preferences, defect)

x86
Other
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.2

People

(Reporter: slogan, Assigned: slogan)

References

Details

Attachments

(6 files)

Need to allow the user at install time to specify if the turbo mode should be enabled or not. Also need preferences to allow the user to turn on and off turbo mode.
Keywords: nsbeta1+
Target Milestone: --- → mozilla0.9.2
Next step is to figure out how to handle setting and clearing of turbo mode in both the native install and in the prefs panel.
Bug 81149 deals with having an option in the installer to enable turbo mode and bug 83882 deals with the preferences UI. However, none of these bugs have code attached (though bug 81149 in particular has some relevant discussion), so they should be marked as duplicates of this bug.
Syd, please don't use the word "Turbo" etc in the UI. (If we're going to use any cute gimmicky names, it should be "Silvia", but I feel I'll be outvoted on that). Anyhow, Turbo really doesn't describe what the functionality does. This is better but not perfect: <!ENTITY enableTurbo.label "Start &brandShortName; silently when I start my computer"> Again, not perfect, but better: -IDC Turbo Mode=&Obtain faster startup times by executing in turbo mode +IDC Turbo Mode=Start &brand; silently when I start my computer to make new browsing sessions begin faster. It's important to identify that this is enabling *preloading*. You may want to deselect this option by default if the target machine has less than 128Mb RAM...
resetting subject for prefs side of things, installer is covered in another bug
Summary: Need turbo mode setting in installer and browser prefs → Need turbo mode setting in browser prefs
The installer option is covered in bug 81149.
Shouldn't the 'Component' field be updated?
Blocks: 75599
Component: Installer → Preferences
besides the removal of a localization comment: -<!--LOCALIZATION NOTE (enbJavaCheck.label): 'Java' should never be translated --> from: /cvsroot/mozilla/xpfe/components/prefwindow/resources/locale/en-US/pref-advanced .dtd other than that, r=ssu
*** Bug 83882 has been marked as a duplicate of this bug. ***
1) I didn't understand what was going on with CreateALink. Could you tell me more about what that's supposed to be doing? 2) Do we really need to link with OLE to make this work? I guess that CreateALink method makes it a requirement. 3) For some reason I thought we were past the localization freeze. Is adding these strings going to cause them a problem? We may need to get an OK from a localization person. 4) Did you have a chance to have a UI person (german or jennifer) help you out with where we are adding the turbo functionality. Seems like you have it in a good spot to me but I don't believe in engineers (i.e. myself) dictating UI policy =). The rest of the code looks good to me.
sr=mscott, a=asa
Anyone able to attach a screenshot of this UI change? I can see three problems from reading the patch itself. (1) The checkbox is in the wrong panel -- it should be in the `System' panel, along with the other Windows-specific OS-related prefs. (2) The word `enable' is introduced twice, which (a) sounds like an order rather than an option, and (b) is tautological with the fact that you're using a checkbox. (Yes I know that mistake exists in other places in the panel, but precedent is no exuse.) (3) An entire groupbox is used to surround only one control (the checkbox), making the UI look incomplete.
rewording was done before I landed. and I consulted documentation people inside of netscape for assistance.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Matthew: I think you should open new bugs based on your comments.
re: #3 in mpt's comments, ugh. It's definitely far from pretty, but we do it all over the place (Software Installation, Colors > View Source Window, Smart Browsing, etc.). I know, precedent isn't justification, but I think there needs to be a larger-scale effort to clean up these singular "groups". Verifying fixed, though, since the UI's there. But I think we need new bugs opened on what Matt mentioned.
Status: RESOLVED → VERIFIED
Could someone please file a bug for me, with a screenshot attached? I can't see this UI, so I don't know what else needs fixing. Thanks.
Please open a new bug for your UI issues, assign to someone else, and discuss there. And don't CC me -- I worked with enough people on getting this right to begin with. I'm learning *everyone* is a UI expert, I have a feeling whatever we do, it will never make anyone happy, and I've got other, more important stuff to look at. Thanks :-)
No longer blocks: 75599
Blocks: 75599
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: