关于Eclipse RCP的两个小问题和解决方法

1、如果你想在RCP应用程序里使用Eclipse提供的Resource Navigator(它是IDE plugin的一部分),要在WorkbenchAdvisor里加入如下代码,否则在Navigator里新建的项目和文件名都会变为空:

WorkbenchAdapterBuilder.registerAdapters();

一 般加在preWindowOpen()方法里就可以了,否则可能需要手动refresh才能看到已有的项目。当然,你还要在plugin dependencies里加上org.eclipse.ui.ide和org.eclipse.ui.views,所以你的RCP程序会变得更大,这就 是代价,目前这个ResourceNavigator不被鼓励用在RCP程序里,以后版本的Eclipse可能会提供更合适的插件。

2、若你在运行RCP Application时遇到以下异常:

java.lang.NoSuchMethodException: com.your.YourPlugin.<init>(org.eclipse.core.runtime.IPluginDescriptor)
    at java.lang.Class.getConstructor0(Unknown Source)
    at java.lang.Class.getConstructor(Unknown Source)
    at org.eclipse.core.internal.plugins.PluginDescriptor.internalDoPluginActivation(PluginDescriptor.java:403)
    at org.eclipse.core.internal.plugins.PluginDescriptor.doPluginActivation(PluginDescriptor.java:359)

或是:

org.eclipse.core.runtime.CoreException[1]: java.lang.ClassNotFoundException: com.your.YourApplication
    at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:404)
    at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java:93)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at org.eclipse.osgi.framework.internal.core.BundleLoader.loadClass(BundleLoader.java:307)

可以检查一下你是否在plugin dependencies里增加了org.eclipse.core.runtime.compatibility,我不太清楚这个plugin是做什么用的,但只要有它在我的RCP Application就无法启动。
最后,如果希望在Eclipse的console里显示log而不是直接写入到文件中,可以在运行时加上-consoleLog参数。

搬家前链接:https://www.cnblogs.com/bjzhanghao/archive/2005/03/16/119607.html

[Eclipse]GEF入门系列(四、其他功能)

最近由于实验室任务繁重,一直没有继续研究GEF,本来已经掌握的一些东西好象又丢掉了不少,真是无奈啊,看来还是要经常碰碰。刚刚接触GEF的朋友大都会有这样的印象:GEF里概念太多,比较绕,一些能直接实现的功能非要拐几个弯到另一个类里做,而且很多类的名字十分相似,加上不知道他们的作用,感觉就好象一团乱麻。我觉得这种情况是由图形用户界面(GUI)的复杂性所决定的,GUI看似简单,实际上包含了相当多的逻辑,特别是GEF处理的这种图形编辑方式,可以说是最复杂的一种。GEF里每一个类,应该说都有它存在的理由,我们要尽可能了解作者的意图,这就需要多看文档和好的例子。

在Eclipse里查看文档和代码相当便利,比如我们对某个类的用法不清楚,一般首先找它的注释(选中类或方法按F2),其次可以查看它在其他地方用法(选中类或方法按Ctrl+Shift+G),还可以找它的源代码(Ctrl+鼠标左键或F3)来看,另外Ctrl+Shift+T可以按名称查找一个类等等。学GEF是少不了看代码的,当然还需要时间和耐心。

好,闲话少说,下面进入正题。这篇帖子将继续上一篇内容,主要讨论如何实现DirectEdit、属性页和大纲视图,这些都是一个完整GEF应用程序需要提供的基本功能。

实现DirectEdit

