kldp.net에 프로젝트 만들었습니다.
글쓴이: suh1978 / 작성시간: 일, 2005/02/13 - 5:06오후
x-windows용 gui 라이브러리중 c++ 용을 찾던중에
gtkmm을 찾았습니다. 벌서 버전이 2.4(개발버전은 2.5)까지
있었는데 지금까지 전혀 몰랐습니다.
현재 이것저것 테스트/숙달(?) 중입니다. 현재 kldp.net에
"BoardGame"이라는 프로젝트 만들었고, 리눅스에서 할수 있는
온라인 보드게임을 개발할 예정입니다. 물론 앞으로입니다.
아직은 그럴만한 실력/능력은 좀 부족하고요.
그래서 현재는 간단한 오목게임부터 시작해서 인공지능 기능,
온라인 게임기능까지 완성되면 웹서버 구축할 예정인데
어느정도 시간이 걸릴지는 잘 예상이 안되네요. 지금까지
파워빌더 개발자로 살고있다보니 감이잘 안옵니다.
그냥 gtkmm이라는 라이브러리도 있다라는. 혹시라도
이런게 필요하신분이 있을까 해서 적을까 했었는데
비록 비상업적이긴해도 광고처럼 되버린거 같네요~~~
Forums:
스톨먼이 쓴 글이 갑자기 떠오르네요.please use gtk..
스톨먼이 쓴 글이 갑자기 떠오르네요.
please use gtk... :)
gtkmm은 gtk의 C++ 바인딩인거 같던데...gtkmm을 쓰
gtkmm은 gtk의 C++ 바인딩인거 같던데...
gtkmm을 쓰나 gtk를 쓰나..크게 차이는 없지 않을까요..
내부적인 로직, 데이터 처리 부분은 C++로 만들고 그냥 그걸 화면에 뿌려주는
GUI부분은 gtk를 쓰고 난다음 g++로 컴파일 해도 별 무리는 없을거같은데..
전 요즘 그렇게 작업하고 있습니다. 고차원적인 GUI는 안만들어봐서 모르겠지만..
대충 그렇게 해도 별 무리는 없더군요.
gtk가 C로 짜여진 이유는 언어 바인딩을 쉽게 만들기 위해서고, 언어
gtk가 C로 짜여진 이유는 언어 바인딩을 쉽게 만들기 위해서고, 언어 바인딩을 쉽게 만들어서 결과적으로 gtk의 언어별 바인딩을 많이 만들어 놓은 이유는, 그걸 쓰라는 얘기겠죠. 잘 사용하는 언어가 있다면 그 언어로 gtk를 사용하는게 가장 좋은 것 같습니다.
(사실 언어별 구현마다 좀 이상한 것도 많지만)
----------------------------
May the F/OSS be with you..
맞는 말이긴 합니다
gtkmm이 gtk의 C++ 바인딩 정도라면
굳이 gtkmm을 개발할 필요가 있었을까 합니다.
님이 말씀하신 글을 보고서 그냥 생각나서 적어본건데
속된말로 내공이 부족해서 논리적이지는 못합니다.
아, 절대 딴지거는거 아닙니다. (혹시라도 오해하실까바요)
열정은 남자의 미래다! - suki1978 style, free style
gtkmm은 gtk의 바인딩에 "불과한" 것이 맞습니다. 하지만 gui
gtkmm은 gtk의 바인딩에 "불과한" 것이 맞습니다. 하지만 gui 프로그램은 c++로 작성하는 것이 c로 직접 작성하는 것보다는 쉽게 마련이지요. MFC나 QT가 GTK보다 진입장벽이 낮은 이유 중 하나는 C++이기 때문인 것이 아닐까 합니다. 이것만으로도 gtkmm의 존재가치는 충분하다고 생각합니다.
하지만 유닉스에서 프로그래밍을 계속 하신 분들은 아무래도 C++보다는 C를 선호하는 경향이 있지요. 저도 그 중 한명이고요. 이것은 또 gtkmm을 사용하는 프로젝트가 그다지 많지 않은 이유 중의 하나이기도 합니다.
저도 처음에 gtkmm이란게 있다는 사실을 알고 한번 써볼까 하다가...
저도 처음에 gtkmm이란게 있다는 사실을 알고 한번 써볼까 하다가...(예전에 만들어놓은 엔진부분이 C++로 되있어서...)
아무래도 크게 대중적이지 않은 라이브러리를 쓴다는게 좀 걸려서 그냥 GTK를 쓰기로 했습니다.
그리고 간단한 GUI 만들기는 GTK도 그리 어렵진않은거 같습니다.
여담입니다만.....
MFC, QT, GTK 중에.. MFC 진입장벽은 결코 낮지 않다고 생각합니다. :D
이상한 프레임워크 구조에 main 함수도 발기발기 찢어서 숨겨 버리고.....(왜 이렇게 했는지 도대체 이해가 안감)
도대체 내가 보고 있는 코드가 어디쯤에 위치한 코드인지 감도 안오고...이상한 도큐먼트, 뷰구조 란거 때문에..골치만 아프고...
차라리 VB에서 처럼 그냥 폼베이스로 이벤트에 대응하는 식으로 하는게 젤 속편하더군요.
C/C++이라고 그렇게 복잡하게 이상한 구조의 클래스라이브러리를 쓸필요는없다고 생각하는데..
언어만 다를뿐 프로그램 방식은 VB처럼 똑같이 해주면 좋을텐데요.. 잠시 구경해본 정도지만 C++ 빌더가 그런거 같더군요. 뭐 .NET에 와서는 적어도 C#,VB등에서는 그렇게 됐었지만...
윈도우즈에서는 그냥 C++/C도 .NET 내부로완전히 들어간 인터페이스를 제공했으면 합니다. managed, unmanaged..골치아프더군요..
gtk의 C++바인딩이 gtkmm이고, 그 위에 bakery라는 MVC
gtk의 C++바인딩이 gtkmm이고, 그 위에 bakery라는 MVC 프레임웍 라이브러리까지 얹으면 MFC비슷하게 만들 수 있습니다.
대중적이지 않다고 하셨는데... 꽤 대중적이고 널리 쓰이는 라이브러리 입니다.
아무래도 GUI의 메타포에는 OO적인 요소가 많은데, GTK에서는 그걸 C문법의 한계내에서 표현하느라고 약간은 무리한 부분이 있지만, gtkmm에서는 그걸 꽤 자연스럽게 처리하고 있지요.
kldp.net에 등록된 sagua라고 하는 프로젝트가 gtkmm을 사용하더군요~..~
gtk노가다(?)를 해보지 않은 분은 gtkmm의 가치를 이해하기 힘들지도 모르겠군요.
----
the smile has left your eyes...
[quote]MFC, QT, GTK 중에.. MFC 진입장벽은 결코 낮지
폼베이스에 이벤트로 대응하는 것이 속편한 방식인 것은 틀림없고, GUI프로그램은 이런 방식이 아니면 제가 아는 한 구성이 불가능합니다. MFC, QT, GTK모두 포장이 달라보일 뿐이지 근본적으로 같은 방식을 따르고 있지요. MFC에 익숙하기 전에는 이해하기 힘든 숨은 가지들이 많다는 점은 사실입니다만, 이것은 어느 것을 사용하더라도 마찬가지가 아닐까요.
그리고 도큐먼트/뷰 구조는 곧 무언가 모자란 MVC패턴인데, 이 녀석은 사실 QT에서도 마찬가지입니다. 그리고 MVC패턴 자체는 고전 중의 고전이지요. 맥 프로그래밍을 해본 적은 없습니다만, 아마 맥이나 next쪽의 툴킷도 이렇게 되어 있을 가능성이 높습니다.
ps. 윈도우 프로그램에 main이 없는 것은 저도 불만이군요. MFC로 만든 프로그램이 대체 어떻게 작동하는지 알게 되는데 몇년이 걸린 것 같습니다. 하지만 다시 말하면 그 구조도 모르면서 몇년동안 프로그램을 개발할 수 있었다는 의미도 되겠지요.
[quote="saxboy"]ps. 윈도우 프로그램에 main이 없는 것
제가 말하는 부분도 바로 이 부분인거죠. :) 전 지금도 MFC가 정확하게 어떤 구조로 동작하는지 명확하게 알고 있지 못합니다. 큰 부류로 봤을때 다 마찬가지인게 사실이지만, MFC 경우는 꼬아 놓은 정도가 좀 심하다고 생각합니다. MFC Internal을 읽어봐도 아리삼삼(?)하긴 마친가지 더군요. main만 명시적으로 나타나도 그렇게 충격적이진 않았을텐데란 생각을 가끔했었거든요. 하여튼 요약하자면 MFC 저에게는 참 어려운 놈입니다. 왠만하면 만나고 싶지 않은.......
아, 그리고, gtkmm이 널리 쓰이고 있었군요.
제가 설치해본 프로그램들은 다 gtk만 쓰는 것들이라... :oops: