스윙(Swing)

Development/Java 2012. 1. 30. 18:36
Swing

스윙(Swing)은 자바에서 GUI(Graphic User Interface)를 구현하기 위해 JDK에서 기본적으로 제공하는 개발 툴킷으로 선 마이크로시스템즈의 자바 기반 클래스의 일부이다.

스윙은 기존에 발표되었던 AWT(Abstract Window Toolkit)가 OS(Operating System) 및 윈도 시스템의 자원을 그대로 제공하기 때문에 자바에서 지향하는 "Write Once, Run Everywhere(WORE)"를 구현하기 위해 각종 시스템에서 공통적으로 제공하는 버튼대화창 등만을 구현하고 나 트리 등의 좀 더 복잡하고 다양한 그래픽 컴포넌트를 사용할 수 없는 단점을 보완하기 위하여 JDK 1.2 버전부터 사용되었다.

목차

  [숨기기

[편집]역사

AWT의 제약을 극복하기 위하여 만들어졌다. JDK 1.1 버전때부터 별도의 라이브러리로 개발되다가 JDK 1.2 버전부터 정식으로 JDK에 포함되었다.

[편집]특징

운영 환경에 영향을 받지 않고 동일한 화면을 보여줄 수 있도록 시스템에 대한 의존도를 최소화하고 각종 컴포넌트들을 자바에서 직접 그려서 구현을 하였다. 따라서 여러 환경에서 동일한 모습을 보일 수 있도록 구현되었으나 대신 해당 시스템의 고유한 모습을 보여줄 수 없다. 이러한 약점을 보완하기 위하여 룩 앤드 필(Look And Feel)이라는 기능을 지원하는데 이 기능을 이용하여 프로그램 전체의 UI 모습을 바꿀 수 있다. 이클립스가 대표적인 자바 통합 개발 환경(IDE, Integrated Development Environment)으로 자리 잡으면서 SWT가 널리 퍼지게 되자 이와 비슷한 그래픽을 보여주는 라이브러리들이 나오기 시작하였다. [1]

직접 컴포넌트를 그리는 방식으로 인하여 하드웨어적인 그래픽 가속장치(Graphic Accelerator)를 사용할 수 없는 경우에는 속도가 많이 저하된다. 이는 스윙이 느리다는 인식을 가져오게 된 계기가 되었으나 추후 JDK가 업그레이드 되면서 차차 개선되었다.

AWTJava2D 등과 함께 자바 기반 클래스(Java Foundation Classes, JFC)를 구성하는 한 요소이다.

스윙의 아키텍처는 플랫폼-독립적인, 자바 모델-뷰-컨트롤러 GUI 프레임워크이다. 스윙은 단일-스레드 프로그래밍 모델을 따른다.

[편집]기타 GUI 툴킷과의 비교

[편집]AWT와의 비교

 이 부분의 본문은 AWT입니다.

AWT는 시스템의 그래픽 컴포넌트를 직접 사용하여 해당 시스템의 모습을 그대로 구현한다. 또한 스레드 보안(Thread Safe)이 되어 있어 스윙과 비교하여 컴포넌트의 업데이트에 문제가 발생하지 않는다. 또한 최소 JDK 1.2, 혹은 성능을 위하여 더 최신의 JVM이 필요한 스윙에 비하여 AWT는 자바에서 지원하는 최초의 그래픽 툴킷으로 버전에 상관없이 모든 JVM에서 사용 가능하다. 마이크로소프트가 썬 마이크로시스템즈와의 자바 사용권에 대한 재판에서 패소함에 따라 신규 JVM을 지원하지 않고 있는데 MS의 기존 JVM에서도 AWT는 사용이 가능하다.(2007년 12월 31일로 만료됨) [2]

그러나 자바 1.2 이후 컴포넌트의 제약에도 불구하고 Java2DJava3D 등의 풍부한 그래픽 환경을 제공한다.

[편집]SWT와의 비교

 이 부분의 본문은 SWT입니다.

스윙에 비교하면 비교적 저수준의 GUI 툴킷으로 많은 경우 고수준의 제어를 위하여 JFace와 함께 사용된다. AWT와 비슷하게 시스템의 컴포넌트를 직접 사용하며 지원하지 않는 경우에만 에뮬레이트한다. 그러나 최신의 대부분 운영 환경에서는 시스템에서 동일한 기능을 제공한다.

시스템 자원을 직접 활용하기에 대개의 경우 스윙에 비하여 속도가 빠르며 해당 운영환경 고유의 모습을 나타낸다. 그러나 시스템 자원 활용을 위하여 JNI(Java Native Interface)를 사용하기 때문에 이식성에 제한이 있다.

[편집]같이 보기


==========================================================================================

Swing 은 프로그래밍 언어 Java 의 그래픽 사용자 인터페이스 (GUI)를 구축하기위한 툴킷. 마찬가지로 Java의 GUI 툴킷이다AWT 를 확장한 것.

AWT는 운영 체제 의 윈도우 시스템에 준한 디자인되는 반면, Swing에서 만든 GUI는 Java 프로그램 에서 렌더링되므로보다 유연한 설계가 가능해진다. AWT 대해 Swing과 같은 구성 요소 를 경량 컴퍼넌트 (Light Weight Component)라고 부른다.

플러그인 가능한 Look & Feel을 가지고 있기 때문에 쉽게 Look & Feel를 전환할 수있다. 또한 AWT에는 없었던 슬라이더와 스피나 트리 표시하는 구성 요소와 같은 고급 구성 요소가 포함되어있다.

목차

  [ 숨기기 ] 

예제 편집 ]