所谓DirectEdit(也称In-Place-Edit),就是允许用户在原本显示内容的地方直接对内容进行修改,例如在Windows资源管理器里选中一个文件,然后按F2键就可以开始修改文件名。实现DirectEdit的原理很直接:当用户发出修改请求(REQ_DIRECT_EDIT)时,就在文字内容所在位置覆盖一个文本框(也可以是下拉框,这里我们只讨论文本的情况)作为编辑器,编辑结束后,再将编辑器中的内容应用到模型里即可。(作为类似的功能请参考:给表格的单元格增加编辑功能

file
图1 Direct Edit

在GEF里,这个弹出的编辑器由DirectEditManager类负责管理,在我们的NodePart类里,通过覆盖performRequest()方法响应用户的DirectEdit请求,在这个方法里一般要构造一个DirectEditManager类的实例(例子中的NodeDirectEditManager),并传入必要的参数,包括接受请求的EditPart(就是自己,this)、编辑器类型(使用TextCellEditor)以及用来定位编辑器的CellEditorLocator(NodeCellEditorLocator),然后用show()方法使编辑器显示出来,而编辑器中显示的内容已经在构造方法里得到。简单看一下NodeCellEditorLocator类,它的关键方法在relocate()里,当编辑器里的内容改变时,这个方法被调用从而让编辑器始终处于正确的坐标位置。DirectEditManager有一个重要的initCellEditor()方法,它的主要作用是设置编辑器的初始值。在我们的例子里,初始值设置为被编辑NodePart对应模型 (Node)的name属性值;这里还另外完成了设置编辑器字体和选中全部文字(selectAll)的功能,因为这样更符合一般使用习惯。

在NodePart里还要增加一个角色为DIRECT_EDIT_ROLE的EditPolicy,它应该继承自DirectEditPolicy,有两个方法需要实现:getDirectEditCommand()和showCurrentEditValue(),虽然还未遇到过,但前者的作用你不应该感到陌生--在编辑结束时生成一个Command对象将修改结果作用到模型;后者的目的是更新Figure中的显示,虽然我们的编辑器覆盖了Figure中的文本,似乎并不需要管Figure的显示,但在编辑中时刻保持这两个文本的一致才不会出现"盖不住"的情况,例如当编辑器里的文本较短时。

实现属性页

在GEF里实现属性页和普通应用程序基本一样,例如我们希望可以通过属性视图(PropertyView)显示和编辑每个节点的属性,则可以让Node类实现IPropertySource接口,并通过一个IPropertyDescriptor[]类型的成员变量描述要在属性视图里显示的那些属性。有朋友问,要在属性页里增加一个属性都该改哪些地方,主要是三个地方:首先要在你的IPropertyDescriptor[]变量里增加对应的描述,包括属性名和属性编辑方式(比如文本或是下拉框,如果是后者还要指定选项列表),其次是getPropertyValue()和setPropertyValue()里增加读取属性值和将结果写入的代码,这两个方法里一般都是像下面的结构(以前者为例):

public Object getPropertyValue(Object id) {
    if (PROP_NAME.equals(id))
        return getName();
    if (PROP_VISIBLE.equals(id))
        return isVisible() ? new Integer(0) : new Integer(1);
    return null;
}

也就是根据要处理的属性名做不同操作。要注意的是,下拉框类型的编辑器是以Integer类型数据代表选中项序号的,而不是int或String,例如上面的代码根据visible属性返回第零项或第一项,否则会出现ClassCastException。

file
图2 属性页

实现大纲视图

在Eclipse里,当编辑器(Editor)被激活时,大纲视图自动通过这个编辑器的getAdapter()方法寻找它提供的大纲(大纲实现IcontentOutlinePage接口)。GEF提供了ContentOutlinePage类用来实现大纲视图,我们要做的就是实现一个它的子类,并重点实现createControl()方法。ContentOutlinePage是org.eclipse.ui.part.Page的一个子类,大纲视图则是PageBookView的子类,在大纲视图中有一个PageBook,包含了很多Page并可以在它们之间切换,切换的依据就是当前活动的Editor。因此,我们在createControl()方法里要做的就是构造这个Page,简化后的代码如下所示:

private Control outline;
public OutlinePage() {
    super(new TreeViewer());
}
public void createControl(Composite parent) {
    outline = getViewer().createControl(parent);
    getSelectionSynchronizer().addViewer(getViewer());
    getViewer().setEditDomain(getEditDomain());
    getViewer().setEditPartFactory(new TreePartFactory());
    getViewer().setContents(getDiagram());
}

由于我们在构造方法里指定了使用树结构显示大纲,所以createControl()里的第一句就会使outline变量得到一个Tree(见org.eclipse.gef.ui.parts.TreeViewer的代码),第二句把TreeViewer加到选择同步器中,从而让用户不论在大纲或编辑区域里选择EditPart时,另一方都能自动做出同样的选择;最后三行的作用在以前的帖子里都有介绍,总体目的是把大纲视图的模型与编辑区域的模型联系在一起,这样,对于同一个模型我们就有了两个视图,体会到MVC的好处了吧。

实现大纲视图最重要的工作基本就是这些,但还没有完,我们要在init()方法里绑定UNDO/REDO/DELETE等命令到Eclipse主窗口,否则当大纲视图处于活动状态时,主工具条上的这些命令就会变为不可用状态;在 getControl()方法里要返回我们的outline成员变量,也就是指定让这个控件出现在大纲视图中;在dispose()方法里应该把这个TreeViewer从选择同步器中移除;最后,必须在PracticeEditor里覆盖getAdapter()方法,前面说过,这个方法是在Editor激活时被大纲视图调用的,所以在这里必须把我们实现好的OutlinePage返回给大纲视图使用,代码如下:

public Object getAdapter(Class type) {
    if (type == IContentOutlinePage.class)
        return new OutlinePage();
    return super.getAdapter(type);
}

这样,树型大纲视图就完成了,见下图。很多GEF应用程序同时具有树型和缩略图两种大纲,实现的基本思路是一样的,但代码会稍微复杂一些,因为这两种大纲一般要通过一个PageBook进行切换,缩略图一般由org.eclipse.draw2d.parts.ScrollableThumbnail负责实现,这里暂时不讲了(也许以后会详细说),你也可以通过看logic例子的LogicEditor这个类的代码来了解。

file
图3 大纲视图

P.S.写这篇帖子的时候,我对例子又做了一些修改,都是和这篇帖子所说的内容相关的,所以如果你以前下载过,会发现那时的代码与现在稍有不同(功能还是完全一样的,下载)。另外要说一下,这个例子并不完善,比如删除一个节点的时候,它的连接就没同时删除,一些键盘快捷键不起作用,还存在很多被注释掉的代码等等。如果有兴趣你可以来修改它们,也是不错的学习途径。

搬家前链接:https://www.cnblogs.com/bjzhanghao/archive/2005/03/15/119010.html

设置Eclipse RCP程序的外观和首选项

RCP应用程序的缺省外观是一个空白窗口,一般我们要通过一个WorkbenchAdvisor类对界面进行定制。 WorkbenchAdvisor有很多回调方法,可以在preWindowOpen()方法里设置菜单、工具条、状态栏、进度栏、透视图切换工具是否可 见,在fillActionBars()方法里添加菜单和工具条项,在getInitialWindowPerspectiveId()方法里指定首选的 透视图。

缺省情况下,透视图切换工具位于窗口左上角,在Eclipse里可以通过Window->Preferences-> Workbench->Appearance改变它的位置,那么怎样用程序控制它呢?有两个方法,第一个是使用如下代码设置 IPreferenceStore中的变量:

IPreferenceStore apiStore = PrefUtil.getAPIPreferenceStore(); 
apiStore.setValue(IWorkbenchPreferenceConstants.DOCK_PERSPECTIVE_BAR, IWorkbenchPreferenceConstants.TOP_RIGHT);

另一个方法是在plugin所在目录建一个名为plugin_customization.ini的文件,里面写如下内容:

your.plugin.id/DOCK_PERSPECTIVE_BAR = topRight 

其他与plugin相关的Preference值可以用同样方法设置。

Update:在最新的Eclipse 3.1M5a版本中,对RCP应用程序菜单和工具条的定制方法有所改变,应该使用新加入的ActionBarAdvisor类来完成此项工作。

搬家前链接:https://www.cnblogs.com/bjzhanghao/archive/2005/03/02/111633.html

[Eclipse]GEF入门系列(三、应用实例)

构造一个GEF应用程序通常分为这么几个步骤:设计模型、设计EditPart和Figure、设计EditPolicy和Command,其中 EditPart是最主要的一部分,因为在实现它的时候不可避免的要使用到EditPolicy,而后者又涉及到Command。

现在我们来看个例子,它的功能非常简单,用户可以在画布上增加节点(Node)和节点间的连接,可以直接编辑节点的名称以及改变节点的位置,用户可以撤消/重做任何操作,有一个树状的大纲视图和一个属性页。点此下载(Update: For Eclipse 3.1的版本),这是一个Eclipse的项目打包文件,在Eclipse里导入后运行Run-time Workbench,新建一个扩展名为"gefpractice"的文件就会打开这个编辑器。

file

图1 Practice Editor的使用界面

你可以参考着代码来看接下来的内容了,让我们从模型开始说起。模型是根据应用需求来设计的,所以我们的模型包括代表整个图的Diagram、代表节 点的Node和代表连接的Connection这些对象。我们知道,模型是要负责把自己的改变通知给EditPart的,为了把这个功能分离出来,我们使 用名为Element的抽象类专门来实现通知机制,然后让其他模型类继承它。Element类里包括一个PropertyChangeSupport类型 的成员变量,并提供了addPropertyChangeListener()、removePropertyChangeListener()和 fireXXX()方法分别用来注册监听器和通知监听器模型改变事件。在GEF里,模型的监听器就是EditPart,在EditPart的active ()方法里我们会把它作为监听器注册到模型中。所以,总共有四个类组成了我们的模型部分。

在前面的贴子里说过,大部分GEF应用程序都是实现为Editor的,这个例子也不例外,对应的Editor名为PracticeEditor。这 个Editor继承了GraphicalEditorWithPalette类,表示它是一个具有调色板的图形编辑器。最重要的两个方法是 configureGraphicalViewer()和initializeGraphicalViewer(),分别用来定制和初始化 EditPartViewer(关于EditPartViewer的作用请查看前面的帖子),简单查看一下GEF的代码你会发现,在 GraphicalEditor类里会先后调用这两个方法,只是中间插了一个hookGraphicalViewer()方法,其作用是同步选择和把 EditPartViewer作为SelectionProvider注册到所在的site(Site是Workbench的概念,请查Eclipse帮 助)。所以,与选择无关的初始化操作应该在前者中完成,否则放在后者完成。例子中,在这两个方法里我们配置了RootEditPart、用于创建 EditPart的EditPartFactory、Contents即Diagram对象和增加了拖放支持,拖动目标是当前 EditPartViewer,后面会看到拖动源就是调色板。

这个Editor是带有调色板的,所以要告诉GEF我们的调色板里都有哪些工具,这是通过覆盖getPaletteRoot()方法来实现的。在这 个方法里,我们利用自己写的一个工具类PaletteFactory构造一个PaletteRoot对象并返回,我们的调色板里需要有三种工具:选择工 具、节点工具和连接工具。在GEF里,调色板里可以有抽屉(PaletteDrawer)把各种工具归类放置,每个工具都是一个ToolEntry,选择 工具(SelectionToolEntry)和连接工具(ConnectionCreationToolEntry)是预先定义好的几种工具中的两个, 所以可以直接使用。对于节点工具,要使用CombinedTemplateCreationEntry,并把节点类型作为参数之一传给它,创建节点工具的 代码如下所示。

ToolEntry tool = new CombinedTemplateCreationEntry("Node", "Create a new Node", Node.class, new SimpleFactory(Node.class), null, null);

在新的3.0版本GEF里还提供了一种可以自动隐藏调色板的编辑器GraphicalEditorWithFlyoutPalette,对调色板的外观有更多选项可以选择,以后的帖子里可能会提到如何使用。

调色板的初始化操作应该放在initializePaletteViewer()里完成,最主要的任务是为调色板所在的 EditPartViewer添加拖动源事件支持,前面我们已经为画布所在EditPartViewer添加了拖动目标事件,所以现在就可以实现完整的拖 放操作了。这里稍微讲解一下拖放的实现原理,以用来创建节点对象的节点工具为例,它在调色板里是一个 CombinedTemplateCreationEntry,在创建这个PaletteEntry时(见上面的代码)我们指定该对象对应一个 Node.class,所以在用户从调色板里拖动这个工具时,内存里有一个TemplateTransfer单例对象会记录下Node.class(称作 template),当用户在画布上松开鼠标时,拖放结束的事件被触发,将由画布注册的 DiagramTemplateTransferDropTargetListener对象来处理template对象(现在是Node.class), 在例子中我们的处理方法是用一个名为ElementFactory的对象负责根据这个template创建一个对应类型的实例。

以上我们建立了模型和用于实现视图的Editor,因为模型的改变都是由Command对象直接修改的,所以下面我们先来看都有哪些 Command。由需求可知,我们对模型的操作有增加/删除节点、修改节点名称、改变节点位置和增加/删除连接等,所以对应就有 CreateNodeCommand、DeleteNodeCommand、RenameNodeCommand、MoveNodeCommand、 CreateConnectionCommand和DeleteConnectionCommand这些对象,它们都放归类在commands包里。一个 Command对象里最重要的当然是execute()方法了,也就是执行命令的方法。除此以外,因为要实现撤消/重做功能,所以在Command对象里 都有Undo()和Redo()方法,同时在Command对象里要有成员变量负责保留执行该命令时的相关状态,例如RenameNodeCommand 里要有oldName和newName两个变量,这样才能正确的执行Undo()和Redo()方法,要记住,每个被执行过的Command对象实例都是 被保存在EditDomain的CommandStack中的。

例子里的EditPolicy都放在policies包里,与图形有关的(GraphicalEditPart的子类)有 DiagramLayoutEditPolicy、NodeDirectEditPolicy和 NodeGraphicalNodeEditPolicy,另外两个则是与图形无关的编辑策略。可以看到,在后一种类型的两个类 (ConnectionEditPolicy和NodeEditPolicy)中我们只覆盖了createDeleteCommand()方法,该方法用 于创建一个负责"删除"操作的Command对象并返回,要搞清这个方法看似矛盾的名字里create和delete是对不同对象而言的。

有了Command和EditPolicy,现在可以来看看EditPart部分了。每一个模型对象都对应一个EditPart,所以我们的三个模 型对象(Element不算)分别对应DiagramPart、ConnectionPart和NodePart。对于含有子元素的EditPart,必 须覆盖getModelChildren()方法返回子对象列表,例如DiagramPart里这个方法返回的是Diagram对象包含的Node对象列 表。

每个EditPart都有active()和deactive()两个方法,一般我们在前者里注册监听器(因为实现了 PropertyChangeListener接口,所以EditPart本身就是监听器)到模型对象,在后者里将监听器从列表里移除。在触发监听器事件 的propertyChange()方法里,一般是根据"事件名"称决定使用何种方式刷新视图,例如对于NodePart,如果是节点本身的属性发生变 化,则调用refreshVisuals()方法,若是与它相关的连接发生变化,则调用refreshTargetConnections()或 refreshSourceConnections()。这里用到的事件名称都是我们自己来规定的,在例子中比如Node.PROP_NAME表示节点的 名称属性,Node.PROP_LOCATION表示节点的位置属性,等等。

EditPart(确切的说是AbstractGraphicalEditpart)另外一个需要实现的重要方法是createFigure(), 这个方法应该返回模型在视图中的图形表示,是一个IFigure类型对象。一般都把这些图形放在figures包里,例子里只有NodeFigure一个 自定义图形,Diagram对象对应的是GEF自带的名为FreeformLayer的图形,它是一个可以在东南西北四个方向任意扩展的层图形;而 Connection对应的也是GEF自带的图形,名为PolylineConnection,这个图形缺省是一条用来连接另外两个图形的直线,在例子里 我们通过setTargetDecoration()方法让连接的目标端显示一个箭头。

最后,要为EditPart增加适当的EditPolicy,这是通过覆盖EditPart的createEditPolicies()方法来实现 的,每一个被"安装"到EditPart中的EditPolicy都对应一个用来表示角色(Role)的字符串。对于在模型中有子元素的 EditPart,一般都会安装一个EditPolicy.LAYOUT_ROLE角色的EditPolicy(见下面的代码),后者多为 LayoutEditPolicy的子类;对于连接类型的EditPart,一般要安装 EditPolicy.CONNECTION_ENDPOINTS_ROLE角色的EditPolicy,后者则多为 ConnectionEndpointEditPolicy或其子类,等等。

installEditPolicy(EditPolicy.LAYOUT_ROLE, new DiagramLayoutEditPolicy());

用户的操作会被当前工具(缺省为选择工具SelectionTool)转换为请求(Request),请求根据类型被分发到目标EditPart所安装的EditPolicy,后者根据请求对应的角色来判断是否应该创建命令并执行。

在以前的帖子里说过,Role-EditPolicy-Command这样的设计主要是为了尽量重用代码,例如同一个EditPolicy可以被安 装在不同EditPart中,而同一个Command可以被不同的EditPolicy所使用,等等。当然,凡事有利必有弊,我认为这种的设计也有缺点, 首先在代码上看来不够直观,你必须对众多Role、EditPolicy有所了解,增加了学习周期;另外大部分不需要重用的代码也要按照这个相对复杂的方 式来写,带来了额外工作量。

以上就是一个GEF应用程序里最基本的几个组成部分,例子中还有如Direct Edit、属性表和大纲视图等一些功能没有讲解,下面的帖子里将介绍这些常用功能的实现。

搬家前链接:https://www.cnblogs.com/bjzhanghao/archive/2005/02/19/106000.html

[Eclipse]GEF入门系列(二、GEF概述)

在前面的帖子已经提到,GEF(Graphical Editor Framework)是一个图形化编辑框架,它允许开发人员以图形化的方式展示和编辑模型,从而提升用户体验。这样的应用程序有很多,例如:UML类图编辑器、图形化XML编辑器、界面设计工具以及图形化数据库结构设计工具等等。归结一下,可以发现它们在图形化编辑方面具有以下共同之处:

  • 提供一个编辑区域和一个工具条,用户在工具条里选择需要的工具,以拖动或单击的方式将节点或连接放置在编辑区域;
  • 节点可以包含子节点;
  • 用户能够查看和修改某个节点或连接的大部分属性;
  • 连接端点锚定在节点上;
  • 提供上下文菜单和键盘命令;
  • 提供图形的缩放功能;
  • 提供一个大纲视图,显示编辑区域的缩略图,或是树状模型结构;
  • 支持撤消/重做功能;
  • 等等。

 file
图1 基于GEF的界面设计工具(Visual Editor,VE)的工作界面

GEF最早是Eclipse的一个内部项目,后来逐渐转变为Eclipse的一个开源工具项目,Eclipse的不少其他子项目都需要它的支持。Eclipse 3.0版本花了很大功夫在从Platform中剥离各种功能部件上,包括GEF和IDE在内的很多曾经只能在Eclipse内部使用的工具成为可以独立使用的软件/插件包了。理论上我们是可以脱离Eclipse用GEF包构造自己的应用程序的,但由于它们之间天然的联系,而且Eclipse确实是一个很值得支持的开发平台,所以我还是推荐你在Eclipse中使用它。

GEF的优势是提供了标准的MVC(Model-View-Control)结构,开发人员可以利用GEF来完成以上这些功能,而不需要自己重新设计。与其他一些MVC编辑框架相比,GEF的一个主要设计目标是尽量减少模型和视图之间的依赖,好处是可以根据需要选择任意模型和视图的组合,而不必受开发框架的局限(不过实际上还是很少有脱离Draw2D的实现)。

现在来看看GEF是如何实现MVC框架的吧,在这个帖子里我们先概括介绍一下它的各个组成部分,以后将结合例子进行更详细的说明。

file
图2 GEF结构图

模型:GEF的模型只与控制器打交道,而不知道任何与视图有关的东西。为了能让控制器知道模型的变化,应该把控制器作为事件监听者注册在模型中,当模型发生变化时,就触发相应的事件给控制器,后者负责通知各个视图进行更新。

典型的模型对象会包含PropertyChangeSupport类型的成员变量,用来维护监听器成员即控制器;对于与其他对象具有连接关系的模型,要维护连入/连出的连接列表;如果模型对应的节点具有大小和位置信息,还要维护它们。这些变量并不是模型本身必须的信息,维护它们使模型变得不够清晰,但你可以通过构造一些抽象模型类(例如让所有具有连接的模型对象继承Node类)来维持它们的可读性。

相对来讲GEF中模型是MVC中最简单的一部分。

控制器:我们知道,在MVC结构里控制器是模型与视图之间的桥梁,也是整个GEF的核心。它不仅要监听模型的变化,当用户编辑视图时,还要把编辑结果反映到模型上。举个例子来说,用户在数据库结构图上删除一个表时,控制器应该从模型中删除这个表对象、表中的字段对象、以及与这些对象有关的所有连接。当然在GEF中这些操作不是由直接控制器完成的,这个稍后就会说到。

GEF中的控制器是所谓的EditPart对象,更确切的说应该是一组EditPart对象共同组成了GEF的控制器这部分,每一个模型对象都对应一个EditPart对象。你的应用程序中需要有一个EditPartFactory对象负责根据给定模型对象创建对应的EditPart对象,这个工厂类将被视图利用。

RootEditPart是一种特殊的EditPart,它和你的模型没有任何关系,它的作用是把EditPartViewer和contents(应用程序的最上层EditPart,一般代表一块画布)联系起来,可以把它想成是contents的容器。EditPartViewer有一个方法setRootEditPart()专门用来指定视图对应的RooEditPart。

file
图3 EditPart对象

用户的编辑操作被转换为一系列请求(Request),有很多种类的请求,这些种类在GEF里被称为角色(Role),GEF里有图形化和非图形化这两大类角色,前者比如Layout Role对应和布局有关的的操作,后者比如Connection Role对应和连接有关的操作等等。角色这个概念是通过编辑策略(EditPolicy)来实现的,EditPolicy的主要功能是根据请求创建相应的命令(Command),而后者会直接操作模型对象。对每一个EditPart,你都可以"安装"一些EditPolicy,用户对这个EditPart的特定操作会被交给已安装的对应EditPolicy处理。这样做的直接好处是可以在不同EditPart之间共享一些重复操作。

在GEF SDK提供的帮助文档(GEF开发指南)里有一份详细的EditPolicy、Role和Request类型列表,这里就不赘述了。

视图:前面说过,GEF的视图可以有很多种,GEF目前提供了图形(GraphicalViewer)和树状(TreeViewer)这两种,前者利用Draw2D图形(IFigure)作为表现方式,多用于编辑区域,后者则多用于实现大纲展示。视图的任务同样繁重,除了模型的显示功能以外,还要提供编辑功能、回显(Feedback)、工具提示(ToolTip)等等。

GEF使用EditPartViewer作为视图,它的作用和JFace中的Viewer十分类似,而EditPart就相当于是它的ContentProvider和LabelProvider,通过setContents()方法来指定。我们经常使用的Editor是一个GraphicalEditorWithPalette(GEF提供的Editor,是EditorPart的子类,具有图形化编辑区域和一个工具条),这个Editor使用GraphicalEditViewer和PaletteViewer这两个视图类,PaletteViewer也是GraphicalEditViewer的子类。开发人员要在configureGraphicalViewer()和initializeGraphicalViewer()这两个方法里对EditPartViewer进行定制,包括指定它的contents和EditPartFactory等等。

EditPartViewer同时也是ISelectionProvider,这样当用户在编辑区域做选择操作时,注册的SelectionChangeListener就可以收到选择事件。EditPartViewer会维护各个EditPart的选中状态,如果没有被选中的EditPart,则缺省选中的是作为contents的EditPart。

初步了解了GEF的MVC实现方式,让我们看看典型的GEF应用程序是什么样子的。大部分GEF应用程序都实现为Eclipse的Editor,也就是说整个编辑区域是放置在一个Editor里的。所以典型的GEF应用程序具有一个图形编辑区域包含在一个Editor(例如GraphicalEditorWithPalette)里,可能有一个大纲视图和一个属性页,一个用于创建EditPart实例的EditPartFactory,一些表示业务的模型对象,与模型对象对应的一些EditPart,每个EditPart对应一个IFigure的子类对象显示给用户,一些EditPolicy对象,以及一些Command对象。

GEF应用程序的工作方式如下: EditPartViewer接受用户的操作,例如节点的选择、新增或删除等等,每个节点都对应一个EditPart对象,这个对象有一组按操作Role分开的EditPolicy,每个EditPolicy会对应一些Command对象,Command最终对模型进行直接修改。用户的操作转换为Request分配给适当的EditPolicy,由后者创建适当的Command来修改模型,这些Command会保留在EditDomain(专门用于维护EditPartViewer、Command等信息的对象,一般每个Editor对应唯一一个该对象)的命令堆栈里,用于实现撤消/重做功能。

以上介绍了GEF中一些比较重要的概念,不知道看过之后你是否对它有了一个大概的印象。如果没有也没关系,因为在后面的帖子里将会有结合例子的讲解,我们使用的实例就是序言里提到的第六个项目。

参考资料

  • GEF开发指南
  • Eclipse Development - Using the Graphical Editing Framework and the Eclipse Modeling Framework

搬家前链接:https://www.cnblogs.com/bjzhanghao/archive/2005/02/13/104045.html

[Eclipse]GEF入门系列(一、Draw2D)

鸡年第一天,首先向大家拜个年——恭祝新春快乐,万事如意。一年之计在于春,你对新的一年有什么安排呢?好的,下面还是进入正题吧。

关于Java2D相信大家都不会陌生,它是基于AWT/Swing的二维图形处理包, JDK附带的示例程序向我们展示了Java2D十分强大的图形处理能力。在Draw2D出现以前,SWT应用程序在这方面一直处于下风,而Draw2D这个SWT世界里的Java2D改变了这种形势。

可能很多人还不十分了解GEF和Draw2D的关系:一些应用程序是只使用Draw2D,看起来却和GEF应用程序具有相似的外观。原因是什么,下面先简单解释一下:

GEF是具有标准MVC(Model-View-Control)结构的图形编辑框架,其中Model由我们自己根据业务来设计,它要能够提供某种模型改变通知的机制,用来把Model的变化告诉Control层;Control层由一些EditPart实现,EditPart是整个GEF的核心部件,关于EditPart的机制和功能将在以后的帖子里介绍;而View层(大多数情况下)就是我们这里要说的Draw2D了,其作用是把Model以图形化的方式表现给使用者。

虽然GEF可以使用任何图形包作为View层,但实际上GEF对Draw2D的依赖是很强的。举例来说:虽然EditPart(org.eclipse.gef.EditPart)接口并不要求引入任何Draw2D的类,但我们最常使用的AbstractGraphicalEditPart类的createFigure()方法就需要返回IFigure类型。由于这个原因,在GEF的SDK中索性包含了Draw2D包就不奇怪了,同样道理,只有先了解Draw2D才可能掌握GEF。

这样,对于一开始提出的问题可以总结如下:Draw2D是基于SWT的图形处理包,它适合用作GEF的View层。如果一个应用仅需要显示图形,只用Draw2D就够了;若该应用的模型要求以图形化的方式被编辑,那么最好使用GEF框架。

现在让我们来看看Draw2D里都有些什么,请看下图。

file
图1 Draw2D的结构

Draw2D通过被称为LightweightSystem(以下简称LWS)的部件与SWT中的某一个Canvas实例相连,这个Canvas在Draw2D应用程序里一般是应用程序的Shell,在GEF应用程序里更多是某个Editor的Control(createPartControl()方法中的参数),在界面上我们虽然看不到LWS的存在,但其他所有能看到的图形都是放在它里面的,这些图形按父子包含关系形成一个树状的层次结构。

LWS是Draw2D的核心部件,它包含三个主要组成部分:RootFigure是LWS中所有图形的根,也就是说其他图形都是直接或间接放在RootFigure里的;EventDispatcher把Canvas上的各种事件分派给RootFigure,这些事件最终会被分派给适当的图形,请注意这个RootFigure和你应用程序中最顶层的IFigure不是同一个对象,前者是看不见的被LWS内部使用的,而后者通常会是一个可见的画布,它是直接放在前者中的;UpdateManager用来重绘图形,当Canvas被要求重绘时,LWS会调用它的performUpdate()方法。

LWS是连接SWT和Draw2D的桥梁,利用它,我们不仅可以轻松创建任意形状的图形(不仅仅限于矩形),同时能够节省系统资源(因为是轻量级组件)。一个典型的纯Draw2D应用程序代码具有类似下面的结构:

//创建SWT的Canvas(Shell是Canvas的子类) 
Shell shell = new Shell(); 
shell.open(); 
shell.setText("A Draw2d application"); 
//创建LightweightSystem,放在shell上 
LightweightSystem lws = new LightweightSystem(shell); 
//创建应用程序中的最顶层图形 
IFigure panel = new Figure(); 
panel.setLayoutManager(new FlowLayout()); 
//把这个图形放置于LightweightSystem的RootFigure里 
lws.setContents(panel);  

//创建应用程序中的其他图形,并放置于应用程序的顶层图形中 
panel.add(); 
while (!shell.isDisposed ()) { 
if (!display.readAndDispatch ()) 
   display.sleep (); 
}

接下来说说图形,Draw2D中的图形全部都实现IFigure(org.eclipse.draw2d.IFigure)接口,这些图形不仅仅是你看到的屏幕上的一块形状而已,除了控制图形的尺寸位置以外,你还可以监听图形上的事件(鼠标事件、图形结构改变等等,来自LWS的EventDispatcher)、设置鼠标指针形状、让图形变透明、聚焦等等,每个图形甚至还拥有自己的Tooltip,十分的灵活。

Draw2D提供了很多缺省图形,最常见的有三类:1、形状(Shape),如矩形、三角形、椭圆形等等;2、控件(Widget),如标签、按钮、滚动条等等;3、层(Layer),它们用来为放置于其中的图形提供缩放、滚动等功能,在3.0版本的GEF中,还新增了GridLayer和GuideLayer用来实现"吸附到网格"功能。在以IFigure为根节点的类树下有相当多的类,不过我个人感觉组织得有些混乱,幸好大部分情况下我们只用到其中常用的那一部分。

file
图2 一个Draw2D应用程序

每个图形都可以拥有一个边框(Border),Draw2D所提供的边框类型有GroupBoxBorder、TitleBarBorder、ImageBorder、ButtonBorder,以及可以组合两种边框的CompoundBorder等等,在Draw2D里还专门有一个Insets类用来表示边框在图形中所占的位置,它包含上下左右四个整型数值。

我们知道,一个图形可以包含很多个子图形,这些被包含的图形在显示的时候必须以某种方式被排列起来,负责这个任务的就是父图形的LayoutManager。同样的,Draw2D已经为我们提供了一系列可以直接使用的LayoutManager,如FlowLayout适合用于表格式的排列,XYLayout适合让用户在画布上用鼠标随意改变图形的位置,等等。如果没有适合我们应用的LayoutManager,可以自己定制。每个LayoutManager都包含某种算法,该算法将考虑与每个子图形关联的Constraint对象,计算得出子图形最终的位置和大小。

图形化应用程序的一个常见任务就是在两个图形之间做连接,想象一下UML类图中的各种连接线,或者程序流程图中表示数据流的线条,它们有着不同的外观,有些连接线还要显示名称,而且最好能不交叉。利用Draw2D中的Router、Anchor和Locator,可以实现多种连接样式,其中Router负责连接线的外观和操作方式,最简单的是设置Router为null(无Router),这样会使用直线连接,其他连接方式包括折线、具有控制点的折线等等(见图3),若想控制连接线不互相交叉也需要在Router中作文章。Anchor控制连接线端点在图形上的位置,即"锚点"的位置,最易于使用的是ChopBoxAnchor,它先假设图形中心为连接点,然后计算这条假想连线与图形边缘的交汇点作为实际的锚点,其他Anchor还有EllipseAnchor、LabelAnchor和XYAnchor等等;最后,Locator的作用是定位图形,例如希望在连接线中点处以一个标签显示此连线的名称/作用,就可以使用MidpointLocator来帮助定位这个标签,其他Locator还有ArrowLocator用于定位可旋转的修饰(Decoration,例如PolygonDecoration)、BendpointerLocator用于定位连接控制点、ConnectionEndpointLocator用于定位连接端点(通过指定uDistance和vDistance属性的值可以设置以端点为原点的坐标)。

file
图3 三种Router的外观

此外,Draw2D在org.eclipse.draw2d.geometry包里提供了几个很方便的类型,如Dimension、Rectangle、Insets、Point和PointList等等,这些类型既在Draw2D内部广泛使用,也可以被开发人员用来简化计算。例如Rectangle表示的是一个矩形区域,它提供getIntersection()方法能够方便的计算该区域与另一矩形区域的重叠区域、getTransposed()方法可以得到长宽值交换后的矩形区域、scale()方法进行矩形的拉伸等等。在自己实现LayoutManager的时候,由于会涉及到比较复杂的几何计算,所以更推荐使用这些类。

以上介绍了Draw2D提供的大部分功能,利用这些我们已经能够画出十分漂亮的图形了。但对大多数实际应用来说这样还远远不够,我们还要能编辑它,并把对图形的修改反映到模型里去。为了漂亮的完成这个艰巨任务,GEF绝对是不二之选。从下一次开始,我们将正式进入GEF的世界。

参考资料

搬家前链接:https://www.cnblogs.com/bjzhanghao/archive/2005/02/09/103595.html

[Eclipse]GEF入门系列(序)

file

前些天换了新电脑,本人一直处于兴奋中,基本是"不务正业"的状态。快过年了,虽然没什么动力干活,但我玩游戏技术比较差,魔兽3打电脑一家还很费劲,干脆写写帖子就当是休息吧!

由于工作的需要,最近开始研究GEF(Graphical Editor Framework)这个框架,它可以用来给用户提供图形化编辑模型的功能,从而提升用户体验,典型的应用如图形化的流程设计器、UML类图编辑器等等。其实一年多来我们做的项目都是和它有关的,只是之前我具体负责的事情和它没什么关系。那时也看过黄老大写的代码,EMF和GEF混在一起特别晕,没能坚持看下去。这次自己要动手做了,正好趁此机会把它搞明白,感觉GEF做出来的东西给人很专业的感觉,功能也很强大,应该挺有前途的。此外,GEF里用到了很多经典模式,最突出的如大量应用Command模式,方便的实现Undo/Redo功能等等,通过学习GEF,等于演练了这些模式,比只是看看书写几个类那种学习方式的效果好很多。

现在网上关于GEF的文章和教程还不是很多(比起一年前还是增加了几篇),基本上都是eclipse.org上的那些,其中少数几篇有中文版,中文的原创就属于凤毛麟角了,市场上似乎也没有这方面的成书。GEF SDK里自带的文档则比较抽象,不适合入门。我觉得最好的入门方法是结合具体的例子,一边看代码,一边对照文档,然后自己再动手做一做。当然这个例子要简单点才好,像GEF的那个logic的例子就太复杂了,即使是flow(运行界面见下图)我觉得也有点大;另外例子要比较规范的,否则学成错误的路子以后还要花时间改就不值得了。

file

图 用GEF编写的流程编辑器

GEF的结构决定了GEF应用程序的复杂性,即使最最简单的GEF程序也包含五六个包和十几个类,刚开始接触时有点晕是很正常的。我找到一个还不错的例子,当然它很简单了,如果你现在就想自己试试GEF,可以点这里下载一个zip包(若已无法下载请用这个链接),展开后是六个项目(pt1,pt2,…,pt6),每一个是在前面一个的基础上增加一些功能得到的,pt1是最简单的一个,这样你就可以看到那些典型的功能(例如DirectEdit、Palette等等)在GEF里应该怎样实现了。关于这个例子的更多信息请看作者blog上的说明

“Back in March, I talked a little about my initial attempts writing an Eclipse Graphical Editor Framework (GEF) application. I wanted, then, to write a tutorial that essentially walked the reader through the various stages of the development of my first application. I even suggested some kind of versioned literate programming approach to writing the tutorial and the code at the same time.

I haven't had time since then to make any progress, but I did get the GEF application to the stage where I had put together a snapshot at each of six milestones. A few people have written to me over the last six months asking the status of my tutorial and I've sent them my six snapshots as a starting point.

It makes sense for me to just to offer them here.

You can download a ZIP file with the six snapshots at http://jtauber.com/2004/gef/gef.zip.

Hopefully they are still useful, even without a surrounding tutorial.”

需要注意一点,这个例子应该是在Eclipse 2.1里写的,所以如果你想在Eclipse 3里运行这个例子,要修改plugin.xml里的dependencies为:

<import plugin="org.eclipse.core.resources"/> 
<import plugin="org.eclipse.gef"/>
<import plugin="org.eclipse.ui"/> 
<import plugin="org.eclipse.core.runtime"/> 
<import plugin="org.eclipse.core.runtime.compatibility"/> 
<import plugin="org.eclipse.ui.views"/> 

再修改一下DiagramCreationWizard这个类finish()方法里page.openEditor(newFile);这句改为page.openEditor(new FileEditorInput(newFile),"com.jtauber.river.editor");,还有一些warning不太影响,可以不用管。

或者如果你不是特别着急的话,留意我这个半新手写的GEF入门系列帖子,说不定能引起你更多的共鸣,也是一个办法吧。

GEF的学习周期是比较长的,学之前应该有这个心理准备。特别是如果你没有开发过Eclipse插件,那么最好先花时间熟悉一下Eclipse的插件体系结构,这方面的文章还是很多的,也不是很难,基本上会开发简单的Editor就可以了,因为GEF应用程序一般都是在Editor里进行图形编辑的。另外,绝大多数GEF应用程序都是基于Draw2D的,可以说GEF离不开Draw2D,而后者有些概念很难搞明白,加上其文档比GEF更少,所以我会从Draw2D开始说起,当然不能讲得很深入,因为我自己也是略知皮毛而已。

说实话,我对写这个系列不太有信心,因为自己也是刚入门而已。但要是等到几个月后再写,很多心得怕是讲不出来了。所以还是那句话,有什么写错的请指正,并且欢迎交流。

搬家前链接:https://www.cnblogs.com/bjzhanghao/archive/2005/02/05/102513.html

给表格的单元格增加编辑功能(In place edit)

使用纯粹的SWT可以实现在单元格中编辑(In place edit)的功能,代码见这个例子,这里要说的是利用jface完成差不多的工作:用户单击单元格,出现一个下拉菜单,用户通过选择来改变单元格所代表的该行对象的属性。

对org.eclipse.jface.viewers.TableViewer.TableViewer的介绍这里就不赘述了,一般我们都是像下面这样定义TableViewer的:

TableViewer viewer = new TableViewer(...); 
viewer.getTable().setHeaderVisible(true); 
viewer.setContentProvider(...); 
viewer.setLabelProvider(...); 
//Add table columns 
TableColumn column = new TableColumn(viewer.getTable(), SWT.NONE); 
column.setText("..."); 

要增加编辑功能,首先得定义一个org.eclipse.jface.viewers.CellEditor数组,对应TableViewer的每一列,在我们这个例子里,第二列(Column 1)需要用下拉框编辑,所以可以这样定义这个CellEditor数组。

final CellEditor[] editors = new CellEditor[tvOre.getTable().getColumnCount()]; 
editors[1] = new ComboBoxCellEditor(viewer.getTable(), new String[] {}, SWT.READ_ONLY); 
viewer.setCellEditors(editors);
viewer.setColumnProperties(columnNames); 

再定义这个TableViewer的CellModifier(org.eclipse.jface.viewers.ICellModifier),该接口定义了三个方法,canModify()指出该单元格是否可被编辑;getValue()应返回单元格的当前值,因为我们使用的是下拉框,所以要返回一个Integer表示当前选中的index;modify()方法中我们将用户修改的值反映到实际模型中。代码如下,注意代码里IOre是我们模型的一部分,表格中每一行是一个IOre对象,IOre.getOrderParams()得到的就是下拉框中的选项,每行的选项与那一行代表的IOre对象有关:

viewer.setCellModifier(new ICellModifier() { 
    public boolean canModify(Object element, String property) { 
        IOre ore = (IOre) element; 
        String[] items = new String[ore.getOrderParams().size()]; 
        for (int i = 0; i < ore.getOrderParams().size(); i++) { 
            NameValuePair pair = (NameValuePair) ore.getOrderParams().get(i); 
            items[i] = pair.getValue(); 
        } 
        editors[1] = new ComboBoxCellEditor(viewer.getTable(), items, SWT.READ_ONLY); 
        return property.equals(columnNames[1]); 
    } 

    public Object getValue(Object element, String property) { 
        if (property.equals(columnNames[1])) { 
            IOre ore = (IOre) element; 
            for (int i = 0; i < ore.getOrderParams().size(); i++) { 
                NameValuePair pair = (NameValuePair) ore.getOrderParams().get(i); 
                if (pair.getValue().equals(ore.getOrderParamValue())) 
                    return new Integer(i); 
            } 
            return new Integer(0); 
        } 
        return null; 
    } 

    public void modify(Object element, String property, Object value) { 
        TableItem item = (TableItem) element; 
        IOre ore = (IOre) item.getData(); 
        NameValuePair pair = (NameValuePair) ore.getOrderParams().get(((Integer) value).intValue()); 
        ore.setOrderParamValue(pair.getValue()); 
        viewer.refresh(); 
    } 
}); 

接下来……哦,原来已经大功告成了,真是太容易了!不相信吗,请看下面的运行结果。

file

搬家前链接:https://www.cnblogs.com/bjzhanghao/archive/2005/01/25/97336.html

给Eclipse插件的View加上菜单和工具条

Eclipse的每个视图(View)都有自己的菜单和工具条,View通过与自己相关的IViewSite对象与这些东西打交道,确切的说,是通过这个IViewSite对象的IActionBars对象来管理,ActionBars对象负责菜单、工具条和状态栏。

file

一个典型的View(继承org.eclipse.ui.part.ViewPart)的代码结构会是这样,作为例子,假设我们有三个功能项:Open、Remove和Reload,我们的View是一个简单的表格TableViewer,里面显示一些条目列表,允许用户进行多选:

TableViewer tvResult;
OpenAction openAction;
RemoveAction removeAction;
ReloadAction reloadAction;
public void createPartControl(Composite parent) {
    //创建视图界面

    //创建菜单
    createActions();
    createMenu();
    createContextMenu();
    createToolbar();
    hookGlobalActions();
}

其中,createActions()是创建必要的IAction对象,这些对象可用在菜单、工具条里;createMenu()的作用是把刚刚创建的IAction对象放进与View相关的MenuManager里,就像前面所说,MenuManager可以通过getViewSite().getActionBars().getMenuManager()方法得到;createToolbar()则是把同样的对象放在工具条里,获得工具条的方法与菜单类似;createContextMenu()则是建立鼠标右键触发的上下文菜单,方法是建立一个新的MenuManager,然后由它建立一个Menu对象,再将Menu对象与控件联系;hookGlobalActions()的作用是把IAction对象与系统菜单(而不是View菜单联系),达到同一菜单项对不同View具有不同响应的效果。下面来看一下具体代码:

package net.sf.solo.actions;

import java.io.IOException;
import java.util.Iterator;
import net.sf.solo.model.IInstance;
import org.eclipse.jface.action.Action;
import org.eclipse.jface.viewers.ISelectionChangedListener;
import org.eclipse.jface.viewers.IStructuredSelection;
import org.eclipse.jface.viewers.SelectionChangedEvent;

public class OpenAction extends Action implements ISelectionChangedListener {

    IStructuredSelection selection;

    public OpenAction() {
        setEnabled(false);
    }

    public void run() {
        for (Iterator iter = selection.iterator(); iter.hasNext();) {
            IInstance ins = (IInstance) iter.next();
            try {
                //TODO Only in windows can do this.
                Runtime.getRuntime().exec("cmd /E:ON /c start " + ins.getReferenceURL());
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }

    public void selectionChanged(SelectionChangedEvent event) {
        selection = (IStructuredSelection) event.getSelection();
        setEnabled(selection.size() > 0);
    }

    public String getText() {
        return "&Open in browser";
    }
}

上面是一个例子IAction,它的作用是在触发时将用户选中的条目在浏览器里打开。这个类同时还实现了ISelectionChangeAction,这样就可以在用户没有选中任何条目的时候将自己变为不可用。当然,你要把它作为监听器加入某个列表对象的监听器列表,像下面代码里这样:

private void createActions() {
    openAction = new OpenAction();
    removeAction = new RemoveAction(tvResult);
    reloadAction = new ReloadAction(tvResult);
    tvResult.addSelectionChangedListener(openAction);
    tvResult.addSelectionChangedListener(removeAction);
    tvResult.addSelectionChangedListener(reloadAction);
}

注意,最后的三句就是加入监听列表的功能。有些IAction需要改变所监听对象(比如一个TableViewer)的行为,所以要把那个对象作为参数传递给它才行。下面是把IAction对象加入菜单的代码:

private void createMenu() {
    IMenuManager mgr = getViewSite().getActionBars().getMenuManager();
    mgr.add(openAction);
    mgr.add(removeAction);
    mgr.add(reloadAction);
}

把IAction对象加到工具条的代码几乎完全一样,只是第一句有所不同:

private void createMenu() {
    IToolBarManager mgr = getViewSite().getActionBars().getToolBarManager();
    mgr.add(openAction);
    mgr.add(removeAction);
    mgr.add(reloadAction);
}

上下文菜单就显得有些麻烦了,因为View并没有一个“PopupMenuManager”这样的东西,所以我们只能半手动的来建立:

private void createContextMenu() {
    MenuManager mgr = new MenuManager();
    mgr.setRemoveAllWhenShown(true);
    mgr.addMenuListener(new IMenuListener() {
        public void menuAboutToShow(IMenuManager manager) {
            fillContextMenu(manager);
        }
    });
    Menu menu = mgr.createContextMenu(tvResult.getControl());
    tvResult.getControl().setMenu(menu);
    getSite().registerContextMenu(mgr, tvResult);
}

这个MenuManager和我们在createMenu()里通过getMenuManager()得到的是同一个类(但不是同一个实例哦),setRemoveAllWhenShown(true)的作用是清空以前显示的菜单项,当触发了menu事件时,重新填充(fillContextMenu),所以如果你不把removeAllWhenShow置为true的话,每点一下右键你就会看到菜单项多出一倍来。Menu是swt的控件(刚才说的MenuManager、ToolbarManager都是jface里的东西,jface给swt包了一层),用MenuManager可以创建出一个Menu对象,然后我们用表格的setMenu方法将表格控件与Menu控件联系在一起就好了。

最后还有一句,它是为扩展这个上下文菜单用的,例如你可以在plugin.xml里统一指定给某种类型的元素都加上某个菜单项(例如,如果用户选中了一个.zip文件,会多出一个“解压缩”选项)。那么新加的菜单项会出现在上下文菜单的哪里呢,最上方还是最下方,还是……?所以呢,要在fillContextMenu的时候指定一下:

protected void fillContextMenu(IMenuManager manager) {
    manager.add(openAction);
    manager.add(removeAction);
    manager.add(reloadAction);
    manager.add(new GroupMarker(IWorkbenchActionConstants.MB_ADDITIONS));

}

前三句都没什么特别,最后一句就是指定了上面我们说的这个“增加点”,这样,你想让后来的菜单放在哪里都行了。

最后,Eclipse的Workbench提供了一些比较通用的系统菜单项,如下:

public static final String [] GLOBAL_ACTIONS = {
        UNDO,
        REDO,
        CUT,
        COPY,
        PASTE,
        PRINT,
     DELETE,
        FIND,
     SELECT_ALL,
        BOOKMARK
};

当你的焦点在不同的View或Editor里时,同一个系统菜单项会有不同的作用产生。例如在文本编辑器中delete项是删除当前选中的文字,而在你的视图里,你希望delete的作用是删除用户选中的表格条目,刚好是removeAction的功能。所以你要把你的IAction对象和系统菜单挂在一起:

private void hookGlobalActions() {
      IActionBars bars = getViewSite().getActionBars();
      bars.setGlobalActionHandler(IWorkbenchActionConstants.DELETE, removeAction);
}

注意,要选择语义上比较相近的系统菜单项来挂接,否则会造成用户的困扰。比如你非要把COPY实现为openAction,当用户在系统菜单里选了copy命令,本以为会把当前选中的条目复制到剪贴板,你却给人家打开了这些条目,多滑稽。

好了,菜单方面基本上就这些内容。可以看出,Eclipse的Workbench的确为我们提供了很多方便,特别是如果能够灵活利用plugin来进行定义,不仅可以节约大量的代码,还能让我们始终保持对系统的掌握。所以说,RCP的风行可不是没有道理哦。

搬家前链接:https://www.cnblogs.com/bjzhanghao/archive/2005/01/14/92122.html

[Eclipse]PreferencePage的小问题花了大把时间

在Eclipse里可以用FieldEditorPreferencePage简化Preference page的创建,但在随机文档里只重点说了要实现createFieldEditors方法,我明明实现了它,但点Preference命令时却总是提示:

java.lang.InstantiationException: org.haree.mobject.ui.BasicPreferencePage
    at java.lang.Class.newInstance0(Unknown Source)
    at java.lang.Class.newInstance(Unknown Source)
    at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:141)
    at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:124)
    at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:113)
    at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:189)
    at org.eclipse.ui.internal.dialogs.WorkbenchPreferenceNode.createPage(WorkbenchPreferenceNode.java:60)
    at org.eclipse.jface.preference.PreferenceDialog.showPage(PreferenceDialog.java:985)
    at org.eclipse.jface.preference.PreferenceDialog$8.selectionChanged(PreferenceDialog.java:529)
    at org.eclipse.jface.viewers.StructuredViewer$3.run(StructuredViewer.java:450)
    at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:616)
    at org.eclipse.core.runtime.Platform.run(Platform.java:747)
    at org.eclipse.jface.viewers.StructuredViewer.firePostSelectionChanged(StructuredViewer.java:448)
    at org.eclipse.jface.viewers.StructuredViewer.setSelection(StructuredViewer.java:1094)
    at org.eclipse.jface.preference.PreferenceDialog.selectSavedItem(PreferenceDialog.java:807)
    at org.eclipse.jface.preference.PreferenceDialog$3.run(PreferenceDialog.java:309)
    at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69)
    at org.eclipse.jface.preference.PreferenceDialog.createContents(PreferenceDialog.java:305)
    at org.eclipse.jface.window.Window.create(Window.java:348)
    at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:925)
    at org.eclipse.ui.internal.OpenPreferencesAction.run(OpenPreferencesAction.java:70)
    at org.eclipse.jface.action.Action.runWithEvent(Action.java:881)
    at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:915)
    at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:866)
    at org.eclipse.jface.action.ActionContributionItem$7.handleEvent(ActionContributionItem.java:785)
    at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:796)
    at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:2772)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2431)

找了一个多小时,才发现原来是要提供一个没有参数的构造方法才可以。想了一下,可能因为Eclipse最终是使用Class.newInstance()的方式来生成界面元素的,所以有这个要求。

算是一个经验吧,我觉得Eclipse的帮助再丰富些就好了,特别是应该提供更多的例子代码。

顺便推荐下面两篇文章(要是Eclipse帮助都这么详细该多好):

Mutatis mutandis - Using Preference Pages as Property Pages

Simplifying Preference Pages with Field Editors

搬家前链接:https://www.cnblogs.com/bjzhanghao/archive/2005/01/11/90073.html