One of the new Requirements For Participation for the Eclipse Galileo Simultaneous Release is Capabilities . As the guy who championed this new "must do", I thought I would post an email I saved about this.
Things are progressing here, and I have what may be a stupid question, but I can't seem to find the answer via google or online help anywhere....
Lets assume that I ship the first release of this product I'm working on as a eclipse platform application, rather than an RCP. Given the numerous dependencies on EMF, GEF, GMF etc that I'll have how do I disable/remove their contributions to the File->New menu? My reasoning is that I really don't want to confuse the user with wizards they should not be looking at or using...
Any ideas on where I can look for examples on how to do this?
The obvious answer for the customer is to take advantage of capabilities in Eclipse. I know several teams have provided example capabilities, such as the platform and EMF, but they are just that, examples. Trying to get a set of working capabilities without the knowledge of how everyone's plug-ins and features fit together is not a fun task.
As part of our Galileo packages, wouldn't it be nice if we provided some out of the box, fully functioning capabilities to do just what our Eclipse customers are asking for. What parts should and should not be active when I am a C++ developer or a PDE developer? What are the advanced features? Do I need an extra capability to allow the end user to turn off the advanced features?
And by coming up with a proper set of capabilities, we will be able to do a little better job of integration testing and be able to turn off the tens of contributions to file -> new.
Subscribe to:
Post Comments (Atom)
3 comments:
Anthony,
If I recall my history correctly, when EMF provided capabilities, immediate concerns were raised that the way we categorized them wasn't the way products wanted to see them. I can imagine that an uncoordinated effort will result in mess of categories; it seems the most likely result. Fortunately, since they are required to be a separate feature, at least they can function as examples when not used directly.
The wording of the requirement is a little too strong though. Given that not all projects have UI contributions, not all projects should be required to define capabilities.
Another problem to consider is that EMF defines a whole bunch of small features and many of these do make UI contributions. Ideally each would provide separate capabilities relative to their specific contributions, but that would significantly bloat the number of plugins and features. How many additional plugins and features will the platform define for this?
I think they need to be examples. It's the final product's responsibility to arrange them in a way suitable for the product. Nobody can expect to anticipate a categorization of capabilities that will work in all environments -- although some of the example capabilities may prove useful in many environments. Therefore, I think that a single "example capabilities" bundle per project should suffice -- There's no need to invest lots of thought and time into trying to separate things at this point. Experience may prompt us to separate some at a later point as we gain more experience, and it should be a very easy thing to do. But for now, a single bundle should suffice.
Capabilities are not like actionsets to enable/disable as needed. They are more hidden (in the Preferences), they can auto-enable themselves via activity triggers, they are pervasive across all perspectives. That's what's making them more a "product" thing than a "framework" thing.
^-- What Ed said. I'm worried that without significant guidance and direction we're going to end up with a glut of capabilities that have no hope of working with one another.
Post a Comment