import  javax.swing.JFrame ; 
import  javax.swing.JLabel ;
 
public  class HelloWorld { 
    public  static  void Main ( String [ ] args )  { 
        JFrame Frame =  New  JFrame ( ) ; 
        frame. setDefaultCloseOperation ( JFrame . EXIT_ON_CLOSE ) ; 
        frame. getContentPane ( ) . add ( New  JLabel ( "Hello, world!" ) ) ; 
        frame. pack ( ) ;  
        frame. setLocationRelativeTo ( null ) ; 
        frame. setVisible ( true ) ; 
    } 
}

역사 편집 ]

  • 1998 년에 출시된 J2SE1.2에서 처음 출시되었다.
  • 2002 년에 출시된 J2SE1.4에서 제공되는 Java Web Start를 이용하여 프로그램을 다시 배포 문제를 해결했다.
  • 2004 년에 출시된 JavaSE1.5 메모리 소비 효율의 개선을 갔다.
  • 2006 년에 출시된 JavaSE6는 Java의 실행 성능이 개선됨에 따라 Swing의 실행 성능도 개선되었다.

관련 항목 편집 ]

외부 링크 편집 ]




================================================================================================

 SWT (Standard Widget Toolkit) 

표준 위젯 툴킷(SWT, Standard Widget Toolkit)은 이클립스에서 사용하고 있는 자바기반의 위젯 툴킷(Widget Toolkit)이다. 처음에 이 툴킷은 IBM이 개발되었으나 지금은 이클립스를 개발하는 이클립스 재단(Eclipse Foundation)이 유지 보수하고 있다. 이 툴킷은 이클립스 공중 사용 허가서(Eclipse Public License)에 따라 배포되고 있다.

