Bugzilla – Full Text Bug Listing
| Summary: | Quick access should not be hard-coded | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Stefan Mücke <s.muecke> |
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | christophe.moine, eiswind, elvisd79, fredrik.attebrant, Lars.Vogel, ob1.eclipse, pwebster, remy.suen, rollsisu |
| Version: | 4.2 | ||
| Target Milestone: | 4.3 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Stefan Mücke
can you give me a pointer inside the code? I would remove it and live with a patch for the first then (In reply to comment #1) > can you give me a pointer inside the code? The code that adds the Quick Access to the trim bar can be found in method WorkbenchWindow.populateTopTrimContributions() (in plugin org.eclipse.ui.workbench). The trim element itself is implemented in class SearchField. Thomas, what do you do in 3.x to prevent the dialog from appearing? Do you disable the quick access command so that Ctrl+3 does nothing? Or perhaps you just unbind the keybinding? That has not been an issue up to now, as I introduced user rights management for the user interface only lately. bevor everyone could invoke a command but then would potentially get an access denied exception from the server side. But from know on I try to hide options that are not allowed front up. I'M not to deep into the dialog, will commands be hidden if i disable all handlers ? or qill they still aoppear? Is there anyway to customize the dialog? For e.g. certain views must not be available to some users. I am open to discussion as long as it does not involve xslt :) I hate xslt. (In reply to comment #5) > I'M not to deep into the dialog, will commands be hidden if i disable all > handlers ? or qill they still aoppear? No, I think they will still be there. > Is there anyway to customize the dialog? No, it is completely powered by internals. I could introduce code that hid the text field by default and only have it shown if an addon was added to the e4xmi file. I'm trying to decide what I want to do with the Ctrl+3 command in that scenario though if the user were to hit that keybinding. Stefan and Thomas, how about the default behaviour stays as being in the dialog but for the SDK we will enable the addon that turns the dialog into an embedded text field into the toolbar? I think that having the it embedded in the toolbar or not is an aesthetic decision for the developer to decide but Ctrl+3 should remain available to the user at all times (unless the developers has chosen to explicitly disable this feature via some means of course). (In reply to comment #7) Yes, there should be no search field by default. Having the dialog mapped to Ctrl+3 is okay as a default, just as there are so many other default key bindings. As for me, I would like to be able to invoke the dialog with Ctrl+3 in the SDK. So there should be an option whether Ctrl+3 brings up the dialog or focuses the search field. Instead of having an option for that, there could be two different key bindings: (1) Open Quick Access Dialog (2) Move Focus to Quick Search Field. *** Bug 356328 has been marked as a duplicate of this bug. *** *** Bug 320744 has been marked as a duplicate of this bug. *** *** Bug 379807 has been marked as a duplicate of this bug. *** *** This bug has been marked as a duplicate of bug 362420 *** The Workaround I've found is to do this:
MWindow mWindow = ((WorkbenchWindow) PlatformUI.getWorkbench().getActiveWorkbenchWindow()).getModel();
EModelService modelService = mWindow.getContext().get(EModelService.class);
MToolControl searchField = (MToolControl) modelService.find("SearchField", mWindow); //$NON-NLS-1$
MTrimBar trimBar = modelService.getTrim((MTrimmedWindow) mWindow, SideValue.TOP);
trimBar.getChildren().remove(searchField);
Control control = (Control)searchField.getWidget();
Composite parent = control.getParent();
control.dispose();
I use the v3.x compatibility layer, then I put that piece of code in the WorkbenchWindowAdvisor.openIntro ovveridden method.
I hope that will give help people that were stuck like me for the e4 migration.
|