Community
Participate
Working Groups
The way how the context produced by ShowInContext IShowInSource.getShowInContext() and is used and finally passed into boolean IShowInTarget.show(ShowInContext) is problematic when determining the ShowInContext from the selection is somewhat more expensive such as when this requires some sort of query. The issue is that the menu display code and the final will operate on the same unchanged ShowInContext object. This doesn't allow the Source View to delay running the queries until the menu action has been invoked. See also http://dev.eclipse.org/newslists/news.eclipse.platform/msg30079.html for some more background
Interesting. I understand the need to extend the ShowInContext with more detailed (and potentially expensive to calculate) info once a target has been chosen. However, you may be able to work around this with one of the following approaches. Both would require some agreement between the two views though. Approach 1: - The MusicView returns a subclass of ShowInContext, augmented with an ISong getSongs() method, which calculates the result lazily. The context's selection would still be in terms of IFoundSong objects. - the MusicReviewView checks for this subclass, casts down to it and uses getSongs() instead of getSelection() - this requires both views to know about the ShowInContext subclass Approach 2: - have IFoundSong implement IAdaptable, and have getAdapter(ISong.class) return the song (again, calculated lazily) - MusicView still provides a ShowInContext where the selection is of IFoundSongs - MusicReviewView checks whether the selection contains either ISongs directly or objects that can adapt to ISong - this approach is more decoupled in that there's no need to agree on a new subclass of ShowInContext, but it still requires a change to MusicReviewView Ideally you'd like to do the database query in a non-UI thread as well, to maintain UI responsiveness, and also provide some kind of progress feedback. This would be easier to do if the ShowIn mechanism had two stages as you suggest. But in the meantime, you could get this if MusicReviewView did either the getSongs() call or the getAdapter(ISong.class) calls in a background job. (See http://eclipse.org/articles/Article-Concurrency/jobs-api.html)
The roles of the two views in the previous comment are opposite to what is described in the news link of the original description. Both approaches seem fine as long as one can change or design the code of MusicView accordingly. On the other hand a mechanism allowing to do this without having to change MusicView which also would facilitate providing some sort of progress feedback seems superior in terms of general platform extensibility and UI consistency and hence this RFE. In my actual case I can change the MusicView code but I still have to solve the feedback issue. Perhaps this is even a different UI issue since the query could also fail if the link is broken in the music review. On the other hand I don’t see this as a case where user should first invoke a search, see some search results and then navigate from there since there are so many unnecessary intermediate steps and UI leftovers resulting for this. Another approach to solve this may be that one starts querying in the background to find referenced songs of a music review and perhaps cache the results in workspace metadata. Similar as this is done in JDT. However I would think that this will cost a lot more in resources and implementation costs. I think having a story to support “queried links” would be a plus for the platform.
See also bug 76036. It feels like the handshaking protocol in the Show In support could be improved. Currently there's no way for the JavaSearchResultPage to say "I'll supply resources in the show in context if the Navigator is chosen as the target, but I'll supply Java elements if the Package Explorer is chosen.". One possibility is to use SWT's DnD Transfer mechanism. So an IShowInSource could provide multiple possible formats, e.g. a ResourceTransfer and a JavaElementTransfer, without having to care about which kind of format particular targets prefer. IShowInSource/IShowInTarget would work similarly to DragSource/DropTarget. This would also address the lazy aspect being requested here, since Transfer.nativeToJava and javaToNative are only called when the data is actually needed. We'd have to request that these methods become public API though.
Reassigning bugs in component areas that are changing ownership.
Remy is now responsible for watching the [ViewMgmt] category.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
