GNOME보다 KDE를 더 좋아하는 이유

mokyj의 이미지

평소 KDE와 GNOME을 쓰면서 받은 느낌을 정리해 보았습니다. 어떤 환경을 쓰던 간에 자신의 목적과 취향에 맞는 것을 쓰면 그만이라고 생각하기 때문에 둘 중 어떤 게 더 뛰어나거나 어떤 것을 쓰는 게 좋다고 말하고 싶지는 않습니다. 다만 왜 내가 KDE를 선택했는지를 한 번 생각해보고 싶었습니다.

GNOME보다 KDE를 더 좋아하는 이유

리눅스를 사용한 지도 7년째 되어가는데, 그 동안 GNOME이나 KDE 중 어떤 게 더 좋다는 생각은 해보지 않았다. 아마 리눅스를 메인으로 쓰지 않고 윈도우즈를 쓰다가 가끔씩 썼기 때문에 별 느낌이 없었던 것 같다. 잘 생각은 안나지만 리눅스를 처음 썼을 즈음에는 GNOME을 더 좋아했던 것 같다.

하지만 작년부터 1년 넘게 리눅스를 메인 데스크톱으로 쓰면서 확실한 느낌이 왔다. 나는 GNOME 보단 KDE가 좋다. 그 이유는 다음 네 가지다.

1. 편의성

일단 KDE가 더 편하다. 특히 파일관리자를 볼 때, GNOME은 너무 불편하다. GNOME의 nautilus에 대한 가장 큰 불만은 왜 사이드바에서 트리뷰가 안되냐는 것이다. 또 사이드바에 기본으로 추가되어 있는 게 홈 폴더, 바탕 화면, 파일 시스템 뿐이라 자주 가는 디렉토리는 수동으로 등록해줘야 한다.(이것은 제가 잘못 알고 있던 사항이라 삭제합니다. 하지만 그 옵션을 찾기가 쉽지 않았기 때문에 기본으로 사이드바 트리뷰를 제공하는 konqueror가 제가 쓰기에 더 편하다는 생각은 변함이 없습니다) 그리고 왜 기본 설정이 새 창으로 열리도록 되어 있는지... (물론 옵션에서 조정해주면 되지만)

반면, KDE의 konqueror는 다양한 보기 모드를 지원하며, 사이드바에서 트리뷰가 된다. 또 기본으로 새 창으로 열리지도 않는다. 너무 기능이 많아 탈이기는 하지만 없어서 못 쓰는 것 보다는 낫다고 생각한다. 필요없는 기능은 안쓰면 되니까.. (웹브라우저 기능까지 포함하는 건 좀 오바인 것 같긴 하다. 파일 관리자로서의 기능만 충실했으면 좋겠는데.. 하지만 뭐 어쨌든 내가 파일관리자로만 쓰면 되니까 큰 문제는 안된다.)

2. 응집성

다음으론 KDE가 GNOME 보다 응집성이 좋다는 것이다. 관련 있는 기능들이 한 곳에 모여 있다. 예를 들면 KDE에서는 바탕화면에서 오른쪽 클릭하여 데스크톱 설정으로 들어가면 디스플레이 설정, 화면 보호기 설정, 바탕화면 설정을 모두 할 수 있는 창이 뜬다. 그러나 GNOME에서는 바탕화면 오른쪽 클릭시 바탕 화면 바꾸기 메뉴 밖에 없으며, 화면 보호기와 디스플레이 설정은 다른 곳에서 찾아야 한다. 이 세 기능은 누가 봐도 관련 있는 것들인데 이렇게 흩어져 있는 건 잘못된 것 같다. 물론 이 때문에 편의성도 줄어들고 말이다.

패키지를 볼 때도 KDE가 더 응집성이 좋다고 생각한다. KDE에서는 관련 있는 프로그램들이 kdebase, kdeutils 이런 식으로 함께 묶여 있다. 그러나 GNOME에서는 패키지들이 너무 잘게 나누어져 있다. 패키지를 잘게 나누어 놓으면 각각을 따로 설치해 쓰기에는 편할지도 모르나 KDE나 GNOME 모두 "데스크톱 환경"이라는 것을 고려할 때 KDE 처럼 몇 개의 덩어리로 묶어 이것은 하나의 환경이라는 느낌을 주는 게 좋은 것 같다.

3. 일관성

KDE용 프로그램들은 그 이름이 K로 시작하는 게 많다. 따라서 그 이름만 보고도 '이건 KDE용 프로그램이구나' 하고 쉽게 알아챌 수 있다. 또 덕분에 앞서 말한 응집성이 강해지는 효과도 있다.(밑에 답변 달아주신 sangu님과 segfault님에 의하면 이 관습도 점점 바뀌고 있다고 합니다. 아무래도 구성 요소 수가 늘어나다 보면 K 작명법을 유지하기가 어렵기는 하겠지만, 그래도 KDE의 고유한 특색이라고 생각했기 때문에 조금 아쉽습니다.)

4. 소스

KDE가 Qt를 기반으로 하여 만들어졌기 때문인지 Qt에서의 관습을 많이 따른 듯하다. Qt의 클래스 이름이 Q로 시작하듯이 KDE의 클래스 이름은 K로 시작한다. 따라서 소스를 볼 때 새로운 클래스가 나오더라도 K로 시작한다면 어디를 찾아봐야 할지(http://developer.kde.org) 금새 알 수 있다.

또 네이밍 룰도 Qt와 마찬가지로 camelCase를 사용한다. GNOME에서는 '_'로 단어 사이를 잇는 방식을 사용하는데, 이것은 이름이 길어지게 되고 깔끔해 보이지도 않아서 나는 KDE에서 사용하는 camelCase를 좋아한다.

그리고 확실히 KDE 소스가 GNOME 보다 읽기 쉽다. C++와 C의 차이 때문인지도 모르지만... 아마도 Qt는 약간 공부했지만 gtk는 거의 모르기 때문이기도 할 것이다.

이런 이유들로 나는 GNOME 보다는 KDE를 더 좋아한다. 하지만 한 가지만은 GNOME의 손을 들어줄 수 밖에 없는데, 그것은 바로 외모이다. 외모만은 정말 KDE가 맘에 안든다. KDE는 너무 원색 계열을 많이 쓰는 것 같다. 특히 파란색을 많이 쓰는데 정말 내 취향은 아니다. GNOME의 색은 맘에 든다. 비유하자면 KDE는 유화 같고, GNOME은 수채화 같다. 난 화려하고 진한 유화 보다는 간결하고 은은한 수채화가 더 좋다. KDE의 기능과 GNOME의 외모를 결합한다면 정말 좋을텐데... 역시 사람이나 사람이 만드는 프로그램이나 완벽한 건 없는 것 같다.

댓글

imyejin의 이미지

소스에 대한 것과 외모에 대한 것을 제외하고는 저도 비슷하게 생각합니다.

C++ 이름 규칙에 대한 취향은 여러가지라 사람마다 다른데,
C++ 표준라이브러리의 경우 calmelCase 가 아니라 '_' 로 단어를 연결합니다.
어느 쪽에 스타일에 더 익숙하냐에 따라 가독성이 달라지겠죠.

KDE든 GNOME이든 테마를 설정하기 나름입니다.
오히려 KDE가 GUI를 더 세부적으로 설정할 수 있어서 꾸미기에 따라서는 더 다양한 데스크탑 환경이 가능하지 않나요?

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

mokyj의 이미지

물론 꾸미기에 따라 달라지겠지만 제가 얘기한 것은 따로 설정하지 않은 기본 상태에서의 외모를 말한 것이었습니다.
제가 좀 게을러서 테마는 기본 상태 그대로 쓰는 경우가 많거든요 :)

