현재 위치

홈 ›› Forums ›› 이슈 ›› 뉴스, 새소식

GTK+ without X

한정훈의 이미지
글쓴이: 한정훈 / 작성시간: 목, 2001/01/11 - 12:23오후

news.gnome.org에서 리눅스프레임버퍼의 GTK+지원이 현재 CVS상에 있다고 합니다. 이것은 X서버를 실행하지않고도 그놈애플리케이션을 작성할 수 있다는 것을 의미합니다.
프레임버퍼 상에서 작동되는 GTK+-기반의 배포판설치를 상상해보십시오. (더 이상 자원을 많이 먹는 엑스를 실행하지 않아도 된다는..)

스크린샷보기:
http://www.lysator.liu.se/~alla/files/testgtk.png
http://www.lysator.liu.se/~alla/files/testtext.png
http://www.lysator.liu.se/~alla/files/gtktetris.png

(자세한 것은 /.에서..)

Forums: 
뉴스, 새소식
익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 목, 2001/01/11 - 10:09오후

일단은 좋은거 같네요...
^^
당췌 감 못잡구
한줄 치구 gtk.org들어가서 레퍼런스 보고...
한줄 치구 다시 들어가서 보고...
아예 열받아서 wget으로 다 받아 버린게 벌써
얻그제 같은데....

아무튼 리눅스에서 더 많은 발전이 있기를 기원합니다...
gtk랑 gtk--도 그러길 바람니다...

마직막으로 저 개인적인 의견은... fltk님의 글에 동감입니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 목, 2001/01/11 - 7:33오후

더이상 자원을 많이 먹는
X를 실행시키지 않아도
된다고 하셨는데...
자원을 많이 먹는건 X가
아니고, gnome입니다..-_-;;

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 금, 2001/01/12 - 1:01오후

GTK의 함수들은 Xlib 함수들을 Wrapping(감싸서)하여 구현되었습니다. 따라서 직접 FB을 억세스하지 않고 Xlib를 거쳐서 가는거죠. 그러니 당연히 자원을 많이 먹는거구요.
그런데 FB를 직접 건드리는 GTK가 발표되었으니 자원을 덜먹을 거란 얘기겠죠...

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 금, 2001/01/12 - 4:05오후

X를 이용해 gtk를 돌리는것보다 fb를 통해 돌리는 것이 X protocol을 피해가니까 조금 빠를 수도 있고, 약간의 자원을 덜 먹을 수도 있죠... 그러나, 그렇게 빠른 것을 원한다면, dri를 이용하면 되는 것이고, 그만큼의 자원을 걱정해야 할 처지라면, 차라리 옆 컴퓨터에서 돌리고, 이 컴퓨터의 X 서버에서 처리하는, 즉, 리모트로 돌리는게 낳지 않을까요? lan에서는 왠만한 어플은 리모트로 돌려도 많이 느려지지 않습니다.

X는 (게임을 하기 위해) 그렇게 빠르지는 않지만, (물론 요즘에는 빠른 것도 생각해서 dri가 있죠.) 왠만한 어플을 돌리는 데에는 적당히 빠르고, 자원도 그렇게 많이 사용하지 않는 훌륭한 시스템입니다.

물론 fb로 gtk를 돌리는 것이 임베디드 환경에서는 크게 도움이 될 것입니다. 그렇지만, 보통의 컴퓨터 환경에서 X를 대체할 만큼 메리트가 있는 것은 아닙니다.

ultracat의 이미지

글쓴이: ultracat / 작성시간: 금, 2001/01/12 - 5:03오후

GtkFB의 용도는 Embedded Device때문에 나온것입니다.
X를 대치하려고 나온것은 아니라고 알고 있습니다.
작년에 한참... Embedded용 Windows System에 대해서 GNOME과 GTK메일링 리스트에서 떠들석할때, 메일링 리스트에서 제안되고 redhat의 engineer들이 시작한 일이져..

embedded용으로는 X는 너무크다가 그 때 결론이였져.

사실 Embedded Device에는 어떤 잘 정의된 Windows System보다는 WinCE만큼 혹은 보다 더 멋있고 쓸만한 GUI FrontEnd가 더 절실하거든요.
그리고 Embedded Linux이므로 기존의 개발자들이 참여할 수 있는 물건이여야 하구..

GNU Guru들이 고려할 수 있는 최고의 GUI FronEnd는 GTK였는디.
이게 X랑 합치면 넘 크니.......... 그렇게 고민하다가..
Qt에서.. Qt/Embedded를 만들어서...그게 자극이 되서 시작된 Project 입니다.

GtkFB를 만드는 사람들도 이게 DeskTop PC용 X를 대체할 것이라고 생각하지는 않을 것 같습니당. ^.^......

ultracat의 이미지

글쓴이: ultracat / 작성시간: 금, 2001/01/12 - 5:07오후

안 한가지더~~

Redhat은 정말 대단하다 라고 느낄 수 있는 곳이 있어여..

labs.redhat.com인데.. 여기는 레드헷 소속 연구소 홈페이지인데.. 거기 프로젝트란을 보면..

와~~~~~~ 하는 탄성이 나옵니다.
한번 가서 보세요...

우리나라 리눅스 회사들도 그런일을 하는 곳이 되면 얼마나 좋을까.. 하는 생각이 들더군요...

가서 일하고 싶다는 생각도 들구요.. 허허허허허..

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 토, 2001/01/13 - 12:53오전

