1. GIMP Toolkit

GTK는 "GIMP Toolkit"의 약자이다.

• 그럼 GIMP는 무엇인가 리눅스에 관심이 있는 사람들이라면 한번쯤 들어봤을만한 이미지 편집기이다.
  바로 리눅스에서 사용할 수 있는 포토샵인것이다 두둥 (과장이 너무 심한건가 ㅡ.ㅡ).
  
  
• 본인도 별로 똑똑한 사람은 아니라 정확히는 모르고 GIMP를 만들기 위해 존재했었다는 얘기를 들었던 기억이 있다. 하지만 지금은 어떤가 GTK의 Tutorial을 보면 이런말이 가장 처음 적혀있다. "GTK (GIMP Toolkit) is a library for creating graphical user interfaces" 그렇다 GUI를 만들기 위한 툴킷 라이브러리이다.

2. GDK

GDK와 우리가 가장많이 할일은 그리기와 Event이다.

• "GDK 라이브러리는 GTK+ 위젯(어플리케이션)과 윈도우 시스템을 이어주는 추상적 계층을 제공해줍니다" 라고 '그놈 플랫폼 아키텍쳐 개관'란에 적혀있다. -_-; 그 이전은 본인도 안해봐서 잘은 모르겠으나 듣기로는 GTK와 GDK의 구분이 없었다고 한다. 하지만 지금은 GTK와 윈도우 시스템 사이에 GDK가 있다.
  
  실제로 X Window든 MS Windows든 플랫폼과의 대화는 GDK가 맡아서 하고 GTK는 GDK와 좀더 쉬운 대화를 하는것이다. Event나 Drawing처럼 X Window와 친하게 지내야하는 작업들을 GTK와 플랫폼(일반적으로 X Window) 사이에서 처리 해 주는것이다. 그뿐 아니라 Font, Style, 이미지제어등 GUI의 중요한 부분들을 담당하고 있다. GTK는 이러한 GDK를 이용하여 구조적인 부분을 담당한다.
  
  현재에는 Xlib을 래핑하고 있는것은 GDK이다. GTK는 그 GDK를 이용하는것이다.

3. GTK와 GDK 그리고 X Window

X Window에서의 GUI 구현을 편리하게하고 개발자를 여유롭게 만들어 준다.

• 우리가 X Window에서 GUI를 만들려면 어떻게 해야할까? 가장 기본적인 방법으로는 Xlib을 이용하여 개발하는것이 있다. 이것은 매우 귀찮고 어려울 수 있는 일이다.
  
  Xlib은 X Window에서 GUI 개발을 할 수 있는 가장 기본적인 라이브러리이다. 화면에 필요한 Widget들을 그려내고 GUI뿐만 아니라 X Window 시스템에 관련된 대부분의 기능을 지원하지만 원초적인 정보와 기능들만을 제공한다. 개발자가 Xlib을 사용하여 GUI부분을 구현한다면 직접 정보를 관리하고 안정성을 책임져야한다.
  
  
• GTK와 GDK를 사용한다면 Xlib이 해주는 역할외에도 GUI 프로그램을 제작함에 있어 필요한 대부분의 유형과 기능들을 미리 구현해 놓았다.
  
  GTK와 GDK도 X Windows에 실제로 무언가 표시할때나 X Window에 관련된 작업을 할때는 Xlib을 사용한다. 결국 Xlib을 사용하지만 이부분은 모두 GTK와 GDK가 내부적으로 처리해주는것이다. 그럼 GTK와 GDK는 그냥 Xlib 래핑 해 놓은것 아니냐라고 할 수 있겠으나 그렇다고 하기엔 GTK와 GDK는 너무나 많은 일을 대신해주고 많은 부분을 확장하여 미리 만들어 놓았다.
  
  버튼 하나만 보더라도 Xlib은 가장 기본적인 부분만 처리해 준다. 버튼을 화면에 그리고 이벤트 처리하고 정도이다. 하지만 GTK와 GDK는 버튼을 구현함에 있어 관련된 대부분의 필요한 정보들과 기능을 확장하여 미리 준비해놓았기 때문에 우리는 그것을 사용하면 된다. 또한 기본적인 Widget들을 GUI 프로그램에서 일반적으로 사용하는 다양한 형태로 변이시켜서 새롭게 구성해 놓았다.
  
  