랜덤여신의 이미지

mokyj 님께서도 말씀드렸듯이, 이러한 주제는 개인의 취향에 따른 문제이기 때문에, 해답이란 없습니다. 자신이 좋아하는 것을 잘 쓰기만 하면 됩니다. 개인적으로는 GNOME과 KDE를 모두 좋아하고, 번갈아가면서 씁니다.

개인적인 취향을 적은 글이므로, 크게 불타오르지 않는 가운데 긍정적인 토론이 있었으면 합니다.

Quote:
그리고 왜 기본 설정이 새 창으로 열리도록 되어 있는지... (물론 옵션에서 조정해주면 되지만)

우분투의 노틸러스는 폴더를 현재 창으로 여는 것이 기본값입니다. 배포판마다 다른 게 아닐까요?

Quote:
반면, KDE의 konqueror는 다양한 보기 모드를 지원하며, 사이드바에서 트리뷰가 된다. 또 기본으로 새 창으로 열리지도 않는다. 너무 기능이 많아 탈이기는 하지만 없어서 못 쓰는 것 보다는 낫다고 생각한다. 필요없는 기능은 안쓰면 되니까.. (웹브라우저 기능까지 포함하는 건 좀 오바인 것 같긴 하다. 파일 관리자로서의 기능만 충실했으면 좋겠는데.. 하지만 뭐 어쨌든 내가 파일관리자로만 쓰면 되니까 큰 문제는 안된다.)

컹커러는 훌륭한 파일 관리자이고, 다재다능합니다만, 이러한 과도한 기능 때문에 컹커러가 "너무 난잡하다"고 느끼는 사용자도 있습니다. "나에게 필요 없는 기능은 안 쓰면 된다"고 말씀하셨지만, 넘치는 것은 모자람만 못하다고 하지요. 나에게 쓸모없는 기능이 덕지덕지 붙어있는 소프트웨어보다, 나에게 꼭 필요한 기능만 빠짐없이 들어있는 소프트웨어가 낫지 않을까요? 기능이 많으면 혼란스럽기만 하지요.

이러한 현상은 비단 컹커러 뿐만 아니라 KDE 시스템 전체에 있습니다. KDE에 대한 비판 중 대표적인 것이 "너무 복잡하고", "설정 옵션이 너무 많다"는 점입니다. 이것은 소프트웨어를 자신의 입맛대로 꾸밀 능력이 있는 고급 사용자에게는 유용하겠지만, 저같은 리눅스 초보자들에게는 혼란을 주는 요인이 되기도 합니다.

물론, 말씀드렸다시피 사용자마다 "필요한 기능"이 다르기 때문에, 절대적으로 노틸러스가 좋다거나 컹커러가 좋다고 말할 수는 없는 문제입니다.

Quote:
패키지를 볼 때도 KDE가 더 응집성이 좋다고 생각한다. KDE에서는 관련 있는 프로그램들이 kdebase, kdeutils 이런 식으로 함께 묶여 있다. 그러나 GNOME에서는 패키지들이 너무 잘게 나누어져 있다. 패키지를 잘게 나누어 놓으면 각각을 따로 설치해 쓰기에는 편할지도 모르나 KDE나 GNOME 모두 "데스크톱 환경"이라는 것을 고려할 때 KDE 처럼 몇 개의 덩어리로 묶어 이것은 하나의 환경이라는 느낌을 주는 게 좋은 것 같다.

혹시, GNOME이나 KDE를 구성하는 패키지들의 이름을 외워서 일일이 설치 명령을 내리십니까? 아니지요? 'GNOME을 설치하라' 내지는 'KDE를 설치하라' 식으로 특정 그룹을 선택하여 설치 명령을 내리지 않습니까? 따라서 패키지가 함께 묶여 있든 없든, GNOME이나 KDE만 사용하고자 하는 최종 사용자에게는 아무런 차이가 없습니다.

Quote:
이런 이유들로 나는 GNOME 보다는 KDE를 더 좋아한다. 하지만 한 가지만은 GNOME의 손을 들어줄 수 밖에 없는데, 그것은 바로 외모이다. 외모만은 정말 KDE가 맘에 안든다. KDE는 너무 원색 계열을 많이 쓰는 것 같다. 특히 파란색을 많이 쓰는데 정말 내 취향은 아니다. GNOME의 색은 맘에 든다. 비유하자면 KDE는 유화 같고, GNOME은 수채화 같다. 난 화려하고 진한 유화 보다는 간결하고 은은한 수채화가 더 좋다. KDE의 기능과 GNOME의 외모를 결합한다면 정말 좋을텐데... 역시 사람이나 사람이 만드는 프로그램이나 완벽한 건 없는 것 같다.

이것은 테마의 문제이지 KDE 자체의 문제가 아닙니다. KDE도 꾸미면 얼마든지 부드럽게 만들 수 있습니다. 게다가 배포판별로 기본 테마가 다르므로 기본 테마를 따지는 것도 의미가 없습니다.
----
블로그 / 리눅스 스크린샷 갤러리 / 듣는 음악 통계
지금 듣는 곡:
sangu의 이미지

1. 편의성
KDE4 기본 파일 메니져 : Dolphin http://enzosworld.gmxhome.de/
* 사용기

Quote:

Dolphin is reminiscent of the Nautilus file browser from the GNOME desktop environment
...
Although Konqueror will no longer be the default file manager in KDE 4, it will still be available for users who rely on its advanced features and extreme flexibility.

2. 응집성
* 배포판에 설치된 것을 사용하면 되기 때문에 일반 사용자에게 패키지 갯수는 중요하지 않죠.

3. 일관성
KDE4 기본 파일 매니져가 Dolphin이군요. 그리고 GNOME2의 기본 프로그램들 같은 경우는 프로그램 이름 보다는 기본 이름을 따라 갑니다. 예를 에볼루션 같은 메일 프로그램은 메뉴에 전자메일로 표시되어 집니다.

