맥OS에서 직접 돌아가는 GTK+

GTK+도 언제부터 멀티플랫폼을 실제로 지원하긴 했습니까? 하하 개가 지나가다 웃일 얘기군요. 심하게 말하자면 완벽하게 지원하는 경쟁자인 Qt에 비하면야 소스 코드에서 디렉토리에 win32, mac 이라고만 이름만 존재하고 코드만 그럴듯하게 있는거에 불과합니다. 아닌가요?

Qt는 해보신분은 아시겠지만 정말 컴파일 새로 하는것만으로 바로 됩니다.

GTK+가 과연 그수준까지 언제야 될까요?

GTK+의 멀티플랫폼 지원은 발바닥에서 이제야 발등으로 올라온거에 불과합니다.

같은 얘기라도 그렇게 하면 기분 좋습니까?

전 지금 윈도에서 gimp, gaim, xchat, dia를 쓰고 있습니다.

죄송합니다. 지나가던 개가 좀 짖었습니다.

완벽하게 지원하는 Qt와 지나가던 개가 웃을 정도인 gtk가 어떻게 '경쟁'이 되나요? 무의미하고 근거 없는 확신으로 지나가던 개를 자극해봐야 뭐 득될 게 있겠습니까. 사람다운 품위를 지켜야 개들도 함부로 안 덤비죠. ;-)

트집을 잡으려면 좀 사실을 가지고 말씀하세요. 그리고 GTK 얘기하는데, Qt 는 왜 끌고 오는 건지 모르겠군요.

그런가요..

제가 보기에는 '지나가는 개가 웃을일' 이라는
표현이 그렇게 격해 보이지 않아서요.. 뭐 근런가 보다 했었는데..

다른분들이 그부분에 민감하신거 같에서..
그리고 혼자 코너로 몰리면 심심할지도 모르잖나요..

이왕이면 약자(로 보이는 ..)쪽에...편을 들려고..ㅎㅎ
고니님말씀도 백번..맏(,맞,많, ㅤㅁㅏㄵ..어떻게 쓰는건지 까먹었어요..--;)는 말씀이세요..

:lol:

안녕하세요 유령 키다군 입니다..^^;;

뭐.. GTK+ 가 멀티 플렛폼이 잘지원되는지 아닌지는 저도 잘 모릅니다만,
원글의 기사는 OSX 플렛폼으로 네이티프 포팅이 되고 있다는 이야기이지, GTK+ 가 멀티플랫폼으로 잘 쓰여지고 있다라는 내용에 대한 기사가 아닙니다...

전혀 원래의 글과 관계없는 내용이 왜 여기 달렸는지 의아하군요...

아~ 그렇군요..
정말 죄송합니다.

뭐 비록 제가 그런 말을 한것은 아니지만..
워낙 저는 주위에서 사람취급을 못받거나 둔감한가 봅니다.

그런 심한 욕을 읽고도 욕한사람을 두둔하다니...
그리고..

저는 어린애가 때리면 맞고 댕겼고요..
앞으로도 그러겠습니다.

ㅤㄱㅙㄶ히 다른 엉뚱한 사람을 욕하는 것 보다는
나은것 같네요.

정말 죄송합니다.

뭐 플레임 제공자를 두둔할 생각은 없지만,
그리고, 엎지러진 물은 담을 수 없다고 하지만,

다시 담을 수 있는 기회를 한번은 주어야 하지 않을까요?

kenny007one : 답글 기다립니다.

죄송하다고 했으니 이번엔 특별히 용서 해 드리죠. 그리고 둔감한다는 것을 깨닳았으니 앞으로 노력이 더 필요하겠군요. 제가 있는 곳으로 오시면 특별히 아는 어린이에게 부탁해서 계속 몽둥이로 후려치게 시키겠습니다. 많이 맞다 보면 좀 더 정상으로 돌아 오겠죠.

한 번 흉내내서 써봤습니다.

