Closed Bug 125883 Opened 23 years ago Closed 15 years ago

Installer should set turbo mode (quicklaunch) to the same setting currently in use

Categories

(SeaMonkey :: Installer, enhancement)

x86
Windows 2000
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jesse.houwing, Unassigned)

References

Details

I'm always inslalling nightlies over old nightlies. Each time I have to enable
turbo mode when I do an install. This should be set to the current user pref, or
should be set to don't change or something.

This would result in 3 options:

O Enable turbo mode
O Disable turbo mode
O Leave current setting untouched

The last option should only appear if a previous installation is detected.
-> curt
Assignee: dveditz → curt
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hmm... either

( ) Enable turbo mode
( ) Disable turbo mode
( ) Leave current setting (enabled) untouched

(Where the text in brackets is either "enabled" or "disabled")

, or - more simple - 

( ) Enable turbo mode (Current Setting)
( ) Disable turbo mode

(Where the stuff in brackets is displayed behind the current setting)

. Confirming problem.
I like the second option more I think. With one small addition (but I think you
already have this in mind :) the current setting should be selected by default.

Another bug on the default value for Turbo is bug 100516. This one is about the
default setting when no previous installation is found, maybe this could be
integrated in a fix for this bug (as it seems pretty simple).
> With one small addition (but I think you
> already have this in mind :) the current setting should be selected by default.

Yup, had that in mind.

And perhaps have "(Current Setting)" in bold or italic?
*** Bug 140282 has been marked as a duplicate of this bug. ***
Summary: Installer should set turbo mode to the same setting currently in use → Installer should set turbo mode (quicklaunch) to the same setting currently in use
Why not simpler yet:  Checkbox for "Enble Turbo Mode" is checked if either the
user has never installed or has installed and selecte it before.  It is
unchecked if user has installed and unchecked it it previous.  This is the
simplest UI, would require no UI change from what we have currently, but would
require some logic change (we'd need to keep track of whether users have made
this decision for previous installations).

Anybody see any problem with this solution?
Yes, I have a slight problem with your solution. You want a) to fix the bug (I
like your solution on this) *and* b) turn turbo on by default when the user has
never installed mozilla before.

This is a change to the current behavior (it is turned off by default) and is
bound to lead to opposition (including mine). Could you please just fix the bug
and if you plan to turn turbo on by default have a seperate bug for this (which
can be bashed)?

Just keep it unchecked when never having installed it or preselect the option
which was detected from previous installations, no changes to UI and stuff. 
=> KISS (Keep it simple and stupid)
Sebastian: That would be bug 108795 I believe. Happy bashing :-)
Oops.  The "turn it on by default" suggestion was not a recommendation to change
current behavior but, rather, a brain cramp about what current behavior is.  So
I believe we are in complete agreement.
*** Bug 147057 has been marked as a duplicate of this bug. ***
*** Bug 181097 has been marked as a duplicate of this bug. ***
I would really love it if the installer could read the Turbo mode currenlty set
and use that as part of the installer, especially for the nightly builds.  If
it's not set then just leave it unchecked.  Any movement on this?
*** Bug 200248 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
QA Contact: bugzilla → general
Quicklaunch is done based on: Bug 383161 – keep in memory (turbo mode?) for
faster startup not working

so this one should be WONTFIX I guess.
Assignee: curt → nobody
The turbo mode is gone
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.