UML软件工程组织

拖放 Eclipse Workbench 标签
作者:Shiva Kumar H.R. 出处:IBM

 

在本文中,我们将学习一种通过编程定制 Eclipse 中的编辑器和视图标签的拖放行为的技术。我们使用了一个示例来展示这种技术,该示例将编辑器与转移类型 org.eclipse.ui.part.EditorInputTransfer 进行关联。可以通过实现对这种转移类型的支持来支持编辑器的拖放行为。我们还为视图标签提供了一个类似的展示。本文假设您熟悉 SWT 的拖放技术。

定制意味着什么?

Eclipse Workbench 中的编辑器和视图标签可以支持默认拖放行为,默认拖放行为支持:

  • 视图在 Workbench 内部的移动和停靠
  • 在有标签的记事本内部重新安排视图或编辑器的顺序
  • 创建快速视图
  • 为了并排查看源代码,在编辑器区域并排显示几个编辑器

尽管这是一个非常令人振奋的功能列表,但在我去年从事的一个项目中,仍然需要更多的功能。用户需要能够对编辑器和视图标签进行拖放,将它们放到一个特殊的视图上。当用户这样做时,我们要做的是截获所拖放编辑器的 editor-id 和 input,以及所拖放视图的 view-id,然后在一个特殊的视图中显示相同的内容。下面的 图 1 和 图 2 将展示这种功能。

图 1 给出了一个标题为 .project 的编辑器,该编辑器被拖放到一个标题为 Drop Window 的特殊视图中。一旦拖放到如 图 2 所示的位置处,这个特殊的视图就会显示所拖放编辑器的 editor-id 和 input。

图 1. 正被拖放到特殊视图中的编辑器标签

 

 图 2. 被拖放到特殊视图上的编辑器标签
 

 与我们在这个项目中的要求类似,还可能存在其他一些需要对编辑器或视图标签的默认拖放行为进行定制的情况。例如,有人可能会希望允许 Eclipse 用户将编辑器标签从工作台窗口中拖出,将它放到相同 Eclipse 实例的另外一个窗口中。本文中介绍的技术也可以在这种情况下使用。

下面让我们来学习定制拖放行为所涉及的步骤,具体地说,这些步骤是针对编辑器标签的,但它们同样适用于视图标签。
定制编辑器标签的拖放行为

当 Eclipse 用户拖动一个编辑器标签时,要实现如 图 1 和 图 2 所示的定制拖放功能,并内部执行以下两个主要任务或操作:

操作 1

 捕获底层编辑器的 IEditorInput 和 editor-id,前者包含有关正在编辑的文件的信息;后者包含有关编辑正在使用的编辑器的类型信息。

 操作 2
 将 editor-input 和 editor-id 放到 EditorInputTransfer.EditorInputData 对象中,并将其设置为拖放过程中正在转移的对象。这种操作可以让 SWT 负责实现其余的拖放操作,例如将编辑器标签放到使用 EditorInputTransfer 作为转移类型的控件上。

 由于编辑器标签通常放在 CTabFolder 容器中,因此我们需要为存放编辑器的 CTabFolder 容器创建一个 DragSource,并在这个 DragSource 的 dragSetData() 方法中执行 操作 1 和 操作 2。假设我们可以捕获存放编辑器的 CTabFolder 容器,那么创建所需拖放源的任务就非常简单,如下所示:

清单 1. 为 Tab folder 创建拖放源

CTabFolder tabFolder = <"CTabFolder" composite that hosts editor-parts>;

int operations = DND.DROP_COPY | DND.DROP_DEFAULT;
DragSource dragSource = new DragSource(tabFolder, operations);

Transfer[] transferTypes = new Transfer[] {EditorInputTransfer.getInstance()};
dragSource.setTransfer(transferTypes);

dragSource.addDragListener(new DragSourceListener()
{
public void dragStart(DragSourceEvent dsEvent) { }
public void dragSetData(DragSourceEvent dsEvent)
{
//code to perform operation-1 and operation-2
}
public void dragFinished(DragSourceEvent dsEvent) { }
});

此处另外一个非常重要的假设是:CTabFolder 容器并没有已经创建好的拖放源。否则,代码 DragSource dragSource = new DragSource(tabFolder, operations); 就会触发一个 SWTError 错误,这是因为我们不能为同一个控件创建多个拖放源。