gtk가 C 언어로 작성되었기에 객체지향적인 요소가 부족하다고 말한다면, 그건 gtk의 철학을 제대로 이해하지 못한 것입니다. gtk 자체는 gtk 개발자들이 C 언어로 최대한 객체지향 개념을 발휘하여 작성한 것이지만, 굳이 사용자들이 C 언어로 프로그래밍하며 gtk 개발자들처럼 묘기(!?)를 부려야 할 필요는 없습니다. gtk가 C 언어를 주 개발언어로 계속 고집하고 있는 것은, 현존하는 프로그래밍 언어 중 C 언어가 다른 언어와의 인터페이스를 작성하기 좋은 언어이기 때문이고, gtk 개발자들의 결정 및 헌신적인 노력 덕분에 gtk는 현존하는 툴킷 중 가장 많은 언어 바인딩을 지원합니다. php-gtk라고 들어보셨죠?

gtk에 객체지향적인 요소가 부족하다고 말할 때, C로 만들었기 때문에 그렇다고 말하는 것은 포인트를 놓친 것입니다. 리눅스 커널이 C 언어로 작성되었기 때문에 리눅스에서 객체지향 프로그래밍을 하기 나쁘다고 말하면 얼마나 황당하겠습니까? ;-) gtk의 객체지향을 논하려면, 원시 C 인터페이스를 다른 객체지향 언어로 고쳐 쓴 gtkmm이나 ruby-gnome2, pygtk 등 자신에게 익숙한 객체지향 언어로의 바인딩을 사용해보고 나서 논하는 것이 적절합니다. 사실 gtk는 객체지향면에서 전혀 모자람이 없습니다.

gtk가 C 언어를 기반으로 한다는 사실 때문에 생기는 장점 중의 하나로 pygtk 예를 들 수 있습니다. pygtk 팀은 다른 언어 바인딩과는 달리 수동으로 래핑 코드를 작성하지 않고, 특별한 코드 제너레이션 기법을 사용합니다. gtk 새버전이 출시되어 API가 몇 개 추가되어도 scheme 문법으로 표현된 API 정의 파일만 만들어두면 자동으로 파이썬 래핑 코드를 만들어냅니다. C 언어가 아닌 다른 복잡한 언어였다면 코드 생성이 훨씬 어려웠을 겁니다. C 언어는 언어 정의가 심플하고, 플랫폼 지원이 매우 좋은 탓에 코드 생성 기법이 많이 연구되어서, 마치 포터블 어셈블리처럼 사용되는 것을 많이 봅니다. C 언어로 이런 툴킷 프레임워크(+ 객체지향 프레임워크)를 만드는 것은 매우 고된 일입니다. 하지만 누군가 이미 잘 만들어두었다면 그것을 이용하는 사람은 잘 사용하면 그만입니다.

참고로 예전에도 비슷한 플레임이 있었습니다.

http://bbs.kldp.org/viewtopic.php?t=33892&highlight=gtk

"지나가는 개" 발언과... 저의 감정적인 댓글로.. 불씨가 이상하게 커졌군요.

뭐 플레임은 플레임 나름대로 재미있으니 상관없지만...
토픽의 범주내에서의 플레임이라야 더욱 재미(?)있지 않을까요?

요는 GTK는 크로스 플랫폼인가? 라는 것인데...

(GTK는 객체지향인가는 앞에 어느분이 지적하신대로.. 다른 쓰레드가 있었습니다. 필요하면 새로 열면 되겠죠)

흠.. 제가 보기엔 충분히 크로스 플랫폼이라고 생각합니다만...

유닉스/X11환경에서 출발해서... 지금은 win32에서도 별 무리없이 돌아가고...
꽤 많은 임베디드 디바이스에서 사용하고 있으니까요~

OOP에서 상당한 고생을 감수하면서 C로 만든 이유중의 하나가 다른 플랫폼으로 이식이 쉽다는 거였죠.(이젠 C++컴파일러가 있지만 아직도 상당수의 임베디드 시스템에선 C++은 그림의 떡이죠.) 다른 또하나의 이유는 위에서 말씀하신대로 여러 언어 바인딩을 만들기 쉽다는 것이었죠.

