Bugzilla – Full Text Bug Listing
| Summary: | [About] allow for an extensible About dialog | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Kim Horne <eclipse> | ||||||||||||
| Component: | UI | Assignee: | Susan McCourt <susan> | ||||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||||
| Severity: | normal | ||||||||||||||
| Priority: | P3 | CC: | digulla, dj.houghton, gabriele.garuglieri, john.arthorne, Kevin_McGuire, mik.kersten, milesparker, pascal, prakash, pwebster, remy.suen, robert.elves, shawn.minto, susan | ||||||||||||
| Version: | 3.5 | ||||||||||||||
| Target Milestone: | 3.5 M6 | ||||||||||||||
| Hardware: | All | ||||||||||||||
| OS: | All | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Bug Depends on: | |||||||||||||||
| Bug Blocks: | 224472, 227220, 236740 | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Kim Horne
We currently use IBundleGroup as the abstraction in the about dialog to avoid dependency on update. Assuming this isn't sufficient (because we want to talk about more than just bundles), we'll likely need to deprecate IBundleGroup/IBundleGroupConstants/etc as part of this work. A few things I didn't capture in the mockups: - the list of what's installed (plug-in, feature, p2 view) can get quite big in certain products. If we go with the idea of a "standard layout" on each page, where each contributor is providing a content provider and some commands that feed a common list presentation, then we need to consider adding a filter to this view. I think it would be nicer to have this be provided as a standard rather than having each page contributor do something different. - likewise, the current "columns..." buttons in the plug-in and feature views could be provided in some standard way for all columnar views Also, the mockups show a common "details" area. This is another thing that could be considered standard across all lists. So that it's always in the same place (perhaps in a tray?) >Assuming this isn't sufficient (because we want to talk
>about more than just bundles), we'll likely need to deprecate
>IBundleGroup/IBundleGroupConstants/etc as part of this work.
I was thinking that the feature details view of the world might continue to exist. Some current p2 users are used to this view of the world. Also in some installations that don't provide self-updating capability, this may be the view that is used for support, etc.
Created attachment 112344 [details]
Patch against workbench/ui
Initial attempt at an extensible dialog. It's not currently wired into the about at all, but it does have a command to open it. See "Installation Dialog" under the keys page or ctrl-3. There is absolutely 0 polish at the moment, so buyer beware.
Some choices:
1) it's entirely based off our new menu/service story. Each page has a set of well known menu ids (exposed via the IInstallationDialog interface) that can be used to augment a toolbar (at the top of the dialog) and the button bar (at the bottom).
2) the button bar extensibility is all new and required our menu service to be able to populate a composite with buttons. Using something like this makes our problem considerably less well contained than the dialog itself, however, as we may have to / want to make the ButtonManager API as well.
Susan: if you can give this a look at see if it is at least marginally useful for you now I will endeavor to put it into HEAD for M2. It still wont be wired up to about then, but at least we can get some more feedback on the mechanism.
As for standard pages that clients can extend (of the tree/table nature you've mentioned) that has yet to be tackled.
yes, this is useful to get started.
It didn't take long to get the content of the current "Installed Software" page to show up in here, though I haven't added the actual buttons yet because I'm new to the menu service model. Is the idea here that I want to use the provided service locator to access both the IMenuService and the IInstallationPageContainer, and having gotten to those I'd do something like...
menuService.populateContributionManager(myInstallContributionManager, pageContainer)
I'll need to play with this to see the impact on my current action structure, but if this is the state of the art in platform UI, I think it's a good idea to use it.
>As for standard pages that clients can extend (of the tree/table nature you've
>mentioned) that has yet to be tackled.
No worries, that seems like a polish item once we get it wired in.
I'm seeing some odd layout (can only see the top corner of the button at the bottom), but you warned me...
Thanks for getting something to me so fast.
(In reply to comment #5) > yes, this is useful to get started. > It didn't take long to get the content of the current "Installed Software" page > to show up in here, though I haven't added the actual buttons yet because I'm > new to the menu service model. Is the idea here that I want to use the > provided service locator to access both the IMenuService and the > IInstallationPageContainer, and having gotten to those I'd do something like... > > menuService.populateContributionManager(myInstallContributionManager, > pageContainer) > Pretty close. I have a sample I used to test this code - I will wrap it up tomorrow and attach it to this bug. > I'll need to play with this to see the impact on my current action structure, > but if this is the state of the art in platform UI, I think it's a good idea to > use it. > > >As for standard pages that clients can extend (of the tree/table nature you've > >mentioned) that has yet to be tackled. > No worries, that seems like a polish item once we get it wired in. > > I'm seeing some odd layout (can only see the top corner of the button at the > bottom), but you warned me... > > Thanks for getting something to me so fast. > Created attachment 112420 [details]
Example plugin
Provides two pages,one of which is vanilla and hte other of which adds a programmatic menu extender. There are also some toolbar/button bar extensions via the menus extension point.
Thanks, that helps. Getting this into M2 would be helpful, as it will allow me to reorganize my p2 workflows and the UI contributions during M3 and in places where my UI invokes the "installed" dialog, I can now just run the command. (In reply to comment #8) > Thanks, that helps. > Getting this into M2 would be helpful, as it will allow me to reorganize my p2 > workflows and the UI contributions during M3 and in places where my UI invokes > the "installed" dialog, I can now just run the command. > Done. The patch is in head and should be tagged next week. I've now got the p2 installed software page actions fully hooked into the InstallationPage mechanism (p2 code is still in progress) I made some changes to the platform UI code and have committed them in Kim's absence: - made the InstallationDialog resizable - Even though the ButtonManager was laying out based on the contributed actions, its parent (the button bar) was not being layed out again, which meant the button bar always stayed at its empty size and clipped the buttons. Changed layout code to a force a layout of the button bar parent after the ButtonManager recomputes contributions - InstallationDialog was using a FillLayout for its page contents. This made it a little harder to move code from one part of the dialog framework to another, since everywhere else, a GridLayout is used. I changed it to GridLayout for now. We should probably revisit whether this makes sense. - added a close() method to IInstallationPageContainer. This is a bit hokey, and rather rude of a page to close its container dialog. But it's needed when one of the actions in the install page launches a long operation. In this case my page wants to close the dialog so that the jobs progress dialog can open. See #236495 comment #3. If someone has a better idea how to solve this problem, I'm all ears. > See #236495 comment #3. If someone has a better idea how to solve this > problem, I'm all ears. sorry, meant to say See bug #236495 comment #3 I noticed this comment in the example for Page1 (the dynamically added action).
public void dispose() {
super.dispose();
menuService.removeContributionFactory(factory);
// not strictly necessary - adding for completeness. THe
// MenuService is a slave service which
// should automatically dispose everything on
// dialog close
}
In fact the dispose is strictly necessary because the page is recreated (and therefore a factory added to the service) every time the tab is selected while the dialog is up. So if you don't remove your factory, you'll have factories referring to dead page instances lying around.
This may or may not cause a visible problem, depending on what your factory does, but it definitely leaves a lot of dead code running. In my case I was accessing a dead widget from a selection handler on the action.
I realize there's been no polish work on this...just starting a list as I think of polish items: - installation extension point should allow clients to specify the mnemonic in addition to the name for traversing pages. This is a bit tricky because we could have mnemonic conflicts between random contributors and the button mnemonics used by individual page contributors - dialog should remember the selected page and open on that page the next time - dialog should remember size/location - button manager layout should honor standard button sizes (ie, the OK button is the standard size and contributed buttons are not) Until this support is hooked into help->about, p2 needs to launch the installation dialog itself from a temporary menu and handler. So the dialog needs a proper title. I hacked in a temporary dialog title to match the p2 temporary menu "Installation Information". It is marked with a //TODO tag. (In reply to comment #1) > We currently use IBundleGroup as the abstraction in the about dialog to avoid > dependency on update. Assuming this isn't sufficient (because we want to talk > about more than just bundles), we'll likely need to deprecate > IBundleGroup/IBundleGroupConstants/etc as part of this work. > Given the progress made in bug #224472, we might now be able to get rid of the "Feature Details" part of the about dialog. The p2 contributed view now traverses the required IU's and shows group IU's required by each root. For M3, a little polish would help the look of the dialog. I'll attach a screen shot from Windows. - the empty toolbar looks funny, at a minimum could we remove the border? - contributed buttons don't adopt the standard button size For M4, we can worry about the big stuff and more polish - what pages the IDE should have (does feature details still exist?) - do we want popup menu support on selections, or just buttons? - is the button layout useful, and is there any notion of kinds of contribution items and how that might affect the button layout? Some buttons launch major work/secondary dialogs, others may not. How should these be specified? (For example the OK button is a bit meaningless, maybe it should be "Close"?) We ran into these issues in p2 and will have them again in this dialog. See bug #236740. - some of the p2 buttons will launch jobs, and progress won't be visible unless the containing dialog is closed. Am I missing some obvious UI alternative? what have others done to avoid this particular problem? - once we have multiple pages - how to contribute mnemonics, remembering selected page - remembering size/location Created attachment 115725 [details]
install dialog screen snap on windows
(In reply to comment #16) > For M3, a little polish would help the look of the dialog. I'll attach a > screen shot from Windows. > > - the empty toolbar looks funny, at a minimum could we remove the border? > - contributed buttons don't adopt the standard button size > I've removed the border and added standard button sizing to the bar. Could you let me know if the toolbar looks decent now in the empty case? > For M4, we can worry about the big stuff and more polish > > - what pages the IDE should have (does feature details still exist?) > - do we want popup menu support on selections, or just buttons? Probably, yes. I can add a new menu id/population routine for that... > - is the button layout useful, and is there any notion of kinds of contribution > items and how that might affect the button layout? Some buttons launch major > work/secondary dialogs, others may not. How should these be specified? (For > example the OK button is a bit meaningless, maybe it should be "Close"?) We > ran into these issues in p2 and will have them again in this dialog. See bug > #236740. By button layout I assume you mean button manager? I was a little afraid of this as well - we dont have anything like this anywhere elsewhere, but at the same time I wanted that area to be extensible and I didnt want to pollute the new API with something like createButtons() or somesuch. As for OK, agreed - I will change that to Close. I will also digest the bug you've linked to. > - some of the p2 buttons will launch jobs, and progress won't be visible unless > the containing dialog is closed. Am I missing some obvious UI alternative? I'm sure we could wire up progress into the dialog/service locator, although I'm not sure that's the best answer.. would it be appropriate for those buttons to close the dialog as well as launch the job? > what have others done to avoid this particular problem? > - once we have multiple pages - how to contribute mnemonics, remembering This will be tricky. I haven't thought on that yet... been trying to avoid it. ;) > selected page > - remembering size/location > That should be easy. I will get that in soon. > I've removed the border and added standard button sizing to the bar. Could you > let me know if the toolbar looks decent now in the empty case? yes, it looks much better, thanks. I think the empty space will get some attention, but it's better than the empty toolbar. Going forward, we should probably establish a guidelines for what would go in the toolbar vs. a button below. > By button layout I assume you mean button manager? I was a little afraid of > this as well - we dont have anything like this anywhere elsewhere, but at the > same time I wanted that area to be extensible and I didnt want to pollute the > new API with something like createButtons() or somesuch. As for OK, agreed - I > will change that to Close. I will also digest the bug you've linked to. By button layout I really mean the bigger issue of these command contributions and where/how they appear. When should it be in a popup on the list vs. a button below vs. the toolbar. Guidelines for contributors of these pages. Related to the buttons specifically - should the "most important" actions/buttons be on the right? (Close is probably the least important, for example.) > I'm sure we could wire up progress into the dialog/service locator, although > I'm not sure that's the best answer.. would it be appropriate for those buttons > to close the dialog as well as launch the job? That's my approach right now, mainly as a workaround to the disappearing progress problem. It just felt odd to push a button that wasn't OK or Close and have the dialog disappear while progress came up. My 2 cents:
- All the dialogs should offer "copy to clipboard" and "export to file" functions so I can easily add the data to a bug report
- There was an "uninstall" button in the mockups. I want the button to check which plugins need the one I want to get rid of, tell me ("After restart, these plugins won't work anymore") and when I click "Delete" to kill the plugin. Killing a plugin must not become impossible just because some other plugin depends on it. Eclipse is smart enough not to start a bundle when some dependency is missing and sometimes, a plugin will corrupt your setup in such a way that deleting it from the disk is the only way to save the rest of your install. After the deletion, I can run install manually and try to replace the buggy version with the last "known-to-work" version or blast the other, now defective plugins from the disk, too.
(In reply to comment #20) > My 2 cents: > > - All the dialogs should offer "copy to clipboard" and "export to file" > functions so I can easily add the data to a bug report yes. And assuming that there is still something like "configuration details" on the main page, that suggests a way all pages can contribute to an export of one file. So maybe part of the page contribution is to specify the class that exports the info. > > - There was an "uninstall" button in the mockups. I want the button to check > which plugins need the one I want to get rid of, tell me ("After restart, these > plugins won't work anymore") and when I click "Delete" to kill the plugin. > Killing a plugin must not become impossible just because some other plugin > depends on it. Eclipse is smart enough not to start a bundle when some > dependency is missing and sometimes, a plugin will corrupt your setup in such a > way that deleting it from the disk is the only way to save the rest of your > install. After the deletion, I can run install manually and try to replace the > buggy version with the last "known-to-work" version or blast the other, now > defective plugins from the disk, too. > This really applies to the p2 contribution to the about dialog. Can you open a bug against p2 on this? (In reply to comment #21) > (In reply to comment #20) > > My 2 cents: > > > > - All the dialogs should offer "copy to clipboard" and "export to file" > > functions so I can easily add the data to a bug report > yes. > And assuming that there is still something like "configuration details" on the > main page, that suggests a way all pages can contribute to an export of one > file. So maybe part of the page contribution is to specify the class that > exports the info. The configuration info section already has an extension mechanism - you can contribute blocks of text to this section already. Deprecating that in favour of the new one doesn't seem like an awful idea though. Incidentally, I was considering putting the contents of the Configuration Info button in a new page in the installation dialog... > > > > > - There was an "uninstall" button in the mockups. I want the button to check > > which plugins need the one I want to get rid of, tell me ("After restart, these > > plugins won't work anymore") and when I click "Delete" to kill the plugin. > > Killing a plugin must not become impossible just because some other plugin > > depends on it. Eclipse is smart enough not to start a bundle when some > > dependency is missing and sometimes, a plugin will corrupt your setup in such a > > way that deleting it from the disk is the only way to save the rest of your > > install. After the deletion, I can run install manually and try to replace the > > buggy version with the last "known-to-work" version or blast the other, now > > defective plugins from the disk, too. > > > > This really applies to the p2 contribution to the about dialog. Can you open a > bug against p2 on this? > (In reply to comment #1) > We currently use IBundleGroup as the abstraction in the about dialog to avoid > dependency on update. Assuming this isn't sufficient (because we want to talk > about more than just bundles), we'll likely need to deprecate > IBundleGroup/IBundleGroupConstants/etc as part of this work. Something needs to be done here. Two issues (at least): 1 - the metadata provided about a feature via IBundleGroup contains more info than that provided in the generated IU description (opened bug 259158). 2 - we need to understand where plug-in/bundle detail is going to come from I'll take this in Kim's absence. Kim, did you have any patch in progress of your previous attempts to move the current about dialog content into the new framework? I'm going to look at that for M5. My thinking was that we do the following: - the current content of the about dialog (summary info) could be moved to its own page, called "Summary." This would no longer have plug-in details or feature details buttons since that content will move to pages, but will likely still contribute a "Configuration Details" button - the existing plug-in details and feature details pages become pages in the framework (for backward compatibility) - IDE contributes summary page and plug-in details (because that info is still valuable in a p2 installation) - IDE does not contribute features page, since the p2 page provides the "feature-esque" view of the world. Products that wish to continue showing a features page can choose to do so - p2 would contribute its own installation pages. We need to address bug #259158 in order to have the p2 page provide the same branding info that the current feature page provides. Products that wish to continue showing a features page can choose to contribute that page. Thoughts anyone? Would it make sense to move the "Configuration Details" to a page as well? What is the behavior in absence of p2? (In reply to comment #25) > Would it make sense to move the "Configuration Details" to a page as well? > What is the behavior in absence of p2? > Probably so...after writing my last comment, I noticed this suggestion in one of Kim's previous comments, also. (In reply to comment #22) <snip> > > Incidentally, I was considering putting the contents of the Configuration Info > button in a new page in the installation dialog... > This point was made in bug 216032 and I want to log it here for consideration when we merge the p2 view of the installed platform with the platform about view. > Because it does worry me as well that we can end up with two different > machines, with the exact same configuration, showing two different setups. This > is the kind of thing that gives Dave nightmares. Again, any simplificaiton like > this has to have a lot of cues that it is just that. The issue here is that the roots of the installed software page are determined by user actions. The roots show what the user installed. Someone who wants to know instead the detailed configuration of the setup (such that it would look identical on machines that had the same configuration) would look at the configuration page, or perhaps the plug-in details page. When all of these pages get integrated, we need to make sure the wording and such make this more clear. It's getting too late for my comfort to slam this into M5. Will get in early M6. Note that extension point/API issues have to get sorted out by the end of M6 (things like page mnemonics, etc.) Another issue that has come up (should probably move to a separate bug but I'll open all the separate about bugs when I've finished the integration on this one....) Installation pages inherit from DialogPage, which provides setMessage(String) and setMessageType(..) protocol. Typically it's up to the container to deal with this, by showing the message somewhere. InstallationDialog doesn't do anything with the page messages. We either need a message area or document that these messages are not supported by the container. Created attachment 125194 [details]
patch against platform ui, ide, and p2
work in progress patch - replaces the old buttons (feature details, plugin details, configuration details) with one button (installation details). This button launches the dialog with contributed pages. p2 is changed to remove the contribution of the "Installation Information" menu item.
There are a few polish details remaining, but this patch is indicative of the direction. Paul and Kevin - Can you review this? I really need some input (from a usability and from a contribution mechanism/API point of view). Kim, too, if you have time. Kevin - Some issues I'm wondering about: - click count is raised by one for the person who used to simply press the "config details" or "plug-in details" button. We could consider remembering the selected page and always bringing it to the front, but it's not clear to me that the usage pattern is a repetitive one - page order - I started out with configuration details at the front, but it is slower to populate than the other pages. The way I have it now is that "Installed Software" appears first if p2 is present, and plug-in details is first otherwise. - we don't have any support for mnemonics on the tabs (it's currently not defined in the extension point). Is this an accessibility show stopper? Note we have other tabbed dialogs (customize perspective) that don't use mnemonics, but the old buttons in the about dialog did. We might want mnemonics added to reduce the click count for someone trying to get to a specific page. Paul - I'm not intimate with the command/handler/contribution item/menu mechanisms, so I need a sanity check - Kim was originally reticent about introducing a "ButtonManager" to manage the command buttons. The issue is we want the pages to contribute commands, but in the context of an about dialog, the commands should appear as buttons. But we've never done this anywhere else. What do you think? - The original patch had a toolbar associated with this dialog. I didn't have any real use cases, and it added a bunch of white space to the dialog, so I removed it. But I haven't yet changed the URI used to access this button bar, which is "toolbar:org.eclipse.ui.installationDialog.buttonbar". Kind of weird? What would you suggest? - note my use of the ActionContributionItem, even in the platform dialogs (ie, AboutFeaturesPage). It was dead simple while porting the code to call the old dialog button selection handlers from an action's run method. Do you find this offensive? I could make commands/handlers for all of these and contribute as part of the extension if that is the best practice. - Related note - it doesn't seem like there's a source (ISources) that fits for use with an activeWhen clause. If a page contributes a handler, how does it specify that the handler is only active when the page is active? Is there some pattern that is used for this? Should I use ACTIVE_CURRENT_SELECTION_NAME? Can you provide an example? Coming to this late, but some random UI thoughts: First, I like getting rid of Installation Info.. and coordinating with About. (In reply to comment #31) > Kevin - Some issues I'm wondering about: > - click count is raised by one for the person who used to simply press the > "config details" or "plug-in details" button. We could consider remembering > the selected page and always bringing it to the front, but it's not clear to me > that the usage pattern is a repetitive one I think this is reasonable, actually, within user session. Analogy is preferences which does return to prior selection. Appropos that, has a tree / list selector been considered? Benefit is that user can see range of choices and do a one-click scan. > - page order - I started out with configuration details at the front, but it is > slower to populate than the other pages. The way I have it now is that > "Installed Software" appears first if p2 is present, and plug-in details is > first otherwise. Assuming configuration details is still text log I would say it shouldn't be the first thing user's see. Text is scary. :) (Hadn't noticed an issue with loading time, though.) I'd say order should be "Installed Software", "[Installed] Features", "[Installed] Plugins", "Configuration Log[??]", and perhaps a direct link to "Error Log". Later, it might be nice to have a separate "export configuration details.." so that users would have an one-click path for creating an email log to send to admins. > - Kim was originally reticent about introducing a "ButtonManager" to manage the > command buttons. The issue is we want the pages to contribute commands, but in > the context of an about dialog, the commands should appear as buttons. But > we've never done this anywhere else. What do you think? Its a little confusing / unattractive that individual apps have those square buttons, while the installation information and presumably other plugin buttons use text. Or perhaps this is changing with new extension points. Even more random set of thoughts here, so feel free to ignore.. I took a quick review of various App about dialogs and even on Mac there is no consistency. But I can't help feeling that an about dialog should have a cleaner/friendlier look. I wonder wether a hyperlink style might look nicer. Also, might consider "More Info.." in place of "Installation Information" and allow that part to be the extensible bit. Then is we were using a tree view, you could have separate entries for each installed product. (In reply to comment #32) > Coming to this late, but some random UI thoughts: thanks for your comments...a few specific answers... <snip> > I think this is reasonable, actually, within user session. Analogy is > preferences which does return to prior selection. Appropos that, has a tree / > list selector been considered? Benefit is that user can see range of choices > and do a one-click scan. Interesting idea, though I don't know that we expect the same scale as preferences. I would see this as an idea if we find this proposed extension point widely used. <snip> >I'd say order should be "Installed Software", > "[Installed] Features", "[Installed] Plugins", "Configuration Log[??]", and > perhaps a direct link to "Error Log". Later, it might be nice to have a > separate "export configuration details.." so that users would have an one-click > path for creating an email log to send to admins. Ths is in effect what the "Configuration" page is. That content is produced by contributions to a system summary extension point. In fact, one could argue that if you contribute an installation page, you should contribute a system summary (I think p2 needs to do this, it's on my to-do list)... > Its a little confusing / unattractive that individual apps have those square > buttons, while the installation information and presumably other plugin buttons > use text. Or perhaps this is changing with new extension points. No, my "mission" in this bug is how to change the hard-coded "feature details", "plug-in details", "configuration details" buttons to instead launch a generic dialog that allows plug-ins to add information. I've specifically avoided addressing existing usability concerns with about since those can be addressed separately. > > Even more random set of thoughts here, so feel free to ignore.. I took a quick > review of various App about dialogs and even on Mac there is no consistency. Same here, though there is definitely a trend to have various "details" buttons on the about, usually at the bottom. What we are doing instead is have one button and it opens the dialog to which plug-ins can contribute. > But I can't help feeling that an about dialog should have a cleaner/friendlier > look. I wonder wether a hyperlink style might look nicer. Also, might consider > "More Info.." in place of "Installation Information" and allow that part to be > the extensible bit. Then is we were using a tree view, you could have separate > entries for each installed product. Not sure what you mean here...a link that says "More Info..." instead of the "Installation Details" button? Otherwise I think we are doing what you suggest (have the launched dialog be the extensible part). Note: In early mockups we showed a fully integrated about, where the front page was the branded page. After trying it, it didn't play well, so we went with the approach to launch the branded dialog and let plug-ins extend the details dialog. I've been meaning to capture our reasons for this change in case the question comes up later: - often users just want build number, keep the about dialog fast, simple, non-cluttered - optimal size is different for the about logo vs. the detail pages. Integrating the two penalizes the user by either having the branded info look funny inside a big page or forcing the user to resize to see the details - tabs detract from branding - takes longer for single integrated dialog to come up...has to read extension registry All of this makes tremendous sense to me. I think my central arguments revolved around 1) keep the about dialog as simple as possible, 2) make configuration information scannable and with smooth transition from accessibility (end-users) to more sophisticated uses. Fitting pluggability into this creates an additional challenge. (In reply to comment #33) > > I think this is reasonable, actually, within user session. Analogy is > > preferences which does return to prior selection. Appropos that, has a tree / > > list selector been considered? Benefit is that user can see range of choices > > and do a one-click scan. > > Interesting idea, though I don't know that we expect the same scale as > preferences. I would see this as an idea if we find this proposed extension > point widely used. Yep. One argument against is that the plugin and features list are already dense and list / trees don't marry well with grids unless there is a lot of white space. > Ths is in effect what the "Configuration" page is. That content is produced by > contributions to a system summary extension point. In fact, one could argue > that if you contribute an installation page, you should contribute a system > summary (I think p2 needs to do this, it's on my to-do list)... OK, that sounds a bit different from what I saw but I've had to go back to Dec build because of some unrelated issues. > > Its a little confusing / unattractive that individual apps have those square > > buttons, while the installation information and presumably other plugin buttons > > use text. Or perhaps this is changing with new extension points. > > No, my "mission" in this bug is how to change the hard-coded "feature details", > "plug-in details", "configuration details" buttons to instead launch a generic > dialog that allows plug-ins to add information. I've specifically avoided > addressing existing usability concerns with about since those can be addressed > separately. OK, so that means that there are two extension points effectively. One at the product (??) level in main about dialog, and one at the generic installation information level. > > Even more random set of thoughts here, so feel free to ignore.. I took a quick > > review of various App about dialogs and even on Mac there is no consistency. > > Same here, though there is definitely a trend to have various "details" buttons > on the about, usually at the bottom. What we are doing instead is have one > button and it opens the dialog to which plug-ins can contribute. > Not sure what you mean here...a link that says "More Info..." instead of the > "Installation Details" button? Otherwise I think we are doing what you suggest > (have the launched dialog be the extensible part). Yeah, we're talking about the same thing. Just one or two buttons and "Installation Details.." works though perhaps it could become more general if/when plugins offer more contributions to the dialog. I was trying to think of some use cases here that wouldn't be common to all plugins/features. Perhaps DTP lists the database drivers installed? Or an RCP app lists product keys. > details dialog. I've been meaning to capture our reasons for this change in > case the question comes up later: All very good reasons. Nothing more off-putting than a cluttered about dialog. <snip> > OK, so that means that there are two extension points effectively. One at the > product (??) level in main about dialog, and one at the generic installation > information level. No, that first cluster of buttons in the about dialog contains branded features known by update manager. (It comes from the platform's bundle group provider, see comment #1 and Platform.getBundleGroupProviders()). In the long run, we won't expect update manager to be in the SDK, so at that point we would either decide to get rid of this row of buttons or else have p2 define a bundle group provider. The only advantage I see to this group of buttons is that it lets a user quickly use the branding info in order to find a particular feature. We could also consider enhancing feature details (or for that matter, installed software), with branding info to achieve a similar effect. (In reply to comment #35) > <snip> > > OK, so that means that there are two extension points effectively. One at the > > product (??) level in main about dialog, and one at the generic installation > > information level. > > No, that first cluster of buttons in the about dialog contains branded features > known by update manager. (It comes from the platform's bundle group provider, > see comment #1 and Platform.getBundleGroupProviders()). In the long run, we > won't expect update manager to be in the SDK, so at that point we would either > decide to get rid of this row of buttons or else have p2 define a bundle group > provider. The only advantage I see to this group of buttons is that it lets a > user quickly use the branding info in order to find a particular feature. We > could also consider enhancing feature details (or for that matter, installed > software), with branding info to achieve a similar effect. Got it, I didn't get the implication of #1. So perhaps OT, but its a bit confusing because the tooltip for those bundles shows the provider -- and as I may have touched on elsewhere the whole product / application / branded feature / feature / category / site thing provides a lot of opportunity for cognitive dissonance. I think a nice model down the road would be to analogize to the Welcome screen, which is really sweet because it promotes "offerings" to the level of first class Eclipse components. So instead of buttons you might have 32 or 64-bit icons and a click would replace or extend the current box with offering details. Paul - Would it make any sense for the installation dialog to programatically create a context for each installation page, perhaps based on the id of the page? Then page contributors could contribute handlers using the activeWhen clause for a context named after their page. Otherwise it feels like a lot of overhead to be able to contribute to the button bar of this dialog (unless I'm missing something obvious, which is certainly possible). Another thought about using a toolbar. I considered having the dialog itself contribute a copy tool bar item so that users can copy from any page (of course it's up to the page to do anything smarter than copy from a text control). Miles' comment 32 suggests other common things that perhaps could go in a common toolbar, such as export the configuration log to a file, open the error log. (In reply to comment #37) > Paul - > Would it make any sense for the installation dialog to programatically create a > context for each installation page, perhaps based on the id of the page? Then > page contributors could contribute handlers using the activeWhen clause for a > context named after their page. Otherwise it feels like a lot of overhead to > be able to contribute to the button bar of this dialog (unless I'm missing > something obvious, which is certainly possible). > Here's one scenario that comes to mind. 1) use org.eclipse.ui.internal.services.IServiceLocatorCreator in org.eclipse.ui.internal.about.InstallationDialog.createDialogServiceLocator(TabItem) The AbstractServiceFactory can be used to specify the specific IInstallationPageContainer and you get a SlaveMenuService for free (if the window restrictions don't interfere with your visibility ... if it does then the SlaveMenuService can be created in the ASF when appropriate). 2) create your one toolbar, and just keep the locationURI toolbar:org.eclipse.ui.installationDialog.buttonbar (or toolbar, whatever you decide). You can add some pre-defined group markers if that makes sense. 3) create a context for each page you add, and activate it when that page becomes active. In org.eclipse.ui.internal.about.InstallationDialog.createFolderItems(TabFolder) something like: public static final String PREFIX = "installationDialog.internal."; IContextService cs = (IContextService) serviceLocator.getService(IContextService.class); menuService.populateContributionManager(buttonManager, "toolbar:org.eclipse.ui.installationDialog.buttonbar"); //.... String id = element.getAttribute(IWorkbenchRegistryConstants.ATT_ID); Context c = cs.getContext(PREFIX+id); if (!c.isDefined()) { c.define(element.getAttribute(IWorkbenchRegistryConstants.ATT_NAME), null, null); } In tabSelected(TabItem) you would do the: cs.deactivateContext(oldRef); oldRef = cs.activateContext(PREFIX+id); // and at the end of the method, you don't need the populate any more // just some updates and layouts buttonManager.update(true); buttonManager.getParent().layout(); getButtonBar().getParent().layout(); 4) the close or dispose will have to release the contributions from the menu service and dispose the service locator. The plus for this approach is that it is do-able right now. The downside is that you need to "publish" PREFIX as well as the locationURI so they can build there own. Use for org.eclipse.ui.menus: <menuContribution locationURI="toolbar:org.eclipse.ui.installationDialog.buttonbar"> <command commandId="o.e.ui.plugins.columns"> <visibleWhen> <with variable="activeContext"> <iterate operator="or" ifEmpty="false"> <equals value="aboutDialog.internal.o.e.ui.pluginsPage"/> </iterate> </with> </visibleWhen> </command> <command commandId="o.e.ui.edit.copy"> <visibleWhen> <with variable="activeContext"> <iterate operator="or" ifEmpty="false"> <equals value="aboutDialog.internal.o.e.ui.configurationPage"/> </iterate> </with> </visibleWhen> </command> </menuContribution> clients would have to use similar expressions in the org.eclipse.ui.handlers extension point to associate handlers to their commands. One potential pitfall with this approach is trying to find the active page that the command needs to run against, and programmatic handler activations by the page need similar programmatic expressions. I'll add another comment with an alternative. > Miles' comment 32 suggests other common things that perhaps could go in a > common toolbar, such as export the configuration log to a file, open the error > log. While I think I would prefer a toolbar over the buttons, the contribution lifecycle would probably be the same for either ContributionManager. PW The second way to do this is to create an ISourceProvider that provides 2 variables, INSTALL_DIALOG_ACTIVE_PAGE and INSTALL_DIALOG_ACTIVE_PAGE_ID (o.e.ui.install.activePageId)
Step 1 and 2 stay the same.
Step 3
You need to fill the manager once:
menuService.populateContributionManager(buttonManager,
"toolbar:org.eclipse.ui.installationDialog.buttonbar");
And on tabSelected(TabItem) you no longer need the context stuff, but you would need to update your ISourceProvider so it is injecting events for these variables into the IEvaluationService.
// you'll still need the update/layout stuff, but perhaps less
// since the change in the source provider will have update the manager.
buttonManager.update(true);
buttonManager.getParent().layout();
getButtonBar().getParent().layout();
and you'll still have to do step 4.
The user contributions change slightly (and look simpler):
<menuContribution
locationURI="toolbar:org.eclipse.ui.installationDialog.buttonbar">
<command commandId="o.e.ui.plugins.columns">
<visibleWhen>
<with variable="o.e.ui.install.activePageId">
<equals value="o.e.ui.pluginsPage"/>
</with>
</visibleWhen>
</command>
<command commandId="o.e.ui.edit.copy">
<visibleWhen>
<with variable="o.e.ui.install.activePageId">
<equals value="o.e.ui.configurationPage"/>
</with>
</visibleWhen>
</command>
</menuContribution>
no more internal IDs, simply the ID of the page.
As an added bonus, you can get the active page from the ExecutionEvent application context with this method.
PW
org.eclipse.ui.tests.services.EvaluationServiceTest.testSourceProvider() contains a simple example of a source provider (and finding it to call a method on it to update its variables) PW Paul - I'm about to attach a patch for a quick lookover. (In reply to comment #39) > The second way to do this is to create an ISourceProvider that provides 2 > variables, INSTALL_DIALOG_ACTIVE_PAGE and INSTALL_DIALOG_ACTIVE_PAGE_ID > (o.e.ui.install.activePageId) This is what I ended up doing, as well as adding another variable for the selection (so that handler expressions could enable on the active page selection where appropriate). As you said, this makes for much simpler client contributions than dealing with contexts and internal id's. > As an added bonus, you can get the active page from the ExecutionEvent > application context with this method That turned out to be really helpful. (In reply to comment #38) > Here's one scenario that comes to mind. > > 1) use org.eclipse.ui.internal.services.IServiceLocatorCreator in > org.eclipse.ui.internal.about.InstallationDialog.createDialogServiceLocator(TabItem) > > The AbstractServiceFactory can be used to specify the specific > IInstallationPageContainer and you get a SlaveMenuService for free (if the > window restrictions don't interfere with your visibility ... if it does then > the SlaveMenuService can be created in the ASF when appropriate). I did get a free slave menu service by doing it this way. The really nasty challenge in all of this was the fact that some of the platform's pages (the feature page and plug-in page) can be launched independently of the installation dialog with their own scoping. This wreaked complete havoc on my visibility expressions at first, until I duplicated the sources (active page, active page id, selection) in separate variables for the nested dialogs. Otherwise nesting the dialogs would swap visibility on the dialog underneath. Likewise, I needed separate toolbar URI's as well as duplicate command id's for these nested dialogs (otherwise there would be handler conflicts or visibility expressions updating the launching dialog). This is a complication that "real clients" shouldn't have to deal with. It arose because I wanted to use the same code (the installation page) in two different settings: the installation dialog and these nested/scoped dialogs. (In reply to comment #31) > Kevin - Some issues I'm wondering about: I've run patch 2009-02-09. This looks really good. It's the right direction. I only have minor comments (below). > - click count is raised by one for the person who used to simply press the > "config details" or "plug-in details" button. We could consider remembering > the selected page and always bringing it to the front, but it's not clear to me > that the usage pattern is a repetitive one Likely not repetitive, that's true. However, because it's modal, there may be patterns where I: 1. Open About dialog, go to say the Plug-ins tab, look what's in there 2. Dismiss dialog, go back to workbench, check something 3. Open About dialog again, confirm what was in the plug-ins list. Since I'm not sure under all the conditions this information is being checked, it's hard to assume that we won't have these brief back and forth cycles. So remembering the last page seems useful. Maybe though you decide to not remember it across workbench sessions. > - page order - I started out with configuration details at the front, but it is > slower to populate than the other pages. The way I have it now is that > "Installed Software" appears first if p2 is present, and plug-in details is > first otherwise. I like "Installed Software" first, I think it's the right choice. I like to imagine a future where new features are found and installed all the time via P2 (think Firefox add-ons). That's the level of granularity that we want most users thinking at. I think second tab then would be "Installation History", since what you have, and how you got it, are highly related. I'm then thinking Features / Plug-ins / Configuration. - Features next, because it's the next logical size of granularity. I can (somewhat) imagine a support person asking, "What Features do you have installed?". I can't imagine the same true for plug-ins. That said, I think Features are becoming a purely technical vehicle and I'm not sure who they're of interest to now other than to verify the build was correct. - Then plug-ins because they're logically less than Features. - Configuration, because it's the most technical of them all and has a different format. > - we don't have any support for mnemonics on the tabs (it's currently not > defined in the extension point). Is this an accessibility show stopper? No, you just need to be able to keyboard navigate, which you can. I verified I can keyboard between the top level tabs fine, and tab into their contents. In any case I think it'd be impractical since the tabs get added via extension and you can't enforce they must have mneumonics (nor ensure they're unique). Note that if you look at the Run Configurations page for an "Eclipse Application", you'll notice some tabs have mneumonics and some do not, and some that you might want for the tab (e.g. a for Arguments) are already used on the another page (e.g. Plug-in > Run an _A_pplication). So I'd recommend none for the tabs but fine if someone wants to add within a page although I question value. > Note > we have other tabbed dialogs (customize perspective) that don't use mnemonics, > but the old buttons in the about dialog did. We might want mnemonics added to > reduce the click count for someone trying to get to a specific page. I find it pretty quick just using keyboard. Mneumonics are good for people doing repetitive tasks since they can train their fingers to do the same gesture. I don't see this here. Other comments: 1) I like the use of the square tabs (ignoring the preference), it looks more streamlined and is consistent with other places too. 2) The Installed Software Details text area has a white background, it should be the same color as under the word "Details". This appears to be a regression. 3) We seem to have picked up an extra frame between the tab and its contents. I don't think we normally do this, I'm looking at Search and Customize Perspective. I think it adds a bit of clutter and doesn't seem necessary. Should we decide to keep, there are minor spacing discrepancies (appears 2 pixels LHS, 1 pixel all other sides). 4) I'm wondering about the button row along the bottom. It has a combination of Dialog buttons and page buttons, together. As you switch tabs, the set of page buttons change. What I've seen in other places in Eclipse is that the set along the bottom stay the same (just for the dialog, OK/Cancel types), but each page then has a set of buttons particular to it in it's own area (see Preferences, Run Configs dialog). If we decided to only have a single row of buttons, I'd add some space to the left of the OK button, visually grouping the page specific ones together and separate from the dialog one. Created attachment 125936 [details]
replacement patch with new contribution mechanism
This patch defines the installation dialog sources and contributes commands to the platform pages. I still use actions to launch the nested dialogs (no one else should ever have to do that), but otherwise the rest of the actions are implemented as commands. Here is some example client markup for the plugins page that shows the page definition, commands, menu contributions, and handlers that rely on selection.
<extension
point="org.eclipse.ui.installationPages">
<page
name="%installationPage.plugins.name"
class="org.eclipse.ui.internal.about.AboutPluginsPage"
id="15.PluginPage">
</page>
</extension>
<extension
point="org.eclipse.ui.commands">
<command
description="%command.installationPageColumns.description"
id="org.eclipse.ui.about.columns"
name="%command.installationPageColumns.name"
defaultHandler="org.eclipse.ui.internal.about.ConfigureColumnsHandler"/>
<command
description="%command.installationPageOpenBrowser.description"
id="org.eclipse.ui.about.openBrowser"
name="%command.installationPageOpenBrowser.name"
defaultHandler="org.eclipse.ui.internal.about.OpenBrowserHandler"/>
</extension>
<extension
point="org.eclipse.ui.menus">
<menuContribution
locationURI="toolbar:org.eclipse.ui.installationDialog.buttonbar">
<command
commandId="org.eclipse.ui.about.columns"
mnemonic="%command.installationPageColumns.mnemonic"
style="push">
<visibleWhen>
<with variable="org.eclipse.ui.installationPage.activePage.id">
<equals value="15.PluginPage"/>
</with>
</visibleWhen>
</command>
<command
commandId="org.eclipse.ui.about.openBrowser"
label="%command.installationPageLegalInfo.name"
mnemonic="%command.installationPageLegalInfo.mnemonic"
style="push">
<visibleWhen>
<with variable="org.eclipse.ui.installationPage.activePage.id">
<equals value="15.PluginPage"/>
</with>
</visibleWhen>
</command>
</menuContribution>
<extension
point="org.eclipse.ui.handlers">
<handler
class="org.eclipse.ui.internal.about.OpenBrowserHandler"
commandId="org.eclipse.ui.about.openBrowser">
<activeWhen>
<with
variable="org.eclipse.ui.installationPage.activePage.id">
<equals value="15.PluginPage"/>
</with>
</activeWhen>
<enabledWhen>
<with
variable="org.eclipse.ui.installationPage.activePage.selection">
<count value="1"/>
</with>
</enabledWhen>
</handler>
</extension>
Thanks for the comments, Kevin. Given your remarks, and other ideas tossed around while doing this work, here's a summary of what I plan to do/not do: Things that are already done or left to do as part of this bug: - remember dialog location/size (done) - remember selected tab - need to document for now that IDialogPage.setMessage has no effect when used in an InstallationPage - some space to separate the common buttons from the page-contributed buttons - should we change OK to Close? - tweak page ordering - fix issue with coloring of Installed Software details area mentioned by Kevin - issues with tab frames and layout mentioned by Kevin Ideas we won't address - I opened bugs to consider later: Bug 264084 - [About] Common filter text support for Installation Pages with lists Bug 265204 - [About] Consider promoting more common commands in InstallationPage (includes discussion of common stuff like copy, details, columns) Bug 265207 - [About] Provide additional services in IInstallationPageContainer (toolbar, popups, progress service, error reporting) Bug 265212 - [About] Common commands that are always available in the InstallationDialog (open error log, copy, export config file, etc.) Ideas we've dismissed: - mnemonics on pages Fixed items mentioned in previous comment. Committed to HEAD >20090217. Renamed OK to Close...Kevin and I looked at several different example dialogs in and outside of eclipse and concluded that Close makes more sense because the page content can be arbitrary and we don't want the user to think this button has any side effect behavior besides closing the dialog. Please refer to the new bugs in comment #44 or open new ones for outstanding issues. I'll do one more API review/javadoc cleanup as part of bug Bug 265204, I want to get this released so folks can try it. After a few days to reflect on this, I'm not happy with where we ended up here. The contribution mechanism seems extremely flexible and general for what we are trying to do. If the about dialog were to provide a common toolbar and common page-independent commands, this might make more sense, but given our use cases are simply for buttons, I'm not sure I like the maintenance implications of a contribution mechanism vs. a garden-variety dialog solution (subclass the page and add buttons). Since this bug is so long already, I propose to have the discussion in bug #265204, but I wanted to let everyone watching this bug know. I'm not proposing changes to the UI or behavior, just the way contributions are made by pages. verified on WinXP, I20090310-0100 |