4. 소스
* 일반 사용자가 소스를 확인할 일이 없죠.

익명사용자의 이미지

개인적인 평가입니다만...
KDE는 GNOME보다 응용프로그램들의 품질이 좋은 것 같습니다.

나름 이유를 생각해 보자면...
GNOME도 GObject라 하여 C로 OO를 구현하고 있지만
뭐랄까 정말 해커적인 사용법이고...

(만들어져 있는 클래스의 사용을 넘어)
막상 커스텀 클래스를 만들게 되면
C++은 GObject에 비해 편안함을 줍니다.

또한 기업의 입장에서 제품을 만드는거라 그런지...
트롤테크의 개발도구(큐티디자이너라던지...) 또한 좋은 것 같습니다.

이런게 좋은 응용프로그램을 양산한 배경이지 않을까 생각됩니다.

7339989b62a014c4ce6e31b3540bc7b5f06455024f22753f6235c935e8e5의 이미지

이제는 GObject를 거의 몰라도 얼마든지 그놈 애플리케이션을 작성할 수 있습니다.
C++용 바인딩도 있고, 파이썬이나 C#을 위한 바인딩도 있기 때문이죠. :) 굳이 언어에 구애받을 필요는 없다고 생각합니다.

권순선의 이미지

좋은 주제 감사합니다. 부디 재미있는 정보와 발전적인 이야기가 오고가기를 바랍니다.

kde를 좋아하시던 분들이 gnome의 장점을 발견하고, gnome을 좋아하시던 분들도 kde의 몰랐던 장점을 알 수 있는 계기가 되었으면 합니다.

moonhyunjin의 이미지

보면.

자기가 설정을 잘 알거나 프로그래밍을 할 줄아는 걸 좋아하더라고요..

<- 이거면 안되는 게 없어~
정품 소프트웨어 사용 캠패인

<- 이거면 안 되는 게 없어~
정품 소프트웨어 사용 캠패인

netkiss의 이미지

우분투의 nautilus에서는 사이트바에서 트리뷰가 나오는데요.
배포본마다 다른건가요?

mokyj의 이미지

노틸러스를 쓸 때는 보기 메뉴와 기본 설정 메뉴만 바꿔봤을 뿐 "위치"라고 되어있는 부분은 손댈 생각은 못해봤군요.

참, X팔린 일이네요..;; 있는 걸 못찾아서.. 스스로 -1점 했습니다..;;

jacojang의 이미지

저는 리눅스를 알게된 이후로 줄곧 gnome 만 사용해온 유저 입니다.
(새버젼이 나오면 잠깐씩 KDE를 써본적은 있지만 얼마 못쓰고 다시 그놈으로 돌아왔습니다.)

제 나름데로 생각하는 Gnome의 장점을 들자면....
얼마전까지 Gnome 홈페이지의 맨앞 화면에 떠있던 2.16버젼의 슬로건? 이었던 "Simply Powerful"
이 아닌가 생각 합니다.
처음 딱 마주하면 너무 썰렁하다는 생각이 들정도로 깔끔한데...
쓰다보면 "정말 필요한 기능만 앞으로 빼 놨구나..." 하는생각이 절로 듭니다.

그리고 또 하나를 들자면..."한글화"를 들고 싶습니다..
Gnome Core나 각종 App들의 한글화가 KDE 보다 잘 되어 있다는 생각이 듭니다.

--------------------------------------------------
http://www.jacojang.com

kasi의 이미지

개인적인 경험일 수도 있지만 kde응용 프로그램은 이유없이

죽을때가 좀 많은것 같습니다. gnome기반 프로그램에서 그런 현상은

본 기억이 거의 없는데 말이죠...

segfault의 이미지

위에서 말씀하셨다시피 KDE에서 소위 말하는 'K 작명법'은 더이상 장려되지 않고 있습니다.
KDE4의 새 파일 매니저인 Dolphin 뿐만이 아니라 Plasma, Oxygen, Decibel, Strigi 등 여러 구성요소들이 K 이름에서 벗어나고 있습니다.

개인적으로 꼽는 KDE의 강점이라면 빵빵한 API 지원이 아닐까 하고 생각합니다.
Qt가 제공하는 기본적인 GUI 클래스 외에도 KDE에서 제공하는 여러 가지 컴포넌트들을 갖다쓰면 외형뿐만이 아니라 어느 정도까지의 호환성도 KDE의 표준 가이드라인에 맞출 수 있지요.
DCOP (KDE4부터는 DBUS)을 이용하면 프로세스간 통신도 어렵지 않게 구현할 수 있으며 KIO를 사용하면 부가적인 네트워크 코드 없이도 KDE가 제공하는 네트워크 투명성을 십분 활용할 수 있습니다.
특히 XMLGUI라든지 KConfig XT 같은 프레임워크는 정말이지 훌륭합니다.

----
http://www.planetmono.org

mokyj의 이미지

네..이제 점점 벗어나는 건가요..

근데 조금 아쉽네요..konsole, konqueror 등의 이름을 보면서 특이하면서도 재밌다고 생각했었는데 말이죠..

권순선의 이미지

비즈니스적인 관점에서의 KDE와 GNOME 비교를 한번 생각해 보았습니다. http://kldp.org/node/81650 를 참고하세요. :-)

병맛의 이미지

컹커러보다 많이 부족하네요. 일단 탭이 없다는 게....

컹커러 = 이미지 미리 보기, ark와의 연동으로 편안한 파일 압축/해제, 북마크, 트리 보기, 탭

리소스는 많이 먹지만 파일 관리자는 컹커러가 웹 브라우저는 아이스위즐이 맡고
각각 따로 북마크를 쓰면 최상의 조합이라고 생각합니다.

컹커러 프로파일별로 북마크를 따로 사용한다면 더더욱 강력한 컹커러가 될 수 있으리라 생각되네요.
지금은 IE마냥 탐색기+웹브라우저 북마크 구분이 없거든요.

------
불가능, 그것은 아무 것도 아니다

antz의 이미지

Trolltech의 홈피에 제목이 "Code Less - Create More"이군요.
딱 맞는 것 같습니다. Qt는 정말 잘 만들어진 개발도구 인 것 같습니다.
(개발자들을 위해서도...)

그래서, 좋은 프로그램이 많이 나오는 것 같고요.
(Gnome에서도 좋은 프로그램이 있지만, KDE, Qt만큼 활발하게 만들어지고,
개발 속도를 비교하면 단기간에 쓸만한 프로그램으로 발전하지는 못하는 것 같습니다.)

그래서, KDE가 사용자에게 더 어필하지 않나? 하는 생각도 해봅니다.

어차피 Qt 프로그램이 KDE 프로그램 이지요~ :-)