• Xlib에 ToggleButton이 있는지 잘 모르겠으나 단순히 예를 하나 들어주겠다.
  
  만약 Xlib에는 그냥 버튼만 있다라고 하자. ToggleButton같은 경우 GUI 프로그램에서 많이 사용된다. Xlib을 사용할 경우 사용자는 기본으로 Button을 가지고 ToggleButton에 맞게 직접 구현해야한다. 버튼의 Toggle 상태를 저장, 상태에 따른 버튼 모양, 그에 따른 사용자 정의 이벤트등을 구현하는것은 매우 귀찮은 일이다.
  
  GTK와 GDK는 이러한일을 미리 해 놓은 것이다. (이는 Xlib에 ToggleButton이 없다라고 가정하고 예를 들었다. 본인도 Xlib의 구성요소가 무엇인지 잘 모른다).
  
  
• 물론 아주 특수한 상황까지 고려되어있는것은 아니지만 GUI 프로그램을 제작함에 있어 불편함을 느낄수 없을만큼 많이 준비되어있다.
  
  
• Xlib은 X Window 시스템을 제어하기 위한 가장 기본적인 라이브러리이고 GTK와 GDK는 GUI 프로그램 개발에 필요한 툴킷 라이브러리 인것이다. 개발자는 GUI를 구현하기 위해 엄청난 시간을 보내야하는것이 아니라 비지니스로직등의 구현에 더 많은 시간을 할애하고 GUI관련해서는 GTK와 GDK에 맡기면 되는것이다.

4. GTK를 사용한다면?

• 아래의 소스를 보자

<x11></x11>    #include <X11/Xlib.h>



    main()

    {

        Display *d ;

        Window   w, root ;



        d = XOpenDisplay(NULL) ;



        root = XDefaultRootWindow (d);

        w = XCreateSimpleWindow ( d, root, 50, 50, 400, 300,

                                  2, BlackPixel (d,0), WhitePixel(d,0) );

        XMapWindow (d, w);

        XFlush (d);



        getchar();



        XCloseDisplay (d);

    }

• 위의 내용이 Xlib을 이용해 창을 하나 띄우는 예제이다. (이만용님의 <X 윈도우 프로그래밍 기초과정>에서 발췌). 당장 창하나 띄우는 소스만 보더라도 왠지 복잡하다. 파라미터도 많고 알아야할것도 많다(앞으로도 누누히 말하겠지만 소스코드가 짧다고 그것이 전부는 아니다. 그 속에 담긴 뜻을 알아야한다).
  
  
• 그럼 이것을 GTK를 이용할때는 어떻게 하면 되는가 아래를 보자.

    #include <gtk/gtk.h>



    int main(int argc, char *argv[])

    {

        GtkWidget *window;



        gtk_init (&argc, &argv);



        window = gtk_window_new (GTK_WINDOW_TOPLEVEL);

        gtk_window_resize(GTK_WINDOW(window), 100, 100);

        gtk_widget_show (window);



        gtk_main ();

    }<gtk></gtk>

• 조금 더 간결하고 명확해졌으며 파라미터도 적다. 지금 당장은 큰 차이가 없어 보일지 모르겠으나 규모가 커지고 기능이 많아진다면 GTK의 편리함을 직접 느끼게 될 것이다. 단지 구현하는것이 편리해지고 소스코드의 길이가 짧아지는 차원 정도로만 본다면 큰 오산이다. 구현이 쉬워지는것은 분명하지만 짧아지고 길어지는건 경우에 따라 다르다.
  
  또 지금 보고 있는것이 전부가 아니다. Xlib을 이용한다면 직접 구현했어야할 Window와 관련된 정보와 기능을 상당히 많이 제공한다. Xlib을 이용하게 되면 이것저것 생각하고 유의해 주어야할것들을 GTK가 많이 처리해주어서 개발자를 덜 귀찮게 한다.
  
  