목차

  [숨기기

[편집]자바 GUI 툴킷의 역사

썬 마이크로시스템즈(Sun Microsystems)에서 1995년 자바 개발 키트(JDK, Java Development Kit) 1.0을 내놓았을 당시 존재한 추상 윈도 툴킷(AWT, Abstract Window Toolkit)은 최초의 자바 GUI용 툴킷이었다. 최초의 AWT는 OS의 메뉴나 버튼 등을 자바로 포장한 형태의 간단한 그래픽 툴킷이었다. 해당 운영 체제의 윈도 시스템을 그대로 이용하므로 윈도 시스템별로 특징적인 형태를 그대로 구현할 수 있으나 자바의 OS 비의존성을 지키기 위하여 각 윈도 시스템별로 공통적으로 지원하는 그래픽 구성 요소(메뉴, 버튼, 문자상자 등)만 이용할 수 있다는 제약 때문에 지원하는 구성 요소가 많지 않았다.

AWT보다 좀 더 다양한 GUI 구성 요소 집합이 제공되기를 바라던 사용자들의 요청에 따라 선에서는 J2SE 1.2 버전을 내놓으면서 차세대 GUI 툴킷으로 스윙(Swing)을 내놓았다. 스윙은 AWT와는 달리 모든 그래픽 구성 요소를 100% 자바로 구성하였으며 따라서 OS의 그래픽 자원을 바로 사용하는 방식이 아니라 Java2D를 이용하여 모든 구성 요소들을 직접 그려서 사용하였다. 이 방식으로 인하여 AWT의 가장 큰 문제점 중 하나였던 OS별(윈도 시스템별) 공통의 그래픽 컴포넌트들만을 지원하는 한계가 해결되었고 추가적으로 다양한 룩 앤드 필(Look and Feel)을 지원할 수 있게 되었다. 그러나 해당 OS 자원을 직접 활용하지 않는 단점으로 인한 이질감(해당 윈도 시스템의 그래픽 구성 요소와 상이한 모습을 보임)과 내부적으로 복잡한 이벤트 처리 및 직접 모든 그래픽을 그리는 데 따른 속도저하는 일반 사용자들이 많이 사용하지 않게 되는 하나의 이유가 되었다.

SWT의 뿌리는 1990년 오브젝트 테크놀로지 인터내셔널(OTI, Object Technology International)이 스몰토크(원래는 OTI 스몰토크였으나, 1993년 IBM이 OTI를 인수하여 IBM 스몰토크가 됨)를 위한 멀티플랫폼, 휴대성을 갖춘 고유의 위젯 인터페이스를 만드는 작업으로 거슬러 올라간다. IBM은 스몰토크 언어로 제작된 비주얼 에이지(Visual Age) 개발 통합 개발 환경(IDE)을 개발하고 있었다. 그들은 마이크로소프트 비주얼 스튜디오와 같은 다른 IDE와 경쟁할 의도로 오픈 소스 프로젝트를 개발하기로 결정했는데, 이는 이클립스의 개발로 이어졌다.

SWT는 그래픽 툴킷으로 실행하는 윈도 시스템 고유의 룩 앤드 필(Look and feel)을 가짐과 동시에 고유의 성능을 발휘하도록 개발되었다. [1] 나중에 IBM이 Visual Age를 이클립스로 바꾸면서 오픈 소스화 할 때 SWT도 같이 공개되었다.

[편집]디자인

SWT는 윈도 시스템에서 제공하는 고유의 그래픽 구성 요소를 자바 네이티브 인터페이스(JNI, Java Native Interface)를 통하여 직접적으로 사용하며 스윙에 비하여 비교적 하위 수준의 간단한 구현을 가진다. 따라서 스윙과 같은 모델-뷰-컨트롤러(MVC, Model-View-Controller)와 같은 디자인 패턴은 직접적으로 지원하지 못한다. 따라서 좀 더 추상화된 고수준의 패턴 지원을 위해 JFace가 개발되었으며 많은 경우 같이 사용되기 때문에 SWT/JFace와 같이 병기하여 사용하는 경우가 많다.

또한 JNI를 사용하기 때문에 각 운영 체제별 고유의 라이브러리 파일이 있어야 구동 가능하므로 자바가 구동되는 모든 운영 체제/윈도 시스템에서 구동 가능하지는 않다. 따라서 여러 OS에서 사용되어야 하는 프로그램 개발 시에는 지원 OS/윈도 시스템이 지원 가능한지 미리 확인해 봐야 한다.

[편집]스윙과의 관계

서로 다르면서도 비슷한 특성 때문에 스윙과 SWT간에 호불호로 인한 논쟁이 많이 있어왔다. 그러나 SWT는 스윙과 직접적인 경쟁을 위한 툴킷이라기 보다는 각각의 용도에 따른 또 하나의 대안의 개념으로 사용되고 있다. [2]

그리고 AWT와 스윙, SWT를 동시에 사용하는 방법도 존재한다.[3]

[편집]지원 플랫폼

2010년 1월 현재 이클립스 3.5.1 버전을 기준으로 SWT가 지원하는 플랫폼은 다음과 같다. [4]

  • Windows x86 32bit, 64bit(XP, Vista, 7)
  • Windows CE(ARM PocketPC J2SE/J2ME)
  • Linux(x86/x86_64 GTK2, PPC GTK2, x86/Motif)
  • Solaris 10(SPARC GTK2, x86 GTK2, SPARC/Motif)
  • HPUX(IA64_32/Motif)
  • QNX(x86/Photon)
  • AIX(PPC/Motif)
  • Mac OSX(Cocoa, Cocoa/x86_64, Carbon)

해당 운영 체제와 윈도 시스템에 맞는 버전을 다운받아야 하며 일부 최신 기능의 경우는 운영 체제마다 조금씩 다를 수 있으므로 개발 문서를 참고해야 한다.

[편집]같이 보기

[편집]참고 자료

  1.  FAQ 왜 이클립스에서 SWT를 쓰는가?
  2.  FAQ SWT가 Swing보다 더 나은가?
  3.  FAQ 어떻게 AWT와 Swing을 SWT와 같이 사용할 수 있는가?
  4.  SWT 다운로드 페이지

[편집]바깥 고리

 

======================================================================================

Standard Widget Toolkit ( SWT )는 Java 플랫폼 에 위젯 툴킷 의 일종. 원래 IBM 이 개발했지만 현재는 Eclipse Foundation 이 Eclipse IDE 함께 관리 유지하고있다. 썬마 이크로 시스템즈 가 Java 표준의 일환으로 제공하는 Java 용GUI 툴킷이다 AWT 와 Swing 을 대체하는 것으로서 개발되었다.

SWT는 Java로 작성되고있다. GUI 구성 요소를 표시하기 위해 SWT는 운영 체제가 제공하는 GUI 라이브러리를 JNI (Java Native Interface )를 통해 사용 (이것은 시스템 고유의 API 를 사용하는 일반적인 방법이다). SWT를 사용하는 프로그램은 이식이 도구 키트 자체의 구현은 Java로 쓰여 있음에도 불구하고 각 플랫폼이다.

SWT는 Eclipse Public License 의 라이센스되고있다. 이 라이선스는 Open Source Initiative 가 오픈 소스 라이센스로 인정하고있다 [1] .

목차

  [ 숨기기 ] 

Java GUI 툴킷의 역사 편집 ]