osx의 경우엔.. 토픽에 소개된 글이 나오기 한참 전 부터 gtk-osx(카본), gtk-aqua(코코아)두 프로젝트가 있었습니다. gtk 1.3(2.0의 불안정개발트리)가 포팅되어 있습니다. 주로 김프만을 대상으로 해서.. 안되는게 많았죠.
(당시에는 저도 맥유저여서 이런저런 패치를 해서 보내곤했었는데.. 이젠 맥유저가 아니거든요^^)

그리고 osx에서 x11을 거쳐 돌아간다고 해서 osx을 지원하지 않는다고 말할 이유는 없어보이네요. 분명히 darwin이 bsd기반이고, 애플이 직접 x server소프트웨어까지 제공하니까요. .net런타임이 필요한 프로그램은 윈도 플랫폼을 지원하는 것이 아닌게 되나요?

qt와 비교하셨는데.. qt는 어떤 플랫폼들에 포팅되어 있나요?

좀 농담반 진담반으로 개가 웃을 일이라 표현한건데 너무들 과민반응하시는 분들이 많으신군요 한편으로 또 무슨 말 끄내면 어떻게 나올런지 무섭습니다.

한편으로는 어떻게 자유와 공유를 지향하는 대표적 곳에 이렇게들 편향적 시각으로 몰려있는 분이 많으신거 같아 좀 실망스럽군요.

GTK+ 객관적으로 보죠. 플랫폼만 따져보도록 하겠습니다.

unix계열의 X-window 에서는 완벽합니다. 뭐 당연 얘기지만..
하지만 그 정도 수준으로 똑같이 타플랫폼에서 X-window만큼의 성능과 속도, 품질, 개발, 유저편의성등등이 만족되냐는 겁니다.

다들 반박하시는 분은 gimp를 비롯해 xchat도 잘 쓰고있다.. 하지만!

gimp가 linux에서 X-window위에 돌리는 만큼 똑같다 말할수 있나요? 개인적으로 저는 수시로 죽고 뻗어버리고 파일저장 안되서 도저히 못쓸수준이었습니다. 그리고 linux에서보다 너무 렌더링자체가 느리기도 하고, 잔상이 심할정도였습니다.

반면 멀티플랫폼 툴킷을 지향하는 또다른 Qt 라이브러리는 완전히 유저가 느끼는 모든것이 같습니다. 이말은 한번 Win32용 Qt라이브러리 인스톨하면 있는 Qt designer 라던가 Qt assistant 하나만 돌려봐도 느껴집니다. 안정성과 속도, 룩앤필 모든게 동일하게 같습니다. 그리고 아주 특별한 종속적 코드가 아닌한 GUI는 완전하게 컴파일 새로 때려주는것만으로 동작합니다. GTK+는 암만 봐도 그렇게 하는 방법은 없더군요. 개발환경부터가 멀티플랫폼을 지원한다는건 사실 천지 차이입니다.. Qt는 VC++용 플러그인까지 제공합니다. GTK+는 알아서 makefile만들고 파일 배치하고 라이브러리 제대로 링크하고 등등.. 코딩보다 환경 만들어 주는시간이 더 걸리더라 말입니다.

제 얘긴 이런 수준을 GTK+는 멀었다는 겁니다.

그리고 가장 중요한! 레퍼런스입니다.

http://www.trolltech.com/success/index.html

Qt는 멀티플랫폼으로 나온 유명회사의 대형 프로그램들이 널렸습니다.

http://www.gtk.org/success/

그러나 GTK+는 여기봐도 사실 하나도 저는 멀티플랫폼이랄수 있는 레퍼런스라 딱히 말할수 있는건 못찾았습니다.

냉정해지시기 바랍니다.

GTK+는 아마추어해커들의 작품일뿐입니다. 애초에 회사의 물건으로 팔고 있는 Qt와는 프로와 아마추어의 레벨차이입니다.

아마추어는 아무리 잘나봐야 취미수준인겁니다.

GTK+가 아마추어 해커들의 작품은 아닌듯합니다. Sun,노벨등의 엔지니어가
그놈과 GTK+에서 설치고 있으니까요.:-)

