gnome 과 KDE 의 근본적인 차이?

두개의 차이점이라.

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

또는..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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