처음 Java 용 GUI 툴킷은 AWT ( Abstract Window Toolkit )이며, 썬 Java 표준의 일부로 JDK 1.0에서 등장했다. AWT는 비교적 간단하고 운영 체제 가 제공하는 네이티브 오브젝트 를 Java 코드로 감싸고 메뉴나 버튼 등 GUI 요소를 생성한다. AWT는 네이티브 위젯 래퍼로 매우 얇고, 플랫폼 고유의 코드를 개발자에게 비쳐 보이고 버그와 OS 고유의 버릇이 그대로 드러 있기 때문에 다른 플랫폼간에 이식 가능한 응용 프로그램을 만들려면 한계가 있었다.

Swing 은 2 세대의 도구 키트에서 Sun이 J2SE 1.2에서 도입했다. AWT보다 객체 지향 이다. Swing의 GUI 부품은 100 % Java이며, 네이티브 코드는 사용하지 않습니다. 네이티브 API를 래핑하는 대신, Swing는 낮은 수준의 OS 루틴을 사용하여 GUI 부품을 자기 부담으로 그립니다.

그 무렵, IBM 은 Smalltalk 를 이용한 통합 개발 환경 (IDE) VisualAge 를 개발하고 있었다. 이것을 오픈 소스로 공개하기로 결정, 그것은 Eclipse 의 개발로 이어져 갔다. Eclipse는 Microsoft Visual Studio 같은 IDE와 충돌있는 것으로하는 것을 목적으로하고 있었다. Eclipse는 Java로 작성되고 있으며, IBM의 개발자들은 "네이티브룩앤필 "와"기본 성능 "을 가진 툴킷이 필요하다고 생각, Swing을 대체하는 것으로서 SWT를 개발했다 .

설계 편집 ]

SWT는 GTK + 객체와 Motif 객체 같은 원시 코드 개체의 래퍼이다. 따라서 SWT 위젯은 "무거운"네이티브 개체 가벼운 Java 래퍼를 씌운듯한 이미지로 "무겁다"라고 말하는 경우가 많다. SWT가 필요로하는 기능을 기본 GUI 라이브러리가없는 경우, SWT는 Swing과 같이 자신의 GUI 코드를 Java로 구현하고있다. SWT는 본질적으로, AWT의 성능과 룩앤필과 Swing의 그것의 중간에 있다고 할 수있다.

Eclipse Foundation에 따르면, SWT와 Swing은 목표 다른 다른 도구이다. SWT의 목적은 다양한 플랫폼의 네이티브 위젯에 액세스할 수있는 공통 API를 제공하기위한 것이다. 설계 목표의 첫 번째는 고성능 네이티브 룩앤필과 플랫폼 통합의 달성이다. 한편 Swing은 고도로 사용자 정의에서 모든 플랫폼에 공통적인 모양과 느낌의 제공에있다.