전 개인적으로 그놈이 모노나 자바 같은 VM위에 올라가기를 희망합니다.;;
미구엘이 말했듯이 C언어는 VM의 한 부분이나 커널등 특정한 부분에서의
사용만 남고 다른 부분에서는 점차 없어지지 않을까 생각되어서요..

기술 분야에서는 나쁜 의도를 가진 사람이 이런저런 가설에 근거하여 불필요한 추측을 함으로써 경쟁자를 교란시키는 전술이 비일비재하게 활용됩니다. anarch님이 그런 의도가 없었더라도 불필요한 걱정을 공표하는 순간 앞서 말한 FUD 유포 행위에 가담한 것이 됩니다. OOP 운운하는 걸로 봐서는 개발자이실 것 같은데, 개발자라면 본인이 직접 써보고 나서 느낌을 얘기해야 생산적인 논의를 할 수 있지 않을까요?

어떤 점이 무섭나요? KLDP에서 토론할 때 가장 신경쓰이는 부분 중의 하나가 기술적으로 성실하게 반박을 했는데, 기술적인 부분과 전혀 상관없는 부분에 대해 지적 당한다는 것입니다.

흠.. 전 기업 마케팅이면 가능하겠지만.. 기술 자체는 힘들꺼라 생각됩니다.. 프로그래밍이 아직 엔지니어닝보다는 예술적인 측면이 많아서 (적어도 아직은.) 선호도나 감정 이입이 많긴 하지만 디테일한 부분에서 옮고 그름은 우겨서 될일이 아니니까.. 쉽게 교란되지 않을 듯 싶습니다.

아..전 여기가 뉴스 게시판이고 해서..가벼운 말로 쓴건데..너무 정색하시고 교과서적인 어투로 말씀하셔서 놀란것 뿐입니다..:-) 언제 GTK+ 메일링 리스트 같은 곳에서는 안 놀라겠죠. 그런 곳은 함축엊이고 효율적으로 이야기해야 하니까요..

흠..네.. 쓰고 보니 그렇군요.. 그 부분은 수정하는게 올바른거 같습니다. 죄송합니다..

제가 요즘 새벽 1~2시 퇴근하는지라.=_= 지금 회삽니다.흑흑;;

음..논쟁에서 약간 벗어난 것 같기도 하고, 핵심인 것 같기도 한데...

gimp, gaim, xchat 이외에 GTK가 "멀티플랫폼"을 구현하기 위해서 쓰인 예가 별로 생각나지 않는군요. 위에 이것저것 나와있습니다만 대부분이 윈도에서는 따로 구현한 제품 아닌가요?

원래 다른 방식으로 구현하던 것을 리눅스 상에서 돌리기 위해 GTK로 다시 만든 것은 적절한 예가 아닌 것 같습니다. (그나마 많은 리눅스로 포팅된 상용 프로그램이 레드햇이 그놈이 아닌 KDE를 썼을때도 GTK를 선택했을까 하는 의문이 있고...)

ethereal 도 gtk 죠 ;)

뭐 좀 받을게 있어서 윈도우에서 bittorrent 를 깔고 open 메뉴를 클릭했더니... 어디서 많이 본 파일 셀렉터가 보여서 잠깐 움찔 했었습니다 헤헤

아인슈타인도 특허청에서 일하며 틈틈히 연구하던 아마추어 물리학자였죠..

제품을 일정에 맞춰 출시해야 하기 때문에 마구 개발하는 프로와
자기가 원하는 퀄리티로 여유있게 일하는 아마추어

어느쪽이 좀더 좋은 코드가 나올까요?

물론 반대로,
범위와 일정, 퀄리티를 완전히 통제하며 높은 수준의 제품을 만드는 프로와
이것도, 저것도 그때 그때 마음에 드는 기능에 신경쓰느라 제대로 것을 못만드는 아마추어

도 분명히 있지요..

ps. 대부분의 경우 무언가를 "단정 짓는 것"은 실수입니다. 실력없는 사람들의 단견인 경우가 대부분입니다. 자신이 실력이 없다고 남을 자신의 수준으로 끌어 내리지 말고, 자신이 높은 수준의 실력을 쌓도록 노력합시다. 저도 포함해서요. ^^

