Community
Participate
Working Groups
Build ID: I20070621-1340 If I want to implement my own CTRL+Whatever, I have to use internal API. It should be possible to implement his own quick-assist (like CTRL+3) without breaking the rules.
Do you mean adding a category to Quick Access, or implementing something that looks like it but has other content?
(In reply to comment #1) >looks like it but has other content Exactly. At the Moment the package org.eclipse.ui.internal.quickaccess is not public. In addition the QuickaccessDialog class has to be copied (default constructor and loading unwanted providers).
I'd suggest copying the code then. I could see us making it API later on, if we see more demand from downstream projects. At this point though, I prefer the flexibility of it not being API.
This would be nice. The PDE team was looking to make use of this viewer to help quickly browse extension registry related information.
(In reply to comment #3) > if we see more demand from downstream projects Good work, Tom! ;-) We now have two interested parties, enough to start looking into making this API. What exactly do people need? Do you need just the widget, populated with your own entries? Would you be better served with an API for JDT's AbstractInformationControl (the Ctrl+O popup dialog)? Do you need the 'Previous Choices' logic? The ability to remember that across sessions?
In our case, just the widget populated with our own entries should suffice. Previous choices is a nice to have. The widget is more important as it provides a level of grouping that AbstractInformationControl or the Ctrl+Shift+T dialog really don't provide.
(In reply to comment #6) > The widget is more important as it provides a level of grouping that > AbstractInformationControl or the Ctrl+Shift+T dialog really don't provide. Ctrl-Shift-T is heavily optimized and can populate the list of matches in the background. It presents a filtered but flat list of elements. Btw, we already have API for these kinds of dialogs: FilteredItemsSelectionDialog JDT's AbstractInformationControl presents a filterable tree. QuickAccess presents a categorized list (sort of like a tree with two levels where parents cannot be picked). It builds a list of all potential elements before it even comes up (unlike Ctrl-Shift-T). The reason for this is the 'Previous Choices' functionality. Without 'Previous Choices', Quick Access could be simpler, and would scale much better. Do you still want 'Quick Access' and not one of the two others?
Remy is now responsible for watching bugs in the [QuickAccess] component area.
This looks to me like a duplicate of bug 162006. Making the classes public goes hand in hand with providing an extension point or similar mechanism for clients to provide their implementations to the platform.
(In reply to comment #9) > This looks to me like a duplicate of bug 162006. Making the classes public goes > hand in hand with providing an extension point or similar mechanism for clients > to provide their implementations to the platform. Makes sense to me. *** This bug has been marked as a duplicate of bug 162006 ***