• Xlib을 이용해 개발을 하면 Xlib을 사용하면서 XWindow의 매우 코어한 부분들까지 생각해주어야 한다. 반드시 그래야만 문제없는 프로그램을 만들어 낼 수 있다. 하지만 GTK와 GDK를 이용하면 GTK에 대해서만 상세히 알면된다. 나머지는 GTK와 GDK에서 충분히 안정적이고 우수하며 편리하게 준비되어져있다. 그렇다고 함수 몇개만 알면 된다는건 아니다. gtk_widget_show를 했을때 GTK와 GDK에서 내부적으로 어떤일이 발생하는것일지에 대해 생각하며 개발을 해야한다.
  
  모든 프로그램 개발이 마찬가지다.
  훌륭한 프로그래머라면 그래야한다고 생각한다. (본인은 그렇지 않은듯하다. 조금도 훌륭하지 않은 프로그래머임이 분명하다 ㅡ.ㅡ)
  
  
• 또 하나의 장점이 있다면 다양한 환경에 적용할 수 있다는것이다. GTK와 GDK로 짠것은 일반적이라면 소스코드의 수정없이 여러 시스템 환경에서 사용할 수 있다. X Window에서도 사용할 수 있고 DirectFB에서도 사용할 수 있다. 심지어는 MS Window에서도 사용할 수 있겠으나 하지 말자. OS를 뛰어넘은 멀티플랫폼을 원한다면 그냥 자바로 하는게 좋겠다.
  
  
• 자 그럼 GTK와 GDK라는 놈이 X Window에 종속된 놈이 아니란것은 이제 알겠다. 드문 경우이지만 DirectFB를 이용하여 임베디드 GUI개발도 가능하다.

5. 우리나라에서 GTK로 밥먹고 살 수 있나?

임베디드

• 리눅스 환경에서의 임베디드는 대부분 QT관련 제품군(?)을 주로 사용한다. 돈을 주고 사야해서 그렇지 라이센스 부분에서 걸리는것도 적고 또 훌륭한(?) 개발환경을 제공받을 수 있다. 기업주의 입장에서는 당연한 선택이다 개발자 또한 당연히 선택해야할런지도 모른다.
  
  GTK를 사용한다고 생각해보자. GTK 개발용 라이브러리는 LGPL인것으로 알고 있다. 다만 제반 환경들은? 하드웨어에 맞게 각종 패키지들을 조금이라도 수정했다면? 그 중에 GPL인것이 있다면? 개발을 의뢰한 고객에게 충분히 알아들을 수 있게 공지하고 소스코드를 오픈하는 준비를 해야한다.제품 개발을 하청을 받은 경우 충분히 문제가 발생할 수 있다.
  
  
• GTK를 이용해 직접 개발한 프로그램에 대해서는 GPL을 적용할 필요는 없겠지만 제반환경을 갖추느라 라이센스가 복잡해질수있다. 어떤거 어떤거 어떤거는 GPL 소스가 약간 변경됐으니 공개해야합니다. 뭐 이런 것을 고객에게 인지시키고 계약서에 넣어야한다는 것이다.
  
  
• QT를 사용한다해도 리눅스를 이용하면 완전히 자유로울수는 없으나 비교적 깔끔한 편이다. 거의 QT에서 다 지원하고 제공한다. X 를 띄울 필요도 없으며 또한 Qtopia같이 훌륭한 놈도 있다.
  
  
• 다만 외국에서는 GTK를 이용해 임베디드를 하는 경우가 종종 있다고 들었다.

GTK는 무조건 X를 띄워야하는가?

• DirectFB를 사용해 본 바 아직은 완전하지 않지만 몇가지를 제외하곤 상당히 잘 작동했다. 하지만 QT같은 상용과 비교하기에는 무리가 있다. 돈을 받고 만들었다면 당연히 제품다운 제품을 만들어야하는것이다. 아직까지는 GTK를 이용해 만들려면 X Window에서 작동시키는것이 바람직하다.

응용프로그램

• 리눅스 데스크탑환경이 국내시장의 30%만 차지해도 충분히 가능한 얘기이겠지만 현재로선 대략 GG다.

어렵다