---


Jabber: lum0320@jabber.org

cwryu의 이미지

"바탕 화면을 우클릭했을 때 디스플레이 및 화면 보호기 설정이 나와야 하는가"의 문제는 좀 생각할 필요가 있는데요. 디스플레이도 그렇고 화면 보호기는 더더욱 바탕 화면을 어떻게 사용할 지와 별로 관계가 없습니다.

학습효과가 아닐까요. Windows 경험이 없는 사람도 바탕화면에서 화면 보호기 설정을 찾을 지 모르겠습니다.

----
익명이나 오래전 글에 리플은 무조건 -1

nohmad의 이미지

파일관리자 좌측에 트리가 나와야 한다는 것도 윈도우 학습의 결과인 것 같습니다.

맥 OS X과 GNOME은 윈도우 스타일과 단절을 이룬 반면, KDE는 윈도우에 익숙한 사용자에게 어필하는 면이 있는 것 같습니다.

----
http://nohmad.sub-port.net

fibonacci의 이미지

저는 LaTeX을 자주 쓰는 관계로, Kile + KPDF + KDVI 환경을 사용합니다.
제 취향에 맞는 겉모습을 가진 GUI는 Gnome인 관계로, 데스크탑 기본 환경은 Gnome을 사용합니다.

그렇지만 겉모습과 일부 메뉴 구성만 Gnome을 좋아할뿐, 기능적인 면에서는 KDE가 더 편한 것 같아요.
앞의 분들이 말씀하셨듯이, 파일관리자는 컹커러가 정말 편해요.

제가 KDE를 기본 데스크탑으로 쓰지 않는 가장 큰 이유는 컹커러가 때때로 오류를 내고 종료하는 일 때문입니다.
컹커러가 뻗으면 세션을 다시 시작해야 하는 경우가 많은데, 세션을 다시 시작해도 비슷한 일이 반복되곤 하지요.

QT는 왠지 한글폰트랑 좀 친하지 않은 것도 같고요. 몇몇폰트는 읽어오다가 KDE가 먹통이 되기도 하고요.
제가 능력이 없는건지 몰라도, 어찌 고칠수 없더라고요.

그렇지만 KDE 어플리케이션은 정말이지 훌륭해요. :-)

No Pain, No Gain.

No Pain, No Gain.

nike984의 이미지

위에 다른분들께서 제가 할말을 미리 다 하신거 같네요.
제 경우는 확실히
kde쪽 어플이 좋은게 많은거 같습니다.
amarok나 basket, vym,ktorrent, kile 어느 하나
gnome 쓴다고 해서 손에서 놓을 수 있는 어플이 아닙니다.
gnome 쓰더라도 어떻게든 깔아서 같이 쓰고 있습니다.

그렇지만 저도 역시 kde용 어플은 종종 다운되는 일들을 많이 겪고 있기
때문에 kde기반으론 넘어가진 못하고 있습니다.
kde용 어플의 화려함과 gnome 시스템의 안정성이 합쳐졌으면 하고 가끔 생각합니다.

segfault의 이미지

그런데 조금 이상하네요.
제가 KDE를 써오면서 요즘에는 이유없이 프로그램이 죽는 현상은 거의 겪어 본 적이 없습니다. 근래에 kwin이 좀 말썽을 부린 적이 있었는데 버젼업하니 어느샌가 고쳐져 있고..
아마도 배포판이나 버젼, 시스템의 영향을 조금씩 타는 것 같습니다.

일단 최신 버젼으로 업그레이드 해 보시고 만약 오류가 발생한다면 core dump나 오류 메시지를 http://bugs.kde.org 에 보고하는게 좋은 방법입니다.

----
http://www.planetmono.org

echol의 이미지

Kubuntu Bridge->Edgy->Feisty 로 바꿔가며 계속 써오고 있는데 Bridge나 Edgy의 경우 kicker나 Konqueror가 이유없이 죽는 경우가 가끔 있었고요 이것보다 드물긴 했지만 Kate가 가끔 뻗어버리기도 했었습니다. Feisty로 업그레이드 하고 나서는 좋아졌네요.
이게 KDE의 문제인지 아닌지는 잘 모르겠습니다.

c0d3h4ck의 이미지

저는 그놈환경을 주로 쓰고 있는데 KDE 의 완성도 높은 어플리케이션들때문에 약간은 가렵습니다
따라서 그놈환경에서 Amarok, Kile, kdissert, BasKet Note Pads 등을 쓰고 있는데
현재 정말 만족스럽고 두 진영이 경쟁 하지 않았으면 리눅스 데스크탑이 지금 보다
심심했을 것 같습니다.

바라미의 이미지

현재 모종의 이유로 한소프트리눅스에서 KDE 를 쓰고 있지요.

하지만 그전에 쓰던 그놈이 훨씬 좋다는 느낌을 지울수가 없었습니다.

노틸러스가 대표적인데요. 저는 트리뷰 보다 그놈의 방식이 더 좋습니다. 저 위의 돌핀이라는 팡리 관리자같은걸 좋아합니다. 특히 그놈 2.14 부터 도입된 방식..(뭐라더라..) 하여간 그런 방식이 좋고요 :)
역시 이런 부분은 사람의 취향 차이겠죠 ?

그리고 그놈을 좋아하는 이유는 그놈의 간결함에 있습니다.
위의 파일관리자와도 연관되는 문제인데.
KDE는 기능은 좋습니다. 하지만 너무 기능 위주로만 발전한 턱에 너무 복잡합니다.
복잡한 것이 나쁘지 않지만, 너무 한 곳에 몰려 있어 오히려 분산되느니 못한 느낌이 많습니다.
오히려 저로서는.. GUI 툴 쓰느니 커맨드 치는게 더 간단하달까요?

윈도우도 너무 복잡한 탓에 커맨드 치느니만 못하는 경우가 많습니다.
저는 그런 윈도우가 싫어서 왔는데. 굳이 그런 닮은 것을 쓸 이유가 없지요.

반면에 그놈은 극단적으로 반대편에 서 있습니다. 너무 분산되어 있지요.
제게 그놈의 단점은 그 점을 꼽고 싶습니다. 초보자가 쓰기에는 그놈만큼 편한 것이 없습니다.
하지만 조금 스스로 조정을 하고 싶을 때에는 컨피그 파일을 까봐야 한다던지,
gconf 를 조작하는 법을 배워야 한다던지 등등.. 여러 난점이 있습니다.

그럼에도 불구하고 제가 그놈을 쓰는 이유는 제 취향이 그놈이 추구하는 심플 이라는 것입니다.

