gnome 과 KDE 의 근본적인 차이?

jinserk의 이미지

이거 또 괜히 플레임을 유발하는게 아닌지 모르겠습니다만..
워낙 초보라 궁금해서 여쭙습니다.

어차피 GUI + 데스크탑 환경이고 다른 어플의 개발에 그러한 환경에서 동작하도록 하는 프레임웍을 지원한다는 면에서는 gnome 이나 KDE 나 별 차이가 없어 보이는데요..
그 외에 뭔가 뚜렷하게 드러나는 차이가 있을까요? 추구하는 비전이 다르다거나.. 둘다 이것저것 찾아보긴 했는데 뭐가 다른지 모르겠습니다.

opiokane의 이미지

gnome는 gtk기반 KDE는 qt를 기반으로 하는 것으로
커뮤니티가 완전히 다르지 않나요?
커뮤니티가 다름에 따라 취향도 좀 다른 것 같고.

George double you Bush has two brains, the left and the right, like normal people. But the problem is that there is nothing right in his left brain and there is nothing left in his right brain"

jinserk의 이미지

질문이 좀 모호한것 같기도 한데.. :oops:

툴킷이 뭐가 기반이냐 하는건 잘 압니다만 제가 관심있는건 앞으로 어떻게 발전할 것이냐에 관심이 있거든요.
그래서 어느 하나를 관심있게 주욱 써보면서 뭔가 기여할만한 꺼리라도 찾아보고 싶습니다.

사실 두개 다 써본 소감은 KDE 가 좀더 잘 organize 되어 있는 느낌이 들긴 합니다만 어차피 그건 시간이 가면 gnome도 조금씩 나아질테니 별로 중요한 팩터는 아닌 것 같구요.
포함된 amarok 이나 Koffice 등과 같은 어플은 사실 데스크탑 환경이란 측면에선 장점이 될지도 모르겠으나 GUI 란 관점에선 그다지 장점이라 보기 어려운 것 같습니다. 환경은 환경으로 끝나야지 포함된 어플을 가지고 판단할 문제는 아닐 것 같더군요.
대략 하드웨어 가속능력을 포함한 디스플레이의 성능과 안정성 (흠.. 이건 Xorg 쪽의 문제로 봐야 하나요?), 그리고 입력기나 파일 매니저와 같은 필수 어플 정도로만 비교해보고 싶습니다.

개인적으로는 맥의 아쿠아 및 Quartz 와 같은 강력한 성능 & look 을 보여주는 환경으로 발전할 것이 무엇이냐에 더 관심이 있습니다. (여전히 설명은 좀 모호하군요 :cry: )

Leo.

lacovnk의 이미지

두개의 차이점이라.

gnome의 vfs나 kde의 kio같은 것의 장단점은 어떨까요? (잘 모릅니다; )

또는..

kde같은 경우 각종 데몬이 알아서들 떠주는 것 같고 (gnome 안쓴지 오래서 가물합니다)

gnome같은 경우 gconf던가, registry 비슷한 기능을 하는게 있던 걸로 기억하는데

이러한 설계의 차이가 어떤 관점의 차이 때문에 생긴건지도 궁금하군요~

antz의 이미지

jinserk wrote:
개인적으로는 맥의 아쿠아 및 Quartz 와 같은 강력한 성능 & look 을 보여주는 환경으로 발전할 것이 무엇이냐에 더 관심이 있습니다. (여전히 설명은 좀 모호하군요 :cry: )

Gnome은 잘 모르구요.

http://www.kde-look.org
http://www.kde-apps.org

RSS를 하신다면 이 두 싸이트를 구독해보세요~

커뮤니티의 활성화 측면에서는
전에도 얘기했지만, KDE가 활발합니다.

랜덤여신의 이미지

GNOME 과 KDE 모두, 사용자 편의성 향상이라는 큰 목표는 같다고 생각합니다.
그래도, "분위기" 라는 것이 있기 때문에, 현재까지의 구현을 보면 약간 차이가 납니다.
제가 직접 써 보고 느끼기로는,
GNOME 은 단순하고 깔끔함을,
KDE 는 복잡하고 다기능을 추구하는 것 같습니다.

화려함과 통합성은 KDE 쪽이 더 낫고, 한글 문제 해결 정도는 GNOME 쪽이 더 낫습니다.
메모리 사용 등 시스템 자원 소모는 KDE 쪽이 더 많습니다.

opiokane의 이미지

jinserk wrote:
질문이 좀 모호한것 같기도 한데.. :oops:

툴킷이 뭐가 기반이냐 하는건 잘 압니다만 제가 관심있는건 앞으로 어떻게 발전할 것이냐에 관심이 있거든요.
그래서 어느 하나를 관심있게 주욱 써보면서 뭔가 기여할만한 꺼리라도 찾아보고 싶습니다.