SWT는 Swing에 비교하면 간단한 도구 키트이며, 표준 개발 관련 기능은별로없는 [2] . 따라서 SWT가 Swing에 비해 기능이 적다고 비판하는 사람도있다 [3] .

Java의 설계자인 제임스 고스린 은 SWT가 단순 너무 AWT와 같은 이유로 새로운 플랫폼에 이식이 어렵다고 주장했다. 단순 너무 낮은 수준 너무 Win32 GUI API와 결합 너무 있기 때문에 Motif와 OS X Carbon 같은 다른 GUI 툴킷에 대한 대응이 어렵다고했다 [2] .

developer.com에서 Mauro Marinillia는 "SWT는 Swing에 비교하면 너무 단순 보인다. Swing 많은 정교한 기능을 가지고 있기 때문에 (예를 들어, 정교한 Swing 클래스 계층, 교환 가능한 모양과 느낌 느낌, Model View Controller 방법 등) "고 주장했다. 이에 대해 Model View Controller 같은 복잡한 문제를 일종의 강제적인 올바른 방법을 적용하는 것은 좋은 것이라고 생각하는 사람도있을 것이다. Marinillia 더 "(SWT와 비교하여) Swing 제공하는 기능은 풍부하고 세련되고 있으며, 추상화 수준이 높은 (즉, 특제 GUI 부품 복잡한 GUI를 구축하는 것이 쉽다)" 라고 계속 "일반적 SWT는 매달리기 쉬운가 복잡한 GUI를 그래서 구축하려고하면 Swing이 더 유연하고 쉬운 결과를 가져온다"고했다 요청 출처 ] .

SWT는 Swing 기타 높은 수준의 GUI 툴킷이 제공하는 Model View Controller 아키텍처를 구현하고 있지 않지만, Eclipse 프로젝트의 하나로 개발된 JFace 라이브러리를 플랫폼에 의존하지 않는 고급 Model View Controller를 SWT에 구현하고있다. 개발자는 트리 / 테이블 / 목록과 같은 복잡한 SWT 컨트롤에 대해 JFace가 제공하는 유연한 추상 데이터 모델을 사용할 수도 있고, SWT 컨트롤을 직접 사용할 수도있다.

성능 편집 ]

SWT는 "고성능"GUI 툴킷으로, Swing보다 시스템 리소스를 낭비하지 않도록 설계된 [4] . SWT와 Swing의 벤치 마크 비교를 몇 가지 실시, SWT가 Swing보다 효율이 좋은 것을 알 수있다. 그러나 벤치 마크에 사용된 어플 리케이션은 그다지 복잡하지 않고 SWT 항상 Swing보다 성능이 좋다 고는 말할 수 없다 [5] .

룩앤필 편집 ]

SWT 위젯은 기본 위젯과 같은 룩앤필 을 제공한다. 이와는 대조적으로, Swing의 위젯은 기본 위젯에 가까운 복제이다. 경우에 따라이 차이가보기에도 분명된다. 예를 들어, Mac OS X의 트리 위젯 기능은 트리를 배포할 때 애니메이션을 기본 버튼을 사용자가 초점을 때 애니메이션을한다. Swing에서는 이러한 애니메이션은 행해지지 않는다.

SWT는 네이티브 GUI 코드 간단한 래퍼이기 때문에 (네이티브 API가 호환성을 한) 네이티브 코드가 변경되어도 큰 수정을 필요로한다. OS 업체들은 API의 호환성을 유지하도록 항상 조심하고있다. Swing에서는 사정이 다르다. Swing은 실행중인 응용 프로그램의 룩앤필을 교환할 수 있고 기본 GUI 테마를 에뮬레이트 가능하다. 이 기능은 OS의 GUI가 변경될 때마다 그 변화 (테마 및 기타 룩앤필 업데이트)를 반영해야한다. 반대로 말하면, 네이티브 API가 변경되면, SWT는 수정이 필수가되지만, Swing은 수정할 필요가 없다.

SWT는 "플랫폼과의 긴밀한 통합"을 목표로하고 기본 위젯을 이용한다. developer.com의 Mauro Marinillia에 따르면 "기본 플랫폼과의 긴밀한 통합이 필요한 경우, SWT는 좋은 선택"이라고하고있다 [6] . 이러한 조밀한 통합의 이점을 살린 예로 SWT는 Microsoft Windows 의 ActiveX 개체를 래핑 가능하다.

