Community
Participate
Working Groups
Some of the things that are provided in the platform installation pages might be of general use to more clients. Consider promoting these concepts to API...They are listed in order of importance. - The about CopyHandler redirects the copy command to the page. We could make this handler API and add the copy protocol in InstallationPage so that any page could use this handler for easy copy support. Otherwise each page has to come up with their own handler. - The support for setting selection variables is currently provided in ProductInfoPage. We could consider promoting this concept to InstallationPage so that client pages need only hook selection handlers on their list and call some framework method. I'm not even sure a client could get this working without us doing something here (because InstallationDialogSourceProvider is not API). - We could consider a common handler and command for getting the details of a selection inside an installation page. This could open a properties page or expand a tray. - ConfigureColumnsHandler and columns command. If an installation page provides a table, the same handler and command could be used to manipulate columns. (Another thought is to just get rid of this dialog.)
> - The about CopyHandler redirects the copy command to the page. We could make > this handler API and add the copy protocol in InstallationPage so that any page > could use this handler for easy copy support. Otherwise each page has to come > up with their own handler. I ended up developing a small ICopyable framework in p2 that allows a page to register which controls support copy, and have a handler installed that redirects the command back to the page. The focus service and handler activation is handled for free. It might be worth taking a look at these concepts and seeing if any of them should be promoted up to InstallationPage. If so, then also where does the copy command appear...in a button at the bottom (as it does in the config page), or in a toolbar, or in a popup?
I've been giving this some thought, and I'm really not happy with the contribution mechanism for about pages. It seems overly complex/generalized given we have only adopted the button bar and not the toolbar. This bug suggests promoting some of the common commands but instead I'm thinking we back down from using contribution items and adopt a more garden-variety dialog approach. Patch forthcoming...
I'm retitling/hijacking my own bug here. This bug started as..."hey, we have this command contribution scheme in the about dialog, and we implemented some commands for the platform pages, which ones should we promote to be common?" Now I'm more of the mind that we completely remove contribution items and command support from this dialog and go back to a JFace Dialog/DialogPage style solution that most page developers would expect. That is, a way for a page to easily create buttons while allowing the outer dialog to manage their placement. To summarize how we got here: - Back in M2 Kim and I discussed how to extend about (bug 246875). Kim was thinking the install details dialog would have a toolbar and a button bar and wanted to be a good citizen and use the menu contribution mechanism consistently for both. She wasn't sure about inventing a "button bar" concept but we needed buttons. She was afraid it might be a can of worms, as is evidenced by her code comments in this area. - During M6 while converting the pages, I couldn't find a use case for a common toolbar, so I ended up removing it without really reconsidering whether the menu contribution scheme made sense without a toolbar. - So now we have an extensive menu contribution scheme for contributing buttons to a page. I released it last week in order to allow p2 to integrate its pages with the platform pages, but I don't like the API. PROS: powerful and flexible - allows us to add a common toolbar or menus later and have contributions be consistent (would we ever do this?) - supports the contribution of install page commands by other plug-ins (ie, plug-in X can contribute a button to the Features page) - supports the contribution of existing commands to any page. CONS: too general, too error prone, more difficult to maintain - most developers (without the history) would expect a more low tech solution, where you just create the buttons you need in your page. This makes things like button enablement very simple inside the page. - In order to support using commands and declarative expressions to define the buttons, we have to support a bunch of new sources: active page, active page id, page selection, etc. - it is too easy to accidentally contribute to the wrong page (see bug 265272) - in practice, the commands used so far did little more than find the page via the source variables and call the original button click code from the page. So...I've released a more JFace-style scheme to HEAD. To compare old code and new code, compare these packages and plugin.xml in HEAD with the version titled pre-installPageContributionRevert. org.eclipse.ui.about org.eclipse.ui.internal.about org.eclipse.ui.plugin.xml org.elcipse.ui.ide.plugin.xml - For the platform pages (features, plug-ins, system), using a JFace-style was simple, because the dialogs were already written and just had to be moved to the page framework without significantly restructuring. Doing it with contribution mechanisms created a lot of new code to define things in terms of handlers, etc. - For the p2 pages, the pages were already using actions, so the difference between expressing these actions as contribution items or buttons was pretty small. (For example compare org.eclipse.equinox.internal.provisional.p2.ui.dialogs.InstalledSoftwarePage with the previous revision).
discussed with Boris and Paul. Consensus is: - the Jface/button approach does seem more appropriate. This bug will be closed. - it would be nice to have a common story for copy/select all in these pages (bug 266186). - there are existing platform hooks for allowing products to sort extensions such as properties pages, we might consider those vs. using the extension id's, so that RCP apps can explicitly sort contributions from different places. (bug 265917).
verified on WinXP, I20090310-0100 through source inspection