그리고 부가적으로.. 제가 처음 리눅 데탑을 접할시, qt의 라이선스가 GPL 이 아니던 시절이었습니다.
첫인상이 90%를 차지한다고.. 저는 그때 그놈을 배웠기에 그놈이 더욱 익숙하며.
또한 지금 QT가 GPL 이라고는 하지만, 저는 차라리 LGPL 인 GTK를 이용한 그놈이 더욱 좋습니다.

ddoman의 이미지

많은 사람들이 오해하는것이( 제 생각에 한국에서만 이상하게 잘못된 이미지가 쌓인것 같습니다. )
Qt의 라이센스가 반오픈소스적인 느낌을 같고 있다던지 기타 등등 잘못된 이미지를 갖고계신분들이
더러 있는데

GPL 라이센스를 지원하기전에 QPL만을 지원할 때도
(위에분이 말쓴하신 Qt가 GPL이 아니던 시절)

분명 오픈소스였습니다.
QPL은 OSI에서 인정하는 오픈소스 라이센스 중 하나이며

http://www.opensource.org/licenses/qtpl.php

GPL말고도 세상에는 BSD라이센스,모질라라이센스,php라이센스,LGPL
기타등등 오픈소스 라이센스가 무지 많습니다.

오픈소스 커뮤니티에서도 GPL을 싫어하는 사람들도 많구요.

근데 Qt에 대해서만, OSI에서 인정한 오픈소스 라이센스 중 하나인!, QPL을
가지고 명확한 이유 없이 GPL이 아니다라는 것 만으로

비판하는 분들이나 안 좋은 이미지를 가지신분들은 참 이해가 안갑니다.

부디 오해를 푸시고,
오해가 아니라 이유가 분명 있다면 이유를 적으면서 해주시길 바랍니다.

참고로 kde.org 가면
왜 kde프로젝트가 Qt를 선택했는지에 대한 문서가 있습니다.
Qt는 분명 훌륭한 오픈소스 프로젝트였고 퀄리티도 좋았습니다.

그 후에도 오픈소스에 대한 많은 지원을 꾸준히 해왔고
끝내는 GPL도 지원( QPL도 아직지원합니다. http://www.trolltech.com/products/qt/licenses/licensing/opensource/ )
도 채택했습니다.

게다가 작년에 읽은 kde.org에 포스팅 된 뉴스에는( 아마 작년 맞을껍니다. )
trolltech( Qt의 회사 )가
kde project를 위해서는 회사에 무슨일이 생기더라도 라이센스를 바꾸지않겠다는 약속을 했던기억이 납니다.

Trolltech는 제가 생각하는 가장 바람직하게 오픈소스를 이용하는 회사중 하나이고
오픈소스에 크게 기여를하며
Qt는 훌륭한 오픈소스 프로젝트라고 생각합니다.

여태 정말 많이 오픈소스커뮤니티에 기여를 해왔고 지금도 하고 앞으로도 할것이고요

GTK 또는 GNOME과 비교할때 CamelCase나 C,C++차이 기타 등의 이유로
비교를 하는것들은 이해가 갑니다만

라이센스 가지고 아직도! 이야기하시는분이 있다는것도 참 안타깝습니다.

바라미의 이미지

뭔가 오해하시는게 있는데..

저도 QT의 라이선스가 GPL 이라는건 알고 있습니다.
QPL도 알고 있고요.

하지만 저는 GPL 과 LGPL 을 비교하는 겁니다.

QT 는 상용 프로그램을 만들 경우, 라이선스 비용을 지불해야 하죠.
이점은 오픈소스가 아닌 다른 상용 어플 회사에서 QT로 만드는걸 주저하게 하는 이유가 되기도 합니다.

물론 기술 지원을 위해서 일부러 QT를 채택하는 회사들도 있지만요.

그러나 플래시 플레이어나 기타 리눅스에서 쓰는 상용 프로그램들은 많은 것들이 QT 보다는
GTK 로 만들어지고 있습니다.

물론 QT 로 만들어진 것들이 품질이 좋을수도 있습니다.( 라이선스 비용을 내는 만큼 기술지원등을 받기 편하니 말이죠.)

그러나 LGPL 에 비해서 다양하고 많은 상용 프로그램들이 나오기에는 무리가 있다고 봅니다.
(리눅스용 한글도 처음엔 QT 였다, 2005부터 GTK로 가죠..)

윈도우용 GUI 플그램 만든다고 라이브러리 비용을 내지는 않자나요? 표면적으로..
(하지만 툴킷 비용에 포함되어 있을지 누가 알아요? 다만 모를 뿐이지..)

이점에 대해서 제가 잘못 생각하고 있는 점이 있으면 지적주세요 :)

지리즈의 이미지

시장 점유율의 문제죠.

mysql도 대표적인 dual 라이센스 업체입니다.

Oracle의 Toad같은 mysql용 상용 클라이언트를 만들려면,
mysql용 OEM라이센스를 구입해야 합니다.
실제로 OEM라이센스로 제작된 상용 클라이언트가 판매되고 있지요.

KDE도 mysql 만큼 시장에서 독보적인 위치가 된다면,
non-free 어플리케이션 제작사들이 라이센스를 구입하게 될 것입니다.

이러한 Dual 라이센스 정책은 오픈소스 비지니스 모델에서 아주 권장할 만한 것이구요.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

바라미의 이미지

하지만 제가 저 위에 써 놓았듯이, 저는 GPL 라이센스보다 LGPL을 더 좋아합니다.
QT 나 GTK 처럼 많은 표준적인 라이브러리리로 쓰이는 것들은 GPL 보다는 LGPL로 되는것이 좋다고 생각합니다.

결국 상용 어플에 QT 라이브러리가 들어간다면. 그만큼의 라이센스 비용을 사용자가 부담하게 되는 것이니까요. 그 상태에서 KDE 가 독보적인 위치가 된다면 전 그 상황을 반기지 않을 겁니다.

저는 GPL 을 좋아는 하지만, 라이브러리들은 LGPL인 것이 더 자연 스럽다고 생각합니다..

그리고 마지막으로..;;

제가 써놓은 글에서.. 라이선스 이야기는 부가적인 얘기라고 써놨습니다..
라이센스를 떠나서 저는 그놈이 좋은거고, 그 시작에 라이센스가 조금 껴 있던 거였습니다.
그때하고 지금하고는 다르잖아요.
지금 보니까 저부터 시작해서 너무 라이선스에 관한 플레임성으로 가는군요 :)
이제 라이센스 얘기는 넘어가죠 :)

다른분들께는 저 때문에 이런 플레임을 보게 해드린점 죄송합니다.

Scarecrow의 이미지

http://www.trolltech.com/developer/knowledgebase/159/

위 링크에 그 대답이 잘 되어 있습니다.

오픈소스 버젼의 QT는 GPL이기 때문에 개발된 프로그램은 소스코드가 반드시 공개되어야 합니다.
(제작된 오픈소스 프로그램으로 공동체에 기여)