사실 두개 다 써본 소감은 KDE 가 좀더 잘 organize 되어 있는 느낌이 들긴 합니다만 어차피 그건 시간이 가면 gnome도 조금씩 나아질테니 별로 중요한 팩터는 아닌 것 같구요.
포함된 amarok 이나 Koffice 등과 같은 어플은 사실 데스크탑 환경이란 측면에선 장점이 될지도 모르겠으나 GUI 란 관점에선 그다지 장점이라 보기 어려운 것 같습니다. 환경은 환경으로 끝나야지 포함된 어플을 가지고 판단할 문제는 아닐 것 같더군요.
대략 하드웨어 가속능력을 포함한 디스플레이의 성능과 안정성 (흠.. 이건 Xorg 쪽의 문제로 봐야 하나요?), 그리고 입력기나 파일 매니저와 같은 필수 어플 정도로만 비교해보고 싶습니다.

개인적으로는 맥의 아쿠아 및 Quartz 와 같은 강력한 성능 & look 을 보여주는 환경으로 발전할 것이 무엇이냐에 더 관심이 있습니다. (여전히 설명은 좀 모호하군요 :cry: )


어떤 질문인지 모호하지는 않았습니다.
다만 툴키트 차이 말고는 별다른 차이를 못 느끼겠더라 이런 생각이었습니다. :oops:

속도나 무게에 있어서도 요새는 KDE나 그놈이나 비슷한 것 같더군요.
아님 저만 그렇게 느끼나요?

George double you Bush has two brains, the left and the right, like normal people. But the problem is that there is nothing right in his left brain and there is nothing left in his right brain"

jinserk의 이미지

랜덤여신 wrote:

화려함과 통합성은 KDE 쪽이 더 낫고, 한글 문제 해결 정도는 GNOME 쪽이 더 낫습니다.
메모리 사용 등 시스템 자원 소모는 KDE 쪽이 더 많습니다.

오프토픽입니다만, 그래서 쿠분투에서 죽어라고 nabi가 안올라왔던거로군요. :cry:

그런데 단순 깔끔을 추구한다면 결국 통합 환경보다는 Enlightenment 같은 윈도우 매니저들과 경쟁해야 하지 않을까요? 요즘은 XFCE4 도 꽤 괜찮아진듯 하구요.

개발자들의 입장에서는 어느것이 더 나을까요?
사실 제가 원하기로는, GUI 환경도 application과 프레임웍 사이에 오가는 메시지를 표준으로 정해놓고 어떤 어플도 임의의 GUI 환경과 동작하도록 만들수 있는 세상이 왔으면 좋겠습니다만..

Leo.

익명 사용자의 이미지

랜덤여신 wrote:
GNOME 과 KDE 모두, 사용자 편의성 향상이라는 큰 목표는 같다고 생각합니다.
그래도, "분위기" 라는 것이 있기 때문에, 현재까지의 구현을 보면 약간 차이가 납니다.
제가 직접 써 보고 느끼기로는,
GNOME 은 단순하고 깔끔함을,
KDE 는 복잡하고 다기능을 추구하는 것 같습니다.

화려함과 통합성은 KDE 쪽이 더 낫고, 한글 문제 해결 정도는 GNOME 쪽이 더 낫습니다.
메모리 사용 등 시스템 자원 소모는 KDE 쪽이 더 많습니다.

GNOME이 단순하다지만, 실제로 별로 단순하지 않아서 1년전에 KDE로 갈아탔습니다. 메모리 소모도 GNOME과 KDE 별 차이 없었습니다. 제가 느끼기에는 체감속도는 KDE가 더 빠르던데요.
(FLAME 환영!)

lacovnk의 이미지

jinserk wrote:
개발자들의 입장에서는 어느것이 더 나을까요?
사실 제가 원하기로는, GUI 환경도 application과 프레임웍 사이에 오가는 메시지를 표준으로 정해놓고 어떤 어플도 임의의 GUI 환경과 동작하도록 만들수 있는 세상이 왔으면 좋겠습니다만..

음. 그 최소한의 선이 xserver..라고 생각하면 되는것이겠죠?

xserver깔고 kde 어플도 잘 돌고, gnome 기반 어플도 잘돌고.. 이렇게 여러가지 기반의 어플을 사용하는 것이 어떤 단점이 있을까요? 언뜻 생각하기엔 비슷한 기능을 하는 기반 라이브러리가 설치된다.. 정도인가;

다른 또다른 중간 단계가 생긴다면 성능의 손실을 감수해야 할테고, 또한 특별한 기능을 구현하는 데 제한도 생길것 같고.. but block처럼 바꿔 사용할 수 있고 (잘 구현되면) 좀더 통합이 될테니 좋을 것 같기도 하고..