....다른건 몰라도,
MFC 와 VC++ 의 관계와 비슷한 녀석들이
QT 와 QT Designer/QT Assistant 인데
이 녀석들을 가지고 비교한다는게 좀 이상하군요....
QT 를 사용한,
Win32 에서 돌아가며, X-Window 환경에서도 돌아가는
다른 프로그램을 예로 드는게 맞다고 봅니다.

그리고, 멀티플랫폼이라는건 그렇게 거창한게 아닙니다.
GTK+ 는 일단 X-Window 환경과 Win32, OS/2, MacOS 등
여러 플랫폼에서 돌아가기 때문에 멀티플랫폼 라이브러리라고 부를수 있는 것이죠.
단지, 돌아가는게 좀 못 미더운 플랫폼들이 있기 때문에 "완벽한 멀티플랫폼 라이브러리" 라고는 부르지 않았지만 말이죠.

지원하는 플랫폼중에 특정 플랫폼에서,
아예 동작하지 않는것도 아니고 못 미덥긴 해도 돌아감에도 불구하고
"이 플랫폼에서 제대로 안 돌아가는데 왜 멀티플랫폼이냐" 라고 하면
할 말이 없네요..

그리고 다른 플랫폼으로의 이전 과정에 대한 불만을 이야기 하셨는데,
그것은 다른 플랫폼으로의 이전 과정에서 손 볼 일이 덜하다 더하다의 차이일 뿐,
그런 지원이 멀티플랫폼의 필수조건은 아니라고 생각되네요.

주제와 좀 벗어난 얘길 수도 있습니다만,

크로스플랫폼과 멀티플랫폼을 혼동하는 분들이 많은 것 같군요.

크로스플랫폼이란 갑돌이라는 플랫폼에서 돌아가야 하는 프로그램을(혹은 어떤 결과물을) 갑순이라는 플랫폼에서 개발한다는 얘기입니다.

멀티플랫폼은 갑돌이라는 플랫폼도 지원하고 갑순이라는 플랫폼도 지원하는 것이지요.

Qt는 갑돌이에서 만든 소스 코드를 갑순이에 가서 컴파일하기만 하면 돌아가니 크로스플랫폼을 지원하는 것이고, 또 갑돌이도 갑순이도 지원하니 멀티플랫폼이기도 한 겁니다.

Gtk는 소스코드 호환성이 떨어지니 멀티플랫폼이기는 하되, 완벽한 크로스플랫폼이라고 보기는 어렵군요.

그리고 상속, 인캡슐레이션, 다형성은 OOP의 특징이지만, 꼭 이것 때문에 OOP를 쓴다고 보기는 어렵지 않겠습니까? 또 저 특징들 중 일부를 지원하지 않는다고 OOP가 아니라고 보기도 어렵구요. OOP는 C를 대표적으로 하는 구조적 프로그래밍에서 더 나아가 좀더 강력하고 안전하고 유연한 프로그램을 만들자는 패러다임의 하나라고 생각합니다. OO면 어떻고 아니면 어떻습니까. OO교 신자가 아닌담에야.

개발하기 쉽고, 빠르고, 작고, 예쁘고, 유지보수가 편하고, 사용자에게 편리한 인터페이스를 제공하고, 다양한 기능을 제공해주면 그게 장땡이지요.

항상은 아니지만, 많은 경우 언어는 그저 거들 뿐입니다. 왼손이 거드는 게 아니구요.

먼저, 크로스플랫폼과 멀티플랫폼에 대한 용어의 정의는 감사합니다.

그런데, gtk의 소스코드 호환성이 떨어진다는 것은 어떤 의미입니까? UI코드에서서 win32와 linux를 구분해서 작성해야하는 부분이 있다는 것인가요? 그렇다면 어떤 부분에서 그런가요?

서로 욕하면서 싸우는 것도 아니고, 어쨌든 재밌는 얘기들이 많이 나오고 있습니다. 굳이 그만하자고 할 필요는 없을 것 같습니다. :wink:

아마추어란 뜻은 취미로만 한단 얘기이고 프로는 돈받고 직업적으로 한다는 뜻이 1차이고 그외 의미는 다른얘기입니다.
고로 레벨차가 난다는 뜻으로 사용한게 아닙니다.

다시 말하자면 linux가 아마추어 해커들 작품이라고 해서 프로페셔널한 면이 없느냐? 그건 아니란 겁니다. 레드햇을 비롯하여 많은 관련 회사들이 있으니까요.

자꾸 얘기를 확장해서 나름대로 해석하지 마시기들 바랍니다.

제가 의도한 것은 맥OS에서 GTK+가 진정 크로스or멀티플랫폼이라 할수 있느냐는 거와 다른 경쟁자와 비교하자는겁니다.

맥OS에서 안그래도 한번 파워북을 빌려 GTK+를 돌아가나 써봤습니다.

혹시나 역시나 안봐도 비디오란 생각이 틀리지 않았습니다.

뜨긴뜹니다만....... 휴.... 그후는 한숨입니다.

뭐하나 클릭만 해도 native와 비교하여 엄청난 버벅거림이 짜증을 시험하더군요.

제가 답답한건 GTK+의 장점만 보고 있는거 같단 겁니다.

이래서갖곤 토론이 안되지요.

우리들끼리만 이게 좋네 저게 좋네 해봐야 우물안 개구리고 어차피 밖에서 보기엔 답답한걸 왜쓰나 쉽게 세상 살지 하는식이란 겁니다.

GTK+의 장단점을 냉정하게 평가해서 발전을 가져오는 비평을 해야 된다 봅니다.

GTK+의 그 복잡다단한 구조도 멀티,크로스플랫폼 이식성과 속도에 상당히 문제가 된다 봅니다.

하위구조는 glib로 나누고 입력은 pango에 두고 그외 또 부가적으로 atk는 또 왜 띠어놓고 등등...

gtk+ 하나만 가져다 컴파일해도 엄청난 의존성과 연결된 고리때문에 대체 어디가 어딘지 알수가 없고 품질저하의 원인이라 봅니다.

그렇게 자꾸 기술적 측면만 강조하며는 mach 커널의 실패한 역사와 똑같이 되는겁니다.

linus가 왜 mach의 커널의 기술적 우위를 인정해도 쓰진 않는다 할까요?

바로 전체적인 성능, 즉 품질의 안좋음을 가져오기 때문입니다.

redhat 에서 linux 커널만 밀고 있는 건 아닙니다 :p

gtk+ 대표 개발자 중 한명인 owen taylor 가 어디서 일하는지는 알고 계신가요?
http://people.redhat.com/otaylor/

ximian (novell) 에서도 gtk 를 예전부터 밀고 있구요.
http://www.novell.com/linux/ximian.html

장점만 보는게 아니라 물론 장단점을 봐야겠지만... 그냥 덮어놓고 gtk KIN 분위기로 가는건 좀 문제가 있지 않을까요?

사용자는 그 엄청난 의존성을 알 필요가 없습니다. gtk 메인테이너들과 패키징을 하는 사람들만 알고 있으면 되는 문제입니다. glib 같은 하위라이브러리에서 중요한 버그가 발생해서 얼른 고쳐야할 경우 사용자 입장에서는 더 작은 패치파일 하나로 문제를 해결할 수 있다는 장점도 있지 않을까 싶네요.

mach 의 기술적 우위를 인정해도 쓰지는 않는걸까요? 너무나도 부분부분을 나눠놓았기 때문에... 메시지 패싱 과정에서 오버헤드가 너무 커지기 때문에, mach 기반으로 만들어졌다는 윈도우 nt 커널과 os x 의 darwin 에서 마저도 어느정도 마이크로커널과 모놀리딕 사이에서 타협점을 찾았는데요 :p

참고로 qt 나 wxwindows 의 툴킷을 사용해도 win32+winapi, mac os x + cocoa or carbon, linux + gtk 등에서 느낄 수 있는 그런 느낌을 완벽하게 얻을 수는 없습니다...