LGPL 라이센스의 라이브러리를 사용하고 소스를 공개하지 않으면
오픈소스를 사용하고도 오픈소스 공동체에 아무것도 돌려주지 않을 수 있습니다.
하지만 QT는 GPL 아니면 상용이기 때문에 소스를 공개하지 않기 위해서는 상용을 구입해야 합니다.
이 경우 상용 구입비용은 QT개발(오픈소스 프로그램 개발)을 위해 사용된다고 설명하고 있습니다.
(QT 구입비용으로 오픈소스-직접적으로는 QT- 제작에 기여)

저 설명을 듣고보니 굉장히 합리적인 듯 합니다.

시그너쳐: ./configure --prefix=/usr; make; sudo checkinstall

지리즈의 이미지

어떠한 것이 GPL라이센스를 채택했다고 해서,
그것이 평가절하의 이유가 되서는 안된다는 것입니다.

그리고, 수많은 상용 혹은 독점적 소스 어플리케이션들이 돈을 지불하고,
3rd 파티 상용 라이브러리를 구입해서 사용하고 있는 마당에,
듀얼라이센스를 구입하느냐 아니냐는
소프트웨어사에게 있어서 오직 선택의 문제일 뿐이지
결코 사용자 부담은 아니라고 생각합니다.

따라서, 라이브러리들은 LGPL이 더 자연스럽다는 것은 편견에 지나지 않다고 보입니다.

소프트웨어가 라이센스를 선택하는 것은 시장성을 확보하는데 있어서 방법의 문제일 뿐이지 종교는 아닙니다.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

바라미의 이미지

저는 GPL 을 평가절하하지 않았습니다..
제가 그럼 왜 리눅스를 하고 있겠습니까.
저 또한 GPL 을 무척이나 좋아합니다.

그렇게 단정지어 말하지 말아주세요 :)
저는 실생활에서도 가톨릭이라는 종교를 가지고는 있지만 거의 냉담자 수준으로 종교와는 거리가 멉니다..

음.. 거의 1년 가까이 성당에 가본적이 없네요 ;)

지리즈의 이미지

제가 좀 표현히 거친 모양이었네요.

GPL을 평가절하해서는 안된다고 한 이유는
라이브러리가 LGPL이 아니라, GPL이기 때문에,
KDE 가 독보적인 위치가 된다면 그 상황을 반기지 않는다고 하셔서,
그런 이야기를 꺼냈습니다.

그리고, 종교이야기를 꺼낸 것은 오픈소스를 신성한 것으로 여기고,
이를 상업적으로 이용하는 것에 대해서
바람직하지 않게 보는 시각들이 있기 때문에 한 것이구요.

오해가 풀리셨으면 하네요.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

바라미의 이미지

저에 대한 오해도 푸셨으면 합니다.
저는 오히려 오픈소스를 상업적으로 이용하는 것에대해 환영하는 입장입니다.
그렇지 않으면 왜 상대적으로 상업적으로 이용하기 더 쉬운 LGPL을 꺼내겠습니까?
아예 상업적으로 사용하기가 조금 까다로운 GPL 라이브러리를 쓰지 말이죠.

오히려 저는 상업적으로 쓰기에 LGPL이 더 좋을 것 같아서 gnome이 더 회사들 입장에서는 끌릴것 같다는 얘기를 하고 싶었던 겁니다.
뭐 덕분에 많은 것들을 얻어 갑니다. :)

nohmad의 이미지

LGPL은 라이브러리를 위해 만들어졌다고 해도 좋은 라이센스입니다. 라이브러리의 라이센스로 LGPL이 자연스럽다고 생각하는 것이 어떤 점에서 편견이라고 생각하시는지 모르겠습니다.

라이브러리의 라이센스를 GPL로 하면 GPL 프로그램 외에는 만들 수가 없고, 이것은 분명히 선택을 제한하게 됩니다. 트롤텍의 GPL/QPL 듀얼 라이센싱 정책은 커뮤니티와 상용 소프트웨어 제작자에게 각각 제한된 선택의 기회를 주는 것일 뿐, LGPL 보다 자유롭다고 볼 수는 없다고 생각합니다.

예를 들어, GPL로 Qt 애플리케이션을 개발하려는데, 만일 여기에 다른 오픈소스 라이브러리, 예를 들면 openssl이 필요한 경우에는 어떻게 해야 하나요? openssl 대신에 gnutls를 쓸 수 있겠지만, 만일 대응하는 GPL 라이브러리가 없거나 gnutls처럼 완성도가 떨어진다면?

----
http://nohmad.sub-port.net

지리즈의 이미지

openssl에 대해서는 분명한 예외조항을 두고 있지요.
http://doc.trolltech.com/4.3/gpl.html

GPL과 다른 라이센스하에 제작된 오픈소스들과의 연결로 인해 발생할 수 있는 라이센스상의 충돌은
Trolltech사가 아니라, GPL을 제창한 GNU 스스로가 많은 가이드라인을 제시한 상태입니다.

물론 그 중하나가 LGPL이지만, 그 방법외에도 다양한 해결책이 있습니다.

http://www.gnu.org/licenses/gpl-faq.html

그리고, 전체 오픈소스중 GPL 비중이 높아지고 있는 관계로 라이센스로 인한 충돌문제도
서서히 사그러들고 있는 추세이구요.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

cwryu의 이미지

어차피 과거의 이야기지만 사실 확인 차원에서 라이센스 문제를 이야기해 보자면, 분명히 과거 Qt의 라이센스는 non-free였습니다. 말씀하시는 QPL은 그 다음의 이야기입니다. 그리고 QPL/GPL 듀얼 라이센스가 되기 전까지는 KDE의 라이센스는 문제가 있었습니다. 정리해 보면,

nonfree 라이센스 -> QPL 1.0 -> QPL 2.0 / GPL 2 듀얼 라이센스

먼저 과거의 non-free 라이센스는 수정한 소스를 배포하는 게 금지되었습니다. 그 당시에 한글도 안 되는 Qt를 가지고 개별적으로 패치를 해서 쓰고 있었으나 배포를 할 수 없었습니다. 한글 패치를 만들었던 어떤 친구는 처음에는 패치만 배포하면 되지 않을까 하다가 트롤테크에서 안 된다는 입장을 밝혔었고, 몇번 개별 패치에 대해 트롤테크의 허락을 받고 배포를 하다가 결국 귀찮다며 때려치웠던 일이 있었습니다. (하긴 10년도 전의 이야기이니 사람들 기억에 거의 남아 있지 않을지도 :-)