확장성과 다른 Java 코드와 비교 편집 ]

네이티브 코드를 사용하기 위해 SWT 클래스는 모든 위젯 클래스에 상속이 쉽게 허용되지 않는다. 따라서 확장성에 문제가 있다고하는 사람도있다 [6] . 이와 Swing 더 쉽게 정의 가능하다. 두 툴킷도 새로운 위젯을 Java 코드만을 사용하여 쓸 수있다.

SWT는 AWT뿐만 아니라 수동으로 개체의 방출을 필요가있다. Swing 및 Java의 메모리 자동 가비지 컬렉션 과는 다르다. close ()하지 않으면 말라 I / O 리소스와 같다. SWT 객체는 "dispose ()"메소드를 사용해 명시적으로 해제해야, C 언어 의 "free"를 닮은 [7] . 이것을하지 않으면 메모리 누수 등의 바람직하지 않은 결과를 낸다. 그러나 부모와 자식 관계에있는 Widget은 부모를 dispose ()하면 자식도 dispose ()된다. 이 문제에 대해 "리소스를 명시적으로 해제 필요는 적어도 평균적인 Java 개발자는 개발 시간과 비용에 악영향을 미친다"고 의견도있다. 또한 "이것은 엇갈린이다. Swing 더 자동화된 느린 반면 SWT는보다 세밀한 컨트롤이있는가 복잡하게된다"고하고있다 [6] . SWT 수동으로 개체 방출을 필요로하는 것은 기본 개체를 사용하는 것이 주요 원인이다. 즉, 그들 객체는 Java VM의 관리 범위 밖에 있으며, Java VM에서 그들이 풀어 가능 여부를 판단할 수 없다.

플랫폼 지원 편집 ]

GTK + 환경에서 Azureus BitTorrent 클라이언트

SWT는 플랫폼의 GUI 라이브러리에 대한 래퍼이기 때문에 Java가 동작하는 플랫폼 모두에서 작동하는 것은 아니다. 즉, SWT GUI 라이브러리마다 이식이 필요하며, Java가 새로운 플랫폼에 이식되어도 즉시 SWT가 이식되는 것은 아님 (Swing과 AWT는 Java 본체의 일부이지만, SWT는 그렇지 않다). 또한 Windows에서 SWT 제외하고는 비교적 효율이 나쁜 것으로 알려져있다 [3] . SWT는 플랫폼마다 다른 네이티브 라이브러리를 사용하고 있기 때문에, 플랫폼 고유의 버그도 SWT는 그대로 존재하고있다.

SWT는 Swing보다 낮은 수준의 세부 사항을 개발자에게 제공한다. 이것은 SWT가 기본 라이브러리에서 제공되는 GUI 기능의 상위 계층이기 때문에이며 기본 GUI 코드를 개발자에게 제시하는 것도 의도적인 것으로 보인다. SWT의 목적은 고급 사용자 인터페이스 디자인 프레임 워크를 제공하는 것이 아니라 가능한 한 많은 플랫폼에서 얇은 사용자 인터페이스 API를 제공하고 그 위에 고급 GUI 응용 프로그램을 구축하기에 충분한 기능을 제공 이다.

SWT의 구현은 플랫폼마다 다르기 때문에 여러 플랫폼으로 응용 프로그램을 배포할 때는 플랫폼마다 SWT (JAR 파일)가 필요하게된다.

SWT는 Java 클래스 라이브러리를 필요 최소한 밖에 사용하지 않기 때문에 기존 JDK (예 : 1.1.8)에서도 동작하는 Java 클래스 라이브러리를 완전히 지원하지 않을 휴대용 기기에서 작동하는 것으로 알려져있다 요청 출처 ] .

2006 년 3 월 현재 SWT가 지원되는 플랫폼 / GUI 라이브러리는 다음과 같다.

SWT 애플 리케이션 편집 ]

SWT를 사용하는 응용 프로그램으로 다음의 것이있다.

SWT 관계 문서 편집 ]

GUI 툴킷은 Swing보다 오래된 것이기 때문에, SWT 관련 문서 / 도서 Swing에 비해 적은 요청 출처 ] .