• 다른것도 하면서 부가적으로 아주 특수한 경우에라면 모를까 GTK만 해서는 밥먹고 살기 어렵다. 차라리 QT를 이용 한다면 임베디드 개발자로 먹고 살 수 있다.

6. 그럼 왜하나?

• 본인은 그냥 한다. ㅡ.ㅡ 그럼 취미로만 하느냐? 꼭 그렇지 많은 않았다 적어도 얼마전까진 전에 다니던 회사에서 GTK로 SI를 진행했던적이있다. 모 대기업에서 기획 설계하고 서브화면 빼고 순수하게 본수로만 400본정도 되는 약간 큰 프로젝트였다.
  
  GTK로 온라인 캐쥬얼 게임도 제작한 적도 있었다. 거기다가 모 호텔의 컨트롤 패드를 납품할 기회가 오는듯했으나 초반 준비중 무산됐다.
  
  전 회사에서 하라고 해서 시작했고 직장을 옮긴 지금은 잘난척하는거 밖에 안된다. (별로 잘난것도 없으면서 말이다 --;)
  
  
• 이렇게 말을 많이 하고도 결론은 왜 아직 없나? 있다. 그냥 하잔거다. ㅡ.ㅡ 이유는 없지만 그냥 해보자 그것이 좋아서든 뻐기고 싶어서든 재미있어서든 뭐든지 간에 말이다.
  
  
• 수 많은 X Window용 응용프로그램이 제작되고 그것이 일반사용자가 주로 사용하는 요건들을 대부분 충족한다면 하나둘 늘어갈 것이다. 그 것이 QT냐 GTK냐는 따질 이유도 없고 일단 따지기 귀찮다. 다만 GTK가 자료도 많아 보통 사람이 접근하기 좀더 쉽고 편하다(나만의 생각인가 ㅡ.ㅡ).
  
  
• 정부에서도 리눅스 보급에 관심이 있고 작년에는 소프트웨어 진흥원에서 정부기관 비스무리한곳에 업무용 데스크탑 환경을 공개용 OS 또는 프로그램들로 전환하게 하는 사업도 있었다. 몇 개의 기관과 학교등이 이 사업으로 인해 리눅스로 바뀌었다. 앞으로는 점점 많아질것이라 기대해보고 또 그것을 촉진시킬 수 있을지도 모른다.
  
  
• 본인 또한 윈도우를 많이 사용하는데 이유는 다양한 소프트웨어들이 존재하기 때문이다.
  이렇듯 충분한 종류와 수의 소프트웨어가 리눅스를 위해 준비되어져 있다면 선택받을 기회는 늘어날 것이다.
  
  
• 장대한 목표도 좋겠고 잘 짜여진 계획도 필요하겠지만 적당한 방향만 생각하고 일단은 그냥 가는게 좋을듯 싶다. 가끔은 별생각없이 시작했던일들이 거대한 결과를 내는 것을 공개 소프트웨어와 관련된 일들에서 많이 봐오지 않았는가 일단은 교양삼아 GTK를 해보자 현재는 본인도 그러고 있다.
  
  자바와 .NET이 대세라 여겨지는 현 시점에서 시대에 뒤떨어지는 생각일지도 모르겠으나 어차피 손해볼 것도 없지 않은가? 환경과 언어가 바뀌었다고 큰일나는건 없다. 제반환경과 언어는 계속 변하겠지만 프로그램 개발이라는 것은 단지 그것만으로 하는 것이 아니지 않은가?
  
  오히려 그것들을 가벼운 것에 불과하다. 스스로에게 축적된 내공은 사라지는 법이 없다. 적을 칼로 제압하느냐 창으로 제압하느냐는 그때그때 상황과 환경에 따라 다른것이다. 도구는 중요한것이 아니다.
  
  우리가 진정 경계해야하는것은 치매와 기억상실이다! -_-; 대부분의 개발자들에겐 돌아갈 리조트나 엄청난 재산이 있을리 없다. 남는건 공백뿐 -0-
  
  (얼마전 모 오락프로에 나왔던 선천성 진지 결핍증이란 말에 왠지 뜨끔)

Meta-Object System

Qt's Meta-Object System provides the signals and slots mechanism for inter-object communication, run-time type information, and the dynamic property system.