처음 글 올린 사람이 마
치 이제 X는 쓰지 않아도
된다는 것처럼 해놔서 쓴
거였구요..
하여튼 redhat은 대단한
회사인 것만은 틀림없습
니다...

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 목, 2001/01/11 - 10:15오후

바보! X가 리소스 많이 먹는다는 얘기가...
Gnome보다 많이 먹는다는 얘기인가?
MS Windows/MacOS보다 많이 먹는다는 얘기지...
(필요이상의 기능들 땜~~~)

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 금, 2001/01/12 - 3:56오후

익명으로 이렇게 거친 글을 쓰는건 답장하기도 싫습니다... 누군지도 모르는데... 괜히 힘을 낭비할 필요까지...

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 목, 2001/01/11 - 6:16오후

무지 신기함 +_+
실용화되면 무지 좋겠군요. ^_^;

뒷북) 근데 프레임버퍼도 해상도랑 색상 수 조절할 수
있나보죠? -.-;;;;;; 리프레쉬 레이트도....

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 목, 2001/01/11 - 6:53오후

당연히 가능합니다. linux 소스 디렉토리에서 Doucmentation 디렉토리의 vesafb 디렉토리를 열어보시면 문서가 있으며 이를 통해서 원하시는데로 프레임 버퍼 상태를 설정 할 수있습니다.

한정훈의 이미지

글쓴이: 한정훈 / 작성시간: 목, 2001/01/11 - 4:55오후

전 이글을 처음 보았을 때 이런 생각도 들었습니다.
"이러다 창관리자의 개념이 없는 환경도 생기는 것 아닌가..", "혹시 도스 쓸 때처럼 프로그램 실행하는 방식?", "이거 윈도우즈나 맥처럼되는 거 아냐..?" ..등등..
그냥 개인적인 생각이었습니다. 그리고 세번째의 것은 엑스를 없이 쓸 수도 있다는 생각에 특히 맥OS처럼 마치 OS와 GUI가 통합된 듯한 느낌을 자아내게 하는 듯.. 한 생각을 표현한 겁니다.

'98th student of KW-Univ., Dept of CE.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 목, 2001/01/11 - 6:59오후

글쎄요... 어떤 분들은 OS 라고 말하면 단지 커널만을 말하시는 분들이 많지만 전 좀 다르다고 봅니다. 이건 교과서적인 이야기죠.

제가 생각하는 지금의 OS 개념이란 넓게는 최상위 어플리케이션의 하위레벨을 모두다 하나의 개념으로 보고 싶군요. (특정 시스템 관련된 어플은 제외)

Gtkfb 가 X 윈도우 시스템을 필요없게 만들지는 못하겠지만 Embeedded S/W 에 개발에서는 매우 큰 방향성을 제시할 것 같더군요.

하~~~ 제 생각이었습니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 목, 2001/01/11 - 4:31오후

난 그래두 큐티 편이당...
내가 쓰고 있는 게 kde고,
알짜 처음 깔던 날, 그 황량하고 그노믹한
그놈의 충격에서 아직 벗어나지 못했고,
리눅스 구이 플밍할라구 산 책이 큐티였고,
그놈이 바퀴를 다시 만드는 경향이 있고
(트롤테크 책임도 있지만...),
큐티가 더 쉽고(난 실용주의자다^^),
무엇보다도 구이같은 건 C 보다 C++로 하는 게
자연스럽다.

요즘 모질라 공부하면서 느낀건,
C++ 객체지향, 디자인 패턴 이런 게 남의 얘기가
아니라는 것... 패턴만 좀 알아도 모질라 하나 먹고
들어갈텐데... 쩌비

근데 모질라는 gtk쪽이죠?

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 목, 2001/01/11 - 3:19오후

전진 앞으로 그놈인가요?
하루가 멀다 않고 쏟아져 나오는 그놈들 땜시
정신이 없네요...^^
(어솨 어솨 시간 좀 나야제... 이러다 깔려
죽겠네...^^)

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 목, 2001/01/11 - 3:18오후

전 1 주일 전쯤에 slashdot 에서 보고 CVS 에 있는 걸 실행시켜 보았는데요. 16 bit mode 에서 잘 작동하는 걸로 확인했습니다. 전체적인 slashdot 의 의견은 이렇더군요.

(1) PDA 또는 Embedded enviroment 환경에서는 매우 의미 있는 일이다.

(2) X 의 Image manipulation 이 주는 오버헤드와 X 자체가 낭비하는 Resource 를 줄여준다.

(3) 실제로 속도 향상에서는 차이가 나겠지만 크게 아주 큰 차이가 날지는 미지수다.

(4) H/W accelation 이 안되므로 GGI 또는 SDL layer 상위 레벨에서 작동되도록 만들어 보자.

(5) Freetype2 라이브러리를 사용하며 antialising 과 ,BIDI 를 지원한다. 다국어 지원도 가능하다. 또한 거의 무리없이 기존의 GTK application 이 작동한다.

(6) QtEmbeddeed 는 GPL 이며 GTK 는 LGPL 이므로 의미가 상당하다.Qt 는 상업적으로 이용할 땐 비용이 든다. 하지만 GTK 는 그렇지가 않다.

전 사실 우리나라 Linux 회사에서도 Qt 만 취급 할것이 아니라 GTK 를 사용하는 회사가 많았으면 하는 바램입니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 목, 2001/01/11 - 3:06오후

대단하군요..

둘러보기