이 플러그인은 15유로를 주고 구입해야 합니다. 저는 그나마 환율이 상식적이였던 시기에 구입했습니다. 꾸준히 업데이트 되고 있어 믿을만 하고, Help > Software Updates에서 손쉽게 설치 및 업데이트를 할 수 있습니다.
Mac OSX 환경에서 Eclipse에 이 플러그인을 설치해보니 CommandMode 창에 글씨가 보이지 않아서, 홈페이지에 어줍잖은 영어 실력으로 문제를 호소했더니, 몇일 후에 패치가 올라왔습니다! 사용자를 위한 세심한 배려에 감동했죠.
오랜기간 사용해 본 소감을 말씀드리면 부족함을 느끼지 못할 정도로 vi가 제공하는 대부분의 기능을 사용할 수 있습니다. 최근에는 Eclipse + CDT + viPlugin을 사용하여 파싱 기반의 정확한 assist를 받으면서 vi의 기능을 활용하여 작업을 수행하고 있습니다.
org.eclipse.ui.views 확장점을 사용합니다. 해당 View를 포함할 카테고리를 지정하고 View를 표현하는 아이콘을 정의합니다. 이제 LogView.java 코드를 보겠습니다. 그렇게 길지 않으니 전체 코드를 늘어놓고 글을 이어나가도록 하지요.
public class LogView extends ViewPart { private Table table; private TableColumn[] columns; private final String[] TABLE_COLUMN_NAMES = { "Message", "Location", "Time" }; private final int[] TABLE_COLUMN_WIDTH = { 400, 400, 150 }; public LogView() { super(); } public void createPartControl(Composite parent) { table = new Table(parent, SWT.BORDER | SWT.V_SCROLL); columns = new TableColumn[TABLE_COLUMN_NAMES.length]; for(int i=0, n=TABLE_COLUMN_NAMES.length; i < n; i++) { columns[i] = new TableColumn(table, SWT.NONE); columns[i].setText(TABLE_COLUMN_NAMES[i]); columns[i].setWidth(TABLE_COLUMN_WIDTH[i]); } table.setHeaderVisible(true); table.setLinesVisible(true); } public void setLog(String message, String location) { Date date = new Date(); SimpleDateFormat dateFormat = new SimpleDateFormat("hh:mm:ss"); String dateString = dateFormat.format(date); TableItem ti = new TableItem(table, SWT.NONE); ti.setText(0, message); ti.setText(1, location); ti.setText(2, dateString); for (int i = 0; i < columns.length; i++) { columns[i].pack(); } } public void clearLog() { table.clearAll(); } public void setFocus() { table.setFocus(); } }
View를 구현한 클래스는 ViewPart 클래스를 상속합니다. 예제의 Log View 처럼 단순히 정보를 보여주는 View를 구현하는 경우에는 createPartControl() 메서드에서 보여주고 싶은 위짓을 정의하는 것으로 간단히 View를 구성할 수 있습니다. View에 Action을 추가한다던가 워크벤치의 다른 View 혹은 Editor와 상호작용하도록 하려면 조금 더 복잡해지겠지요.
여기서 한가지 명확히 해야할 것은 JFace viewer의 위상입니다. JFace viewer는 모델-뷰 구조를 기반으로 사용자가 쉽게 유려한 viewer를 만들 수 있도록 돕기 위해 제작된 일종의 UI 프레임워크입니다. 따라서 JFace viewer를 제작할 때 모델의 데이터를 뷰에 전달하는 Contents Provider, Label Provider 등을 구현해야 하는 것이죠. 중요한 것은(!) JFace viewer는 이클립스에서 UI를 표현할 수 있는 어떤 곳에도 붙일 수 있다는 것 입니다. 마법사의 한 페이지에 붙일 수도 있고 Editor에 붙일 수도 있죠. 이 글에서 말하는 Viewer가 아닌 View는 이클립스 워크벤치의 일부로서 화면에 정보를 나타내기 위한 부분이라고 생각할 수 있습니다. 구현하기에 따라서는 ViewPart를 상속하여 Editor의 역할을 수행하도록 만들 수도 있습니다.
본론으로 돌아와서 createPartControl() 메서드에서 SWT의 table 컨트롤을 추가하고 초기화 합니다. View에 정보를 제공하고자 하는 다른 클래스에서는 clearLog(), setLog() 메서드를 이용해서 View에 포함된 table 위짓에 값을 추가 및 삭제하게 됩니다. LogView의 인스턴스는 id를 이용해서 다음과 같이 얻을 수 있습니다.
public void init(IWorkbenchWindowwindow) { this.window = window; }
Multi-page Editor는 여러페이지를 가진 에디터로, VICODE에서 spec.xml을 편집하는 Specifiaction Editor를 다음과 같이 총 4페이지로 구성된 형태의 에디터로 작성하였습니다. 이 글에서는 에디터 자체에 대한 내용보다는 여러페이지로 구성된 에디터를 작성하는 경우에 구현방법과 고려해야할 사항들에 대해서 소개하겠습니다.
0123
Specification Editor에서 편집할 spec.xml 파일은 총 3가지 section으로 구성되어 있습니다. 에디터의 처음 3페이지는 각 section의 편집과정을 돕기 위해 컨트롤로 구성된 폼 에디터를 제공하며 마지막 페이지는 spec.xml을 직접 편집할 수 있도록 XML 에디터를 포함하고 있습니다.
구현 디테일로 들어가기 이전에 Multi-page Editor를 구현할 때 고려해야 할 사항에 대해서 설명하겠습니다. Multi-page Editor는 하나의 EditorInput을 여러 페이지에서 편집하게 되므로 편집하는 내용이 겹치는 경우에는 서로 다른 페이지 간의 값을 동기화 처리를 해주어야 합니다. 이 글에서 설명하는 페이지간의 동기화 방법은 직접 고안한 것이므로 효율적이지 않을 수 있습니다. ^^;
VICODE의 Specification Editor의 경우에 EditorInput은 spec.xml 입니다. 처음 3페이지의 폼 에디터와 마지막 페이지의 spec.xml 페이지는 편집의 범위가 겹치게 됩니다. 게다가 spec.xml을 구성하는 3가지 section 사이에서도 서로 값이 의존적으로 사용되기 때문에 각 페이지에서 변경된 값은 항상 다른 페이지에도 적용되어야 합니다. VICODE의 경우 다음과 같이 3가지 객체의 값이 동기화된 상태로 유지되어야 합니다.
spec.xml - AST - 각 페이지의 컨트롤이 가지는 값
AST는 spec.xml을 파싱해서 얻게 되는 Abstract Syntax Tree를 의미합니다. 에디터가 실행되면 spec.xml을 파싱해서 AST에 저장하게 되고 각 페이지의 컨트롤의 값은 AST의 값을 바탕으로 채워지게 됩니다. 이 것은 제가 말한 동기화의 아주 일부분이죠. 상세내용은 뒤에서 다루기로 하고 일단 코드를 보도록 하겠습니다.
우선 Editor의 확장점은 org.eclipse.ui.editors 입니다. Multi-page editor의 확장은 다른 editor의 확장방법과 다르지 않습니다. 다음은 확장을 정의한 plugin.xml의 일부입니다.
filenames 속성을 통해 spec.xml 파일에만 적용되도록 정의하였습니다. 이제 에디터를 구현한 SpecEditor 클래스를 살펴보겠습니다.
public class SpecEditor extends MultiPageEditorPart implements IResourceChangeListener { private final String endl = "\n"; private TextEditor editor; private String specFilePath; private int currentPageIndex = 0; private int editorPageIndex; private CommunicationPage communicationPage; private ApiPage apiPage; private RulePage rulePage; private Spec spec;
MultiPageEditorPart를 상속하여 구현합니다. 멤버변수로 눈여겨 보아야 할 것은 각 페이지를 참조할 수 있는 인스턴스와 AST를 저장하는 spec 입니다. ApiPage 등은 Composite을 상속한 클래스로 페이지를 구성하는 컨트롤을 정의하고 있습니다. editor는 마지막 페이지를 구성하는 XML 에디터의 레퍼런스 입니다. 이제 각 페이지를 어떻게 에디터에 추가하는지 살펴보겠습니다.
createPages() 메서드에 페이지를 추가하는 코드를 작성해 주어야 합니다. 여기서 불리는 createRulePage()를 살펴보면 addPage() 메서드를 이용해서 에디터에 페이지를 추가하는 것을 확인할 수 있습니다. XML 에디터를 추가하는 createXmlEditorPage() 메서드에서는 addPage() 메서드의 두번째 인자에 Multi-page Editor의 EditorInput(spec.xml)을 넘겨줍니다.
Multi-page Editor에서 save가 발생한 경우 호출되는 doSave() 메서드를 작성해야 합니다.
public void doSave(IProgressMonitor monitor) { if (currentPageIndex == editorPageIndex) { getEditor(editorPageIndex).doSave(monitor); // save Xml2Spec parser = new Xml2Spec(specFilePath); spec = parser.parseSpec(); // parsing to get AST communicationPage.setSpec(spec); // set AST to each page apiPage.setSpec(spec); rulePage.setSpec(spec); } }
Specification Editor에서 첫 3페이지는 저장 명령이 유효하지 않고 Apply 버튼을 클릭함으로써 수정내용을 AST와 파일에 적용하도록 구성되어 있습니다. Reply 버튼을 클릭하면 AST의 내용으로 컨트롤의 값을 복구 합니다. 반면에 4번째 페이지인 XML 에디터 페이지를 선택한 경우에 저장하게 되면 XML 에디터의 doSave() 메서드를 호출하여 spec.xml에 저장하게 됩니다. 저장이 완료되면 spec.xml의 내용이 갱신되었기 때문에 이를 다시 파싱하여 새로운 AST를 얻고 각 페이지에 setSpec() 메서드를 이용해 AST를 갱신해줍니다. 각 페이지는 이 AST를 이용해 컨트롤에 값을 설정하겠죠.
다음으로는 페이지가 변경되었을 때 호출되는 pageChange() 메서드를 볼까요?
protected void pageChange(int newPageIndex) { switch (newPageIndex) { case 0: communicationPage.updatePage(); // AST to control break; case 1: apiPage.updatePage(); break; case 2: rulePage.updatePage(); break; case 3: updateSpecFile(); // AST to spec.xml break; default: } currentPageIndex = newPageIndex; // save current page index }
처음 3페이지가 선택된 경우에는 AST의 내용을 바탕으로 컨트롤의 값을 채워주는 함수인 updatePage() 메서드를 호출합니다. 4페이지가 선택된 경우에는 AST의 내용을 spec.xml에 저장합니다. 따라서 XML 에디터는 최근 변경된 spec.xml의 코드를 출력하게 됩니다.
흐름을 다시 정리해보면, 에디터가 열리면서 spec.xml을 파싱하여 AST를 저장합니다. 처음 3페이지가 선택된 경우에는 AST의 내용을 가지고 페이지를 구성하는 컨트롤의 값을 채웁니다. 이 컨트롤의 값을 수정한 후 Apply 버튼을 누르게 되면 AST를 갱신함과 동시에 spec.xml 파일을 AST를 가지고 저장합니다. 반대로 XML 에디터에서 수정하고 저장한 경우에는 저장된 spec.xml 파일을 다시 파싱하여 AST를 구하고 이 것을 각 페이지에 넘겨줍니다.
이해를 돕기 위해 아래에 SpecEditor.java, RulePage.java 파일을 예제로 남깁니다.
이 글에서는 SWT와 JFace가 대략 무엇인지, 그리고 이클립스에서 차지하는 위상은 어떤 것인지에 대해서 개괄적으로 이야기하겠습니다. JFace는 일종의 프레임워크이다 보니 공부를 상당히해야 코딩이 가능하지만, SWT를 이용한 코딩은 AWT/Swing으로 UI를 작성해 보신 분이라면 쉽게 적응하실 수 있으리라 생각됩니다. 구조에 큰 차이가 없습니다.
SWT는 Standard Widget Toolkit의 약자로 이클립스에서 UI를 표현하는데 사용되는 API 입니다. SWT가 나오기전에는 AWT와 Swing을 사용했습니만, 써보신 분은 아시겠지만 UI가 어설프고 예쁘지가 않습니다. SWT의 특징은 현재 사용중인 OS에 어울리는 미려한 UI를 제공한다는 것입니다. JNI를 이용해 호스트 운영체제가 제공하는 사용자 인터페이스를 불러서 사용하기 때문이죠. 이클립스를 윈도우, 리눅스에서 각각 실행해보면 SWT와 Swing의 차이를 확인할 수 있습니다. Swing을 사용한 어플리케이션은 윈도우에서나 리눅스에서나 적당히 비슷하면서도 적당히 어설픈 UI를 보여줍니다.
이클립스 플러그인을 제작할 때, SWT는 빈번히 사용됩니다. 마법사의 각 페이지나 Preference 페이지를 작성할 때 등등 세부 사용자 인터페이스를 정의할 때 SWT 코딩을 해야 합니다. 이클립스에서 UI를 제공하는 클래스는 다음과 같이 createContents() 메서드를 오버라이딩 함으로써 유저 인터페이스를 정의합니다. 이때 사용되는 것이 SWT 입니다.
protected Control createContents(Composite parent) { // TODO Auto-generated method stub initializeDialogUnits(parent); // Get composite and set layout manager Composite composite = new Composite(parent, SWT.NONE); GridLayout layout = new GridLayout(); layout.marginHeight = convertVerticalDLUsToPixels (IDialogConstants.VERTICAL_MARGIN); layout.marginWidth = 0; layout.verticalSpacing = convertVerticalDLUsToPixels(10); layout.horizontalSpacing = convertHorizontalDLUsToPixels (IDialogConstants.HORIZONTAL_SPACING); composite.setLayout(layout);
AWT/Swing과 다른 몇가지 SWT의 특징을 언급하고 JFace로 넘어가겠습니다. 우선 Widget간의 부모/자식 관계를 맺는 방법에서 차이가 있습니다. AWT/Swing에서는 다음과 같은 방법으로 부모 인스턴스에 자식 인스턴스를 추가합니다. 패널에 버튼을 추가하는 것을 예로 들 수 있겠습니다.
부모_인스턴스.add(자식_인스턴스);
반면에 SWT에서는 자식 인스턴스를 생성할 때 부모의 인스턴스를 첫번째 인자로 넘겨줍니다. 예제코드에서 Composite을 추가하는 부분을 참조하세요. 그리고 두번째 인자로 스타일 비츠(style bits)라는 것을 정의합니다. SWT.NONE, SWT.PUSH, SWT.CHECK 등이 스타일 비츠에 해당합니다. 이 상수들을 |로 묶어 Widget의 속성을 결정합니다. 물론 각 Widget마다 유효한 스타일 비츠가 정해져 있습니다. 마지막으로 언급할 것은 SWT가 실제 운영체제의 리소스를 사용하기 때문에 더 이상 쓰지 않을 때 해제해야 한다는 점 입니다. 대부분의 SWT Widget은 앞서 살펴본 것 처럼 생성자에서 부모를 지정하기 때문에, 부모를 폐기하면 자식도 폐기된다는 규칙에 의해서 문제가 되지 않습니다. 하지만 부모의 Widget 없이 생성된 SWT 오브젝트인 Font, Image, Color 등등은 사용하지 않을 때 직접 폐기해야 합니다.
JFace는 SWT를 보완하기 위해, 모델 기반 접근 방법(model-based approach)을 기반으로 더 적은 시간에, 더 이해하기 쉬운, 재사용 가능한 코드를 작성할 수 있도록 설계되었습니다. JFace는 UI를 효과적으로 작성하기 위한 일종의 프레임워크라고 할 수 있습니다. JFace 뷰어를 예로 들자면, JFace 뷰어가 제공하는 클래스를 상속해 정해진 절차를 따라서(!) '뚝딱뚝딱' UI를 코딩하면 '짠!' 하고 그럴듯한 하이퀄리티(?)의 UI를 화면에서 확인할 수 있는 것 입니다. JFace는 모델-뷰 구조로 구성되어있기 때문에, 이미 어플리케이션에서 사용하던 모델을 자연스럽게 사용할 수 있습니다. 물론 모델과 뷰사이의 연결을 담당하는 코드를 작성해야 하겠지만요. (e.g. ContentProvider , LabelProvider) JFace는 UI의 얼개에 해당하므로 SWT 역시 함께 사용해야 합니다.
아주 오랜만에 이클립스 플러그인에 관한 글을 다시 적게 되었습니다. 연구실에 남아있을 마지막 2주일 동안 그 동안 못다뤘던 부분들을 정리하려 합니다. 오늘은 마법사에 대해서 다루겠습니다. 마법사(Wizard)가 무엇인지는 각종 개발툴을 써보셨다면 이미 잘 알고계실 것 같습니다. VICODE 사용자 메뉴얼을 존대말로 쓰다보니 탄력받아(?) 존대말로 쓰게 되었네요.
마법사는 여러 페이지로 구성되어 있습니다. 각 페이지는 프로젝트를 생성하는 등의 작업을 위한 일련의 단계를 표현합니다. 그리고 각 페이지는 자신에게 필요한 정보가 입력되었는지를 판단하여 마법사에게 알립니다. 마법사는 페이지의 상태에 따라 다음 페이지로의 이동가능 여부를 판단하여 UI에 반영하는 것이죠. 모든 페이지가 완료 상태에 도달하면 Finish 버튼이 활성화 되어 마법사를 종료할 수 있습니다. Finish 버튼이 클릭되면 마법사는 각 페이지에서 받은 정보를 바탕으로 원하는 작업을 수행하게 됩니다.
코드레벨에서 살펴보면 마법사는 마법사 클래스와 각 페이지에 해당하는 클래스의 집합으로 구성됩니다. 마법사 클래스는 페이지 클래스를 참조하고 있고 addpages() 함수에서 페이지 클래스를 마법사에 등록합니다.
지금부터는 코드를 가지고 상세구현 과정을 살펴보도록 하겠습니다. 이클립스 플러그인의 시작은 확장점입니다. 마법사를 추가할 수 있는 확장점은 총 3가지가 있는데, 이 글에서는 프로젝트 생성 마법사를 추가하는데 사용되는 org.eclipse.ui.newWizards를 사용하겠습니다. 다음코드는 확장을 정의한 plugin.xml 코드의 일부분입니다.
마법사 확장점에는 여러가지 속성이 있습니다. Perspective 관련 속성에는 VICODE perspective의 id를 정의하였습니다. canFinishEarly는 모든 페이지를 다 거치지 않아도 완료할 수 있는 마법사인지를 정의합니다. hasPages는 여러 페이지를 가진 마법사인지를 정의합니다. 예제로 보여드릴 VICODE 프로젝트 생성 마법사는 2페이지로 구성되어 있고 모든 페이지를 거쳐야 하므로 위의 코드와 같이 정의하였습니다.
먼저 마법사 클래스(NewProjectWizard)를 살펴보도록 하겠습니다.
public class NewProjectWizard extends Wizard implements INewWizard { private WizardNewProjectCreationPage mainPage; private WizardInitialPage initialPage; private IProject newProject;
public boolean performFinish() { createNewProject(); initialPage.finish(newProject); return true; }
public void addPages() { mainPage = new WizardNewProjectCreationPage("New VICODE Project (1/2)"); mainPage.setDescription("Create a new VICODE project in the workspace"); mainPage.setTitle("Create VICODE Project"); initialPage = new WizardInitialPage("New VICODE Project (2/2)"); initialPage.setDescription("You can specify top module name and communication event."); initialPage.setTitle("Module declaration for hardware and Communication Event"); addPage(mainPage); addPage(initialPage); }
프로젝트 마법사 클래스는 Wizard 클래스와 INewWizard 인터페이스를 상속합니다. 예제 마법사의 목표는 두 페이지에 걸쳐 정보를 받아 들인 후 프로젝트를 생성하는 것 입니다. 총 2페이지로 구성되어 있는데, 첫번째 페이지는 구현하지 않고 이미 작성된 프로젝트 생성 페이지를 가져다가 사용하였습니다. 이 페이지는 단순히 프로젝트 이름과 저장위치를 지정할 수 있도록 구성되어 있습니다. 두 번째 페이지는 VICODE 프로젝트를 생성하는데 있어 필요한 정보를 입력받기 위해 직접 구현한 페이지입니다.
addPages() 메서드에서는 각 페이지의 인스턴스를 생성하고 초기화한 후에 addPage() 메서드를 호출하여 마법사에 각 페이지를 등록합니다. Finish 버튼이 클릭되면 호출되는 performFinish() 메서드에서 마법사 완료시에 필요한 일들을 기술합니다. 실제 프로젝트가 생성되는 코드는 첨부파일을 참조하시기 바랍니다.
01
지금부터는 두번째 페이지에 해당하는 코드를 살펴 보겠습니다.
public class WizardInitialPage extends WizardPage { public void createControl(Composite parent) { Composite composite = new Composite(parent, SWT.NONE); GridLayout gridLayout = new GridLayout(); gridLayout.numColumns = 1; composite.setLayout(gridLayout); createModuleNameGroup(composite); createCommunicationGroup(composite); setControl(composite);
updatePageComplete(); setMessage(null); setErrorMessage(null); } private void updatePageComplete() { setPageComplete(false); // 페이지의 완결성 체크 if (moduleNameText.getText().equals("")) return; // 페이지의 완결성 체크를 건너 뛰었다면 페이지를 완료상태로 변경 setPageComplete(true); setMessage(null); setErrorMessage(null); }
마법사의 모든 페이지 클래스는 WizardPage 클래스를 상속합니다. UI를 정의하는 다른 클래스와 마찬가지로 createControll() 메서드에서 SWT로 사용자 인터페이스를 작성합니다. 마지막에 호출되는 메서드인 updatePageComplete()는 페이지에 필요한 정보가 입력되어 있는지를 판단하기 위해 제가 작성한 메서드 입니다. 이 메서드는 각 컨트롤에서 값이 변경될때마다 호출되어 페이지가 완료상태인지를 setPageComplete() 메서드를 호출하여 마법사에 알립니다.
이상으로 이클립스 플랫폼에서 마법사를 구현하는 방법에 대해서 말씀드렸습니다. 아래 첨부한 소스코드를 참조하시면 이해하시는데 도움이 될 것 같습니다.
이클립스 워크벤치에서 perspective라고 하는 것은 툴바와 메뉴에 위치하게될 action들의 사용여부와 view의 초기 레이아웃을 정의하는 역할을 담당한다. 아래의 그림의 우측상단에 VICODE라고 선택되어 있는 부분이 바로 perspective를 의미한다.
이클립스에 기본적으로 제공되는 perspective가 몇가지 있다. Java를 선택하면 자바 어플리케이션을 개발하는데 필요한 action이 메뉴와 툴바에 나타날 것이고, Debug를 선택하면 디버깅을 위한 view들이 화면에 배치되는 것을 확인할 수 있다.
따라서 특정 목적(VICODE의 경우 임베디드 시스템 개발)을 가지는 개발환경을 이클립스에서 구현한다면, 이에 해당하는 action들만을 메뉴나 툴바에 나타내고 특정 정보를 화면에 보여주기 위한 view를 원하는 레이아웃에 따라 배치하고 싶을 것이다.
VICODE perspective를 선택했을 때를 살펴보면, Project 메뉴 아래에 필자가 여기저기서 주워와서 갔다 붙인 조악한 툴바 아이콘을 볼 수 있고 화면의 하단에는 따로 만들어서 추가한 Log, Result view가 존재하는 것을 알 수 있다. 이와 같이 perspective는 플러그인이 제공하는 특정 개발 환경을 정의하는 역할을 한다.
개념의 대한 설명은 여기서 마치고 구현방법을 소개하자면, 다음과 같이 org.eclipse.ui.perspectives 확장점을 이용한다.
package edu.kaist.vicode.perspective;import org.eclipse.ui.IFolderLayout; import org.eclipse.ui.IPageLayout; import org.eclipse.ui.IPerspectiveFactory; public class PerspectiveFactory implements IPerspectiveFactory { public static final String ID_VICODE_ACTIONS = "edu.kaist.vicode.actionset"; public static final String ID_VICODE_PROJECT_WIZARD = "edu.kaist.vicode.projectwizard"; public static final String ID_VICODE_MODULE_WIZARD = "edu.kaist.vicode.modulewizard"; public static final String ID_VICODE_LOG_VIEW = "edu.kaist.vicode.logview"; public static final String ID_VICODE_RESULT_VIEW = "edu.kaist.vicode.resultview";
위의 VICODE perspective가 선택된 화면과 소스코드를 비교해보면 이해하기가 수월 할 것이다. createInitialLayout() 메서드에서 넘어온 IPageLayout 인스턴스를 이용하여 레이아웃을 지정할 수 있다. 차례로 왼쪽의 Navigator를 추가하고 하단에 3개의 view를 추가한다. 그리고 우측의 Outline view를 정의한 후 추후에 다루게 될 마법사를 추가한다. 마지막으로 action에서 다루었던 action set을 추가한다. action set의 visible 속성이 false로 지정되었다면 이렇게 perspective에서 추가해주어야만 화면에 나타나게된다. 모든 것의 참조는 plugin.xml에서 정의한 ID로 이루어진다.
물론 이미 존재하는 perspective에 자신의 view나 action을 추가할 수 있는데 (JDT를 확장하는 경우) 이럴 때는 org.eclipse.ui.perspectiveExtensions 확장점을 이용해야 한다.
Plug-in Development Environment(이하 PDE)는 그 자신이 플러그인이면서 플러그인을 개발하는 환경을 제공한다. 우리가 일반적으로 다운받는 Eclipse SDK에 기본적으로 포함되어 있다. 이는 플러그인 개발의 편의를 도모하기 위해 플러그인의 정보를 담고 있는 plugin.xml을 효과적으로 편집할 수 있는 플러그인 설명서 편집기와 개발 중인 플러그인를 실행하고 디버깅할 수 있는 환경을 제공한다.
위의 그림은 여러 페이지로 구성되어 있는 플러그인 설명서 편집기이며 plugin.xml 파일을 쉽게 편집할 수 있도록 도와주는 역할을 한다. 이클립스 3.0에서 개발을 시작하였고 현재는 3.2 버전을 사용하고 있는데 플러그인의 구조가 적잖이 변경되었다. 이전에는 대부분의 정보가 plugin.xml에 저장되었던 것에 반하여 3.2 버전에서는 일부정보가 MANIFEST.MF 파일에 저장된다. 따라서 3.2 버전에서의 plugin.xml은 확장점과 확장에 관한 내용만 담고 있다.
각각의 페이지에 대해서 간략히 설명하자면,
Overview - 플러그인의 ID, 이름, 버전, 제작자등의 정보 Dependencies - 플러그인이 의존하고 있는 다른 플러그인의 집합 Runtime - 런타임에 client에게 export할 package의 집합 Extenstion - 확장정의 Extension Points - 확장점정의 Build - 빌드할때 포함해야할 파일등 플러그인 빌드 관련 설정 MANIFEST.MF - MANIFEST.MF 파일 텍스트 편집기 plugin.xml - plugin.xml 파일 텍스트 편집기 build.properties - build.properties 파일 텍스트 편집기
정리하자면,
Overview, Dependencies, Runtime 페이지를 수정하면 MANIFEST.MF 파일이, Extenstion, Extenstion Points 페이지를 수정하면 plugin.xml 파일이, Build 페이지를 수정하면 build.properties 파일이 수정된다. 텍스트 편집기에서 파일을 직접 수정한 내용도 각 페이지의 폼에 바로 적용되어 상호보완적으로 편집할 수 있다.
플러그인의 실행을 이해하기 위해서는 host 워크벤치와 runtime 워크벤치의 개념을 이해해야한다. 먼저 host 워크벤치는 현재 PDE를 이용해 플러그인을 개발하고 있는 워크벤치를 의미한다. host 워크벤치에서 개발 중인 플러그인의 Run을 구성해 실행시키면 쉽게 말해서 이클립스가 하나 더 뜬다! 이 것이 바로 runtime 워크벤치다.
위의 그림에서는 PDE에서 vicode 플러그인의 Run을 구성하고 있다. 여기서 Plug-ins 탭으로 들어가보면 host 워크벤치와 runtime 워크벤치의 개념을 이해할 수 있다. 여기서 선택된 것은 runtime 워크벤치를 실행할 때 포함하는 플러그인을 의미한다. 다시 말하면 runtime 워크벤치는 host 워크벤치에 포함된 플러그인에 더하여 현재 개발 중인 플러그인을 추가한 워크벤치를 의미한다. (물론 개발하는 플러그인과 의존관계가 없는 플러그인은 제외하고 수행해도 무방하다)
개념을 잡는 것에 도움을 드리기 위해 씌여지고 있는 글이기 때문에 실제 PDE를 사용하는 예제를 수행해보고 싶으신 분은 이클립스 메뉴의 Help > Help Contents를 클릭하시고 나오는 메뉴얼에서 Platform Plug-in Developer Guide > Simple plug-in example을 참조하시기 바랍니다.
플러그인이란 무엇인가? 이클립스에 어떤 기능을 제공하기 위한 것들의 집합이다. 기능을 제공하기 위해서 필요한 것에는 무엇이 있는가? 예를 들어 선택된 파일을 리눅스 콘솔에서 실행하는 기능을 제공한다고 가정하자. 이 때 필요한 것은 이클립스의 어떤 부분(확장점)을 통해 이 기능을 제공할 것인지에 대한 정보(파일을 선택하고 오른쪽 버튼을 눌렀을 때 나오는 팝업메뉴에서? 혹은 파일을 선택하고 툴바의 버튼을 눌러서?)와 이 기능의 이름이 화면에 어떻게 표시 될 것인지, 툴바에 버튼이 추가 된다면 icon 파일은 무엇을 사용할 것인지 등의 정보가 필요할 것 이다. 가장 중요한 것은 메뉴선택이나 툴바버튼이 눌렸을 때 수행되는 일이 무엇인지를 정의하는 것이다.
정리하자면, 이클립스에 기능을 제공하기 위한 플러그인이 가져야 할 정보는 텍스트 데이터와 자바 코드로 나누어 볼 수 있다. 우리는 이 사실로 부터 플러그인의 구조를 유추할 수 있다. 하나의 플러그인 프로젝트는 텍스트 데이터를 담고 있는 plugin.xml 파일과 자바소스코드들로 구성되어 있다. 다음의 다이어그램을 보고 좀 더 상세히 살펴보자.
왼쪽은 이클립스 워크벤치에 해당하는, 즉 이클립스 플랫폼에 기본적으로 포함되어 동작하는 플러그인이며 오른쪽은 우리가 개발하고 있는 플러그인 이라고 하자. 왼쪽의 플러그인은 다른 플러그인이 자신의 기능을 확장할 것을 고려하여 확장점(extenstion-point)를 plugin.xml에 정의하고 있다. 오른쪽의 플러그인은 이 확장점(popupMenus)을 이용하여 확장(extension)하고 있다. 쉽게 이야기 하면 왼쪽의 플러그인은 다른 플러그를 꽂을 수 있는 콘센트를 제공하고, 오른쪽 플러그인은 그 콘센트에 꽂을 수 있는 플러그가 되는 것이다!
확장을 할 때 필요한 정적인 정보는 오른쪽 플러그인의 plugin.xml 파일의 extenstion태그 아래 기술 될 것이며 팝업메뉴가 클릭되었을 때의 동작은 MyObjectAction 클래스에 정의한다. 확장점을 열어주는 입장(Workbench plug-in)에서는 확장하는 방법을 제공해주어야 한다. 즉 확장하는 플러그인(MyAction plug-in)에서 아무렇게나 MyObjectAction 클래스를 정의한다면 제대로 확장이 이루어질 수 없다. 확장점을 열어주는 플러그인에서는 IOjbectActionDelegate 인터페이스를 제공함으로써 확장하는 클래스가 이를 구현하여 자신에게 필요한 코드를 정의하도록 유도한다.
확장점을 열어준 플러그인은 자신을 확장한 플러그인에 대해서 처리해야할 책임을 갖는다. 현재 자신이 제작하고 있는 플러그인에서도 확장점을 얼마든지 정의할 수 있고 이를 다른 사람 혹은 자신이 제작하는 또 다른 플러그인에서 확장이 가능하다. 필자의 경우에는 다른 플러그인이 VICODE를 확장할 가능성을 염두해 두지 않았기 때문에 이클립스 워크벤치가 제공하는 기본 확장점을 이용하고 따로 확장점을 정의해본 경험이 없다.
위의 예제는 실제 VICODE에서 확장자가 *.console인 파일을 선택하고 오른쪽 버튼을 눌렀을 때 나타나는 팝업메뉴에서 리눅스 console 프로그램을 수행하는 기능을 제공하기 위한 것이다. 자세한 내용은 나중에 팝업메뉴 확장하기에 대한 글에서 다루도록 하고 여기서는 확장점과 확장의 관점에서 살펴본다.
이 플러그인은 org.eclipse.ui.popupMenus 라는 확장점에 확장하고 있다. 이 확장점이 필요로 하는 정보가 obejctContribution 태그 아래로 정의되어 있는 것을 볼 수 있다. 정적인 정보는 이렇게 plugin.xml에 정의되고 behavior에 해당하는 내용은 확장점이 기대하는 behavior를 정의한 IOjbectActionDelegate 인터페이스를 구현한 RunConsoleProgramAction 클래스에 정의된다.
이클립스 플랫폼이 구동될 때 플러그인의 정적인 정보를 담고 있는 plugin.xml 파일을 읽어 확장점과 확장의 관계를 고려하여 화면의 UI를 구성한다. 그리고 효율성을 위해 자바 클래스는 그 것이 필요한 시점, 즉 action이라면 메뉴가 클릭되었을 때 객체가 생성되어 수행된다.
이클립스(Eclipse)는 많은 사람들에게 흔히 꽤나 훌륭한 자바개발환경으로 널리 알려져있다. 그러나 이클립스를 자바개발환경으로만 생각한다면 이클립스의 잠재력을 무시하는 일! 다음 이클립스 Help에 있는 이클립스의 정의를 읽어보자.
Eclipse is a platform that has been designed from the ground up for building integrated web and application development tooling. By design, the platform does not provide a great deal of end user functionality by itself. The value of the platform is what it encourages: rapid development of integrated features based on a plug-in model.
여기서 중요한 것은 이클립스 그 자체로 사용자에게 기능을 제공하는 것이 아니며 기능적인 요소는 플러그인으로 제공된다는 사실! 애초에 이클립스는 plug-in model을 기반으로 하는 개방성을 목표로 개발되었다. 다음 다이어그램을 참조하면 이 사실은 더욱 명확해진다.
이클립스 플랫폼 자체는 자바 개발환경(JDT)와 플러그인 개발환경(PDE)를 포함하지 않는다. 다시 말하면 자바 개발환경 조차도 이클립스 플랫폼에 확장되는 플러그인 중에 하나 일 뿐이다. 다만 우리가 일반적으로 이클립스를 다운받을 때 Eclipse SDK의 형태로 가져오기 때문에 이클립스가 마치 자바개발환경인 것 처럼 보일 뿐이다. eclipse가 설치된 디렉토리 밑에 plugins 디렉토리를 열어보면 org.eclipse.jdt.* 형태의 이름을 가지는 파일과 디렉토리를 통해 JDT가 플러그인임을 확인할 수 있다. 필자가 개발하고 있는 VICODE는 오른쪽의 New Tool 중에 하나에 해당할 것 이다.
이미 매우 다양한 플러그인들이 개발되어 있다. 여기를 방문하면 다운받아 사용해볼 수 있다. 이클립스에서 데이타베이스 스키마 디자인을 하거나 UML 다이어그램을 그리는 작업등이 이클립스 플랫폼에 플러그인을 추가함으로써 가능해진다.
Platform Runtime은 이클립스 플랫폼의 핵심으로 앞서 이야기한 plug-in model을 책임지는 역할을 한다. 이클립스가 시작될때 현재 플랫폼에 어떤 플러그인이 기여되어있는지를 확인하고 그 정보를 바탕으로 현재의 이클립스 플랫폼을 구성한다. 플러그인이 어떤 방법으로 이클립스 플랫폼에 확장(Extension)되는지는 "확장점과 확장"이라는 제목의 글에서 다룰 예정이다.
현재 저는 연구실 프로젝트 겸 석사학위를 위하여 Verification Integrated CODesign Environment(이하 VICODE)라고 하는 하드웨어/소프트웨어 동시설계 개발환경을 이클립스 플러그인 형태로 개발하고 있습니다. 블로그에서 제가 쓰고자 하는 글은 이클립스 플랫폼을 기반으로 하는 통합개발환경(IDE)를 구축하는 방법에 관한 것 입니다. 따라서 동시설계에 관련된 내용이나 이 툴이 제공하는 기능의 상세 대해서는 생략하겠습니다만, 간략히 하드웨어와 소프트웨어가 모두 존재하는 시스템을 설계하는 도구정도로 생각할 수 있습니다.
올해 초 swing으로 작성하던 어플리케이션을 갑자기 이클립스 기반으로 다시 개발해야 했을 때, 많이 난감했던 기억이 납니다. 이클립스 플러그인 개발에 대한 국내서적은 거의 없었고 번역서 조차도 찾기 어려웠습니다. 물론 몇몇 분들이 쓰신 이클립스 강좌가 있었지만 IDE를 개발하기에는 부족했습니다. 다행히 "자바 개발자를 위한 이클립스 바이블"이라는 책이 출판되었고 이 책을 차근차근 공부하면서 이클립스와 친해질 수 있었지만 책의 구성 탓인지 번역 탓인지 모르겠지만 잘 읽히지가 않아서 인내를 배워야 했습니다.
다른 일에 집중하다가 오랜만에 다시 제가 개발한 플러그인을 뜯어 보았을 때, 잊은 부분이 적지 않았고 제가 개발한 플러그인을 이어서 개발할 후임자를 위해서도 정리가 필요하다고 생각되었습니다. 또한 제가 정리한 글들이 이클립스 플러그인 개발을 처음으로 접하는 분들의 삽질을 조금이라도 줄여드릴 수 있다면 큰 보람이 될 것 입니다.
다른 사람을 가르치면서 배우는 것이 많다는 이야기가 있듯이 그동안 공부한 지식들을 정리 및 공개하여 많은 분들의 피드백을 받으며 제가 공부한 지식을 더욱 굳건히 하고자 하는 욕심도 있습니다. 틀린 부분이나 보충할 부분이 있으면 가감없이 덧글로 남겨주시면 큰 도움이 될 것 같습니다. 질문도 주저없이 덧글로 남겨주시면 제가 모르는 것은 공부해서라도 답변할 수 있도록 노력할 것 입니다.
블로그에서 제가 다룰 것으로 예상되는 부분은 다음과 같습니다. 개발을 진행하면서 틈틈히 쓰는 글이라 예정된 순서가 없고 중간에 필요하다고 생각되는 부분은 추가될 수도 있습니다. 제가 아는 바를 모두 정리한 후 적었던 글들을 체계적으로 정리할 생각입니다.
제가 쓰는 글들이 강좌라고 할 것 까지는 없지만, 인터넷의 강좌나 마소의 기사를 보면 반말(?)을 사용하는 경우가 많아서 저도 글쓰기의 편의를 위해서 반말로 글을 작성하고자 합니다. 플러그인 개발에 대한 글들은 제가 다음의 책들을 공부한 결과를 기반으로 하고 있기에 참조하시면 도움이 될 것 같습니다.
자바 개발자를 위한 이클립스 바이블 Official eclipse 3.0 FAQs The Definitive Guide to SWT and JFace
Eclipse 플러그인 개발에서 action이라고 하는 것을 간단히 정의하자면 메뉴나 툴바의 아이콘을 클릭하였을 때 수행되는 어떤 일이라고 이야기 할 수 있다. IDE에서 소스를 편집하는 editor 혹은 무언가 정보를 보여주는 viewer를 제외하면 대부분의 기능이 바로 action의 형태로 기여된다고 할 수 있다.
action에 대해서 공부하기 이전에 알아야 할 것이 있는데 action set 이라고 하는 녀석이다. 이는 menu와 action으로 구성되어 있는 action을 정의하기 위한 논리적인 집합이라고 생각하면 되는데 일단 다음의 plugin.xml의 일부를 읽어보자.
action에 대한 기여는 action 기여를 위한 확장점(extenstion point)이 있어서 여기에 바로 기여(extenstion)하는 것이 아니라 그 것을 둘러싼 action set에 해당하는 확장점(org.eclipse.ui.actionSets)에 기여 함으로써 이루어진다.
menu는 action의 분류를 제공한다. 아래에 정의되어 있는 각 action들이 UI에 나타나려면 적어도 하나 이상의 menu를 지정해야한다. 위의 플러그인을 수행하면 "Interface"와 "Verification"이라는 최상위 메뉴가 (실제로 그 메뉴에 기여하는 action이 존재하는 경우) 메뉴바에 나타난다. menu의 정의는 메뉴바뿐만 아니라 툴바의 분류가 되기도 하며 어떻게 사용되는지는 action 태그의 menubarPath와 toolbarPath에 달려있다.
메뉴는 하나 이상의 separator를 가진다. 쉽게 설명하자면 인터넷 익스플로러에 파일 메뉴를 클릭하면 4가지 그룹의 메뉴가 나타나는 것을 볼 수 있으며 이는 4개의 separator를 하나의 menu 태그에서 정의하는 것으로 구현될 수 있다. 그리고 각각의 action은 그들이 속해야 하는 menubarPath = "menu의 id/separator의 name" 형태로 자신이 UI의 어디에 나타나야 하는지를 지정할 수 있다. 툴바에 기여하는 경우에는 separator를 지정할 필요가 없다.
여기서 action set의 중요한 속성을 하나 살펴보자. Eclipse 플랫폼은 다수의 플러그인을 포함하여 동작하고 있다. 모든 플러그인이 제공하는 action과 menu가 UI에 모두 나타난다고 상상해보면 어떨까?
나중에 perspective에 대한 글에서 자세히 설명하겠지만, 이와 같은 문제를 해결하기 위해서 플러그인이 제공하는 환경과 기능을 관리할 수 있는 perspective라는 개념을 도입하였다. Eclipse 플랫폼에 기본적으로 포함되어 있는 perspective에는 Java, Debug, Resource등이 있다. Java라는 perspective를 선택하면 자바프로그램을 편집하는데 필요한 에디터와 뷰어 그리고 툴바의 아이콘등이 나타나는 것을 알 수 있다. Java와 Resource perspective를 변경하면서 툴바를 살펴보면 그 차이를 알 수 있을 것이다.
action set에서 visible 속성을 이용하여 action set에 포함되는 menu와 action들이 perspective와 상관없이 무조건 UI에 나타날 것인지 아닌지를 true, false로 지정할 수 있다. 다시 말하면 이 값이 true인 경우 항상 action set에 포함되는 것들이 UI에 표현되고, false인 경우에는 특정 perspective에 action set을 포함시켜 그 perspective로 전환되었을 때만 UI에 표현하게 한다. 자세한 내용은 perspective에 대한 글에서 다룰 생각이다.
지금까지는 action set의 구조와 메뉴(menubarPath)와 툴바(toolbarPath)에 각 action이 어떻게 추가될 수 있는지를 살펴보았다. 지금부터는 action 자체에 대해서 살펴보자. action에서 지정되는 클래스는 IWorkbenchWindowActionDelegate 인터페이스를 상속해야 한다.
public class SimulationInterfaceGenAction implements IWorkbenchWindowActionDelegate { private IStructuredSelection selection;
public void dispose() {
// TODO Auto-generated method stub
}
public void init(IWorkbenchWindow window) {
// TODO Auto-generated method stub
}
public void run(IAction action) {
// TODO Auto-generated method stub
IProject project = (IProject) selection.getFirstElement();
...
...
...
} public void selectionChanged(IAction action, ISelection selection) {
// TODO Auto-generated method stub if (selection instanceof IStructuredSelection) {
this.selection = (IStructuredSelection) selection;
} }
}
action을 구현한 클래스는 위와 같은 구조를 가지게 된다. 툴바의 아이콘이나 메뉴를 클릭하면 해당 action의 run() 메서드가 호출되어 특정 작업이 수행된다. 여기서 추가로 알아야 할 것은 특정 action은 특정 selection과 관계를 맺을 수 있다는 것! 즉 action을 수행하는 대상이 무엇인지 알아야 한다. 예를 들어 JDT에서 메서드의 이름을 바꾸는 리펙토링 액션을 수행한다고 한다면 분명 선택한 메서드가 있을 것이다. 이러한 선택을 selection이라고 하며 selectionChanged() 메서드에서 이 selection을 얻어올 수 있다. 이렇게 얻어온 selection을 통해 특정 영역에 해당하는 action을 수행하게 된다.
action은 selection의 형태에 따라 enable/disable 될 수 있다. 이를테면 어떤 action은 프로젝트(IProject)만을 선택으로 받아들일 수 있고, 어떤 action은 디렉토리(IFolder)에 대해서만 작업을 수행할 수 있다. 이는 plugin.xml에서 selection 태그로 지정할 수 있다. 심지어 name 속성을 이용하면 특정 파일명에 대해서만 action을 제한할 수 있다.
Preference는 IDE에서 흔히 볼 수 있는 환경설정을 의미한다. 우리가 어떤 특정 플러그인을 개발할 때, 그 플러그인에 특화된 환경설정이 필요한 경우가 있다. 예를 들어 설명하자면, 이전에 소개한 바 있지만 Esterel 언어는 소프트웨어 언어인 C로도 컴파일이 되고 하드웨어 언어인 Verilog로도 컴파일이 가능하다.
Preferences in Eclipse
Esterel 언어를 위한 개발환경에서 위와 같은 환경설정이 존재한다면 각 항목의 체크유무에 따라 소스코드의 컴파일시에 생성되는 아웃풋 파일의 종류를 결정할 수 있다. 이와 같은 작업을 위해서 알아야 할 확장점(Extension Point)에는 두가지가 있으며 이를 포함한 plugin.xml의 일부분의 내용은 다음과 같다.
첫번째 확장점인 org.eclipse.ui.preferencePages을 이용해 Preference page에 기여할 수 있으며, 두번째 확장점인 org.eclipse.core.runtime.preferences에서는 환경설정의 기본값을 지정할 수 있다.
우선 첫번째 확장점을 위한 클래스인 VicodePreferencePage를 살펴보자. 이 클래스는 PreferencePage를 상속하며 UI를 만드는 createContents() 메서드, Restore Defaults 버튼을 눌렀을 때 호출되는 performDefaults(), OK 버튼을 눌렀을 때 호출되는 performOk() 메서드등으로 구성되어 있다. 메서드 이름만으로 각 메서드의 역할을 알 수 있을 것이다.
다음 생성자(Constructor)와 performOk() 메서드를 통해서 환경설정을 어떻게 이용하는지 알아보자.
public VicodePreferencePage() {
super(); setPreferenceStore(Activator.getDefault().getPreferenceStore()); setDescription("Development environment settings for VICODE");
fCheckBoxes = new ArrayList<Button>();
}
public boolean performOk() { IPreferenceStore store = getPreferenceStore();
for (int i = 0; i < fCheckBoxes.size(); i++) {
Button button = (Button) fCheckBoxes.get(i);
String key = (String) button.getData(); store.setValue(key, button.getSelection()); }
return super.performOk();
}
생성자에서는 setPreferenceStore() 메서드를 호출하여 preference page에서 사용할 preference 저장소를 지정한다. performOk() 메서드에서는 preference 저장소를 얻어와 여기에 setValue() 메서드를 이용해 <key, value>의쌍으로 환경설정을 저장한다. 저장할 수 있는 값들은 boolean, double, float, int, String, long 등의 simple data type중에 하나이어야 한다. 위의 예제는 플러그인이 UI에 기여하는 경우(Activator 클래스가 AbstractUIPlugin를 상속하는 경우)에 해당하며 그렇지 않은 경우(Plugin 클래스를 상속하는 경우)에는 getPluginPreferences 메서드를 사용해야 한다.
정리하면 생성자에서 preference 저장소를 지정한 후, createContents() 메서드에서 preference page에 들어가는 UI를 작성한다. 그리고 각 버튼에 해당하는 코드를 작성한다. 이는 UI에 입력된 정보를 환경설정에 저장하거나 그 반대의 일이 될 것이다.
지금부터는 환경설정의 기본값(Default)를 지정하기 위한 클래스인 Defaults를 살펴보자. 여기서는 간단히 initializeDefaultPreferences() 메서드에서 setDefault() 메서드를 호출해서 각 key에 해당하는 기본값을 지정하기만 하면 된다.
public void initializeDefaultPreferences() {
// TODO Auto-generated method stub
// get preference store IPreferenceStore store = Activator.getDefault().getPreferenceStore(); store.setDefault("CDE_ESTEREL_C", true);
store.setDefault("CDE_ESTEREL_VERILOG", true);
store.setDefault("CDE_ESTEREL_BLIF", false); }
지금까지 Eclipse plug-in 개발시에 preference를 활용하는 방법을 살펴보았다. 아래 첨부한 소스코드를 읽어보면 쉽게 이해할 수 있을 것이다. 예제코드에서 UI 부분은 JDT의 JavaBasePreferencePage 클래스의 것을 응용하였다.
Draw2D는 GEF에 내장되어 있기도 하지만 standalone으로 사용될 수 있는 그래픽 라이브러리다. GEF에서 그림을 그릴 때 내부적으로 이 라이브러리를 사용한다. Display a UML Diagram using Draw2D 문서를 읽고 금방 그 사용법을 익힐 수 있을 정도로 잘 구성되어 있다. 여러 Figure를 조합해서 하나의 component를 구성하고 그 component 사이에 connection을 정의할 수 있도록 되어있다. 물론 그림 처럼 connection에 해당하는 외관을 변경한다던지 레이블을 추가하는 등의 작업이 가능하다. Eclipse 혹은 SWT 기반의 어플리케이션에서 유용하게 사용할 수 있을 것 같다.
The Graphical Editing Framework (GEF) allows developers to create a rich graphical editor from an existing application model. GEF consists of 2 plug-ins. The org.eclipse.draw2d plug-in provides a layout and rendering toolkit for displaying graphics. The developer can then take advantage of the many common operations provided in GEF and/or extend them for the specific domain. GEF employs an MVC (model-view-controller) architecture which enables simple changes to be applied to the model from the view.
GEF는 이름 그대로, Graphical Editor의 구현을 도와주는 프레임워크라고 할 수 있다. 무에서 Graphical Editor를 구현한다고 상상해본다면 어떨까? 유사한 경험을 가지고 있지 않다면 대체 어디서 어떻게 시작해야할지 도무지 감을 잡을 수 없을 것이다.
항상 어떤 프레임워크나 플랫폼을 활용할 때는 딜레마를 느끼게 된다. 잘 짜여진 프레임워크를 활용하면 내가 한 일에 비해서 보기좋은(?) 아웃풋을 얻을 수 있다는 장점이 있는 반면에 얼마나 자유도를 가지고 시스템을 개발할 수 있는지에 대해서 의구심을 떨쳐버릴 수가 없고 충분히 활용하기까지 공부를 많이 해야한다는 단점이 있다.
분명한건 이런 프레임워크나 플랫폼은 나보다 똑똑한 여러명이 심사숙고해서 만들어 놓은 뼈대이며, 자유도를 고려한 디자인을 가지고 있다보니 본의 아니게(?) 복잡해질 수 밖에 없다. 따라서 이를 활용하기 위해서 적잖이 공부해야한다.
연구실에서 개발하는 Verification Integrated CODesign Environemnt (VICODE)에서 임베디드 시스템을 설계 할때 전체 시스템의 논리적인 디자인을 다이어그램 에디터에서 이루어지게 하려고 한다. 분명 xml 코드를 직접 쓰는 것보다는 훨씬 낫겠다는 기대와 함께 ...
이들은 모두 MVC (Model-View-Controller) Architecture를 기반으로 한다. EMF는 Eclipse에서 사용할 Model의 클래스 구조를 자동생성해주는 녀석 쯤으로 보이고 GEF는 특정 Model을 편집할 수 있는 그래픽 편집기를 생성하는 프레임워크라고 볼 수 있다. 여기서 EMF로 생성된 Model이 GEF의 Model의 조건을 만족하기 때문에 EMF+GEF 조합의 솔루션이 소개되었다. 그리고 이를 돕기 위해 GMF 프로젝트가 전개되고 있다.
나는 GEF만을 사용하여 다이어그램 에디터를 구현하고자 한다. 여전히 복잡하고 어려워보이지만 "복잡한 문제는 단순한 문제의 합" 이라고 믿고 그냥 가보는거다! GEF를 공부하고 그 틀대로 구현을 하게 되면 아래와 같이 보기 좋은 그래픽 에디터가 생성된다.
invalid-file