에라 모르겠습니다 :) (개념도 안서고 orz )

덧. 랜덤의 여신님 죄송해요;;; 수정했습니다 :)

랜덤여신의 이미지

lacovnk, 그렇게 인용하시니까 마치 제가 한 말 같네요. 흑흑...

Anonymous wrote:
GNOME이 단순하다지만, 실제로 별로 단순하지 않아서 1년전에 KDE로 갈아탔습니다. 메모리 소모도 GNOME과 KDE 별 차이 없었습니다. 제가 느끼기에는 체감속도는 KDE가 더 빠르던데요.
(FLAME 환영!)

GNOME 이 KDE 보다는 더 단순하다고 생각합니다. 테마 시스템만 봐도, KDE 테마는 하나하나가 다 GNOME 쪽의 엔진과 맞먹습니다. 덕분에 각각의 KDE 테마들은 자체 설정 메뉴까지 있는 등 굉장한 커스터마이징 기능을 제공하지만, GNOME 테마보다는 설치하기가 어렵고 복잡하지요.

제가 느끼기에도 체감속도는 KDE 가 GNOME 보다 더 빨랐습니다. 터미널 뜨는 속도도 KDE 쪽이 더 빠르더군요(konsole 과 gnome-terminal). 정확한 테스트를 해 본건 아니라서 단정지을 수는 없지만요.
KDE 의 성능을 이야기할 때, KDE 의 기본 파일 관리자인 컹커러(konqueror)를 빼놓을 수 없다고 생각합니다. 컹커러는 다재다능하면서도 굉장히 빠르죠. GNOME 의 기본 파일 관리자인 노틸러스(nautilus)도 예전보다 많이 빨라졌다고 들었습니다만, 컹커러를 따라잡으려면 더 많은 개선이 이루어져야 할 듯 합니다.

랜덤여신의 이미지

jinserk wrote:
랜덤여신 wrote:
화려함과 통합성은 KDE 쪽이 더 낫고, 한글 문제 해결 정도는 GNOME 쪽이 더 낫습니다.
메모리 사용 등 시스템 자원 소모는 KDE 쪽이 더 많습니다.
오프토픽입니다만, 그래서 쿠분투에서 죽어라고 nabi가 안올라왔던거로군요. :cry:

이것은 KDE 의 문제라기보다는 사용자의 불찰일 가능성이 높습니다.
nabi 는 XIM 이니까 KDE 에서도 안 될 이유가 없죠.
아마, nabi 세팅 방법이 나와있는 문서 대부분이 GNOME 을 위주로 작성되었기 때문이 아닌가 싶습니다. 우리 나라에서는 GNOME 을 주로 사용하기 때문에, 한글 설정 문서의 대부분이 GNOME 용으로 작성되어 있죠. 이러한 한글 설정 문서의 부족도 KDE 에서 한글 문제를 해결하기 어려운 이유 중 하나입니다. 또한, 많은 국내 개발자들이 GNOME 에서의 한글 문제를 해결하기 위해 노력하셨으며, GNOME 의 번역도 담당하셨습니다. KDE 쪽에서 한글 문제가 해결되려면 일단 이러한 것들이 선행되어야 할 것 같습니다.

jinserk wrote:
그런데 단순 깔끔을 추구한다면 결국 통합 환경보다는 Enlightenment 같은 윈도우 매니저들과 경쟁해야 하지 않을까요? 요즘은 XFCE4 도 꽤 괜찮아진듯 하구요.

단순함과 기능성을 잘 조화해야겠지요. 지금의 GNOME 도 기능성에서 결코 뒤지지 않는다고 생각합니다. KDE 의 구성요소가 워낙 많고, 기능도 많다보니 비교가 되는 것이지요.

jinserk wrote:
사실 제가 원하기로는, GUI 환경도 application과 프레임웍 사이에 오가는 메시지를 표준으로 정해놓고 어떤 어플도 임의의 GUI 환경과 동작하도록 만들수 있는 세상이 왔으면 좋겠습니다만..

그래서 Freedesktop 이 있는 것이지요. Freedesktop 에서 만드는 데스크탑 표준을 GNOME 과 KDE 에서 구현하고 있습니다. 덕분에 GNOME 에서도 KDE 어플의 트레이 아이콘을 볼 수 있고, 그 반대도 가능합니다.

D-BUS 프로젝트도 비슷한 것입니다. Freedesktop 에서 만들고 있는 메시지 버스 시스템이죠. (KDE 의 dcop 에 해당합니다)

지금의 리눅스 어플은 대부분이 다른 데스크탑 환경에서도 잘 돌아갑니다. GNOME 에서도 amaroK 을 사용할 수 있고, KDE 에서도 Evolution 을 사용할 수 있습니다.