要查看这种假设是否有效(这也是 清单 1 的一个可能用途),让我们来看一下与这个编辑器标签有关的默认拖放行为。默认的行为提示说存放这个编辑器标签的 CTabFolder 容器可能早已为其创建了一个拖放源。然而,快速查看 org.eclipse.swt.custom.CTabFolder.java 的代码可以看到,CTabFolder 的默认拖放操作都不是通过创建一个拖放源来实现的,而是通过为 SWT.DragDetect、SWT.MouseMove 和 SWT.MouseUp 类型的事件添加监听程序来实现的。CTabFolder 容器还没有创建拖放源的假设仍然有效,正如我们可以看到的一样,这是基于查看非 API 内部类获得的信息而作出的假设。因此,如果这种假设在将来的版本中无效,也不用感到惊奇;不过我认为这种可能性非常小。

下面让我们来看一下如何捕获存放编辑器的 CTabFolder 容器。通过对编辑器平铺行为的观察,我们注意到不管在何时平铺显示编辑器,都会创建一个新的 Tab 文件夹。另外,当一个标签组中的所有编辑器全部关闭或被移动到一个不同的 Tab 文件夹上时,原来的 Tab 文件夹就会被销毁。这意味着 CTabFolder 容器的创建和销毁都是动态的,因此 CTabFolder 容器的拖放源的创建也应该是动态完成的。

要实现这种功能,需要能够对 CTabFolder 容器的创建进行控制。但是 Eclipse 并没有提供任何可以在创建 CTabFolder 容器时进行回调的功能。另外一种方法是对 CTabFolders 进行特殊化 (specialize) 处理(继承),继承这些 specialized CTabFolders(继承类,而不是基类 CTabFolder),并在这些 specialized CTabFolders 的 constructors 中创建拖放源。然而,在 Eclipse 中实例化这些 specialized CTabFolders 是一项非常繁杂的任务,因此我们需要寻找一种新的解决方案。

一种创建拖放源的新方法

下面让我们为 Display 添加一个拖放检测监听器(用来监听 SWT.DragDetect 类型的事件),如下所示:

清单 2. 为 Display 添加拖放监听器

PlatformUI.getWorkbench().getDisplay().addFilter(SWT.DragDetect, new Listener()
{
public void handleEvent(Event event)
{
}
});

不论何时发生拖放操作时,都会调用这个监听器的 handleEvent() 方法,其中 event.widget 指向产生这个事件的控件。在拖动编辑器标签时,event.widget 指向存放这个拖放编辑器标签的 CTabFolder 容器。这样我们现在就可以为这个 CTabFolder 容器创建一个拖放源,如下所示:

清单 3. 捕获存放编辑器的 Tab 文件夹

PlatformUI.getWorkbench().getDisplay().addFilter(SWT.DragDetect, new Listener()
{
public void handleEvent(Event event)
{
//ignore drag of widgets other than tab-folders (which host editor and view tabs)
if(!(event.widget instanceof CTabFolder))
return;

CTabFolder draggedFolder = (CTabFolder)event.widget;

int operations = DND.DROP_COPY | DND.DROP_DEFAULT;
final DragSource dragSource = new DragSource(draggedFolder, operations);

Transfer[] transferTypes = new Transfer[] {EditorInputTransfer.getInstance()};
dragSource.setTransfer(transferTypes);

dragSource.addDragListener(new DragSourceListener()
{
public void dragStart(DragSourceEvent dsEvent) { }
public void dragSetData(DragSourceEvent dsEvent)
{
//code to perform operation-1 and operation-2
}
public void dragFinished(DragSourceEvent dsEvent)
{
dragSource.dispose();
}
});
}
});

现在我们主要关心的是在开始拖放操作之后创建了一个新的拖放源。在开始拖放操作之后创建一个拖放源,这样做是否能够确保这个新的拖放源可以接收现在发生的拖放操作的通知?

为了寻找答案,首先让我们来了解一下 Eclipse 的事件分发行为。