SWT : The Standard Widget Toolkit 은 Eclipse Foundation 추천의 SWT 해설서이다 [8] . 이외에도 SWT 관련 서적으로 다음과 같다.

  • Rob Warner, Robert Harris (2004 년) The definitive guide to SWT and JFace . Apress. 
  • Eric Clayberg and Dan Rubel (2004 년). Eclipse : Building commercial - quality plug - in . Addison - Wesley. 
  • Erich Gamma and Kent Beck (2004 년). Contributing to Eclipse . Addison - Wesley. 
  • Sherry Shavor et al (2004 년) The Java Developers Guide to Eclipse . Addison - Wesley. 

Web에서 SWT 편집 ]

Eclipse 커뮤니티의 최근 움직임으로 SWT (와 JFace)을 Web위한 위젯 툴킷으로 이식하려고하고있다. Eclipse RAP [9] (Rich Ajax Platform)은 Qooxdoo AJAX 라이브러리와 SWT API를 조합한 것이다. 다른 Java AJAX 프로젝트 (Echo2와 GWT )뿐만 아니라 SWT API를 사용하면 데스크탑과 같은 형태로 Web 용 응용 프로그램 개발이 가능해진다.

개발 편집 ]

Eclipse가 인기를 얻어 온 결과로, Swing과 SWT를 어떤 의미에서 "통합"하려고하는 활동도있다.

Swing과 SWT의 통합에 대해서는 다음과 같은 몇 가지 방법이 존재하고있다.

  • Eclipse 프로젝트는 Swing 위젯 SWT 컨테이너 위젯에 포함 시키려고하고있다. 요청 출처 ]
  • SwingWT 는 Swing API의 대체 구현을 제공하려는 프로젝트이다. 그 중 하나 SWT에서 Swing 위젯을 사용할 수 있도록하는 프로젝트가 진행되고있다 [10] .
  • SWTSwing 는 반대로 Swing에서 SWT API를 제공하는 프로젝트이다. 이것은 SWT가 지원되지 않는 플랫폼에서 Java조차 작동하면 SWT 응용 프로그램을 실행 가능하게된다 [11] .

각주 편집 ]

  1. Open Source Initiative " Licenses By Name " 2007 년 3 월 24 일 보기.
  2. b Ella Morton " James Gosling Q & A " 2007 년 3 월 24 일 보기.
  3. b Performance Benchmarks of Nine Languages ​​" 2007 년 3 월 24 일 보기.
  4. ^ Akan, Ozgur ( 2004 년 11 월 19 일 .. ) " Why I choose SWT against Swing " 2006 년 11 월 7 일 열람.
  5. ^ Swing vs. SWT Performance - Have a Look at the Call Stacks Javalobby, StephenStrenn 2006 년 3 월 3 일
  6. C Marinilli, Mauro " Swing and SWT : A Tale of Two Java GUI Libraries " 2006 년 11 월 7 일 열람.
  7. ^ The Java developers guide to Eclipse, 2nd ed., p359
  8. Steve Northover, Mike Wilson . SWT : The Standard Widget Toolkit . Addison - Wesley. 
  9. ^ Rich Ajax Platform (RAP)
  10. ^ SwingWT
  11. ^ swtswing

외부 링크 편집 ]




==============================================================================================

JFace는 이클립스에서 사용되는 일반적인 사용자 인터페이스(UI)를 구현하기 위해 사용되는 툴킷(toolkit)이다. JFace는 그 API와 구현에 있어서 윈도 시스템에 독립적이고 하위 그래픽 사용자 인터페이스(GUI)인 SWT를 숨기지 않고 같이 사용되도록 구현되어 있다.

주요 기능은 액션(actions)과 뷰어(viewers)로서 액션은 사용자의 명령이 어떠한 UI에서 발생되었는지를 상관하지 않고 동일하게 처리할 수 있는 추상적인 매커니즘을 제공하고 뷰어는 특정 모델 기반의 SWT 위젯(widget)의 어댑터가 되어 자료를 목록(lists), 테이블(tables), 트리(trees) 형태로 표현하는 기능을 간략히 할 수 있도록 제공한다.

위 내용을 포함한 JFace가 제공하는 기능은 다음과 같다.

  1. MVC가 적용된, 필터, 정렬, 업데이트 기능을 갖춘 뷰어들을 제공한다.
  2. 액션을 정의하고, 적절한 위치에 배치하는(메뉴, 툴바, 버튼) 기능을 제공한다.
  3. 표준 대화상자 및 마법사를 제공한다.
  4. 이미지, 글꼴등을 관리하는 레지스트리를 제공한다.