luark의 이미지

랜덤여신 wrote:
jinserk wrote:
사실 제가 원하기로는, GUI 환경도 application과 프레임웍 사이에 오가는 메시지를 표준으로 정해놓고 어떤 어플도 임의의 GUI 환경과 동작하도록 만들수 있는 세상이 왔으면 좋겠습니다만..

그래서 Freedesktop 이 있는 것이지요. Freedesktop 에서 만드는 데스크탑 표준을 GNOME 과 KDE 에서 구현하고 있습니다. 덕분에 GNOME 에서도 KDE 어플의 트레이 아이콘을 볼 수 있고, 그 반대도 가능합니다.

D-BUS 프로젝트도 비슷한 것입니다. Freedesktop 에서 만들고 있는 메시지 버스 시스템이죠. (KDE 의 dcop 에 해당합니다)

지금의 리눅스 어플은 대부분이 다른 데스크탑 환경에서도 잘 돌아갑니다. GNOME 에서도 amaroK 을 사용할 수 있고, KDE 에서도 Evolution 을 사용할 수 있습니다.

그런데 Enlightenment E17에서는 왜 트레이나 창목록 같은게 제대로 안되는 걸까요? 설마 E17은 freedesktop표준을 지키지 않는걸까요 ㅜㅜ 그럴리야 없겠지만 이쪽을 우선순위가 좀 높게 잡아서 어서 추가해 줬으면 좋겠네요.; 마땅한 패널도 없는 주제에 다른 패널들과 연동도 제대로 안되다니...쩝;

---

---
키체의 힘으로 당신에게 평안을...

지리즈의 이미지

어디까지나 제 느낌은...

gnome은 기능 본연에 것에 더 중점이 두고 있고,
(이를테면, vfs같은 것은 상당히 유현하더군요. 구체적으로
KDE의 무엇이 대응되는지는 모르지만, 노틸러스와 컨커러에서
보여주는 미리보기 기능은 gnome쪽이 낫더군요.)
KDE는 전반적인 사용성에 중점이 있는 것 같습니다.

실제로 거의 비슷하지만,
gnome은 가볍다는 느낌과(이것이 좋은 뜻과 나쁜 뜻이 모두 있습니다.)
KDE는 약간은 무겁지만, 사용자의 지시에 반응하는 느낌이 좋습니다.

사용자입장에서 조작자체의 완성도는 KDE가
하지만, 부가기능자체의 완성도는 gnome이 좀 낫다는 느낌이 들었습니다.

하여튼.. 이글의 제목인 근본적인 차이는 gtk기반이냐 qt기반이냐 차이를 빼면,
거의 없다고 봐야할 것 같습니다.

저는 이러한 것보다는 두 프로젝트 아니 다른 모든 프로젝트에 대해서
무엇보다 불만 사항은 common Dialogue의 부재입니다.

이를 테면, 파일선택창, 이미지선택창, 프린터 선택 창 등등...

이 모든 것들은 자신이 기반이되는 라이브러리(이를테면, gtk, qt)에
의존하죠.

저는 일종의 표준화된 wrapper layer로 작성된
Common Dialogue interface를 두고,
사용자가 윈도우 메니저뿐만 아니라,
이런 들도 선택할 수 있게 하면, 좋을 것 같습니다.

마치, X의 표준을 이용해서 윈도우 메니저가 프로그램을 제어하는 것처럼요.

There is no spoon. Neo from the Matrix 1999.

segfault의 이미지

지리즈 wrote:
gnome은 기능 본연에 것에 더 중점이 두고 있고,
(이를테면, vfs같은 것은 상당히 유현하더군요. 구체적으로
KDE의 무엇이 대응되는지는 모르지만, 노틸러스와 컨커러에서
보여주는 미리보기 기능은 gnome쪽이 낫더군요.)
KDE는 전반적인 사용성에 중점이 있는 것 같습니다.

