Linux Power - 스페셜 KDE와 GNOME 애플리케이션 개발 A To Z MS의 윈도우에 대적할만큼 발전한 KDE와 GNOME은 리눅스에서의 데스크탑을 이끄는 양대 산맥으로 통하고 있다. 이들의 실행 구조는 조금씩 다르지만 서로의 장점을 흡수하고 단점을 보강해 가면서 상당부분 유사한 형태로 방향을 맞춰가고 있는 실정이다. 애플리케이션을 개발하려면 그 기반 환경에 대한 이해가 반드시 뒤따라야 한다. 이에 양대 데스크탑 환경에 대한 전반적인 내용을 살펴보고 데스크탑 환경에서 응용 애플리케이션이 어떻게 만들어지는지 알아보도록 하자. 글 ? 김재선 ARA IDC System 사업팀장 coca@kldp.org Part 1 . 개발자를 유혹하는 리눅스 데스크탑의 발전 Part 2 . 자유롭게 만들자! GNOME 애플리케이션 Part 3 . 리눅스 데스크탑 원조, KDE로 개발하기 Part 1. 개발자를 유혹하는 리눅스 데스크탑의 발전 리눅스 개발에 참여하고 있는 개발자는 잠재적으로 10만 명에 육박하고 있다. 이는 리눅스 커널을 비롯하여 각종 애플리케이션 개발자 수를 추정한 숫자이다. 인터넷이라는 망망대해에서 얼굴도 모르는 개발자끼리 정보를 주고 받으며 하루에도 수십 개의 새로운 애플리케이션들을 쏟아내고 있다. 역사적으로 볼 때 참으로 대단한 일이 아닐 수 없다. 세계적인 초대형 소프트웨어 회사들도 이렇게 많은 수의 개발자를 보유하기란 불가능 하기 때문이다. 최근 최대의 유닉스 상용회사 중의 하나인 썬에서도 리눅스의 발전에 자극받아 솔라리스를 공개 운영체제로 전환하였다. 처음에는 CD 발송만 하였지만 현재는 사이트에서 다운로드도 가능하게 되었다. 이렇듯 리눅스 이론의 큰 뼈대를 이루는 ‘성당과 시장’ 이론(성당은 페쇄된 개발환경, 시장은 개방된 개발환경을 의미한다는 것으로 넷스케이프의 소스공개를 이끈 오픈 소스 개발환경 이론)처럼 흘러가는 것은 리눅스를 사용하는 한 사람으로서 참으로 고무적인 일이라고 할 수 있다. 1. 누구나 참여하는 리눅스 프로젝트 이렇듯 수없이 많은 애플리케이션을 개발하는 사람들은 과연 누구인가? 이들 중 상당수는 소프트웨어 회사에 개발자로 일하면서 고액의 연봉을 받는 고급 개발자들이다. 또한 다른 직종에 종사하고 있지만 취미로 프로그램을 만드는 사람들도 있다. 물론 많은 비중을 차지하고 있는 사람들은 바로 학생이다. 컴퓨터와 관련된 학과의 학생들이 자신들의 프로그램 개발 기술을 습득하고자 작성하는 많은 프로그램들이 상당부분 차지하고 있다. 이렇듯 리눅스 응용프로그램 개발에는 누구라도 좋으리만큼 다양한 직종의 다양한 연령층의 개발자들이 참여하고 있다. 그럼 이들은 주로 어떤 응용프로그램을 개발하는가? 리눅스의 핵심이라고 할 수 있는 리눅스 커널에서부터 각종 게임, 서버 프로그램, 간단한 프로그램들까지 그 종류에 관계 없이 다양하고 많은 프로그램들을 개발하고 있다. 규모가 큰 프로젝트의 경우 짜임새 있는 개발체계를 만들고 시작하기도 하지만 대부분의 경우 개발자의 필요나 흥미에 따라 자신이 스스로 개발과정을 계획하고 코딩한다. 또 상황에 따라서 개인이 개발하던 프로젝트가 대형화 되어 많은 개발자가 동시에 참여하는 프로젝트로 성장하기도 한다. 아파치나 PHP 같은 대형 프로젝트들이 그 대표적인 예라고 할 수 있다. 2. 리눅스 데스크탑의 양대 산맥 KDE와 GNOME 위에서 언급하였듯이 리눅스 프로그램 개발은 누구든지 언제든지 무엇이든지 개발할 수 있는 여지를 가지고 있다. 중요한 것은 어떤 프로그램을 어떤 환경에서 개발할 것인지를 결정하는 것이다. 특히 리눅스가 데스크탑을 지향하고 있는 현재의 시점에서 중요한 것은 작고 가볍지만 사용자에게 편리한 그런 응용프로그램들이 다량으로 개발되고 있다는 특징이다. 수없이 많은 윈도우 매니저들이 있지만 데스크탑을 지향하는 포괄적인 환경을 갖춘 것으로 GNOME과 KDE가 대표적이라고 할 수 있다. KDE는 처음에는 마치 유닉스 환경의 CDE(Common Desktop Environment)를 그대로 옮겨 놓은 듯한 모습으로 유명하였는데 현재는 훨씬 발전된 모습을 갖추고 있으며 개인용 데스크탑 운영체제로 유명한 마이크로소프트의 윈도우 시리즈와 비교해도 손색이 없을 정도로 놀라운 발전을 거듭하고 있다. KDE가 Qt라는 뛰어난 라이브러리를 가지고 발빠르게 발전하였지만 라이센스 정책 등이 리눅스 진영에서 수용할만한 것이 못되어서 한 때는 여러 배포판으로부터 외면당하는 시련도 겪었었다. 이에 반해 처음부터 자유 소프트웨어 진영에서 개발을 착수한 GNOME은 개발 초기에 GIMP라는 그래픽 툴을 개발하기 위해 만들어진 gtk+라는 엄청난 개발툴을 가지고 포괄적인 데스크탑 환경을 지향하면서 개발되어 왔다. KDE보다는 늦은 출발로 인해 더딘 발전을 하였지만 현재는 거의 비슷한 수준의 개발환경을 보유하고 있다고 판단된다. 그럼 리눅스 진영의 양대 데스크탑 환경이라고 할 수 있는 GNOME, KDE의 데스크탑 환경에서의 애플리케이션의 개발에 대해서 보다 구체적으로 살펴보도록 하자. 2. 자유롭게 만들자! GNOME 애플리케이션 GNOME은 ‘그놈’이라고 발음하며 최초 사용자가 사용할 수 있는 편하고 자유스러운 사용을 목적으로 하는 포괄적인 데스크탑 환경의 제공을 위해서 그 프로젝트가 시작되었다. 그 이름에서도 알 수 있듯이 최초 개발시기부터 GNU의 프로젝트로서 시작되었고 유닉스환경 시스템에서 선진화된 데스크탑 환경을 구현하고자 하였다. GNOME 프로젝트는 크게 GNOME 데스크탑, GNOME 개발환경, GNOME 오피스의 세 분야로 분류된다. 데스크탑은 순수하게 윈도우 기반의 사용자 환경을 지향하며 무엇보다도 쉬운 사용이 그 대표적인 컨셉이라고 할 수 있다. 개발환경은 각종 툴, 라이브러리, 컴포넌트 등 애플리케이션에 필요한 대부분의 것들을 제공하며 보다 강력한 개발환경을 제공하고자 하는데 그 목적이 있다. 오피스 환경은 개인 사용자들이 가장 필요로 하는 오피스 환경을 제공하여 GNOME을 개인적인 데스크탑 환경으로 옮기는데 불편이 없도록 하는 것이 목적이다. 이를 크게 두 부분으로 압축한다면 개인 데스크탑 환경과 개발자 환경으로 나눌 수 있을 것이다. KDE 역시 이런 두 가지의 뚜렷한 특징을 그대로 유지하고 있다. <박스> GNOME 개발 철학 GNOME은 2년 넘게 개발되어 온 각종 소프트웨어들의 집합이라고 할 수 있다. 작은 것부터 큰 규모의 시스템 소프트웨어들이 있고, 고도의 로우레벨 개발 라이브러리에서부터 최종사용자의 응용 프로그램에 이르기까지 모두 해당된다. GNOME은 개발 초기부터 가지고 있는 기본 개발 철학이 있는데 이는 다음과 같다. ◆ Free 자유라고 번역할 수 있는 이 단어는 많은 의미를 내포하고 있다. 소프트웨어 사용에 대한 정당성을 내포하고 있으며 소프트웨어의 정당한 재배포, 소프트웨어의 올바른 이해, 소프트웨어에 대한 전체적인 공개 등 기본적으로 자유 소프트웨어 진영이 내포하는 그 ‘자유’라는 것과 기본 이념을 같이한다. 바로 이 컨셉이 오늘날의 GNOME을 있게 한 가장 핵심적인 개발철학이라고 할 수 있다. ◆ 사용자 친화 전통적으로 유닉스/리눅스 시스템들이 강력하고 다양성을 가지는 반면 사용자에게는 상당히 불편함을 제공했던 것이 사실이다. GNOME은 이런 단점을 타파하고자 여전히 강력하고 다양성을 가지면서도 사용자에게 친화적인 측면으로 이들을 전달하고 하였다. 최신 버전의 GNOME을 사용해 본 경험이 있다면 얼마나 세련되고 사용자에게 편리한 인터페이스를 제공하는지 한눈에 알아볼 수 있을 것이다. ◆ 최신 동향 리눅스를 사용하는 사람들에게 왜 사용하냐고 물어보면 가장 많이 나오는 답변이 바로 ‘최신의 것’을 사용하고 싶기 때문이라는 것이다. 때론 ‘Bleeding Edge'로 표현되는 최신의 기술 동향의 최전방에 바로 리눅스가 서 있기 때문이다. 어떤 기술이든지 새롭게 발표되면 그것을 흡수하고 때론 본질의 것에 더욱 잘 부합하도록 개조해서라도 최신 기술을 통합하려고 노력한다. CORBA, XML 등이 네트워크 지향의 컴포넌트들에 사용된 것을 보면 쉽게 이해할 수 있을 것이다. ◆ 개발자 지향적 GNOME의 개발자 커뮤니티는 매우 광범위하며, 세밀하게 구성되어 있고, 높은 친화성을 가지고 있다. 만약 유닉스/리눅스 환경에서 GUI 응용 프로그램을 작성하고자 한다면 바로 GNOME이 시작할 수 있는 모든 것을 제공할 것이다. 가장 기초적인 부분의 자세한 문서 자료들과 편리한 각종 개발툴, 또한 최종 결과물을 테스트해주고 버그를 리포트해줄 커뮤니티까지 그야말로 개발자는 오직 개발에만 몰두 할 수 있도록 여타의 제반사항을 모두 제공해주는 것이다. ◆ 국제적 GNOME의 개발에 관련된 나라는 세계적으로 100여 개가 넘으며 이들은 모두 GNOME의 국제화의 새로운 개발에 기여하고 있다. 각국의 언어로 관련 문서들이 번역되고 있으며 응용 프로그램 역시 각종 언어로 번역되고 있다. 1. GNOME 개발환경 GNOME 프로젝트에 참여하고자 한다면 다음과 같은 것들이 바로 직접 참여할 수 있는 부분이다. - 문서화(Documentation) - 번역(Translation) - 그래픽(Graphics) - 사용자 인터페이스(User Interface/Human Interface) - 시스템 사운드(Sound) - 패키징(Packaging) - 웹 디자인과 개발(Web Design and Development) - 테스트(Testing) - 응용 프로그램 개발(Application Development) - GNOME 플랫폼 개발(GNOME Platform Development) - 개발자 도구 개발(Developer Tool Development) 위의 내용 중에서 이 글에서 다루고자 하는 부분은 마지막 세가지 부분이 될 것이다. 이 세 가지에 관련하여 무언가를 시작하기 위한 개발자라면 시작하기에 앞서 GNOME 커뮤니티에 접근할 수 있는 두 가지의 길이 있다. 첫째 메일링 리스트로 www.gnome.org/resources/mailing-lists.html에서 모든 리스트를 한꺼번에 볼 수 있고 그 동안의 것들을 읽어 볼 수도 있다. 두 번째, ‘인터넷 실시간 채팅'을 통하여 안내를 받을 수 있는데 이는 특정 IRC 클라이언트를 사용하여 irc.gnome.org로 접속한 다음 #gnumeric 채널에서 GNOME 개발에 대한 이야기를 사람들과 나눌 수 있다. 1.1 GNOME의 체제를 갖춰준 개발 툴키트 GTK+ GTK는 처음에는 GIMP 툴키트로 개발되었다. 하지만 많은 개발 가능성을 시사하면서 GNOME 프로젝트의 주된 툴키트로 성장하였고 현재는 관련된 모든 애플리케이션의 기반으로 사용되고 있다. GTK는 Xlib나 엑스윈도우 시스템 수준으로 접근하기 위하여 저수준의 기능들의 구현을 총괄하는 GDK(GIMP Drawing Kit)의 최상위 수준에서 동작한다. 최초의 GTK 개발자들은 다음과 같다. * 피터 매티스 Peter Mattis (petm@xcf.berkeley.edu) * 스펜서 킴벨 Spencer Kimball (spencer@xcf.berkeley.edu) * 조시 맥도날드 Josh MacDonald (jmacd@xcf.berkeley.edu) GTK는 기본적으로 객체지향적 API(Application Programmers Interface)를 제공한다. 또한 클래스와 콜백 기능을 실행할 수 있도록 완벽히 C언어로 구현되어 있다. 또한 세 번째 컴포턴트로 불리는 GLib를 사용하는데 이는 표준 콜을 위한 몇 가지 대체 기능을 포함하고 있으며 연결 목록과 같은 몇 가지 첨부 기능들도 구현할 수 있는 수준이다. 이러한 대체 기능들은 GTK의 용이성을 더욱 증가시켜 주는 역할을 하며 g_strerror() 같이 다른 유닉스에서는 찾아 볼 수 없는 비표준적인 요소들이 포함되어 있다. 물론 보다 진보된 기능은 g_malloc 같은 디버깅 유틸리티들도 포함되어 있다. C로 구현되어진 툴이므로 주로 C를 기반으로한 프로그래밍에 맞춰 설명하겠지만 다른 여러 언어들과의 호환성도 내재되어 있음을 주목하자. C++, Guile, Perl, Python, TOM, Ada95, Objective C, Free Pascal, Eiffel 등도 모두 지원하는 언어들이므로 이중에 자신이 선호하는 어떤 것을 선택하여도 지장이 없다. 또한 wxWindows와 같은 크로스 플랫폼 개발을 위한 API들이 제공되므로 해당하는 목적 플랫폼(Trarget Platform) 등에 GTK를 사용하여 개발할 수도 있다. 만약 C++로 GTK 애플리케이션을 개발하고자 한다면 몇 가지 기억해 둬야 할 사항들이 있다. 특히 중요한 것은 C++을 위하여 GTK--가 있으며 이는 보다 C++에 편리한 인터페이스를 제공하는 GTK이다. 다른 방법을 강구하고자 한다면 기본적인 GTK의 사용에 있어서 C++중에서 C 서브세트(subset) 만을 사용하면 된다. 다른 방법으로는 C++ 클래스에 있는 모든 콜백들을 고정 기능으로 정의하는 방법으로 C++와 GTK를 함께 사용할 수 있다. 그렇게 하므로 GTK에서 C 인터페이스를 사용할 수 있게 된다. 하지만 이와 같은 방법은 여러 가지 복잡한 제반 사항을 필요로 하므로 GTK--를 사용하는 것이 효과적이라고 생각된다. 1.2. C언어를 위한 기능 라이브러리 GLib GLib는 앞서 설명하였듯이 C언어를 위한 기능 라이브러리이다. 여러가지 기능 중에서도 C와 밀접하게 Data containers, Portability, Utility의 세 부분으로 말할 수 있다. GLib는 매우 우수하고 강력한 기능들을 제공하는데 특히 이식성이 높은 코드를 작성하는데 매우 유용하다. 특히 개발자에게 커다란 목적 플랫폼에 대하여 부수적인 기능을 하는 코드에 대하여 제한할 필요성이 없게 하며, 여러 다른 플랫폼에서의 동작성에 대하여 의심할 필요없이 확신하게 하는 매력을 가지고 있다. 사실 프로그램을 작성하면서 다른 플랫폼에서 제대로 동작할지 걱정하는 것처럼 큰 스트레스는 없기 때문이다. 또한 이는 기본적인 C언어 라이브러리보다 일관된 기능 라이브러리들을 제공하는데 개념은 거의 비슷하며 보다 간단한 언어적 분석자와 작성할 프로그램의 이벤트를 위한 주요 루프 기능과 같은 선진적인 면들을 갖추고 있다. ◆ 다양한 용도로 쓰이는 Glib에서의 Typedefs GLib에 포함된 typedefs셋은 생각보다 넓은 영역에 관여할 수 있다. 어떤 부분은 타이핑을 줄이기 위하여, 또 어떤 부분은 이식성을 높이기 위하여, 또 다른 부분은 네이밍(naming) 작업의 일관성이나 소스 코드의 명확성을 높이기 위하여 사용된다. 만약 타이핑을 줄이기 위하여 typedefs를 사용하길 원한다면 이러한 경우에는 정의되지 않은 int를 사용하기 보다는 guint를 사용하면 된다. 이는 모든 캐릭터 타입이나 정수형태의 타이핑을 포함할 수 있기 때문이다. 이식성을 높이기 위하여 typedefs를 사용하고자 할 때, 이는 주로 구체적인 사이즈의 정수들과 관련된 문제들이다. 예를 들어 정의된 16비트 정수는 gint16과 같은 형태로 사용하면 되고 8비트의 정의되지 않는 정수는 guint8과 같은 형태로 사용할 수 있다. 만약 64비트 정수를 사용하고자 한다면 G_HAVE_INT64 매크로가 정의되어 있는지 여러분의 시스템의 지원여부를 알아보아야 할 것이다. ◆ 메모리 배열로 알아보는 기본 구성체 가장 기본적인 구성체로 메모리 배열에 대하여 생각해보자. 표준 malloc과 free도 좋지만 완벽하진 않다. 예를 들어 NULL을 사용하고자 한다면 malloc은 아마도 NULL을 되돌려줄 것이다. 반환값을 체크하지 하지 않고 무시한다면 이는 응용프로그램의 동작에 예상치 않은 결과를 가져올 때가 종종 있다. 그래서 GLib는 g_malloc과 g_free 같은 대응책을 정의해 놓았다. g_malloc은 새로운 메모리에 대한 포인터의 반환을 보장한다. 만약 더 이상 할당할 수 없게 되면 프로그램은 취소될 것이다. 이것은 이후에 핸들링 할 수 없는 NULL 포인터에 의한 단편적인 오류(segfault)를 얻는데 선호되는 것이다. g_free는 NULL을 통과시키는 기능을 갖으며 이 경우에는 어떤 문제도 야기하지 않으며 만약 프리시켜야 할 많은 포인터들을 갖는 객체가 있다면 단순한 클리너(cleaner) 기능을 수행할 것이다. g_malloc도 좋지만 g_new와 g_new() 역시 매우 유용하다. 이 두 가지가 좋은 것은 할당된 객체의 타입과 디자인된 수의 타입 두 가지를 모두 간단한 매크로로 취할 수 있다는 점이다. g_new() 매크로는 또한 모든 기점으로의 메모리로써 사용되어 질 수 있다. 이 기능의 좋은 점은 만약 랜덤함수보다 모든 것이 기점으로 회귀한다면 초기화되지 않은 값을 사용하여 에러를 찾는데 보다 유리하다는 것이다. ◆ GLib 스트링 유틸리티 기능 개발자는 항상 C 스트링을 가지고 작업을 할 것이다. C를 가지고 스트링을 조작한다는 것은 축복받음과 동시에 매우 곤욕스러운 작업이다. 하지만 GLib의 스트링 유틸리티를 사용한다면 힘든 부분을 손쉽게 처리할 수 있을 것이다. 그럼 어떻게 이를 사용하는지에 대해서 간단히 언급해 보도록 하자. 상위에서 하위로의 전환을 가정해보면, g_strup 또는 g_strdown을 사용하여 스트링을 독립변수로 사용할 수 있을 것이다. 또한 개발자는 코드의 앞뒤의 여백처리가 골치아픈 문제로 느껴질 것이다. g_strchug가 스트링의 앞 여백을 없애줄 것이며, g_strchomp가 뒤쪽 여백을 처리해줄 것이다. g_strstrip는 일종의 매크로로 전후여백을 처리하는데 사용되어질 수 있다. 이 세가지 기능은 사실 독립변수를 그대로 되돌리는 결과를 갖는다. 그러므로 이들을 남용해서는 안될 것이다. 결국 새로운 스트링이 생기는 것이 아니라는 것을 명심하기 바란다. 단순히 독립 변수의 반환을 보다 쉽게 할 수 있도록 조작적인 이점이 있을 뿐이다. ◆ 연결목록 연결목록은 지금까지 가장 애용되어온 어떻게 보면 남용되기까지 한 GLib의 컨테이너 중의 하나이다. 구조적인 이름은 GList와 GSList이다. GList는 이중 연결된 리스트의 수행이며 GSList는 단순 링크 리스트를 수행한다. 이들은 매우 비슷한 기능을 가지며 대부분 GList의 사용만으로도 필요한 내용들을 수행할 수 있다. GSList는 단순히 GList와 비교하여 몇 가지의 기능적인 보충만을 소유한다. 일반적으로 g_list_로 스트링을 시작하기 보다는 GList 기능을 사용하기 위해서는 g_slist_로 시작하는 것이 좋다. GLib의 몇 가지 기능들의 특성에 대하여 알아보았는데 언급되지는 않았지만 기본적인 기능들에도 상당히 편리한 기능들이 포함되어 있으며, GString 등도 매우 뛰어난 기능성을 가지고 있다. 1.3 GTK+ 그래픽 인터페이스 제작용 라이브러리 Glade Glade와 libglade는 GTK+의 그래픽 인터페이스를 만드는 라이브러리로서 보다 쉽고 편하면서도 깔끔한 인터페이스를 제공한다. 무엇이든지 프로그래밍하기로 계획을 하였다면 그 프로그램에 따른 인터페이스는 필수적이며 GNOME 데스크탑 환경에 맞는 응용 프로그램을 작성하기로 했다면 당연히 그래픽 인터페이스를 설계해야만 한다. 인터페이스 설계는 매우 까다롭고 한번 작업을 마치고 나면 수정하거나 확장하기가 상당히 곤란해진다. 최초에 GTK+가 발표되기 시작할 때부터 사람들은 그래픽 인터페이스 설계를 위한 좋은 것을 찾기 시작하였는데 번번히 무산되곤 하였다. 수만은 시행착오를 거친 끝에에 선택되고 사용된 것이 바로 libglade다. libglade는 프로그램이 동작할 때 포함된 XML 표기를 읽어들이고 이를 바로 위젯으로 변환하여 보여준다. 이는 얼마든지 소스코드와 함께 변형될 수 있고 조작이 가능하다. libglade가 사용하는 XML 형태는 Glade 인터페이스 디자이너가 개발자가 조작한 프로젝트를 그대로 수용하는 형태를 갖는다. Glade는 개발자의 소스코드를 표현하기 위하여 그대로 변형한다는 면에서 전통적인 인터페이 디자인 툴이다. 하지만 이 글에서 소개하고자 하는 것은 Glade를 단순히 인터페이스를 디자인하는데 사용하고 또 그것을 어떻게 XML 포맷으로 저장하는지에 대하여 알아보기로 하자. 그리고 직접 작성한 Glade 파일을 사용하여 위젯을 표현하는지 알아보자. 1.3.1 Glade 사용하기 Glade는 <그림 1>에서 보이는 메인 화면으로 구성되는데, 팔레트 윈도우, 정보 윈도우 등이 나타나 있다. 글레이드를 사용하여 인터페이스를 구성하고자 한다면 이에 관한 자세한 문서는 www.gnome.org에 있는 튜토리얼을 참고하도록 하자. 그림 1 . Glade 메인 화면 글레이드를 사용하여 인터페이스를 구성하기 위해서는 먼저 인터페이스를 설계하고 이를 XML 형태로 저장하여 소스코드에 삽입하는 과정을 거친다. 작성된 소스코드에 글레이드를 사용하기 위하여 다음을 적어준다. #include 위와 같은 표기로 글레이드를 사용하여 인터페이스 한 부분을 소스코드가 참조할 수 있도록 하며 소스코드 컴파일 시에 다음과 같이 makefile을 작성하여 컴파일해 주어야만 올바르게 동작한다. CFLAGS=-g -Wall `gnome-config --cflags gnome gnomeui libglade` LDFLAGS=`gnome-config --libs gnome gnomeui libglade` all: phonebook clean: rm -f *.o core phonebook 글레이드를 사용하여 인터페이스를 작성하고 소스코드에 포함하여 사용하고자 할 때 가장 중요한 점은 동작시에 적절한 인터페이스를 응용 프로그램이 찾아내고 이를 libglade가 보여줘야 한다는 것이다. 또한 Glade와 libglade는 현재 개발중이므로 상당부분 안정화 과정을 거치고는 있지만 약간은 불안정한 모습도 가지고 있다는 것이다. 다음 버전의 GNOME에서는 이들이 핵심 프로그램으로 포함될 것이며 곧 완벽한 개발 환경을 지원할 것으로 기대된다. 1.4 프리 C에 기반한 ORBit ORBit은 프리 C에 기반한 ORB(Object Request Broker)로써 CORBA 2.2를 따른다. CORBA란 Common Object Request Broker Architecture의 약어이며 애플리케이션 레벨에서의 통신을 가능하게 한다. 한마디로 함축하자면 '객체 지향 RPC(Remote Procedure Call)'라고 할 수 있다. 이는 현대적인 프로그램 작성에 있어서 매우 획기적인 면이며 GNOME 역시 최고를 지향하는 데스크탑 환경으로서 이를 잘 활용하고 있다. GNOME 환경에서의 응용프로그램 개발을 계획한다면 이에 대한 보다 심도있는 고찰이 반드시 필요하게 될 것이다. ORBit은 CORBA의 다른 실행면에 있어서 몇가지 구별되는 중요한 면을 갖는다. 첫째, CORBA의 많은 다른 실행적인 면이 요구하지 않는 것이 반해 철저히 C 기반의 실행 즉 기본적인 C 매핑을 기반으로 한다는 것이다. 둘째, 매우 빠른 실행이 가능하다는 것이다. 프로그램 내에서 정보의 전달을 조작하는 것이 매우 빠르기 때문이다. 셋째, 메모리 사용에 매우 효과적이므로 규모가 적은 시스템에서도 잘 동작한다. 넷째, 실제적인 문제를 해결하는데 매우 좋은 방법들을 제시해 준다는 것이다. CORBA의 매카니즘은 클라이언트/서버 응용 프로그램의 이상적인 관계를 표현하는 것으로 클라이언트인 GUI가 데이터베이스 서버와 통신을 한다든가, 보다 간단한 프로그램들이 메일 서비스와의 통신을 하는 것들을 표현한다. ORBit은 후자의 경우 더 적절한 응용을 할 수 있으며 한 데스크탑에서 운용되고 있는 응용 프로그램들 사이에 정보 교환을 보다 원활하게 하도록 한다. ORBit은 완전한 일반 ORB에서 나왔으며 GNOME 데스크탑 이외에도 얼마든지 많은 부분에 사용되어 질 수 있다. 실제적으로 ORBit을 사용하기 위하여 GNOME에서 선행되는 조건이 없기 때문이다. 1.5 GNOME 패널 애플릿 GNOME 데스크탑 환경을 사용하거나 스크린 샷을 본 적이 있다면 항상 화면 가장자리 쯤에 위치한 패널을 본 적이 있을 것이다. 여기에는 응용 프로그램들을 내장시킬 수도 있고, 포함된 응용 프로그램을 손쉽게 시작할 수도 있고 메뉴 등을 삽입할 수도 잇다. 패널은 작은 프로그램으로 사용자 인터페이스로서의 역할을 하면서 손쉽게 데스크탑을 구성하고 편의성을 도모하고자 하는데 목적이 있다. 예를 들어 사운드 믹서와 같은 것을 예로 들 수 있는데 이는 언제든지 사용자가 볼륨 조절이라든가 상황에 맞는 설정을 할 수 있도록 애플릿으로 상주하게 된다. <리스트 1>의 일반 프로그램과 <리스트 2>의 애플릿 프로그램을 비교하면 다음과 같다. <리스트 1>와 <리스트 2>에 나타나 있는 #2와 #3은 보기만 해도 이해할 수 있듯이 GTK의 윈도우 위젯을 사용하는 대신 애플릿 컨테이너를 사용하였다. #1은 일단 등록하기 위해서는 패키지와 버전의 정보가 필요로 한다. argc, argv는 애플릿 등록 매카니즘에 따라 명령어줄 옵션을 해석한다. #include int main(int argc, char **argv) { /* ... we build the user interface ... */ gtk_init(&argc, &argv); /* #1 */ GtkWidget* window = gtk_window_new(GTK_WINDOW_TOPLEVEL); /* #2 */ gtk_window_set_title(GTK_WINDOW(window), PACKAGE); /* controls is the name of the container all our widgets are in */ gtk_container_add(GTK_CONTAINER(window), controls); /* #3 */ gtk_widget_show(window); /* Everything's ready to begin our main loop */ gtk_main(); /* #4 */ return 0; } 리스트 1 . 일반 응용 프로그램 소스 코드 #include int main(int argc, char **argv) { applet_widget_init(PACKAGE, VERSION, argc, argv, NULL, 0, NULL); /* #1 */ GtkWidget* applet = applet_widget_new(PACKAGE); /* #2 */ applet_widget_add(APPLET_WIDGET(applet), controls); /* #3 */ gtk_widget_show(applet); applet_widget_gtk_main(); /* #4 */ return 0; } 리스트 2 . 패널 프로그램 소스 코드 이상의 내용을 C++ 용 GTK--를 사용하고자 할 때는 다음과 같은 부분을 변경해 주어야 한다. controls.show_all(); applet_widget_add(APPLET_WIDGET(window), GTK_WIDGET(controls.gtkobj())); /* #3 */ 2. GNOME 애플리케이션 작성 기본 사항 GTK와 더불어 GNOME에는 프로그래밍을 하는데 중요한 몇 가지 라이브러리들이 있는데 이들을 사용하여 사용자는 보다 많은 시간을 절약하고 관련 응용 프로그램을 제작할 수 있다. 많은 코드들이 이미 씌여진 상태로 사용 가능하며, 다양한 위젯들이 사용가능하기 때문이다. 이러한 위젯들은 GNOME 라이브러리를 사용하는 모든 응용 프로그램들에 적용 가능하도록 구성되어 있으며 코드들 역시 여러 응용 프로그램들 사이에서 서로 메모리 사용을 나눌 수 있도록 최적화 되어 있다. 무엇보다도 가장 진보적인 GNOME 응용 프로그램 작성의 이점은 바로 만들고자 하는 응용 프로그램의 실제적인 기능에 초점이 맞춰진 GNOME 라이브러리들이 있다는 것이다. 그래서 개발자들은 자신들이 만든 프로그램의 인터페이스 설계나 디버깅에 시간을 들일 필요가 없다는 것이다. 그림 2 . GNOME 응용 프로그램의 기본 구조 <그림 2>는 GNOME의 응용 프로그램의 기본 구조를 나타내고 있으며 그림에서 알 수 있듯이 여러 가지의 라이브러리 구조를 가지고 있다. GNOME 라이브러리는 최상위의 라이브러리 레벨에 위치하며 이것은 헬퍼루틴(helper routines), 클래스, 특화된 위젯(Specialized widgets)들을 포함한다. 두 번째로 높은 레벨인 GTK는 GTK+ 라이브러리의 한 부분이다. 이 라이브러리는 버튼, 레이블, 입력박스와 같은 GUI 응용 프로그램을 설계하는데 사용되어질 것들을 제공한다. 대부분의 GUI는 GTK를 통하여 제공되며 또한 GNOME 라이브러리 안에서 상호간의 긴밀한 협력을 목적으로 매우 정교한 객체 시스템을 제공한다. 다음 레벨인 GDK는 X라이브러리들과 관련된 것들을 통합한 형태이며 프로그래머가 특별한 윈도우나 특별한 그리기를 필요로 할 때 관련된 라이브러리들을 제공한다. 가장 낮은 레벨의 GLib는 C를 위한 툴 형태의 라이브러리를 제공하며 ‘연결리스트(linked lists)', '재 조정 가능한 배열', '다양한 크기의 스트링', '해시', ’캐시' 등에 관련된 툴 기능을 포함하고 있다. GNOME 응용 프로그램을 제작하는데 있어서 가장 기본이 되며 가장 중요한 역할을 하는 GNOME 라이브러리에 대한 이해는 아무리 강조해도 지나치지 않을 것이다. 이 중요한 GNOME 라이브러리는 크게 세 부분으로 나뉘어져 있는데 이 기본적인 세 부분은 libgnome, libgnomeui, libgnorba이다. 첫째, libgnome은 개념적으로 GLib와 같은 기능 라이브러리로서 설정 내용을 읽어들이고 저장하며, 애플리케이션을 동작시키고, 각 애플리케이션들에 따른 MIME 타입의 개체를 인식하는 것과 같은 기능들을 제공한다. libgnomeui는 유저 인터페이스의 일부로써 응용 프로그램의 프레임워크(GnomeApp), 캔버스(GanomeCanvas)와 여타의 다른 다양하고 특화된 위젯들을 제공한다. 마지막으로 libgnorba는 GTK+/GNOME 응용 프로그램을 CORBA 기술과 융합하는 핵심적인 기능을 제공한다. 그러므로 여러분이 GNOME 응용 프로그램을 제작하고자 한다면 무엇보다도 중요한 것은 바로 GTK+를 얼마나 이해하고 잘 사용하느냐에 달려있다는 것을 알 수 있을 것이다. 그림 3 . GTK+로 제작된 응용프로그램 위젯 구조 예제 응용 프로그램을 제작하는데 늘 당면하게 되는 문제인 폰트 설정과 같은 비쥬얼 문제, 프로그램 윈도우의 크기 재설정시에 재반응 등과 같은 문제는 이들의 계층 구조와 관계가 있으며 버튼 클릭과 같은 액션을 특별한 동작으로 연결하기 위해서는 GTK+ 클래스에서 제공하는 특별한 신호를 사용하여 일련의 동작들이 문제없이 동작하도록 규정해야 할 것이다. 그러기 위해서는 위에서 보여진 <그림 3>의 구조를 잘 파악하고 자신이 지금 바인딩하고자 하는 일련의 동작이 어디에 위치해야만 하는지 고민해야할 것이다. 3. GNOME에서의 프로그래밍 가이드라인 마지막으로 GNOME 환경에서의 프로그래밍 가이드라인에 대해서 말하고자 한다. 솔직히 몇 줄의 소스 코드를 분석하고 몇 개의 팁을 알려주는 것만으로 독자에게 특별한 도움이 될 것으로 기대하지 않는다. 그렇다고 해서 소스의 분석이나 프로그래밍 팁이 전혀 쓸모없다는 것은 아니다. 그래서 범위를 좀 넓게 생각하여 GNOME 데스크탑 환경을 잘 이해하여 더욱 좋은 프로그래밍을 할 수 있도록 하자는 것이 필자의 생각이다. GTK+는 기본적인 GNOME의 인터페이스 라이브러리로서 소프트웨어 디자인에서 매우 중요하고 빠르게 성장해왔다. GTK+ 코드는 매우 간결하고, 일관성이 있으며, 유지하기가 용이하다. 이러한 소스코드는 작업시의 즐거움뿐 아니라 좋은 프로그래밍을 할 수 있도록 자극하며 좋은 연습 과정이 될 수 있다. 하지만 이러한 좋은 프로그래밍 습관을 갖기 위해서는 무엇보다도 지향하는 환경을 잘 이해하고 있어야 한다. GNOME은 매우 위대한 자유 소프트웨어의 산물이고 여러 가지 규모의 소프트웨어 패키지들이 종합되어 있다. 이들은 모두 지원자들의 오랜 노력의 산물이며 이들은 모두 GNOME 프로젝트를 통하여 개발자들이 서로 협력하고 코드를 공유하는 과정을 통하였다. 대부분이 지원자들의 여가시간이나 취미로 프로젝트에 참여하기 때문에 서로의 부분에 대해서 이해적인 관계가 전혀 없다. 이는 오직 함께 진행하는 프로젝트의 소스코드로만 서로의 의견을 주고 받을 수 있는데 이럴 때 바로 프로그래밍 스타일이 중요하게 나타난다. <박스> GNOME 프로젝트에 참가하게 된다면 꼭 갖추어야 할 프로그래밍 스타일 ◆ 간결함 (Cleanliness) 일단 간결하고 군더더기가 없는 소스 코드는 읽기가 좋다. 읽기 좋다는 것은 이해하기 좋은 것으로, 여러 명이 함께 프로젝트를 진행할 때 이보다 좋은 프로그래밍 습관은 없을 것이다. ◆ 일관성 (Consistency) 일관성은 프로그램이 어떻게 동작하는지 이해하게 만드는 것으로 일관성 있는 코드를 작성 때에 수정과 관리가 용이해진다. ◆ 확장성 (Extensibility) 매우 특별하고 복잡한 코드보다는 일반적인 목적의 코드는 재사용과 수정이 용이해야만 한다. 개발자가 새로운 기능을 추가하고 싶다거나 기능상의 수정을 하고 싶다면 이것이 가능하도록 최초의 소스가 확장성을 고려하여 작성되어야만 한다. ◆ 정확성 (Correctness) 공동 작업자들이 버그에 보다 많은 시간을 들이지 않도록 자신이 작성한 부분에 대해서는 항상 정확성을 유지하고 협력 개발자들이 새로운 기능의 추가에 더욱 시간을 할애하도록 해주어야 한다. 사용자의 입장에서도 제대로 동작하지 않는 프로그램은 달갑지 않을 것이다. Part 3. 리눅스 데스크탑 원조 KDE로 개발하기 오픈소스 진영의 양대 데스크탑 환경이라고 할 수 있는 KDE와 GNOME이 있는데 둘 중에서도 먼저 프로젝트가 시작되어 많은 유닉스/리눅스 시스템의 데스크탑 환경에 많은 영향을 준 KDE의 위대함은 필자가 재차 설명하지 않아도 알고 있을 것이라 생각한다. KDE는 최초의 상용 유닉스인 CDE처럼 편리하고 조화로운 데스크탑 환경을 목표로 시작되었다. 기반이 되는 Qt 라이브러리가 라이센스 정책이 자유롭지 못하여 상당부분 자유진영으로부터 배척당했지만 그후 라이센스 정책이 바뀌면서 리눅스 배포판에도 적극적으로 참여하게 되었고 무엇보다도 KDE는 리눅스 뿐만이 아닌 최초의 철학을 그대로 실천하여 많은 유닉스 상에서도 무리없이 동작하는 훌륭한 환경을 제공하고 있다. 유닉스, 리눅스 모두 같은 환경에서 작업할 수 있다면 바로 KDE 추구해온 노력의 결과일 것이다. 프로그램세계 1월 호에서도 KDE 2.0에 대해서 소개한 적이 있는데 KDE는 크게 ‘개인용 데스크탑 환경 (Personal Desktop Environment)와 ’개발 환경(Development Envrionment)'으로 나눌 수 있다. 그 중에서도 데스크탑 환경의 개발에 초점을 맞추고 있으므로 개발환경에 관하여 집중적으로 이야기 하도록 하자. 1. 리눅스 데스크탑의 원조, KDE의 개발 KDE는 현재 GPL을 따르는 Qt 툴킷을 사용하여 개발하고 있다. 주된 컴포넌트로는 파일 매니저인 kfm, 윈도우 매니저인 kwm, 그리고 패널인 kpanel이 있다. 그 밖에도 많은 기능성 프로그램들이 포함되어 있고 대부분 기본 KDE 패키지에 포함되어 있다. GNOME이 C위주의 프로그래밍 기법으로 개발되어 왔다면 KDE 시작부터 C++ 기반의 개발환경에서 개발되어져 왔다. GNOME이 여러 가지 언어를 혼용하여 개발할 수 있도록 환경을 제공했던 것 과는 달리 KDE 현재 가능한 바인딩 언어는 파이썬(Python, PYKDE)뿐이다. 이는 서로 장단점이 있다. KDE 무엇보다도 신속하면서도 질이 높은 방향성을 제시하고 있기 때문이다. 주된 라이브러리와 툴키트를 살펴보면 다음과 같다. * libkdecore : KApplication, KConfig, KProcess * libkdeui widget : KHTML widget, KEdit, KFontDialog, KToolBar * libkio class : KIO::NetAccess, KFileDialog, KSpell 위의 세가지 라이브러리에 대하여 알아보면 libkdecore는 애플리케이션의 정의, 설정, 프로세스 제어에 관련된 핵심 라이브러리이다. libkdeui widget는 툴바, 다이얼로그 박스 등을 만드는 KDE 사용자 인터페이스 위젯 라이브러리이다. 그리고 libkio class는 애플리케이션 간의 통신에 필수적인 라이브러리이다. KDE의 응용 프로그램 개발에 참여하고 싶다면 konold@kde.org에 문의하여 필자의 e메일(coca@kde.org)과 같은 KDE e메일을 얻는 것도 좋을 것이다. 각 프로젝트에 따른 메일링 리스트는 http://lists.kde.org에서 자신이 참여하고 싶은 프로젝트의 메일링에 가입하고 현재 진행되지 않는 것이 있고 그것을 개발하고 싶다면 각 프로젝트에 맞는 책임자와 상의해야 한다. KDE 응용 프로그램을 개발하기 위해서는 C++ 프로그래밍 언어에 어느 정도의 이해를 가지고 있어야 한다. 또한 KDE에 대한 기본적인 이해와 자신이 개발하고자 하는 응용 프로그램이 주된 KDE 데스크탑과의 조화에 대한 나름대로의 의미를 판단할 줄 알아야 한다. 또한 KDE는 보다 빠른 응용 프로그램 작성을 고무하기 위해 KDevelop이라는 개발툴을 제공한다. 처음엔 조금 복잡하더라도 이런 툴을 사용한다면 훨씬 빨리 원하는 결과물을 얻을 수 있을 것이다. 물론 기반이 되는 Qt 라이브러리에 대한 이해와 온라인 레퍼런스는 한번쯤 읽어보고 언제든지 찾을 수 있도록 준비되어야 한다. 완전히 초보개발자라면 다음의 사항들에 대해 자신이 어느 정도를 갖추고 있는지 판단해 보는 것이 좋다. * 기본 응용 프로그램의 클래스(QApplication) * 그래픽 유저 인터페이스를 위한 위젯 라이브러리(widget library) * 그래픽, 파일, 데이터의 운용을 위한 부가적인 헬퍼(helper) 클래스에 대한 이해 * 객체 통신을 위한 신호슬롯 메카니즘 (signal-slot mechanism) * 이벤트 루프(loop)와 가상법(virtual methods)을 통한 이벤트 조정 시작에 앞서 모든 것을 알 수는 없지만 위의 내용을 알고 있다면 후에 프로그래밍 하는데 무척 많은 도움이 될 것이다. 특히 KDE의 응용 프로그램을 개발하고자 한다면 Qt에 대한 철저한 이해가 무엇보다도 우선이다. 이 글에서는 Qt에 대해서 특별히 언급하지는 않겠지만 관심있는 독자들은 먼저 Qt 프로그래밍 스타일을 배우길 권한다. 2. KDE 개발 환경 먼저 KDE 응용 프로그램에 앞서 KDE가 갖는 개발 환경을 살펴보고 이제 맞는 적절한 프로그램을 작성하므로써 KDE가 가지고 있는 특징을 최대한 응용 프로그램에 반영하는 것이 좋은 프로그램을 만들 수 있는 방법일 것이다. 2.1 KDE 프로세스 통신 프로토콜 DCOP GNOME이 ORBit 즉, CORBA 기반의 애플리케이션 수준 통신을 기반으로 하는데 반해 KDE는 DCOP(Desktop COmmunications Protocol)라는 것을 자체 개발하여 사용하고 있다. 몇 년 전에 KDE 역시 CORBA를 기반으로 하려고 노력한 적이 있었지만 KDE 코어 개발팀에서 최종적으로 CORBA는 너무 무겁다고 판단하여 그것을 대체할만한 방법을 찾게 되었다. 프로세스들 간의 통신은 데스크탑 환경에서 매우 중요하며 어떻게 유기적으로 데스크탑 환경 내의 프로세스들이 동작하느냐에 따라 빠르고 강력한 데스크탑 환경을 끌어 낼 수 있기 때문이다. DCOP는 KDE가 CORBA로부터 사용하고자 하는 부분만을 특화시켜서 개발한 특수한 목적의 프로토콜이며 간단한 IPC/RPC 메커니즘을 사용하고 있다. 부분적으로 TCP/IP 소켓들도 지원한다. DCOP을 사용하는 모든 응용 프로그램들은 스스로 클라이언트가 되며, DCOP 서버를 통해 서로 통신하게 된다. DCOP 서버는 트래픽을 조정하고, 메시지와 콜을 목적지까지 발송한다. 이를 통하여 모든 클라이언트들이 연결되는 것이다. DCOP에서 운용되는 액션은 'send and forget'과 'calls'의 두 가지 뿐이다. 어떤 데이터든지 Qt 클래스에 포함되어 있는 QDataStream을 통하여 연속한 형태로 보내진다. 간단히 DCOP를 사용하여 애플리케이션 수준에서 어떻게 통신이 이루어지는지 살펴보도록 하자. ◆ 연결 만들기 K애플리케이션은 'KApplication::dcopClient()'를 사용하여 DCOPClient에게 포인터를 넘긴다. 이것은 'KApplication::name()'을 반환하게 되고 사실 DCOP 통신의 시작은 'DCOPClient:::attach()'로 시작하게 된다. DCOP 서버와 연결을 만들지 못하거나 여타의 다른 에러가 생기면 'false'를 반환하게 된다. 'false'가 리턴되면 적당한 에러 메시지 박스가 보여지게 되고 만약 연결되었다면 'appld'를 사용하여 연결된 프로그램에 등록하도록 하는데 이때 'DCOPClient::registerAs(const QCString &name)'이 사용된다. ◆ 리모트 프로그램에 데이터 보내기 앞서서 설명 했듯이 DCOP로 가능한 두 가지 액션은 ‘send' 또는 ’call' 이다. 이것을 사용하기 위해서는 세 가지의 인증 절차를 필요로 하게 되는데 ‘application identifier', 'remote object', 'remote function'이 바로 그것이다. QByteArray data, replyData; QCString replyType; QDataStream arg(data, IO_WriteOnly); arg << 5; if (!client->call("someAppId", "fooObject/barObject", "doIt(int)", data, replyType, replyData)) qDebug("there was some error using DCOP."); else { QDataStream reply(replyData, IO_ReadOnly); if (replyType == "QString") { QString result; reply >> result; print("the result is: %s",result.latin1()); } else qDebug("doIt returned an unexpected type of reply!"); } 리스트 3 . 원격 프로그램에 데이터를 돌려 받는 코드 리모트 커넥션으로부터 데이터를 되돌려 받기 위해서는 반드시 call()를 사용하여야 한다. 데이터 파라미터는 'reply'로 사용하는 것이 가능하다. 실제적인 call()의 반환값은 여전히 DCOP 통신이 성공했는지 안했는지의 여부를 나타낸다. ◆ DCOP를 통하여 데이터 받기 현재로선 DCOP를 통하여 데이터를 받는 실제적인 길은 DCOPObject 클래스처럼 QWidget 하위클래스나 QObject 등을 사용하여 상속받는 일반적인 클래스로부터 상속을 증가하는 것이다. bool BarObject::process(const QCString &fun, const QByteArray &data, QCString &replyType, QByteArray &replyData) { if (fun == "doIt(int)") { QDataStream arg(data, IO_ReadOnly); int i; // parameter arg >> i; QString result = self->doIt (i); QDataStream reply(replyData, IO_WriteOnly); reply << result; replyType = "QString"; return true; } else { qDebug("unknown function call to BarObject::process()"); return false; } } 리스트 4 . DCOP로 데이터를 받고 디버그 하는 소스 코드 DCOPObject는 DCOPObject::process()라는 매우 중요한 한가지 방법을 제공한다. 이것은 순수한 가상 방법으로서 반드시 DCOP 메시지를 수신하기 위해서 실행하여야 한다. 이것은 함수의 신호를 받아 QByteArray 파라미터를 수신할 수 있도록 해준다. DCOP는 KDE의 응용 프로그램을 이해하고 새롭게 작성하는데 있어서 매우 중요한 개념이며 KDE 데스크탑 환경에서의 유기적인 프로그램의 동작을 필요로 한다면 반드시 이 개념을 이해하고 사용하도록 해야한다. 2.2 KDE 응용 프로그램 개발용 컴포넌트 아키텍처 응용 프로그램을 개발하는데 컴포넌트 아키텍처에 대한 이해가 필요한 것은 당연하다. 컴포넌트 구성으로 보다 빠르고 정확하게 원하는 프로그램을 개발할 수 있기 때문이다. KDE 개발 환경에는 크게 세가지 요소의 컴포넌트가 사용되었는데 KDE 응용프로그램을 개발하고자 한다면 이 세가지 컴포넌트 요소들을 이해하고 사용하여 보다 충실한 프로그램을 개발하는데 도움이 될 것이다. 2.2.1 KDE 표준 객체를 위한 프레임워크 KParts Kparts의 QWidget과 KTMainWindow같은 것들은 KDE/Qt의 표준적인 객체들을 위한 프레임워크이다. 매우 간단한 클래스들의 집합으로 이루어져 있으며 part, plugin, mainwindow와 part manager로 이루어져있다. 각 부분들은 다음과 같이 구성되어 있다. ◆ part : 앞서 설명한 것과 같이 KDE 컴포넌트의 이름이다. 새로운 part를 정의하기 위해서는 물론 위젯을 제공해야 하고 또한 part의 기능에 접근할 수 있도록 액션을 지정해 주어야 한다. XML이 그러한 사용자 인터페이스에 어떻게 접근할지 레이아웃을 지정한다. ◆ plugin : 기능성의 조그만 부분으로서 내장된 위젯에 의해 실행되진 않지만 KSpread의 계산기처럼 응용프로그램의 사용자 인터페이스로서의 약간의 액션을 정의한다. 그러나 이것은 그래픽으로 표현되어 질 수 있으며 다이얼로그 박스나 각개의 윈도우로써 팝업되어 질 수 있다. ◆ mainwindow : XML로 정의되고 내장된 부분으로 정의되어 질 수 있는 KTMainWindow는 매우 특별한 것이다. 사용자 인터페이스를 XML을 해석하여 수행되도록 하기 위해서 XML을 사용한다. ◆ part manager : 보다 추상적인 객체로서 그것의 임무는 활성화와 비활성화 부분을 제어하기 위한 것이다. 물론 한 부분으로서의 수행보다는 메인 윈도우에 내장된 형태로서 수행될 때 사용성이 높다. 2.2.2 시스템 트레이, 도킹 트레이 윈도우란 일반적으로 24x24 크기의 조그마한 윈도우로서 데스크탑 패널의 시스템 트레이에 도킹되는 것을 말한다. 이것은 보통 아이콘이나 애니메이션 되는 아이콘으로 보여지게 된다. 아이콘은 태스크바 버튼과 같은 비슷한 기능을 하며 보다 적은 스크린 공간을 차지한다. 그림 4 . CD 플레이어와 노트 프로그램이 패널의 시스템 트레이에 도킹된 모습 사용자가 아이콘 위에서 마우스 버튼의 왼쪽 클릭을 하게 되면 메인 윈도우가 나타나거나 올라오게 되고 활성화 된다. 오른쪽 마우스 버튼은 팝업 메뉴를 보여주며 '아이콘화', '끝내기'와 같은 특별한 명령어를 수행할 수가 있다. 사용자와 상호작용이 없이도 가끔 사용되는 데몬과 같은 프로그램은 시스템 트레이에 아이콘화 시킴으로써 많은 이득을 얻을 수 있다. kpp, kisdn, kscd, kmix, knotes 같은 프로그램들이 이를 잘 활용하는 예라고 할 수 있다. 시스템 트레이용 애플리케이션을 작성할 때 주의를 기울여야 할 부분에 대해서 알아보기로 하자. 자신이 작성하는 프로그램이 시스템 트레이용으로 사용하길 원한다면 다음과 같은 특별한 등록정보를 애플리케이션에 이식해야 한다. _KDE_NET_SYSTEM_TRAY_WINDOW_FOR 윈도우 매니저는 위와 같은 부분을 트레이 윈도우로 다룬다는 것을 인식하게 된다. 등록정보의 값은 트레이 윈도우의 메인 윈도우에 더 상세히 정의 되어야 한다. /** Prototypes: Display dpy; Window trayWin, forWin; */ Atom net_kde_system_tray_window_for = XInternAtom( dpy, "_KDE_NET_SYSTEM_TRAY_WINDOW_FOR", False); XChangeProperty( dpy, trayWin, net_kde_system_tray_window_for, XA_WINDOW, 32, PropModeReplace, (unsigned char *)&forWin, 1); 리스트 5 . 윈도우의 트레이 윈도우를 정의하는 부분 응용 프로그램의 윈도우는 XMapWindow()로 매핑되며, 가능하다면 윈도우는 시스템 트레이로 도킹될 것이다. 도킹을 해제하기 위해서는 XUnmapWindow 또는 XDesttoryWindow()를 사용하면 된다. 2.2.3 응용 프로그램 작성을 돕기 위한 KDE의 자바 지원 KDE 2.0부터는 응용 프로그램의 작성을 돕기 위하여 각 애플리케이션에 자바 애플릿의 지원과 추가를 보다 손쉽게 하였다. kdejava라는 고급 수준의 라이브러리 API를 제공하며 만약 보통의 QWidget를 사용한다면 자바 애플릿이 동작하도록 하였다. KDE의 자바에 대한 지원은 두 부분으로 나눌 수 있는데, 첫째는 자바 애플릿이 동작할 수 있도록 해주는 순수한 자바 서버 환경을 제공하는 것이고, 둘째는 응용 프로그램 내에 애플릿 윈도우를 내장하여 조절하도록 KDE 라이브러리를 제공하는 방법이다. C++과 자바는 표준화된 유닉스 파이프를 통하여 간단한 텍스트 기반의 프로토콜을 사용하여 통신하게 된다. 간단한 예를 살펴보면 <리스트 6>과 같다. 이러한 방식을 사용하면 손쉽게 자바를 KDE 응용 프로그램에서 사용할 수 있게 된다. #include #include #include int main(int argc, char **argv) { KApplication app( argc, argv ); QString a,b,c,d,e,f; // 애플릿 이름t a = "fred"; // 사용되어질 클래스 이름 b = "Lake.class"; // 기본적으로 사용될 URL // 파일을 다음과 같이도 사용이 가능하다. "file:/dos/pcplus/java/lake/Lake.html" c = "file:/dos/pcplus/java/lake/"; // 애플릿 위젯을 만든다. 여기서는 일반적인 환경과 서버를 포함시킨다. // 반드시 환경이 다른 하나를 또 하나 설정한다. // 부모 QWidget을 설정하고 애플릿 위젯을 예제의 탑 레벨로 설정한다. KJavaAppletWidget *applet = new KJavaAppletWidget(); CHECK_PTR( applet ); // show() 콜을 사용하기 전에 다음 부분을 설정한다. applet->setAppletName( a ); applet->setAppletClass( b ); applet->setBaseURL( c ); // 본 예제에서는 이미지를 파라미터로 설정한다. d = "image"; e = "arch.jpg"; applet->setParameter( d, e ); // 일반적인 위젯을 보여준다. applet->show(); // 이벤트 루프를 시작한다. app.exec(); } 리스트 6 . 간단한 텍스트 기반의 프로토콜을 통한 KDE에서 자바 사용예 <그림 5>는 중요한 클래스와 KDE 자바들 간의 연관관계를 보여주는 것이다. libkdejava에 있는 클래스들은 모두 C++ 클래스들이며 시스템의 나머지 부분들은 자바로 씌여져 있다. KSAS 서버를 위한 JVM보다는 하위의 의존성을 가지며 이것이 KDE Java 환경이 다른 시스템에 자바를 지원하도록 사용되는 부분이다. 그림 5 . KDE의 자바 아키텍처 다음에 설명되는 것들은 libkdejava 안에 있는 중요한 클래스들의 개략적인 설명이다. 보다 자세한 설명이나 정의에 대해서는 kdoc에서 제공하는 문서를 참고하기 바란다. ◆ KJavaAppletWidget : KDE 응용 프로그램 GUI속에 애플릿 윈도우들을 통합하는 책임성이 높은 클래스이다. 간단한 예로, 이것은 단순한 클래스이며 매우 직접적인 API를 제공한다. ◆ KJavaApplet : 애플릿 운영을 책임지는 클래스다. 이것은 애플릿의 다운로드, 시작과 중지를 관할한다. ◆ KJavaAppletContext : 애플릿이 존재하는 환경이다. 애플릿은 같은 문맥 안에서 서로 통신할 수 있으며 서로 다른 문맥에서는 그럴 수가 없다. 웹 브라우저 상에서는 모든 애플릿들이 한 문맥에 존재하게 되고 하나의 프레임 안에서 동작하게 된다. 문맥은 또한 내장된 애플릿과 응용 프로그램과의 사이에 통신도 가능하다. ◆ KJavaAppletServer : KJAS 서버에 접근할 수 있는 권한을 갖는 클래스다. 보통, 개발하고자 하는 코드가 기본 서버로 자동 접근하도록 해놓았다면 이 클래스를 무시해도 좋다. ◆ KJavaProcess : JVM(Java Virtual Machine)의 실행을 위해서 보다 높은 수준은 API를 제공하는 KProcess를 위한 랩퍼(wrapper)이다. KDE-java는 여전히 개발중이며 여러 가지 기능들이 현재 테스트되며 개발되고 있다. 앞으로 가능한 기능들에 대하여 잠깐 언급하자면 다음과 같다. QtAWT라는 AWT 포트를 사용하는 Qt 툴킷이 개발될 예정이다. 현재는 이벤트 발송원(dispatcher)이 없는데 이를 추가할 예정이며 캔버스(Canvas)와 같은 중요한 클래스들에 대한 지원이 전무한 상태인데 적어도 절반 정도의 기능은 지원될 예정이다. 보다 자세한 내용에 대해서는 KDE-자바 CVS(Concurrent Version System) 모듈과 관련된 문서를 참고하기 바란다. 2.3 KDE 사용자 인터페이스 스타일 어떤 응용 프로로그램이든지 자체만의 사용자 인터페이스를 갖는다. 유닉스 시절에는 이러한 사용자 인터페이스가 별로 중요한 부분을 차지하지 못했지만 사실 유닉스에도 CDE와 같은 통합적이고 일관성 있는 데스크탑 환경이 있었던 것은 사실이다. 하지만 이러한 데스크탑 환경은 개인용 컴퓨터의 사용이 급증하면서 더욱 중요하게 생각되었고 MacOS, 넥스트스텝, MS 윈도우 등이 급성장 하면서 이와 함께 GUI는 더욱 중요하게 자리매김하게 되었고 그 철학도 더욱 깊어지게 되었다. KDE용 데스크탑 응용 프로그램을 작성할 계획이라면 이러한 GUI에 담긴 KDE만의 스타일이 있음을 간과해서는 안될 것이다. 특히 세련된 응용 프로그램들은 여러가지의 메인 윈도우와 매우 유사한 레이아웃을 갖는 특징이 있다. 조작하고 조정하며 문서를 보여주는 기능을 가지고 있다. 제어를 위한 메뉴로의 접근은 ‘메뉴’에 의해 조작되며, 툴바에 조그만 아이콘으로도 가능하다. 일반적으로 무엇이 진행되는지 등의 상태에 관한 것은 상태바에 보여진다. 사실 소프트웨어는 의도하는 데로 동작만 하면 된다고 생각하는 것은 초보 개발자의 의견이 되어버릴 것이다. 정작 중요한 것은 사용자에게 어떻게 보여지고 같은 목적의 프로그램을 어떻게 편하게 사용할 수 있는가가 더욱 중요하게 여겨지는 시대이기 때문이다. 이러한 사용자 인터페이스 모델은 매우 유행하는 형태이며 문서 형태의 모든 것을 보여주는 유일한 방법으로까지 인식되고 있다. 소프트웨어가 사용자 친화적으로 인식되기까지는 몇가지 조건들을 만족시켜야만 한다. 현대에 개발되는 소프트웨어들의 80~90 퍼센트가 이를 충족시키지 못하고 있다. 소프트웨어가 사용자 친화적이 되기 위해서는 다음과 같은 조건들을 만족시켜야만 한다. ◆ 적당한 기능성(task suitable) : 너무 많은 기능들을 포함하는 것은 사용자에게 오히려 난해하게 할 수도 있고 거부감이 들 수 있다. ◆ 이해력 도모(understandable) : 만약 사용자가 해당 소프트웨어를 처음 사용하는 것이라고 가정하면 사용자의 입장에서는 어떻게 동작하는지 이해하는 것이 가장 중요한 문제일 것이다. ◆ 손쉬운 조작(navigable) : 사용자는 현재 소프트웨어의 어느 부분을 사용중인지 즉각 파악할 수 있어야 하며 소프트웨어 내에서의 사용자 위치변화를 제약해서는 안된다. ◆ 실수에 대한 아량(tolerant of mistakes) : 사용자는 사람이므로 실수도 할 수 있다. 소프트웨어는 이러한 실수에 대해 언제든지 원상태로 복구하는 기능을 포함하고 있어야 한다. ◆ 기대상응성(conformable to expectations) : 응용 프로그램은 일관성을 유지해야 한다. ◆ 반응 풍부성(feedback-rich) : 응용 프로그램은 즉각적인 반응성을 사용자에게 보장하여야 한다. 사용자의 관점과 개발자의 관점은 얼마나 다른 것일까? 그것을 이해하여 보다 개발자들은 사용자에게 충실한 사용자 인터페이스를 제공할 수 있을 것이다. 이 문제를 두 가지의 적절한 예를 들어 관점을 파악해 보고 그 보안책을 생각해 보도록 하자. 2.3.1 종료 이야기(story of quit) 응용 프로그램이란 단어는 종종 혼란을 초래하기도 한다. 사용자에게는 태스크바에 있는 각 엔트리들이 응용 프로그램을 실행하는 것이라 생각되고 개발자에게는 유닉스에 프로세스가 응용 프로그램을 실행하는 것이라 여겨진다. 왜냐하면 사용자들은 세부적인 실행에는 관심이 없으나 유닉스 프로세서는 프로그래머에게는 적절한 수를 부여해야 하는 필수적인 사항이기 때문이다. 사용자 인터페이스는 이러한 유닉스 프로세스라는 단어가 프로그램이라는 것을 사용자가 지각하기 위해 표현되어야 한다. 이러한 사용자 인터페이스 관점에서 ‘종료’라는 옵션은 유닉스 프로세스에 의해 동작하는 모든 프로그램의 종료를 뜻한다. 하지만 실제 'quit'가 뜻하는 것은 단지 사용자가 선택한 하나의 응용 프로그램의 종료만을 의미한다. 다른 프로그램들은 영향을 받지 않고 그대로 남아서 동작하며 유닉스 프로세스를 공유하기도 하고 그렇지 않기도 하다. 2.3.2 용어의 정의(definition of terms) 다음은 사용자에게 용어가 인식되는 과정 즉, 사용자 인터페이스가 사용자에게 인식되는 내용을 나타낸 것이다. * UNIX-process : 리소스를 소비한다. ps나 top 등과 같은 프로그램으로 참고할 수 있다. 크래시(crash)가 생길 수 있다. * Application : 사용중인 프로그램은 메뉴바와 툴바를 갖고 있는 일종의 윈도우 형태로 보인다. 현재 사용중인 프로그램의 상태는 상태바에 표시된다. 응용 프로그램은 아이콘 클릭에 의해 동작되어진다. * Document : 정보를 내포한다. 애플리케이션 내에서 동작될 수 있다. 열려있는 문서만이 수정할 수 있다 * Window : 프로그램의 일부이며 문서, 정보를 보여주고 사용자에게 툴을 제공한다. 사용자는 위에 설명한 바와 같은 이해를 하고 있을 뿐이며 유닉스 프로세스 한 개가 한 개의 프로그램과만 상관이 있고 하나의 윈도우가 하나의 문서만을 포함한다면 가장 간단한 이해가 될 것이다. 몇 개의 유닉스 프로세스가 몇 개의 응용프로그램을 실행하고 있는지 주소지를 정하는 것 등은 개발자의 기술적인 문제일 뿐이다. 이렇듯 사용자에게는 보다 편리하고 쉬운 사용만이 중요한 문제일뿐 그 이면의 문제들은 모두 개발자들의 몫이며 이를 사용자에게 사용자 인터페이스를 통하여 잘 전달해야 하는 것이다. 필자는 가끔 리눅스 사용자들로부터 KDE는 너무 MS 윈도우와 비슷해서 거부감이 생긴다는 이야기를 듣는다. 보기에 비슷한 것은 사실이다. 하지만 이러한 사용자 인터페이스는 어떤 형태의 인터페이스 보다도 인간을 생각하는 HCI(Human Computer Interface) 철학으로부터 나온 가장 훌륭한 인터페이스이기 때문에 이를 따르는 것이다. 이것은 마이크로소프트 사가 생각해낸 것만이 아닌 어떤 데스크탑 환경이든지 적용 가능하고 사용시에 그 기능을 다할 수 있는 형태가 그것이기 때문이다. 각 구성요소의 인터페이스 설정에 대하여 설명하기엔 지면이 너무 부족하므로 예를 들어 전체적인 설명을 하는 것으로 인터페이스에 관한 이해는 마치기로 하자. 그림 6 . Document-Centric 사용자 인터페이스 <그림 6>은 문서를 보여주는 응용 프로그램의 화면이다. 메뉴의 순서를 살펴보고 툴바의 디자인, 상태바 등의 상태를 보자. 모든 기능들이 컨텐트 부분을 중심으로 배치되어 있고 그 순서도 사용자에게 친숙할 수 있도록 설계되어 있는 예제이다. 그림 7 . 윈도우 95 파일 찾기 일부 응용 프로그램들, 특히 조그만 유틸리티 등은 도큐멘트 중심적인 형태의 사용자 인터페이스 패러다임을 갖지 않는 것들도 있다. <그림 7>의 예제는 단순히 다이얼로그 박스로서 사용자 인터페이스를 디자인한 것으로는 매우 훌륭하다. 그러나 두 가지의 패러다임을 하나의 윈도우에 묶으려는 무리한 시도로 사용자를 혼란하게 하고 보기 좋은 사용자 인터페이스가 되지 못하였다. 사용자 인터페이스의 최고의 규칙은 다이얼로그 박스 패러다임을 도큐맨트 중심의 사용자 인터페이스와 동시에 사용하지 말라는 것이다. 다이얼로그 박스는 다이얼로그 박스 형태의 간단한 형태로, 도큐멘트 중심적인 사용자 인터페이스는 언제나 도큐멘트 중심적인 사용자 인터페이스 만을 갖는 형태로 설계해야 한다는 것이다. 이것은 예제에서도 잘 나타나 있듯이 다이얼로그 박스가 메뉴를 가지고 있다는 문제를 지적하는 것이다. 어떠한 경우에도 다이얼로그 박스는 단순히 입력 가능한 텍스트 부분이나 간단한 클릭으로 모든 것이 끝나야 한다. 복잡한 메뉴를 다이얼로그 박스가 갖는 것은 사용자에겐 최악이기 때문이다. 3. KDE 개발 도구 KDE에는 몇 가지 IDE(Integrated Development Environment) 도구가 있다. 이것들은 보다 쉽고 빠르게 애플리케이션을 개발할 수 있도록 도와주며 여러 가지 기본적인 컴포넌트를 수반하므로 개발의 통일적인 모습도 가져올 수 있다. 3.1 Kdevelop 구성 요소 응용 애플리케이션의 개발에 필수적인 IDE 가운데 KDE에서는 특히 KDevelop를 주목할 수 있는데 초기부터 상당히 각광 받아오고 있으며 현재도 가장 많이 애용되는 툴이다. 간단히 사용법을 살펴보고 이면에 깔린 개발철학에 대해 살펴보도록 하자. ◆ 프로젝트 관리자(Project Management) 프로젝트 파일은 개발하고자 하는 프로젝트의 모든 정보를 수록하고 있으며, 개별적으로 새롭게 추가하고 변화될 수 있다. 생성된 프로젝트들은 autoconf/automake-compatible 이어야 한다. ◆ 다이얼로그 편집기(Dialog Editor) 내장된 다이얼로그 편집기는 개발자고 보다 쉽게 GUI를 생성할 수 있도록 제공된다. 개발자는 KDevelop에서 다이얼로그 소스코드를 수정하고 모든 다이얼로그 기능들을 사용할 수 있다. ◆ Classparser / Classtools classview는 현재 C++과 C문, 클래스의 집합, 클래스와 연산자의 구조, namespace 등을 완벽하게 분석할 수 있다. 또한 메소드와 속성들을 사용하여 classtools 다이얼로그를 추가할 수 있다. classtool이란 KDevelop의 새롭게 추가된 기능으로 상속성을 통하여 메소드를 사용할 수 있고 상속의 개념을 일반적인 형태로 보여주는 것이다. ◆ 통합 디버거(Integrated Debugger) KDevelop 1.1부터는 보다 완벽한 통합적 디버거를 제공하고 있는데 이는 개발자가 구분점과 프로그램의 변수 등을 소스 코드 수준에서 좀 더 쉽게 접근할 수 있도록 디버깅 환경을 제공하며 이런 것들은 KDevelop의 클래스뷰어를 사용하여 할 수 있다. ◆ 애플리케이션 위저드 KAppWizard는 새로운 프로그램을 제작하기 위해서 서로 다른 응용 가능한 프레임워크를 제공한다. 표준 KDE 응용 프로그램의 메뉴바, 툴바, 상태바 등과 미니 KDE 응용 프로그램의 빈 메인 윈도우, GNOME 응용 프로그램, Qt 기반의 응용 프로그램의 메뉴바, 툴바, 상태바 등이 사용 가능하며 C/C++ 터미널 타입의 응용 프로그램 등이 사용가능 하다. ◆ 사용자 편의를 위한 완벽한 종합문서 시스템 KDevelop는 완벽한 종합문서를 제공하며 다섯 개의 핸드북 형태로 이루어져 있다. 사용자 매뉴얼, 프로그래밍 핸드북, 튜토리얼 핸드북, KDE 라이브러리 레퍼런스 가이드들로 이루어져 있다. 모든 문서는 통합 문서 브라우저를 통하여 쉽게 읽어볼 수 있도록 되어 있고 Qt, KDE, C/C++ 문서들과의 조화도 이루어져 있다. ◆ 강력한 도움말 시스템 도움말 시스템은 짧은 메시지 형태의 도움말부터 상태바의 도움말 등 언제든지 개발자가 무엇을 필요로 하는지, 무엇을 하고 있는지를 바로 인식할 수 있다. KDevelop는 상당 부분 국제화되어 한글화도 개발자가 참여하여 진행되고 있다. 완벽하진 않지만 현재 한글 메시지로 보여지는 KDevelop를 사용할 수 있다. 3.2 위저드로 따라하는 Kdevloper KDevelop는 위저드를 제공하므로 순서에 따라서 자신이 생각하고자 하는 응용 프로그램을 제작해가면 된다. 어떤 프로그램을 만들지 먼저 결정하고 목적에 맞도록 설정 내용을 계획해 나가면 된다. 그림 8 . KDevelop 새로운 프로그램 생성하기 최근에 개발 방향의 큰 맥을 이루는 CVS(Current Version System)도 제공하므로 필요에 따라서 사용이 가능하다. 일반적인 설정이 끝나면 뼈대 형태의 소스 코드와 부수적으로 필요한 설정 및 makefile 등을 만들게 되는데 그 과정은 <그림 9>와 같다. 그림 9 . KDevelop 실제적인 프로젝트 생성 KDevelop는 몇 가지 다양한 구성 요소들을 포함하는데 이들은 다음과 같다. - Class와 소스 파일 브라우저 - 문맥 편집기 - 에러와 메시지를 출력하는 상태 윈도우 - 다이얼로그 에디터 - 통합 디버거 - 아이콘 에디터(Kiconedit)와 그림툴(Kpaint) 제공 이 밖에도 몇가지 IDE 툴들이 개발되고 있으며 KDevelop 역시 이들 중의 하나이고 현재도 활발하게 개발중이라는 것을 염두에 두자. 좋은 프로그래머라면 좋은 툴을 잘 사용할 줄 아는 것도 중요하며 개발이 빠르게 진행되는 만큼 최신 버전의 툴이 나왔는지를 잘 챙기도록 하자. 유닉스/리눅스 환경이 늘 그렇듯이 생각하는 것보다 훨씬 빠르게 모든 것이 진행된다. Gnome과 KDE 현재 프로젝트가 실행되는 구조는 조금씩 다를지 모르지만 전체적으로 서로의 장점을 흡수하고 단점은 과감하게 제거해 가는 것으로 상당부분 유사한 형태의 개발방향을 가지고 진행되고 있다. 한번쯤 양대 산맥인 이들 데스크탑 환경에서 응용 프로그램을 개발하고자 하는 개발자라면 지금까지 강조해 왔듯이 자신이 개발하고자 하는 응용 프로그램의 특성이나 활용도 중요하지만 해당 개발 환경의 데스크탑 특성을 잘 파악하여 이들과의 조화가 더 중요하다는 것을 인지했으면 한다. 다른 프로그램들과는 달리 데스크탑 환경의 프로그램들은 데스크탑과의 조화 정도에 따라서 개발된 프로그램이 빛을 발할 수 있기 때문이다. 또한 개발하고자 하는 환경을 잘 이해하는 것은 보다 쉽고, 보다 능률적으로 프로그램을 개발 할 수 있는 계기가 된다는 것도 명심하도록 하자. 아직 국내에서는 한글이 완벽히 지원되는 오피스 제품군이 없어서 리눅스가 데스크탑 환경으로 옮겨 가는데 애로사항이 있지만 올해 하반기 쯤이면 오피스와 게임들이 리눅스에서 자유롭게 한글 환경으로 구현될 것으로 기대된다. 벌써 1바이트 언어권인 서양에서는 리눅스가 학생들, 가정, 사무실을 가리지 않고 안정되고 기능성이 뛰어난 데스크탑 환경으로 인식되고 있고 그에 보답이라도 하듯이 GNOME과 KDE 같은 훌륭한 데스크탑 환경이 빠르게 발전해 가고 있다. 작은 프로그램이라도 개발해 보고자 하는 개발자가 있다면 이들 두 데스크탑 환경에서 개발해 보기를 권하면서 글을 마친다. 용어 설명 1. ORB (Object Request Broker) CORBA에서 ORB는 분산 객체 또는 컴포넌트에서 제공할 서비스에 대해, 클라이언트가 요구하는 시점부터 그 요구가 완료될 때까지 마치 "거래 중개인"처럼 동작하는 프로그램을 말한다. 네트웍 상의 ORB 지원이라는 것은, 서버가 분산 네트웍의 어디에 위치해 있는지 또는 정확히 어떤 서버의 인터페이스가 그런 일을 해주는지 전혀 알지 못하더라도, 클라이언트 프로그램이 원하는 서비스를 요구할 수 있다는 것을 의미한다. 이러한 것들을 찾고, 실행되면서 서로 인터페이스 정보를 교환하는 것은 컴포넌트들의 몫이다. 2. 래퍼 (wrapper) 정보기술에서 말하는, 래퍼는 주가 되는 데이터의 앞에서 틀을 잡는 데이터 또는 다른 프로그램이 성공적으로 실행되도록 설정하는 프로그램이다. 래퍼는 흔히 헤더와, 캡슐화된 데이터, 그리고 마지막에 따르는 트레일러로 구성된다. 데이터베이스 기술에서, 래퍼는 감추어진 데이터를 보거나 변경하기 위해 누가 액세스해야 할지를 결정하는데 사용될 수 있다 정리 ? 모상진 기자 msj@pserang.co.kr