목차

  [숨기기

[편집]사용

[편집]SWT와의 사용

JFace는 하위 UI 시스템인 SWT를 대체하기 위하여 만들어진 것이 아니고 자주 쓰이는 UI Framework을 추상화 하도록 만들어졌기 때문에 단독으로는 쓰일 수 없고SWT와 같이 사용해야 한다. 따라서 SWT/JFace와 같이 병기하여 표기하는 일이 많다.

[편집]스윙과의 차이

스윙(Swing)은 자바 1.1 버전부터 지원하는 그래픽 라이브러리로 기존의 AWT의 단점을 보완하고자 여러 플랫폼에서 동일한 모양으로 실행될 수 있도록 만들어진 자바 표준 그래픽 라이브러리이다. 그러나 느린 속도와 복잡한 개발방식, 그리고 윈도 시스템별로 다른 UI를 제공하지 못하는 한계로 인하여 일반 사용자를 대상으로 한 프로그램에서는 대중적으로 사용되지 못하였다.

그에 반에 SWT/JFace는 해당 윈도 시스템의 화면 구성 컴퍼넌트를 직접 사용하기 때문에 실행하는 윈도 시스템별로 해당 시스템 고유의 그래픽을 보여줄 수 있고 속도 또한 빠르다.

다만 이러한 구현을 위해 내부적으로 JNI(Java Native Interface)를 사용하므로 자바의 기본적인 Write Once, Run Everywhere(한번만 작성하여 VM이 존재하는 어디든 구동한다.)라는 원칙을 지키지는 못한다. 그러나 주요 OS와 윈도 시스템을 지원하므로 대부분의 경우 플랫폼에 큰 제약을 받지 않는다.

그리고 이클립스 3.2버전 이상의 SWT/JFace에서는 Swing 뿐만 아니라 AWT와도 같이 사용할 수 있는 기능을 제공한다. [1]

[편집]버전별 종속성

JFace는 이클립스와 함께 쓰일 수도 있고 RCP(Rich Client Platform) 형태로 별도의 프로그램으로 실행될 수 있다.(이클립스 버전 3.2부터 SWT, org.eclipse.equinox.common, org.eclipse.core.commands만 의존성을 가짐.) [2]

이클립스 버전 3.3부터는 OSGi와 관계된 의존성 추가로 인하여 org.osgi.framework가 추가되었다.

[편집]참고 문헌

  1.  SWT FAQ
  2.  Eclipse Bug 49497 [RCP JFace dependency on org.eclipse.core.runtime enlarges standalone JFace applications]

[편집]같이 보기

SWT

[편집]외부 링크

(영어) 이클립스 JFace 위키 페이지


===============================================================================================

컴퓨터 프로그래밍에서 위젯(widget) 또는 컨트롤(control)은 컴퓨터 사용자가 상호 작용하는 인터페이스 요소이다. 이를테면, 텍스트 상자가 있다. 위젯은 위젯 스스로를 물리적인 대응물(counterpart)과 구별하기 위해virtual(가상)의 자격을 갖는다. 이를테면, 마우스 커서로 클릭되는 가상 버튼과 그의 대응물인 손가락으로 눌리는 물리적 버튼을 들 수 있다. 위젯은 자주 위젯 툴킷 안에 포함된다. 프로그래머들은 위젯을 사용하여 그래픽 사용자 인터페이스를 만든다.

목차

  [숨기기

[편집]어원

위젯(widget)이라는 용어는 영어로 소형 장치나 요소를 뜻한다. 1980년대에 프로젝트 아테나가 최초로 GUI 요소를 위젯이라고 부르기 시작했다. 다른 비슷한 용어에는 적절하지 못한 뜻이 포함될 수도 있었기 때문에 이 낱말이 선택되었다. 또 이 프로젝트의 Intrinsics툴킷(Xt 라이브러리)은 X 윈도 시스템 위에서 창과 각 위젯을 연결시켰기 때문에 창과 같은 접두어가 선택되었다고 한다.[1]

[편집]다양한 위젯

위젯은 여러 가지 종류가 있지만, 작업 표시줄은 여러 운영 체제에서 쓰이는 공통 위젯에 속하지 않는다.

[편집]선택

[편집]탐색

[편집]문자 입력

[편집]출력

[편집]

[편집]같이 보기




 
Posted by linuxism
,