큐티의 베타 객체 시스템은  객체간 내부 커뮤니케이션, 런-타임타입 정보 그리고 동적 속성 시스템 위해 시그널과 슬롯 매커니즘을 제공한다.

The Meta-Object System is based on three things:

메타 객체 시스템은 세 가지 특징을 기반으로 하고있다.

1. The QObject class provides a base class for objects that can take advantage of the meta-object system.
2. The Q_OBJECT macro inside the private section of the class declaration is used to enable meta-object features, such as dynamic properties, signals, and slots.
3. The Meta-Object Compiler (moc) supplies each QObject subclass with the necessary code to implement meta-object features.

1. QObject 클래스는 메타 객체 시스템을 이용할수있는 객체들에게 기본 클래스를 제공한다.
2. 클래스 선언부의 private영역내에 존재하는 Q_OBJECT 매크로는 메타 객체 속성(동적 속성, 시그널 과 슬롯) 들을 사용가능하게 하기위해서 사용되어진다.
3. 메타 객체 컴파일러(MOC)는 각 QObject 하위 클래스에게 메타 객체 속성들을 구현하기위해 필요한 코드들을 생성한다.

The moc tool reads a C++ source file. If it finds one or more class declarations that contain the Q_글상자OBJECT macro, it produces another C++ source file which contains the meta-object code for each of those classes. This generated source file is either #include'd into the class's source file or, more usually, compiled and linked with the class's implementation.

In addition to providing the signals and slots mechanism for communication between objects (the main reason for introducing the system), the meta-object code provides the following additional features:

• QObject::metaObject() returns the associated meta-object for the class.
• QMetaObject::className() returns the class name as a string at run-time, without requiring native run-time type information (RTTI) support through the C++ compiler.
• QObject::inherits() function returns whether an object is an instance of a class that inherits a specified class within the QObject inheritance tree.
• QObject::tr() and QObject::trUtf8() translate strings for internationalization.
• QObject::setProperty() and QObject::property() dynamically set and get properties by name.

It is also possible to perform dynamic casts using qobject_cast() on QObject classes. The qobject_cast() function behaves similarly to the standard C++ dynamic_cast(), with the advantages that it doesn't require RTTI support and it works across dynamic library boundaries. It attempts to cast its argument to the pointer type specified in angle-brackets, returning a non-zero pointer if the object is of the correct type (determined at run-time), or 0 if the object's type is incompatible.

For example, let's assume MyWidget inherits from QWidget and is declared with the Q_OBJECT macro:

The obj variable, of type QObject *, actually refers to a MyWidget object, so we can cast it appropriately:

   

  QWidget *widget = qobject_cast<QWidget *>(obj);

The cast from QObject to QWidget is successful, because the object is actually a MyWidget, which is a subclass of QWidget. Since we know that obj is a MyWidget, we can also cast it to MyWidget *:

    

  MyWidget *myWidget = qobject_cast<MyWidget *>(obj);

The cast to MyWidget is successful because qobject_cast() makes no distinction between built-in Qt types and custom types.

   

  QLabel *label = qobject_cast<QLabel *>(obj);

     // label is 0

The cast to QLabel, on the other hand, fails. The pointer is then set to 0. This makes it possible to handle objects of different types differently at run-time, based on the type:

     if (QLabel *label = qobject_cast<QLabel *>(obj)) {

         label->setText(tr("Ping"));

     } else if (QPushButton *button = qobject_cast<QPushButton *>(obj)) {

         button->setText(tr("Pong!"));

     }

While it is possible to use QObject as a base class without the Q_OBJECT macro and without meta-object code, neither signals and slots nor the other features described here will be available if the Q_OBJECT macro is not used. From the meta-object system's point of view, a QObject subclass without meta code is equivalent to its closest ancestor with meta-object code. This means for example, that QMetaObject::className() will not return the actual name of your class, but the class name of this ancestor.

Therefore, we strongly recommend that all subclasses of QObject use the Q_OBJECT macro regardless of whether or not they actually use signals, slots, and properties.

See also QMetaObject, Qt's Property System, and Signals and Slots.

출처 : http://doc.trolltech.com/4.2/metaobjects.html