|
|
|
| Re: Target 3.4 and 3.5 P2 APIs despite APi changes - fragments? [message #49184 is a reply to message #48335] |
Wed, 04 March 2009 16:20  |
 Chris Williams
Messages: 29
Registered: July 2009 |
Junior Member |
|
|
Chris Williams wrote:
> Pascal Rapicault wrote:
>> As an aside I would be interested in understanding why you can't use
>> the p2 UI (3.4 or 3.5).
> It's basically just an ease of use feature. We pop up an install wizard
> that is a tree of features we offer as well as common 3rd-party features
> that are popular among our users. Users check off what they want,
> oblivious to the need for the repo URI/URLs or what IU they need to check
> off. We then add the necessary repos for that feature under the hood,
> query for the specific feature group IU and then start the P2
> InstallWizard with those IInstallableUnits.
> This makes it much easier for users to plugin in our other features
> quickly and painlessly. Obviously with 3.5 we could add touchpoints that
> add the repositories for them, but even then, the P2 UI can be a bit
> overwhelming for many people - all they know is "I want a Git plugin".
> Particularly since we ship our own standalone and those users aren't
> familiar with Eclipse.
As an effort to be a bit more helpful, here's the concrete
enhancements/fixes we'd really need for the P2 UI to match what we have. I
know that some of these are/have been addressed for 3.5 ("Uncategorized",
and the addRepo touchpoint, I believe) but beyond that I'm not sure if
these could/should be entered as enhancement requests. At the very least
it gives you an idea of the UI and workflow we prefer users have to
install additional features into our product.
1. The addRepository touchpoint working so we can pre-populate with all
the repos we hide from the user in our UI.
2. Ability to filter the contents of the repo listing - i.e. no more
"Uncategorized". In most cases we just want to show one umbrella feature.
3. Ability to decorate the main IU with an icon, description, and an URL
link the user can click to see "more" about the feature/plugin.
4. The ability to hide/combine multiple actual repos into one logical
repo. The main genymede update site is nice because pretty much everything
is in one main repo/root. We build all our features separately and point
to third-party repos. but we really want the repos themselves to sort of
not be shown, and instead to compose multiple of them under one root
labelled with our product's name or something along those lines.
To describe our UI: it's a tree of features under categories (like SCM,
Languages, Mobile). The categories and features have sort weights that
correspond to where the show up vertically in the tree (so that we can
push the more common/popular ones to the top). Each feature has an 16x16
icon, a short description and a link to learn more about it. The repos
themselves are hidden and do not really play into the view at all, each
feature tree node contains the repo it can be found on in it's metadata.
The feature id is also hidden from the user but kept in the metadata.
The user clicks something like "SCM > Git integration" and under the hood
we grab the feature id (and append ".feature.group") and the repo URL and
then use the P2 APIs to query the repo for that feature group and then
begin the installation process.
|
|
|
|
|
| Re: Target 3.4 and 3.5 P2 APIs despite APi changes - fragments? [message #592727 is a reply to message #48335] |
Wed, 04 March 2009 16:20 |
Chris Williams
Messages: 29
Registered: July 2009 |
Junior Member |
|
|
Chris Williams wrote:
> Pascal Rapicault wrote:
>> As an aside I would be interested in understanding why you can't use
>> the p2 UI (3.4 or 3.5).
> It's basically just an ease of use feature. We pop up an install wizard
> that is a tree of features we offer as well as common 3rd-party features
> that are popular among our users. Users check off what they want,
> oblivious to the need for the repo URI/URLs or what IU they need to check
> off. We then add the necessary repos for that feature under the hood,
> query for the specific feature group IU and then start the P2
> InstallWizard with those IInstallableUnits.
> This makes it much easier for users to plugin in our other features
> quickly and painlessly. Obviously with 3.5 we could add touchpoints that
> add the repositories for them, but even then, the P2 UI can be a bit
> overwhelming for many people - all they know is "I want a Git plugin".
> Particularly since we ship our own standalone and those users aren't
> familiar with Eclipse.
As an effort to be a bit more helpful, here's the concrete
enhancements/fixes we'd really need for the P2 UI to match what we have. I
know that some of these are/have been addressed for 3.5 ("Uncategorized",
and the addRepo touchpoint, I believe) but beyond that I'm not sure if
these could/should be entered as enhancement requests. At the very least
it gives you an idea of the UI and workflow we prefer users have to
install additional features into our product.
1. The addRepository touchpoint working so we can pre-populate with all
the repos we hide from the user in our UI.
2. Ability to filter the contents of the repo listing - i.e. no more
"Uncategorized". In most cases we just want to show one umbrella feature.
3. Ability to decorate the main IU with an icon, description, and an URL
link the user can click to see "more" about the feature/plugin.
4. The ability to hide/combine multiple actual repos into one logical
repo. The main genymede update site is nice because pretty much everything
is in one main repo/root. We build all our features separately and point
to third-party repos. but we really want the repos themselves to sort of
not be shown, and instead to compose multiple of them under one root
labelled with our product's name or something along those lines.
To describe our UI: it's a tree of features under categories (like SCM,
Languages, Mobile). The categories and features have sort weights that
correspond to where the show up vertically in the tree (so that we can
push the more common/popular ones to the top). Each feature has an 16x16
icon, a short description and a link to learn more about it. The repos
themselves are hidden and do not really play into the view at all, each
feature tree node contains the repo it can be found on in it's metadata.
The feature id is also hidden from the user but kept in the metadata.
The user clicks something like "SCM > Git integration" and under the hood
we grab the feature id (and append ".feature.group") and the repo URL and
then use the P2 APIs to query the repo for that feature group and then
begin the installation process.
|
|
|
Powered by
FUDForum. Page generated in 0.02841 seconds
] 
Search
Help
Register
Login
Home
