[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] Is there a need: optional features - disabled at first install
|
If we forget implementation issues for now (implementation is reasonably
simple), the real question is whether users will know what they are doing :
-). Try as I might, I cannot recall an example where I was asked to select
optional portions of a product, then was not able to use them when the
installation was complete. From the usability standpoint, it strikes me as
less severe to ask users to disable optional features they don't need after
the installation than to figure out why they cannot find the
menus/toolbars/etc. for the feature they are sure they installed.
Another problem with the proposal is that we are encoding optional feature
state in the feature manifest itself. If anything, users should be asked
about the initial state of the optional feature right where they are asked
whether to install it or not. If the default state encoded in the feature
is 'disable', users will be mightily pissed that they cannot find an
optional feature they are certain they checked in the install wizard. In
other words, setting this in the manifest means that somebody will make a
decision for a users as to whether they need the feature or not even if
they choose to install it.
Another subtle point here is that we will be introducing a notion of
enabling/disabling features very early in the process. The only place to
change the state of a feature is in the Install Manager, and I was under
impression that we don't want normal users to go there unless they really
have to (hence the 'one-click update' capability).
Last but not least, the entire Eclipse platform was designed with lazy
loading in mind. Having a feature installed does not mean much unless its
plug-ins are actually used, and they will not be activated unless something
triggers it. To use your example, the fact that PDE is installed (and
enabled) as optional feature does not mean that PDE will ever run unless
you trip-load it by creating a new plug-in project or activate another of
its extensions.
I would therefore reason that I think it is a lesser evil to let users
install all the optional feature they think they will need, then figure out
how to temporarily remove them (by disabling them) from the picture. I like
it more then trying to figure out why are there no PDE artifacts even
though its installation was explicitly requested.
Regards,
Dejan Glozic, Ph.D.
Application Development
D2/MY7/8200/MKM
IBM Canada Ltd.
Tel. 905 413-2745 T/L 969-2745
Fax. 905 413-4854
Pat
McCarthy/Raleigh/IBM@IBMUS To: platform-update-dev@xxxxxxxxxxx
Sent by: cc:
platform-update-dev-admin@ Subject: [platform-update-dev] Is there a need: optional features - disabled
eclipse.org at first install
09/10/2002 06:10 PM
Please respond to
platform-update-dev
Goal is the ability to configure a system with more features than I might
need or even think I might ever need. But at the same time, have the right
to install all the features that fall into the "category of not yet" and/or
"maybe not ever" such that they are optional (works today in 2.0.1), but
disabled at first reference.
I want to avoid finding out later that a feature I did not install is now
critical to my task and having to chase down the CD, find an install site,
or any of all that to get the feature running on my configuration. This
would allow me to install more code, but use less at first launch.
For example, if an install has four features: MustUse, ShouldUse,
MightUse, ProbablyNeverUse
MustUse is a root feature
ShouldUse is included by MustUse (optional="true")
MightUse is included by ShouldUse (optional="true")
ProbablyNeverUse is included by MustUse (optional="true")
I'd like to have the MightUse feature tagged with defaultEnable="false".
This could be in the MightUse feature.xml, but could also be in the include
of MightUse by the ShouldUse feature.xml as well.
This way I could say this during the install:
feature install enable
MustUse Yes forced
ShouldUse Yes yes
MightUse Yes no
ProbablyNeverUse no no
I want to avoid finding out later that MightUse is now critical to my task
and having to scramble to find a way of adding it to my system.
Or put another way, I'd like to have products that install PDE just in
case, but set it up so that it is disabled by default. When I discover
that I can develop extensions - I'd want to enable PDE and get to work, at
least in one workspace.
Anybody agree that this might be worthwhile? (I'll add a bugzilla feature
request if so).
What I have been able to do is mimic this by following this process:
Configure base workbench on disk and then invoke using eclipse -initialize
Then either:
1) Add link file to feature I want available but not installed.
2) Unzip/add new features I want available but not installed into current
eclipse directory
(tried both of the above using the eclipse examples as the added features)
Start Eclipse without any options, say no to Updates Pending Dialog.
If you wander over to Install/Update and request that the view show
disabled features, the examples are there and ready to be enabled when you
like...
On subsequent invocations for that workspace you do not get prompted by the
Updates Pending dialog.
Comments?
Pat Mc.
