Community
Participate
Working Groups
The Visual Editor for Java has a ChooseBean dialog which directly extends the internal TypeSelectionDialog2. The ChooseBean dialog is used during UI designing to select a 'bean' from the existing 'types', and drop it onto the designing surface (like adding buttons to shells etc.) Optionally we have a text field to let the user say what he wants the bean to be named as, like 'okButton', 'cancelButton' etc. Currently we have to extend the internal TypeSelectionDialog2 dialog to reap the benefits of the caching of types, the jobs which do searches in the background etc. Since we dont want to rely on internals, we would like to have a public mechanism by which we could make use of all the efficient internals of the Type selection process. Also required is ways by which we could control the contents shown in the list of types - like the label provider, image provider, filter for classes, selection notification etc. Implementaion wise, the person owning the dialog could pass in the composite where JDT can house the type selection text and list, or the other way round. This would be a great for us in effectively making resue of the efficient type selection process.
The only public API that exist to access the dialog is in JavaUI. The methods are named createTypeDialog. Making the current dialog API isn't an option for two reasons: - API freeze was M6 - and more important making the dialog API would put us into a position not being able to changE the internals again. We were able to remove the all types cache and all the memory consumption problematic assigned to hit due to the reason that the way/internals how the old dialog worked wasn't API.
The only thing I can recommend right now is that you have a look at the internal class TypeInfoViewer, which contains all the code for the table and the background jobs or the TypeSelectionComponent which additionally provides the text input field for the pattern.
When we have more confident that the current story will stay for a while ( > 3.1) then we can look into providing an API without revealing to many internals. Thinks to consider then: - what to do with type infos. - need correct selectio provider then. Currently we are providing fake selections sometimes.
One of things which I am not able to achieve with the internal TypeInfoViewer class is the ability to filter out classes based on some criteria. For example, we would like to show only SWT widgets when editing a UI in SWT - I was wondering if it could be possible for the TypeInfoViewer to accept a filter which would basically accept or reject a type. This would be helpful for us to show Swing/SWT/AWT only beans, or beans which implement a particular interface etc.
Also with the current TypeSelectionDialog2, TypeSelectionComponent and the TypeInfoViewer, there is no way to provide custom label and image providers. It would be very helpful to provide for a way to contribute a label provider for the list.
It would ne nice to have this support for M7 build of Eclipse as it does not involve any new public API - only internal changes.
I added two factory methods to the type info viewer to create the label provider and the filter. Please note, that I simply don't have the time right now to do a good API. Adding a factory method or making methods protected is fine with me, however restruction the code can not happen for M7/3.1.
Thanks for making the methods protected. However extending the createLabelProvider() fails as the return type org.eclipse.jdt.internal.ui.dialogs.TypeInfoViewer.TypeInfoLabelProvider is private.
Is now protected
Is there any reason why a search is not performed by when someone types '*' in the filter. In the TypeInfoViewer.setSearchPattern() it ignores the text field if it is null or if a '*' is typed. Wouldnt users want to see all classes when '*' is typed - isnt that the meaning of having '*' there? Thanks.
This is an optimazation for cases when the user types '*something'. Searching for all types doesn't make sense anyways so we decided to only fire this search if the user types **
I need public API for this as well. Is this a possibility for 3.2? Thanks.
As already stated making the whole class with all internals API is not an option since it will put us into a position where we can't change/evolve it anymore (if we made the old two pane dialog and it internals API then we would never be able to remove the all types cache and all the memory consumption problem bound to it). However, what we can look at is providing API which would allow you to provide custom filters or label decorators. But to understand the requirements better it would be useful to have some use cases / requirements form your side. Can you provide me with those ?
Created attachment 28400 [details] Choose Bean Dialog The Visual Editor extends the Type selection dialog to select Visual Beans. Called the Choose Bean Dialog, it shows all the beans in the classpath. Also it shows beans per tookit - SWT/Swing/AWT/All (see image). Optionally the user can customize the selected bean, by specifying the variable name to use in code, etc. We plan to add additional customizations to the selected bean. So basically to implement this we would need some way of dynamically changing the filter on the types list. Also we would need to change the label provider for the types/pkgs so that the labels/images are updated as needed. Also we would need a way to change the text. Also we would like to contribute some UI to the dialog. It would be great if the type selection area could be filled in by JDT in an area that the caller provides, so that the type selection's UI - text box, types list, pkg Label, etc. - could be placed in dialogs, wizard pages etc. Similar to BuildPathDialogAccess's api, maybe something like 'public ITypeSelection createTypeSelection(Composite parent, ISelectionListener)', where ITypeSelection has setText(), setFilter(), setLabelProvider(), etc.
Sri, after seeing your screen shot and reading our requests I am not sure if extending the open type dialog is the right way to go. You are basically changing/extending a lot of things and making all this API will lock us into a mode where we can't change the dialog in the future anymore. Understanding your request better I am not thinking that you are looking for a special search query that only returns you types that are beans. Having this building the dialog would not be so complicated then.
Basically we wanted to have a Type selection process where 1. We could specify the initial search text 2. Filter the displayed results 3. Show the displayed results with appropriate images/labels Additionaly having the ability to contribute UI components to the dialog would be helpful in determining which filter to use. You could come with any API which is convenient for you, and we would use it accordingly. Please ignore the API I mentioned if it is not what you had in mind. JDT's TypeSelection dialog gives many advantages in that it is *very* fast, it caches the searches based on what is already typed, maintains the history of selections, has background search threads, etc. We would like to reuse the speed and efficiency of the Type selection dialog to refine it to our needs. Is there any public API by which we can achieve this efficiency in searching a classpath? Could you please describe as to what API you had in mind for us to have a type selection process from JDT? Thanks.
Sir, I haven't seen your implementation however from the API we provide and what I am imagine from the screen shot I think you are doing the following: - you post filter every type info object we create in the all types dialog - to further filter it you resolve the corresponding Java element using TypeInfo#resolveType - you then call some additional methods on IType to figure out if it is a bean or not. However the whole design of the all types search engine and the all types dialog is put arround the assumption that this method is only called for the actual selected type. Calling it for all results return from the search engine populates the Java model and causes a lot of parsing. Having the search all types name is special API to avoid this. Otherwise we would simply search for all type declarations. So I am very reluctent making something API that at the end will hit back on us since we can't provide a good implementation for it. However I can understand that there is lots of value in the dialog framework (background search, syncing the results, progress reporting, ...) which you don't want to copy. There are plans in Platform/UI to adapt some of the Open Type dialog code and reuse it for Open Resource. The generic part of this dialog could then be made API in Platform/UI. Tod, can you comment on whether this is still on the plan for Platform/UI. Philippe, is there a better way to find out all visual beans. Would it make more sense to build a type hierarchy for SWT, AWT or Swing components ?
Susan is looking at pulling some of the open type dialog mechanism down into the workbench and basing the resource dialog on it. I'm not sure what her plan is regards making any API based on it in the 3.2 timeframe.
Comment #17: Hi Dirk, I just wanted to clarify first, that providing this filtering of results mechanism, should in NO way effect the performance/efficiency of the JDT's Type selection dialog. JDT's Type selection dialog will work as usual. The only thing we are asking for is a way to filter what is displayed on the visual list. Your internal search-cache, history-cache, etc. should not be effected by the filters we provide. To address the concern of CPU-intensive work - this will only effect those who provide CPU-intensive filters. Since the JDT type selection dialog will not apply any filters, it will work with the same speed/efficiency. Our ChooseBean dialog will do a little bit more work per entry, but that effects ONLY the ChooseBean dialog - NOT the TypeSelection dialog. Just to describe the way our dialog works, we already have a list of FullyQualifiedNames for the appropriate widget toolkit (SWT/Swing/AWT/..), as the TypeSelection dialog filters a TypeInfo, we see if it's FQN is in the list we already prebuilt - if present we accept it, else reject. So that way its fast than to search the hieracrhy of EACH typeinfo. Regarding > is there a better way to find out all visual beans. Would it make more > sense to build a type hierarchy for SWT, AWT or Swing components ? We unfortunately do no know what constitutes 'visual beans' - It could extend Object but be a 'visual bean' like 'org.eclipse.jface.viewers.TableViewer', or WizardPages, PreferencePages, etc. It could be any factory which contributes something UI/visual. Not only that sometimes we are interested in showing all the 'ILabelProvider's or all 'IContentProvider's in the classpath. Hope this has clarified the purpose of what we intend to use it for. Please let me know if you have any concerns with the above. Thanks.
Sri, now I am a little pit puzzled. I always assumed that you don't have a list of all the elements you want to present in the dialog. That's why I assumed that you have to resolve the Java element and do some additional checking to filter the elements. And resolving the Java element is expensive and nothing that we want to make API. Given that you have the list of all your elements you want to present can you explain why the TwoPaneElementSelector dialog doesn't work for you. It provides all the means for filtering, background population of the lists, etc. It allows to plug-in cumstom filters and label providers and allows sub classsing and UI extensions. I understand that you are looking for a dialog that is more like the Open Type dialog (no two panes). However, Platform/UI is working on making a dialog framework that is comparable to the Open Type dialog still providing the extensibility of the TwoPaneElementSelector (since the Open Type Dialog will be based on the new framework as well; see bug 94382).
The reason we needed this is because - If you look at our dialog, the user can choose to select no filter 'All Types' (regular type selection dialog behaviour), or he can choose any of the filters 'Swing', 'AWT', 'SWT', etc. Since the filters always provide a subset of the result of 'All Types', we filtered the display based on the classes required by the filter. It is true that in our present implementation it might be easier to just show the list of classes and apply text pattern matching on the names, but it would be inconsistent with how we show all types. Search history for example would be something which we couldnt acess with public api. Also the cool pattern matchers the type selection dialog has like TZ=TimeZone etc. we will not be able to access. Also we would have to re-implement how the TypeSelection dialog shows only like 200 results, and as the user scrolls down the list it shows even more etc. Irrespective of how its implemented in our dialog, there is the general problem of filtering the results. What if someone efficiently wanted to show only Types which have the default nullary constructor defined in them so that a Class.newInstance() can be called? Or someone who wanted to see all types which implement two or more interfaces? etc.
Sri, regarding the three points you raised: - the first one is taken and would need clients to duplicate the code searching for all types (although this isn't much code see SearchEngineJob). - as already said Platform/UI is working on a framework that allows constructing such dialogs which all the bells and whistles of background searching, filling the table, ... (see bug 94382). The TwoPaneElementSelector already provides all the means mentions except of a two pane layout and no history. The camel case matching algorithms are already API (see SearchPattern# camelCaseMatch) - as outlined in comment #17 we will never provide API that allows resolving the Java element from a TypeInfo for further inspection. This will be against the whole design of the dialog (being fast and avoiding creating of Java elements, except the ones selected in the dialog). So for me the bottom line is: you are able to implement such a dialog which the currently available API. If Platform/UI has bug 94382 fixed you are even able to implement a dialog with the same look & feel as the Open Type Dialog. I agree that this is more work to do than extending the Open Type dialog however making the Open Type dialog and all the surrounding classes API will look us into the current implementation and will make it hard to evolve the dialog any further (for example pushing more of the functionality into Core (as we did for camel case searching for M2)). Additionally this isn't a small amount of work either. The only compromise I can think of is us adding a filter provider which allows you to provide a composite to the UI and a select method which gets parts of the information (minus the path) as we are getting from the search engine (this for example will not allow resolving the corresponding Java element). For anything else I think you should build your own dialog.
The filter provider could also offer a method to provide a custom image for an entry.
Enclosed a first scetch of a type dialog extension interface: public interface ITypeDialogExtension { /** * Interface to access the type dialog hosting a * type dialog extension. */ public interface ITypeDialog { /** * Triggers a search inside the type dialog with the * current settings. */ public void search(); } /** * Initializes the type dialog extension with the given type dialog * * @param dialog the type dialog hosting this extension */ public void initialize(ITypeDialog dialog); /** * Creates the content area which the extensions contributes to the * type selection dialog. The area will be presented between the * table showing the list of types and the optional status line. * * @param parent the parent of the additional content area * @return the additional content area */ public Composite createContentArea(Composite parent); /** * Returns whether the the given type makes it into the list or * not. * <p> * For a detailed description of the parameters please look at * {@link TypeNameRequestor}. * </p> * @param modifiers the modifier flags of the type * @param packageName the dot-separated name of the package of the type * @param simpleTypeName the simple name of the type * @param enclosingTypeNames the type names of the enclosing type or an * empty array if the type is a top-level type. * * @return whether the type is selected or not */ public boolean select(int modifiers, char[] packageName, char[] simpleTypeName, char[][] enclosingTypeNames); /** * Returns an image for the given type or <code>null</code> if the * default image is to be used. * <p> * Note that any non shared images provided by the extension must * be disposed in the corresponding {@link #dispose} method. * </p> * * @param modifiers the modifier flags of the type * * @return the image used to render the given type in the list */ public Image getImage(int modifiers); /** * Hook to dispose any remaining UI resources. */ public void dispose(); }
Excellent. The interface will allow us to 1. Contribute UI 2. Trigger a refresh based on user selections 3. Filter types based on the refresh 4. Change images based on the refresh This should definitely help us extend on the speed/efficiency of the TypeSelection dialog. I had some implementation questions. Currently the only way to launch the TypeSelection dialog is JavaUI.createMainTypeDialog(...), and this returns a SelectionDialog. Unfortunately we dont have a way of listening to which type[s] a user has selected - and thus update the statusbar of the dialog. Unfortunately for us not all Types are 'Visual beans', and we need to disable/enable the dialog based on the selection of the user with a way to show why it is disabled/enabled. Also do you think it would be necessary to set the filter text through this interface, to show classes like '*Exception' etc. Thanks.
- the initial filter can already be passed in via the create methods - the super class of the TypeSelectionDialog supports the concept of a ISelectionStatusValidator. I will see how I can leverage this. It is currently used internally.
Fixed as outlined in comment #24. The new API is in package org.eclipse.jdt.ui.dialogs. The type selection dialog can be created via a factory method in JavaUI. Fixed for build >= I20051129
A small implementation deatil - the 'dispose()' method as mentioned in comment #24 has not been implemented in the I20051129 build.
There was no need for a dispose as we could just add dispose listeners to the UI components and cleanup images etc. Verified in the I20051129 build. Thanks for providing this extension.
The dispose method isn't provided since the API requests an ImageDescriptor and no images. Image descriptors don't need to be disposed. The dialog manages the images created from the descriptor and disposes them.