当控件上产生某种类型的事件时,首先将是那些为相同事件类型注册的 Display 的所有过滤器 收到发生该事件的通知(使用 Display.addFilter() 方法添加的监听器),接收顺序是过滤器在 Display 上的注册顺序。然后发生该事件的通知会发送给控件中为该事件类型注册的所有监听器,发送顺序是这些监听器在控件上的注册顺序。

例如,假设 Listener 1 是在某个控件上为 t1 类型的事件注册的第一个监听器,而 Listener 2 是在这个控件上为相同的 t1 类型的事件注册的第二个监听器。另外假设 Filter 1 是在 Display 上为相同的 t1 类型的事件注册的过滤器。现在,当这个控件上产生一个 t1 类型的事件时,第一个接收到发生该事件的通知的是 Filter 1,然后是 Listener 1,最后是 Listener 2。

在这种新方法中,我们给 Display 为 SWT.DragDetect 类型的事件添加了一个 filter。默认拖放行为与编辑器标签有关,这意味着要对编辑器重新进行排列和平铺,说明 CTabFolder 存在多个拖放检测监听器。因此,我们有一个 filter 和多个与 CTabFolder 有关的 default-listeners,它们都要监听 SWT.DragDetect 事件。

当我们拖动一个编辑器标签时,filter 会第一个接收到这种拖动操作。在 filter 的 handleEvent() 方法中,我们正在创建一个 drag source,并为这个 drag-source 添加了一个 DragSourceListener。然后,它会向父 CTabFolder 容器注册了另外一个拖放检测监听器,我们称之为 drag-listener-x。因此,当程序控制返回 filter 的 handleEvent() 方法时,就会有一组 default-listeners 和 drag-listener-x 在等待接收拖动事件的通知。在通知 default set of listeners 之后,新注册的 drag-listener-x 也会接收到拖放事件的通知,这样就可以实现我们的目的了。

下图以图形方式显示了这些操作:

图 3. 拖放编辑器标签的序列图
 

注意,在 dragFinished() 方法中(参见上面的 清单 3),我们对在 CTabFolder 容器上创建的 drag-source 进行了处理。实际上这是因为为每次拖放操作都创建了一个 drag-source,我们并没有对原来的 drag-source 进行处理,这会使问题变得更加复杂。对 drag-source 的处理还从 CTabFolder 的事件监听器表中删除了 drag-listener-x(它是在创建 drag-source 时添加的),如上面的 图 3 所示。

如何捕获所拖放编辑器的 IEditorInput 和 Editor ID?

下面让我们来看一下怎样在 dragSetData() 方法中实现 操作 1 和 操作 2。

由于编辑器与包含它的 CTabFolder 之间的映射并没有公开,因此可以依靠 IWorkbenchPage.getActivePart() 来获得正在拖放的工作台部分,从中可以很容易地提取出所需的信息,如下面的代码所示:

清单 4. 捕获所拖放编辑器的 editor-input 和 editor-id

public void dragSetData(DragSourceEvent dsEvent)
{
IWorkbenchWindow workbenchWindow =
PlatformUI.getWorkbench().getActiveWorkbenchWindow();
IWorkbenchPart workbenchPartBeingDragged =
workbenchWindow.getActivePage().getActivePart();
if(workbenchPartBeingDragged instanceof IEditorPart)
{
String editorId = workbenchPartBeingDragged.getSite().getId();
IEditorInput editorInput =
((IEditorPart)workbenchPartBeingDragged).getEditorInput();
EditorInputTransfer.EditorInputData data =
EditorInputTransfer.createEditorInputData(editorId, editorInput);
dsEvent.data = new EditorInputTransfer.EditorInputData[] { data };
}
}

限制 tab 文件夹的默认拖放监听器的行为

正如上面介绍的一样,编辑器标签有一种默认的拖放行为,它将进行重新排列和平铺操作,这可以使用拖放检测、鼠标移动 和鼠标释放 类型的事件的监听器实现。这些鼠标移动和鼠标释放的事件监听器的行为可能会与我们正在对编辑器实现的拖放行为冲突。例如,在将编辑器标签拖放到 Drop Window 上之后,如 图 2 所示,编辑器标签的重新排列和平铺会重新出现,这会导致在执行定制行为中产生意料不到的操作。(我们可以认为这是另外一次操作。)因此,限制默认监听器的行为是非常有必要的。