왜 KDE 라이센스가 문제가 있었냐에 대해서는, Qt의 nonfree 라이센스에는 "Qt를 사용한 프로그램에 대해 GPL 라이센스를 채택하기를 요구"하는 조항이 있었습니다. (싫으면 상업버전을 구입) 하지만 이렇게 해 놓으면 Qt 라이센스와 GPL은 호환성이 없어지게 됩니다. GPL이어야 하는데 GPL과 호환성이 없는 상황, GPL로 배포되던 KDE의 존재가 분명히 모순적이었습니다. (여기에 대해 GPL의 OS major component 예외조항으로 Qt를 OS major component로 생각할 수 있다라는 반론은 분명히 있었습니다.)

http://www.debian.org/News/1998/19981008

그리고 QPL 1.0이 릴리스된 직후에도 KDE의 모순적인 상황은 명백히 해결되지 않았습니다. (또 여기에 대해서도 반론은 있었습니다. QPL이 릴리스된 상황에서, Qt를 사용했다는 것은 그냥 GPL이 아니라 Qt 링크에 대한 예외를 implied한 것이다라는 반론도 분명히 있었습니다.) 이 모순은 dual licensing이 된 후에야 종료되었습니다.

----
익명이나 오래전 글에 리플은 무조건 -1

nahs777의 이미지

제가 KDE를 더 좋아하는 이유..

1. 광역단축키.
KDE는 광역단축키를 지정하기 쉽죠. Gnome은 안됐던 것으로 기억합니다. Amarok의 플레이 / 스톱 단축키를 특정한 것으로 설정해두면 다른 작업을 하면서도 아마로크를 제어할수 있습니다.

2. 클립보드.
Gnome은 프로그램이 종료되면 그 프로그램에서 클립보드에 있었던 내용이 지워집니다.

3. 프로그램 자체의 일관성
어떤 프로그램이건 비슷한 메뉴를 가지고 있습니다. gnome은 각각 다른경우가 많죠.

4. 프로그램 자체의 완성도
개인적인 주관으로 gnome은 몇몇부분에서 약간 완성도가 떨어진다고 생각하는 어플이 있습니다. 그러나 이건 gnome이 어플숫자가 많으니 장/단점이 되겠죠.

ganadist의 이미지

1. 광역단축키

2. 클립보드
gtk+ 2.6부터 클립보드 매니져스펙이 구현되었습니다. 클립보드 매니져만 구동되어 있으면 잘 동작합니다.
3. 프로그램 메뉴
용도가 다른데 메뉴 계층이 굳이 같을 필요는 없다고 생각합니다. (개인 취향따라서 다르겠죠.)
4. 완성도
3번과 마찬가지로 취향차겠죠;;

그리고 그놈에서 어플 단축키를 바꾸는 방법을 모르시는 분이 꽤 많으시던데...

http://wiki.gnome.or.kr/index.php/GnomeTips#s-2.8

아직 그놈보다 단축키 변경을 쉽고 직관적으로 변경할 수 있는 플랫폼은 못본 것 같습니다.~

(이것도 개인 취향차일까요;; )

----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러

antz의 이미지

Quote:
2. 클립보드
gtk+ 2.6부터 클립보드 매니져스펙이 구현되었습니다. 클립보드 매니져만 구동되어 있으면 잘 동작합니다.

음. 발전이라고 할 수 있지만...
어쩔 수 없이 KDE쪽을 따라가는건 아닌지...
어느정도 타협을 하고 있는것은 아닌지 모르겠습니다.

KDE는 확실히 Gnome 보다 유기적으로 얽혀 있습니다.
처음 부터 그렇게 설계된것 같습니다.
그래서 Gnome쪽에서는 KDE가 Windows를 따라한다고 싫어하는 측면도 있었는데요.

KDE는 그런면에서는 Gnome보다는 개방적인것 같습니다.
성당과 시장을 비교하면 KDE가 시장이 아닐지 개인적인 생각입니다.
KDE는 윈도우즈, 맥 과 같은 유저들이 편해 하는것에 관심을 많이 가지고 개발 되고 있습니다.
(따라하는것 이상을 생각하며 개발을 하고 있다고 개인적으로 생각합니다.)

반면, Gnome은 독특하게 개발되고 있지요.
Geek하게 (어떤면에서는 linux데스크탑의 자존심으로) ... 그래도 이제 슬슬 조금씩 변해 가는게 아닌지 하는 생각이 드네요.
독립을 중요시 했는데... 통합 환경으로 변해 가는건 아닌지 하는 생각이 듭니다.

보충하자면,
좀 억지가 있지만,
KDE는 사용자 입장을, Gnome은 리눅스 입장을 생각하는게 아닌지 하는 생각입니다.

---


Jabber: lum0320@jabber.org

ganadist의 이미지

gnome's way
1. 있는 것을 쓴다.
2. 없으면 spec을 만들고나서 spec대로 구현한다.

kde's way
1. 일단 구현해놓고 본다.

1번의 예를 들면 html 렌더러 엔진이군요.
gnome에서는 모질라엔진을 주로 씁니다만 kde에서는 khtml을 만들어버렸죠.

2번의 예를 들면.. dock이나, 데스크탑 효과 같은걸 들 수 있습니다.
데스크탑 효과(shadow drop)의 경우에는 kde에서 xrender hack을 통해서 구현을 했지만 gnome진영에서는 데탑환경에서 할 짓이 아니다라는 의견이 대부분이었고 결국 composite manager를 통해서 효과를 구현하게 되었습니다.

dock의 경우에는 kde2, kde3에서 각각 구현했지만 gnome에서는 tray spec이 정해지고 난 후에야 들어갔습니다.

뭐 gtk/gnome의 경우에는 이미 바닥의 자원을 쓰고 있다는 전제하에서 구현되고 있습니다만, qt/kde의 경우에는 qt라는 독립적인 플랫폼 위에서 만들다 보니 이런 관행이 유지되지 않나 싶습니다.
뭐.. 프로젝트 굴러가는 분위가 대충 이렇다는 이야기죠 =33

----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러

segfault의 이미지

사족을 붙이자면 KDE에서 자체 제작한 것이 이후에 표준이 되는 경우도 있습니다. 대표적인 경우가 DBUS와 GHNS입니다.
DCOP -> DBUS인것은 아니지만, DCOP가 DBUS의 디자인에 지대한 영향을 끼쳤죠.

freedesktop.org 덕분에 양쪽 데스크톱간 호환성과 관계있는 부분에서의 격차는 점차 좁아질 듯 합니다. 예를 들면 KDE4에서는 이전까지 써 왔던 독자적인 mime 구현을 버리고 fd.o의 mime database를 이용하게 됩니다. dbus는 말할 필요도 없구요.

----
http://www.planetmono.org

keedi의 이미지

완전 동감합니다. 어느 순간 cairo를 채택하는 것도 그렇고
gnome의 변화는 변화무쌍해서 따라가는 것이 참 쉽지 않더군요.