KDE쪽의 gnome-vfs equivalent로는 KIO가 있습니다.
지원되는 프로토콜 수는 gnome-vfs에 비해 더 많습니다.
(ar:// 이나 locate://, man:// 같은게 있을 정도니 말 다했죠.)
유연함 같은건 둘 다 비슷비슷할 겁니다.

지리즈 wrote:
저는 이러한 것보다는 두 프로젝트 아니 다른 모든 프로젝트에 대해서
무엇보다 불만 사항은 common Dialogue의 부재입니다.

이를 테면, 파일선택창, 이미지선택창, 프린터 선택 창 등등...

이 모든 것들은 자신이 기반이되는 라이브러리(이를테면, gtk, qt)에
의존하죠..

잘못 알고 계신 것 같습니다.
kdelibs에 일반적으로 쓰이는 common dialogue는 전부다 구현되어 있습니다.
파일 선택창부터 시작해서 colorpicker, khotnewstuff, 심지어는 단축키, notification 셋팅까지 전부 표준화되어 있습니다. 그리고 대부분의 kde 어플들이 이 표준을 사용하고 있구요..

(qcomicbook이나 scribus 같은 순수 qt기반은 제외)

랜덤여신의 이미지

지리즈 wrote:
어디까지나 제 느낌은...

gnome은 기능 본연에 것에 더 중점이 두고 있고,
(이를테면, vfs같은 것은 상당히 유현하더군요. 구체적으로
KDE의 무엇이 대응되는지는 모르지만, 노틸러스와 컨커러에서
보여주는 미리보기 기능은 gnome쪽이 낫더군요.)
KDE는 전반적인 사용성에 중점이 있는 것 같습니다.


헛, 제가 느낀것과 정반대로 느끼셨군요...

gnome-vfs 에 대응하는 kde 쪽의 구성요소는 kio 입니다.
kio 와 gnome-vfs 모두 구조는 비슷할 것이라고 생각됩니다만, 수십개의 프로토콜이 지원되는 kio 에 비하면, gnome-vfs 는 아직 초기단계입니다.

kio 로 할 수 있는 것들이 많지만, 몇가지만 언급하자면:
* 파일 복사로 CD 리핑하기
* man 프로토콜
* KMail 이 메일을 보낼 때 kio 를 이용
* 웹 사이트를 컹커러로 서핑할 때, 컹커러의 업로드 대화상자에 http://어쩌구.com/어쩌구.jpg 를 입력하면, kio 를 이용해서, 그림을 받은 후 업로드

Quote:
컹커러(kio 사용)가 지원하는 프로토콜 목록

로컬 프로토콜
applications ar audiocd camera file floppy fonts home lan man mbox media programs remote rlan settings system tar trash zeroconf zip

인터넷 프로토콜
fish ftp imap imaps invitation mac nfs nntp nntps nxfish perldoc pop3 pop3s print printdb pydoc sftp smb smtp smtps svn svn+file svn+http svn+https svn+ssh webdav webdavs

그리고, 제가 느끼기로는 노틸러스와 컹커러의 미리보기 중 더 나은것은 컹커러였습니다. 노틸러스는 500여개의 그림 파일이 있는 폴더를 대략 4초 정도만에 보여주는 반면에, 컹커러는 1초만에 바로 보여주었습니다.
노틸러스는 미리보기 생성을 시작하는데 시간이 좀 걸리는 것 같습니다.

지리즈 wrote:
저는 이러한 것보다는 두 프로젝트 아니 다른 모든 프로젝트에 대해서
무엇보다 불만 사항은 common Dialogue의 부재입니다.

이를 테면, 파일선택창, 이미지선택창, 프린터 선택 창 등등...

이 모든 것들은 자신이 기반이되는 라이브러리(이를테면, gtk, qt)에
의존하죠.


네. 이 말은 맞습니다만, 최소한 KDE 쪽에서는 QT 와 독립적으로 kdelibs 를 쓰고 있습니다.
덕분에 거의 모든 KDE 어플들은 단축키 변경/설정 기능을 가지고 있습니다(개인적으로 굉장히 놀라웠던 기능입니다). 또한, 전역 단축키 기능(데스크탑 어디에서나 동작하는 단축키)도 kdelibs 에서 제공하며, 기타 표준화된 인터페이스가 많습니다.

kparts 도 표준화된 인터페이스를 만드는 데 일조합니다. 컹커러에서 돌아가는 amaroK 처럼, KDE 에서 널리 쓰이는 kparts 를 사용하여, KDE 프로그램들은 프로그램 안에 컹커러를 내장하거나, kate 에디터를 내장하거나 하는 일이 자유롭습니다.

아까 말씀드렸다시피, KDE 쪽의 "통합성" 은 굉장히 뛰어납니다.

지리즈 wrote:
저는 일종의 표준화된 wrapper layer로 작성된
Common Dialogue interface를 두고,
사용자가 윈도우 메니저뿐만 아니라,
이런 들도 선택할 수 있게 하면, 좋을 것 같습니다.

마치, X의 표준을 이용해서 윈도우 메니저가 프로그램을 제어하는 것처럼요.


헉, 공용 대화상자의 "부재" 를 말씀하신 것이 아니라, 공용 대화상자를 "선택" 할 수 있는 기능을 말씀하시는 건가요? :shock:
jinserk의 이미지

랜덤여신 wrote:

jinserk wrote:
사실 제가 원하기로는, GUI 환경도 application과 프레임웍 사이에 오가는 메시지를 표준으로 정해놓고 어떤 어플도 임의의 GUI 환경과 동작하도록 만들수 있는 세상이 왔으면 좋겠습니다만..

그래서 Freedesktop 이 있는 것이지요. Freedesktop 에서 만드는 데스크탑 표준을 GNOME 과 KDE 에서 구현하고 있습니다. 덕분에 GNOME 에서도 KDE 어플의 트레이 아이콘을 볼 수 있고, 그 반대도 가능합니다.

D-BUS 프로젝트도 비슷한 것입니다. Freedesktop 에서 만들고 있는 메시지 버스 시스템이죠. (KDE 의 dcop 에 해당합니다)

지금의 리눅스 어플은 대부분이 다른 데스크탑 환경에서도 잘 돌아갑니다. GNOME 에서도 amaroK 을 사용할 수 있고, KDE 에서도 Evolution 을 사용할 수 있습니다.

이 말씀은, GTK 가 없는 KDE 시스템에서 GNOME 어플을 돌릴 수 있다는 말씀은 아니시지요? 제가 의도한 바는 특정 GUI 라이브러리에 종속되지 않도록 어플을 만들 수 있는 메시지 표준을 의미한 것이었는데요. 생각해보면 아주 어려울 것 같긴 합니다만.. :oops:

말하자면, 현재 OS가 HAL을 포함하고, 그 위에 자바VM이 올라가고, 그위에 만들어진 모든 어플은 OS를 막론하고 돌아가는 것처럼, GUI 라이브러리도 X 위에 VM 처럼 돌아가고, 모든 어플은 그 위에 표준화된 메시지를 이용해서 돌아가도록 만드는건 어려울까요? 자바 VM 이 sun 것뿐만 아니라 IBM 이나 BEA 것도 존재하듯이 말이죠.

Leo.

지리즈의 이미지

제가 gnome의 vfs가 kde보다 낫다고 느껴지건은
속도라는 측면보다는 동영상때문이었던 것 같습니다.

랜덤여신 wrote:
헉, 공용 대화상자의 "부재" 를 말씀하신 것이 아니라, 공용 대화상자를 "선택" 할 수 있는 기능을 말씀하시는 건가요? :shock:

Qt, kdelib나 gtk Motif 등등... 이런 의존하는 라이브러리에서 자유로울 수 있는
"공용대화상자"의 "부재"를 말했습니다.(공용이 정말 공용이죠^^)

firefox가 gtk로 작성되었다고 이를 KDE에서 사용할 때
Window Title이 gtk로 나오지 않는 것처럼,
내가 KDE를 사용하면, firefox에서도 KDE선택창이 나오는 식이죠..

좀 더 나가면, 어플리케이션(x에서도 이렇게 부른다면) 메뉴 정도까지는
wrapper가 있었으면 좋겠습니다.

There is no spoon. Neo from the Matrix 1999.

랜덤여신의 이미지

jinserk wrote:
이 말씀은, GTK 가 없는 KDE 시스템에서 GNOME 어플을 돌릴 수 있다는 말씀은 아니시지요? 제가 의도한 바는 특정 GUI 라이브러리에 종속되지 않도록 어플을 만들 수 있는 메시지 표준을 의미한 것이었는데요. 생각해보면 아주 어려울 것 같긴 합니다만.. :oops:

말하자면, 현재 OS가 HAL을 포함하고, 그 위에 자바VM이 올라가고, 그위에 만들어진 모든 어플은 OS를 막론하고 돌아가는 것처럼, GUI 라이브러리도 X 위에 VM 처럼 돌아가고, 모든 어플은 그 위에 표준화된 메시지를 이용해서 돌아가도록 만드는건 어려울까요? 자바 VM 이 sun 것뿐만 아니라 IBM 이나 BEA 것도 존재하듯이 말이죠.


아... 그런 뜻이셨군요... 죄송합니다. 제가 이해력이 부족해서... :oops:

음, 그러려면, 넓은 의미의 표준이 필요하겠군요. 현재의 Freedesktop 처럼 개요만 제공하는 것이 아니라, 라이브러리 수준의 표준이 필요하겠네요.
으흐... 어렵군요. =3

지리즈의 이미지

jinserk wrote:
말하자면, 현재 OS가 HAL을 포함하고, 그 위에 자바VM이 올라가고, 그위에 만들어진 모든 어플은 OS를 막론하고 돌아가는 것처럼, GUI 라이브러리도 X 위에 VM 처럼 돌아가고, 모든 어플은 그 위에 표준화된 메시지를 이용해서 돌아가도록 만드는건 어려울까요? 자바 VM 이 sun 것뿐만 아니라 IBM 이나 BEA 것도 존재하듯이 말이죠.

jinserk님께서 하신 부분 중,
저는 일부(공용대화상자(Common Dialogue Box),메뉴)만
말한 것이군요. :oops:

There is no spoon. Neo from the Matrix 1999.

pok의 이미지

Quote:
kio 로 할 수 있는 것들이 많지만, 몇가지만 언급하자면:
* 파일 복사로 CD 리핑하기

이기능 쓸만한가요? 제 512램 노트북은 아주 죽어나던데...
그래서 그냥 ripperx를 씁니다.
(gtk1을 쓰는 (저의) 유일한프로그램입니다. :D )

랜덤여신의 이미지

pok wrote:
Quote:
kio 로 할 수 있는 것들이 많지만, 몇가지만 언급하자면:
* 파일 복사로 CD 리핑하기

이기능 쓸만한가요? 제 512램 노트북은 아주 죽어나던데...
그래서 그냥 ripperx를 씁니다.
(gtk1을 쓰는 (저의) 유일한프로그램입니다. :D )

저는 그냥 잘 되더군요. 일반 시디 리핑 프로그램하고 동일하게...

독립된 리핑 프로그램을 찾으신다면, soundjuicer(gtk2), kaudiocreator(kde) 등을 써 보세요.

lacovnk의 이미지

kdevelop을 설치하시고 kde 어플 개발 프로젝트를 보면 꽤 신기하더군요.. 앞서 말씀해주신, 그런 통합성을 위한 기본 컨트롤등이 잘 제공되는 것 같습니다.

wrapper가 많아지는 것이 성능에 꽤 영향을 주기도 할 뿐더러, 기능 구현에 불편함을 준다는 면에서 저는 마냥 추가만을 할 수는 없다고 생각합니다.

freedesktop의 행보가 궁금하군요. 앞서 말씀하신 여러 시도들이 잘 되면 좋겠습니다. 결국 어느 선을 그어야 겠지만...

살짝 원래 주제로 돌아가면..

kde같은 경우, kdelib덕분인지, 작은 프로그램이더라도 메뉴의 일관성이나, 앞서 말한 단축키 등의 꽤 가시적인 통합성을 보여줍니다.

반면, gnome의 개발환경이나, 여건은 어떤지 궁금합니다. kde가 qt위에 kdelib을 제공한다치면, gnome은 gtk위에 다른 것을 제공해주는 것이 있는건가요?

jinserk의 이미지

지리즈 wrote:
jinserk wrote:
말하자면, 현재 OS가 HAL을 포함하고, 그 위에 자바VM이 올라가고, 그위에 만들어진 모든 어플은 OS를 막론하고 돌아가는 것처럼, GUI 라이브러리도 X 위에 VM 처럼 돌아가고, 모든 어플은 그 위에 표준화된 메시지를 이용해서 돌아가도록 만드는건 어려울까요? 자바 VM 이 sun 것뿐만 아니라 IBM 이나 BEA 것도 존재하듯이 말이죠.

jinserk님께서 하신 부분 중,
저는 일부(공용대화상자(Common Dialogue Box),메뉴)만
말한 것이군요. :oops:

예.. 사실 저는 이보다 더 큰 그림을 생각해보고 있습니다. 단순히 GUI 환경만이 아니라, 아예 OS도 시스템 콜을 포함해서 유저 스페이스에서 사용할수 있는 메시지를 표준화할 수만 있다면 하드웨어 종속에서 완전히 자유로운 소프트웨어의 개발이 가능하지 않을까 하는 생각이 듭니다. JVM 의 개념이 OS로 확장되는것이죠.. (예전에 아마 자바 프로세서 얘기도 한참 있었더랬죠?)
이렇게만 된다면 크로스 컴파일 같은건 아예 불필요해지고 임의의 하드웨어에서 컴파일된 바이너리들(하드웨어종속이 아닌 일종의 IL로 컴파일된)은 다른 하드웨어의 같은 OS 에서 그대로 돌아가게 만들수 있을 것 같더군요.

어째 KDE vs GNOME 얘기하다 발제자인 제가 삼천포로 빠지는 기분이 들긴 합니다만.. :oops:

어쨌든 동일한 어플리케이션을 IA32 니 IA64 니 Power 니 하는식으로 별도로 개발 유지하는것도 꽤나 낭비라는 생각이 들어서 말입니다.. 마찬가지로 심지어 같은 하드웨어 같은 OS 에서 KDE 와 GNOME 용으로 별도로 개발하는것 역시 낭비가 아닐까 합니다. 다양성을 추구하는 것은 좋지만 지나친 다양성은 혼란만 일으킬 수도 있지요. 다양성을 보장하면서도 일관적인 환경을 갖추어야 하는 것이 앞으로 FOSS 쪽에서 더 신경써서 해야할 일 중 하나가 아닐까 싶네요.

Leo.

익명 사용자의 이미지

lacovnk wrote:
kdevelop을 설치하시고 kde 어플 개발 프로젝트를 보면 꽤 신기하더군요.. 앞서 말씀해주신, 그런 통합성을 위한 기본 컨트롤등이 잘 제공되는 것 같습니다.

wrapper가 많아지는 것이 성능에 꽤 영향을 주기도 할 뿐더러, 기능 구현에 불편함을 준다는 면에서 저는 마냥 추가만을 할 수는 없다고 생각합니다.

freedesktop의 행보가 궁금하군요. 앞서 말씀하신 여러 시도들이 잘 되면 좋겠습니다. 결국 어느 선을 그어야 겠지만...

살짝 원래 주제로 돌아가면..

kde같은 경우, kdelib덕분인지, 작은 프로그램이더라도 메뉴의 일관성이나, 앞서 말한 단축키 등의 꽤 가시적인 통합성을 보여줍니다.

반면, gnome의 개발환경이나, 여건은 어떤지 궁금합니다. kde가 qt위에 kdelib을 제공한다치면, gnome은 gtk위에 다른 것을 제공해주는 것이 있는건가요?

gnome은 gnome-libs가 있긴 한데 이게 엄청나게 엃히고 설혀서 버전별로 각각 다른기능과 특성을 제공하기에 대체 머가 머고 어떻게 해야되는건지 모릅니다.

gnome 해커들을 위한 해킹용 데스크탑입니다. 이것저것 시험해보기위한..

반면 KDE는 진정한 유저를 위한 데스크탑입니다.

gnome 은 메이져 버전도 마이너버젼에 따라 서로 호환이 안되는 경우가 많습니다. 반면 KDE는 거의 호화됩니다.

크데_그놈의 이미지

KDE의 경우 단순 환경 뿐만 아니라 포함되어있는 어플때문에 좋은 평가를 받고 또 유저들 입맛대로 고칠수 있는 특성상 많은 유저들이 좋아합니다. 반면에 그놈은 심플한 것을 추구하므로 삐까번쩍이는 UI를 기대하기는 힘듭니다.......

semjase의 이미지

15년전에는 이런 이야기를 하고 놀았군요

.

익명 사용자의 이미지

KDE는 상업적 오픈소스이고
GNOME은 기업으로부터 지원받지만 상업성에 반대하는 오픈소스
한국에서 오픈소스는 내로남불의 대명사임
한국에서는 오픈소스라는게 민주당, 대깨문이랑 하는 짓이 똑같나요. 내로남불.
공산주의 주창하지만 나는 안 하고 남들보고 하라 ㅋㅋ 무임승차 논리 ㅋㅋ

황병희의 이미지

익명 사용자 wrote:
한국에서 오픈소스는 내로남불의 대명사임

한국이 잘못했나요 오픈소스가 잘못했나요 선생이 이야기하는바를 알고 싶네요.

[우분투 18.04 파여폭스 나비에서 적었어요]

--
^고맙습니다 감사합니다_^))//

