Bug 175939 - Drop support not implemented in the STEM Project Explorer
Summary: Drop support not implemented in the STEM Project Explorer
Status: CLOSED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: OHF (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Daniel Ford CLA
QA Contact: Daniel Ford CLA
URL:
Whiteboard:
Keywords: ui
Depends on:
Blocks:
 
Reported: 2007-02-28 18:05 EST by Daniel Ford CLA
Modified: 2012-01-05 13:31 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Ford CLA 2007-02-28 18:05:09 EST
needs to be implemented
Comment 1 Daniel Ford CLA 2008-05-27 14:06:21 EDT
I started looking at this.  It seems like we want to add a "dropAssistant" to the appropriate navigatorContent extension point and that we want to specify an instance of org.eclipse.ui.navigator.resources.ResourceDropAdapterAssistant.  It seems from my reading that the "possibleChildren" extension point is used to decide if the contents of the drop match the point where the drop might occur, if so then the CommonDropAdapterAssistant (parent of ResourceDropAdapterAssistant) is called to handle the drop.

This EclipseCon talk describes the common navigator framework http://www.eclipsecon.org/2006/Sub.do?id=260
Comment 2 Daniel Ford CLA 2008-05-28 17:17:18 EDT
Having looked at it a bit more, it looks like the class IdentifiableInstanceTreeNode is doing the same job as IdentifiableDelegate.  Each IdentifiableInstanceTreeNode is created from the files in the project that correspond to the various serialized Identifiable instances in the project.  Each IdentifiableDelegate instance is created from an IConfigurationElement instance read from the org.eclipse.ohf.stem.geography/plugin.xml.  Basically, the IdentifiableDelegate instance contains a URI to the serialized file and the DublinCore data, both of which come from the IConfigurationElement.

The IdentifiableInstanceTreeNode maintains the name and extension of the serialized file, but no DublinCore.  If we used the class IdentifiableDelegate instead, we'd have to provide the URI of the serialized file (not a big deal), and the DublinCore metadata, which could only be obtained by reading the file itself.  The IdentifiablDelegate class would likely have to change a bit to hide it's origin, right now it explicitly exposes the IConfiguratElement instance to allow clients to get access to the URI and other values from the DublinCore.  Probably the best thing to do would be to create an explicit DublinCore instance for IdentifiableDelegate instead of linking it to IConfigurationElement.

The advantage of doing this is that there is already support for dealing with IdentifiableDelegates in the menus and in the Platform's adapter factory that does things like create an IExecutable instance out of a IdentifiableDelegate and start running a Simulation.  We'd have to do the same for IdentifaibleInstanceTreeNode.
Comment 3 Daniel Ford CLA 2008-05-29 13:56:09 EDT
I removed all traces of IConfigurationElement except from the constructor.  I think we need another constructor that takes a URI before we can use IdentifiableDelegate to replace IdentifiableInstanceTreeNode.
Comment 4 Daniel Ford CLA 2008-06-24 12:20:49 EDT
I checked in a partial implementation that handles dragging and dropping Scenarios from the Scenarios view.  
Comment 5 Daniel Ford CLA 2008-06-24 12:51:15 EDT
Implemented support for Models, Sequencers, etc.
Comment 6 Daniel Ford CLA 2008-10-31 16:11:56 EDT
fixed by bug 251590
Comment 7 Daniel Ford CLA 2008-10-31 16:12:06 EDT
close