I see. >- A user installs both CDT and DSDP at the same time and sees this set as >"C tooling". An entry points named "C tooling" is created.
Who picked the name "C tooling" (and when)? if the user in this scenario originally picked CDT and DSDP then they must have picked the overall name. feels like "entry point" has too many possible semantics associated with it (witness my interpretation of the term). this also feels like a pretty high burden to put on the user. Just imagine the bug reports. "When I go to add Mylyn it says that the Foo, Bar and Fred entry points need to be updated. why?" This level of capability would be great for advanced users but for beginners it seems too demanding. They just want to be told what the interesting "groupings/entry points" are. Since this is how people interact with the provisining system, there needs to be some shared understanding of names etc. If my Foo is different from your Foo, we can't talk about it. Perhaps this fits into the "bookmarks/favorites" metaphor mentioned earlier. Jeff Pascal Rapicault/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 08/22/2007 08:32 AM Please respond to Equinox development mailing list <[email protected]> To Equinox development mailing list <[email protected]> cc Subject Re: [equinox-dev] [prov] wondering how pluggable the IU user model is It seems that there is some confusion around the concept of "entry point". An "entry point" captures what the user installed in a profile. These entry points are what users will remember they have installed. In a UI for beginners, it will be what is being presented when the profile is being browsed, thus allowing to hide group IUs, configuration IUs, etc. Entry point will also be the entity that users ask for update and uninstallation. Example: - A user installs both CDT and DSDP at the same time and sees this set as "C tooling". An entry points named "C tooling" is created. - When he browses his profile, he sees "C tooling" and can act on it. By default, the groups that have been installed are not shown. - Now the user trys to install "Mylyn" but this requires a higher version of the RCP group than the one currently installed thus requiring a new version of CDT. In this case the user will be prompted with "do you want to update 'C tooling'", because it is the only thing he knows about. He does not want to hear about the RCP or Platform feature or what else. In short, entry points are not things to be found in metadata repositories. [EMAIL PROTECTED] wrote on 08/21/2007 08:46:08 PM: > > Maybe I'm really wondering how much the IU taxonomy will change from > product to product. > > We've already discussed that the presentation to the user of what a > repository is may differ from product to product. Or at least that > most end users (of the Eclipse SDK, RCP products) are unaware of > metadata and artifact repositories as separate entities. I would > expect that many products would want to keep the concept of a "site" > (maybe plug in their own terminology or icons), so we must have API > to find the artifact repo from a metadata repo or colocate them. > (See discussion in https://bugs.eclipse.org/bugs/show_bug.cgi?id=200259 ). > > Same is true for profiles. A user of most RCP products, and even > many Eclipse SDK users, would likely not want to know that the > provisioning infrastructure supports multiple profiles. Their view > is likely of the "product install location" or something like that, > and the fact that there exists a profile that drove this > configuration, the fact that bundles might be shared, etc...would behidden. > > So now I'm wondering if the same is true for IU's, at least those > that the user knows about. We have the notion of IU's that are > groups (which is how we filter the IU views in M1). And Pascal is > thinking about an "entry point" concept that would define what the > "product view" of a bunch of installable units would be. > > Should we assume a particular taxonomy for most/all RCP apps and > build a UI that can be reused in this way? > Pascal, do you think the entry point concept is the way that we > would expect many/most products to show the user what they have? > > I used to think that I could build a fairly reusable update UI that > could be plugged into different products. Products could define > their terminology for things like IU's (feature, add-on, plug-in), > and repositories (sites, repositories, etc.). Then I realized that > we need to do some mapping from the user view (site) to the reality > (metadata + artifact repo), and that we might have a default > strategy (such as colocation of repos), but ultimately we can't > assume how repos are presented to the user. > > Do we think that, for IU's, we can also come up with a default > strategy (such as entry points) for deciding how to present IU's? > ie, how to filter the list of IU's the user sees, and more > interesting, what would show up on the property page for those kindsof IU's. > > I hope this makes sense.... > > susan_______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