hirameki의 이미지

그냥 겉으로 보이는 경향만 따지면
기본적으로 유럽에서 시작해서 아직도 유럽사용자가 많은 KDE 는 아시아쪽 언어 설정에 아직 손이 많이 가는 편이고
시작메뉴같은 윈도우즈 친화적인 UI를 많이 채택하고 있습니다.

GNOME이나 유니티쪽은 비교적 아시아 계열에서도 많이 쓰고 있어서 CJK쪽 언어 설정이 좀 더 편하고,
UI는 설정나름이라 기본적으로 독자노선이긴 하지만, 우분투에 한해서 KDE에 비하자면 맥오에스 친화적인 편입니다.
(상단의 어플리케이션 별로 바뀌는 메뉴와 아이콘 독)

그러므로 다국어 보는건 상관없는데 딱 한국어와 영어만 입력하면 되고, 기존 윈도우즈 사용하던 유저라면 KDE도 괜찮고
여러 언어권에 걸쳐 일을 하는 다국어 입력을 해야 하는 사람이라면 (코딩중에 다국어로 커멘트를 넣는다던가)
GNOME이 시작하는데 편합니다.... 만...
어차피 추가 설정만 해준다면 KDE사용해도 되고.. 결국 써보고 맘에 드는것 쓰면 됩니다.
어차피 둘다 깔고 GNOME에서 KDE부속 Qt계열 프로그램 실행도 가능하고 그 반대도 가능하니까요.
GNOME도 compiz깔고 이것저것 꾸미기 시작하면 할거 많아요.

음? 너무 무책임한가?

--

LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
Hirameki --X-
Mail : hirameki_krjp@yahoo.co.jp
God is not customer center. Do it yourself
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.