gnome의 최고 철학(?)은 일단 있는 것 가져다 쓴다! 인 것 같습니다.
덕분에 직접 빌드하려면 의존성이... ㅜㅜ

---------------------------
Smashing Watermelons~!!
Whatever Nevermind~!!

Kim Do-Hyoung Keedi

----
use perl;

Keedi Kim

sangu의 이미지

antz wrote:

어쩔 수 없이 KDE쪽을 따라가는건 아닌지...
어느정도 타협을 하고 있는것은 아닌지 모르겠습니다.

http://freedesktop.org/wiki/Specifications_2fclipboards_2dspec

Clipboard는 KDE를 따라 간다기 보다는 freedesktop에서 제시한 표준을 따라가고 있습니다.

antz wrote:

KDE는 그런면에서는 Gnome보다는 개방적인것 같습니다.
성당과 시장을 비교하면 KDE가 시장이 아닐지 개인적인 생각입니다.

어떤 기준을 가지고 성당과 시장을 구분하시는지 모르겠지만 GNOME은 freedesktop이나 xorg 관련 개발자들 혹은 리눅스 커널 개발자들과 매우 밀접한 관계를 유지하고 있습니다.

예를 들자면 dbus/HAL, cairo가 GNOME 환경에 도입 할때 서로 다른 개발 공동체 또는 배포판 공동체/회사에 소속된 개발자들이 그놈 개발 주기에 맞추어서 개발을 했습니다. 현재도 dbus/HAL, cairo 개발 주기와 그놈 개발 주기는 밀접한 연관을 가지고 있습니다.

antz wrote:

반면, Gnome은 독특하게 개발되고 있지요.
Geek하게 (어떤면에서는 linux데스크탑의 자존심으로) ... 그래도 이제 슬슬 조금씩 변해 가는게 아닌지 하는 생각이 드네요.
독립을 중요시 했는데... 통합 환경으로 변해 가는건 아닌지 하는 생각이 듭니다.

GNOME은 Geek하고, 독립을 중요시한다는 것이 무슨 의미 인가요? GNOME은 여러 배포판 공동체/회사또 여러 개발 공동체에 소속된 개발자들이서로 협력해서 개발해 나가고 있습니다.

antz wrote:

좀 억지가 있지만,
KDE는 사용자 입장을, Gnome은 리눅스 입장을 생각하는게 아닌지 하는 생각입니다.

네. 억지 입니다. =_=

echol의 이미지

예전부터 궁금한게 있었는데 vim-gtk나 emacs-snapshot-gtk는 있는데 vim-kde나 emacs-snapshot-kde는 없거나 더이상 개발이 되지 않더군요.
우연인지 아니면 뭔가 gnome/kde 개발자의 마인드의 차이인지 궁금하네요.

antz의 이미지

저도 확답할 수는 없지만, (찾아보기도 좀 귀찮군요. ^^;)
저도 Emacs를 사용하고 있습니다만,
KDevelop을 쓰면서, 그 나름데로 사용하기 편함에 빠져있습니다.
(Emacs를 사용하는 사람들이 이 좋은 에디터를 모르는게 안타까운것 처럼,
KDevelop 역시 Emacs와 다른 좋은 에디터로 Emacs를 고집하는 사람들에게 안타까운 마음이
조금은 듭니다. ^^;;; 그만큼 편하다는 거지요~ )
emacs는 (vim도) 일반인들에게는 어려운 에디터 입니다.
그런면에서 개발툴도 일반인들이 쉽게 사용할 수 있는 방향으로 개발되는게 아닌가? 생각합니다.

KDE가 윈도우즈를 많이 따라가는 이유도 일반인들이
접근하기 편하게 하기위해서 입니다.

그리고, 저도 kubuntu를 사용하지만,
synaptic, gimp, emacs-snapshot-gtk 등을 사용합니다.
adept는 아이디어가 좋긴하지만, 기존 사용방식에서 너무 진보한것 같네요.
좀 더 빨라지고 안정적으로 되면, adept가 synaptic을 대체할것 같습니다. :-)

---


Jabber: lum0320@jabber.org

bh의 이미지

"GNOME VS KDE" 전 잘 모르겠네요..
아직 KDE를 써본적이 없습니다.
구경만 해봤다죠.. 우체국 리눅스 박스에 깔려있더라구요..;;

FreeBSD에서는 굉장히 GNOME이 잘 패키징 되어있습니다.
"gnome2"보다 한결 가벼운 "gnome2-lite"로 말이죠..

결론은.. GNOME에 조용히.. 한표..

--
이 아이디는 이제 쓰이지 않습니다.

onion의 이미지

취향상... gnome이 좋아요....
참 요즘은.. 암담하기는 합니다만.....
kde가 gnome보다 빠르다는 생각이 들기도 합니다...(아하하하)
그래도.. 뭔가 손맛이랄까.. gnome apps가 손맛이 있어서..(아하하하하하)
kde가 나쁘다는게 아니라...
어차피 terminal을 주로 사용하기때문에...
(노래 동영상.. 다 mplayer console모드...-.-)
쓰는건.. 뭐랄까..... office나..(office를 콘솔로 쓰는건 의미가 좀..-.-)
또는 웹이나..(플래쉬...우후후후)
뭐 이런것들이 아닐까 합니다.....
결과적으로 웬지.. 그냥.. 취향상.. gnome이. .맞는것 뿐이죠....

-----새벽녘의 흡혈양파-----

-----새벽녘의 흡혈양파-----

병맛의 이미지

양파옹. 노래는 mpd도 좋아요.

(덤: mpd로 스트리밍 방송 듣는 방법 혹시 없을까요?)

------
불가능, 그것은 아무 것도 아니다

warpdory의 이미지

저는 처음에 설치하는 화면에서 테마나 바꿀뿐 거의 건드리지 않고 쓰자.. 주의라서 ...
Gnome 이든 KDE 든 그냥 씁니다.

지금 데스크탑은 Gnome 이지만, 쓰는 애플리케이션은 amaroK 도 있고 ... 뭐 기타 등등 ...

어차피 gtk+, qt, 거기에 몇몇 라이브러리들만 있으면 어디서건(Gnome 이든 KDE 든) 필요한 건 다 쓸 수 있으니까요.

제 노트북은 xfce4 입니다...

---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.
http://akpil.egloos.com


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

onion의 이미지

몇몇라이브러리라고하기에는.. gnome는 숫자가 좀 많은편..-.-;
의외로 kde가 기본 라이브러리숫자는 더 적은거같아요....
(하긴 컴파일시간은 그게 그거 같기는 합니다만..ㅋㅋㅋ)

-----새벽녘의 흡혈양파-----

-----새벽녘의 흡혈양파-----

댓글 달기

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
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.