我们的想法是取消或忽略所发生的其他拖放操作。Eclipse 用户可以通过使用 Esc 键或右键点击鼠标来轻松实现这种功能。通过编程可以很容易实现这种功能:使用 event.button 值而不是 1 来执行触发鼠标释放事件,如下所示:

清单 5. 取消其他拖放操作

public void dragFinished(DragSourceEvent dsEvent)
{
dragSource.dispose();

// inhibit the action of CTabFolder's default drag-drop-listeners
draggedFolder.notifyListeners(SWT.MouseUp, null);
}

对视图标签的拖放行为进行定制

由于视图通常都存放在 CTabFolder 容器中,因此上面用来定制编辑器的拖放行为的方法也可以用来定制视图的拖放行为。要像上面的 图 1 和 图 2 中所显示的那样对视图的拖放行为进行定制,则需要执行以下操作:当用户拖动一个视图标签时,捕获底层视图的 view-id,并将其设置为拖放过程中正在转移的对象。下面黑色字体表示的代码是应该在上面 清单 3 和 清单 4 的基础上添加的代码。

清单 6. 定制编辑器和视图标签的拖放行为

PlatformUI.getWorkbench().getDisplay().addFilter(SWT.DragDetect, new Listener()
{
public void handleEvent(Event event)
{
//ignore drag of widgets other than tab-folders (which host
//editor and view tabs)
if(!(event.widget instanceof CTabFolder))
return;

final CTabFolder draggedFolder = (CTabFolder)event.widget;

//Handle special case where no editors are open but editor area
//(and hence containing tab-folder) are still visible. Now try
//dragging the tab-folder. This drag should be ignored.
if( draggedFolder.getItemCount() < 1 )
return;
int operations = DND.DROP_COPY | DND.DROP_DEFAULT;
final DragSource dragSource = new DragSource(draggedFolder, operations);

//get a reference to the workbench-part that is being dragged
IWorkbenchWindow workbenchWindow =
PlatformUI.getWorkbench().getActiveWorkbenchWindow();
final IWorkbenchPart workbenchPartBeingDragged =
workbenchWindow.getActivePage().getActivePart();

Transfer[] transferTypes = null;
if(workbenchPartBeingDragged instanceof IEditorPart)
transferTypes = new Transfer[] {EditorInputTransfer.getInstance()};
else
transferTypes = new Transfer[] {TextTransfer.getInstance()};
dragSource.setTransfer(transferTypes);

dragSource.addDragListener(new DragSourceListener()
{
public void dragStart(DragSourceEvent dsEvent) { }
public void dragSetData(DragSourceEvent dsEvent)
{
if(workbenchPartBeingDragged instanceof IEditorPart)
{
String editorId = workbenchPartBeingDragged.getSite().getId();
IEditorInput editorInput =
((IEditorPart)workbenchPartBeingDragged).getEditorInput();
EditorInputTransfer.EditorInputData data =
EditorInputTransfer.createEditorInputData(editorId, editorInput);
dsEvent.data = new EditorInputTransfer.EditorInputData[] { data };
}
else if(workbenchPartBeingDragged instanceof IViewPart)
{
String viewId = workbenchPartBeingDragged.getSite().getId();
dsEvent.data = viewId;
}
}
public void dragFinished(DragSourceEvent dsEvent)
{
dragSource.dispose();

// inhibit the action of CTabFolder's default drag-detect-listeners
draggedFolder.notifyListeners(SWT.MouseUp, null);
}
});
}
});

运行这个示例

这个 DragDropWorkbenchParts 插件在 Window 菜单中增加了一个菜单项 Enable Drag-n-Drop of Editor/View Parts。它在工具条中添加了一个相应的触发按钮。当用户选择这个菜单项或触发按钮时,就会有一个如 清单 6 所示的过滤器 被添加到 Display 中,从而启用编辑器和视图标签的拖放操作。当没有选择这个操作时,就会从 Display 中删除这个过滤器,恢复编辑器和视图标签的默认拖放行为(这意味着又可以进行重新排列和平铺操作了)。

该插件还定义了一个标题为 Drop Window 的视图,它有一个支持 EditorInputTransfer 和 TextTransfer 的拖放目标,允许将编辑器和视图标签拖放到此窗口中。

 

版权所有:UML软件工程组织