MS-Windows에서는 SendInput() 함수를 이용하여 키보드의 입력이나 마우스의 입력을 흉내 낼 수 있다.
그렇다면 Linux에서는 사용자의 입력을 흉내낼 수 있는 방법이 있을까?
궁금해서 먼저 마우스에 대해 검색을 해 보자 다음과 같은 유용한 정보를 얻게 되었다.
http://stackoverflow.com/questions/7675379/how-to-control-mouse-movement-in-linux
리눅스의 특성상, 모든 장치들이 파일을 다루는 것과 동일한 방식을 취하기 때문에,
마우스의 경우에도 /dev/input/mouse* 혹은 /dev/input/event*를 활용하여 제어를 한다는 것이었다.
직접 원하는 결과를 얻을 수 있을지 시험해 보기 전에 간단한 시험을 해 보았다.
$ sudo cat /dev/input/mice
마우스를 움직이거나 버튼을 누르면 화면에 알 수 없는 문자들이 출력됨을 알 수 있다.
최소한 실제 마우스의 이벤트에 접근할 수 있음은 알 수 있었다.
위에서 지정한 장치 이외에도 내가 사용하고 있는 시스템에서는
/dev/input/mouse1
/dev/input/event4
에서 유사한 양상을 보이고 있었다.
단, /dev/input/event1에서는 같은 작동에 대해서도 더 많은 문자들이 출력되는 듯 하였다.
링크의 게시물에 있는 소스를 약간 수정하고 에러를 수정하였습니다.
이제 빌드를 하고 루트 권한으로 실행을 하면, 마우스의 커서가 우측으로 100 픽셀씩 점프하는 것을 보게 됩니다.
소스 파일 https://docs.google.com/file/d/0B8Yj1UpwCBnhR0Fkck85WDZZaHc/edit?usp=sharing
2013년 4월 9일 화요일
2013년 3월 14일 목요일
C++에서 string 함수들
아직도 C++에 익숙하진 않지만, 어쩔 수 없이 C++로 작성된 코드를 많이 접하다 보니 그때 그때 알아가는 수 밖에는....
Linux에서 GameBoy Advanced의 에뮬레이터인 VBA(Visual Boy Advanced)를 컴파일하면서 만나게 된 에러코드 입니다.
에러 메시지만으로 보자면 type이 맞지 않아서 발생한 에러인 것으로 보입니다.
문제의 해결은 어렵지 않을 것으로 생각되는 에러이지만,
완성된 프로그램의 Source에서 에러가 발생하는 것이 잘 이해되진 않습니다.
해당 Source인 GBA.cpp의 1133 line입니다.
아마도 strrchr()의 첫번째 인자로 사용된 file의 type(const char *)이 문제인가 봅니다.
strrchr의 man page를 열어보았습니다.
이상하네요?
첫번째 인자의 type은 const char *가 맞습니다.
그럼 왜 에러가 발생한걸까요?
헤더파일이 저장되어 있는 /usr/include에서 string.h를 열어 보았습니다.
strrchr()의 함수 프로토타입이 있습니다.
238~256 line은 C++에서 호출될 경우이고 260~261 line은 C에서 호출될 경우입니다.
그런데 C++의 경우에는 함수의 프로토타입이 두가지입니다.
첫번째는 인자가 char *이고 리턴값도 char *입니다.
두번째는 인자가 const char *이고 리턴값도 const char *입니다.
소위 C++에서 얘기하는 함수 다형성(Polymorphism)의 경우인가 봅니다.
그러니까 첫번째 인자가 const char *로 사용된 경우에는 2번째에 해당하며, 리턴값도 const char *형이 되어야 하는 것인데, 우리의 소스에선 첫번째 인자는 const char *이고 리턴값은 char *였기에 문제가 되었던 거죠.
위와 같이 리턴값의 type을 const char *로 수정하니 에러가 발생하지 않습니다.
아마도 C++의 프로그래머들은 통상적인 문자열을 다룰 때, String class를 사용하니 자주 부딪히는 문제는 아닐지도 모르겠습니다.
하지만 어째서 C와는 다르게 C++에서는 "const"가 붙어 있는 경우에 대해서 이렇게 구별을 해 놓았는지 궁금해 집니다.
혹시 reference 변수와 관련된 것일까요?
const가 어디에 위치하는가에 따라 의미가 달랐던 것도 있는데 이것도 명확하지 못하니 저렇게 수정하는 게 뒤끝이 구리구리합니다.
이렇게 소스를 보는 중에 눈에 띈 하나.
char *const * argv
이건 대체 무슨 의미일까요? 에휴~~
Linux에서 GameBoy Advanced의 에뮬레이터인 VBA(Visual Boy Advanced)를 컴파일하면서 만나게 된 에러코드 입니다.
![]() |
| 컴파일 에러 |
에러 메시지만으로 보자면 type이 맞지 않아서 발생한 에러인 것으로 보입니다.
문제의 해결은 어렵지 않을 것으로 생각되는 에러이지만,
완성된 프로그램의 Source에서 에러가 발생하는 것이 잘 이해되진 않습니다.
![]() |
| GBA.cpp |
아마도 strrchr()의 첫번째 인자로 사용된 file의 type(const char *)이 문제인가 봅니다.
![]() |
| Man Page |
이상하네요?
첫번째 인자의 type은 const char *가 맞습니다.
그럼 왜 에러가 발생한걸까요?
![]() |
| string.h |
strrchr()의 함수 프로토타입이 있습니다.
238~256 line은 C++에서 호출될 경우이고 260~261 line은 C에서 호출될 경우입니다.
그런데 C++의 경우에는 함수의 프로토타입이 두가지입니다.
첫번째는 인자가 char *이고 리턴값도 char *입니다.
두번째는 인자가 const char *이고 리턴값도 const char *입니다.
소위 C++에서 얘기하는 함수 다형성(Polymorphism)의 경우인가 봅니다.
그러니까 첫번째 인자가 const char *로 사용된 경우에는 2번째에 해당하며, 리턴값도 const char *형이 되어야 하는 것인데, 우리의 소스에선 첫번째 인자는 const char *이고 리턴값은 char *였기에 문제가 되었던 거죠.
![]() |
| 수정한 GBA.cpp |
아마도 C++의 프로그래머들은 통상적인 문자열을 다룰 때, String class를 사용하니 자주 부딪히는 문제는 아닐지도 모르겠습니다.
하지만 어째서 C와는 다르게 C++에서는 "const"가 붙어 있는 경우에 대해서 이렇게 구별을 해 놓았는지 궁금해 집니다.
혹시 reference 변수와 관련된 것일까요?
const가 어디에 위치하는가에 따라 의미가 달랐던 것도 있는데 이것도 명확하지 못하니 저렇게 수정하는 게 뒤끝이 구리구리합니다.
![]() |
| getopt.h |
char *const * argv
이건 대체 무슨 의미일까요? 에휴~~
2013년 1월 3일 목요일
Unix vs. Windows
얼마 전에 썼던 [조엘 온 소프트웨어]의 다른 부분 얘기입니다.
<더불어 살기>라는 제목의 글인데 원어로는 Biculturalism이군요.
시작은 Unix와 Windows의 차이점에서 시작을 했는데,
이내 The Art of Unix Programming (에릭 S. 레이몬드 저)이라는 책이 중심이 됩니다.
전체적인 이야기의 흐름은, TAOUP를 읽고 난 후의 감상문(?) 정도의 글입니다.
하지만 TAOUP에 대해 소개하는 부분과 글의 마지막 부분 정도를 제외하면 꽤 비판적인 어조로 글을 썼습니다. 특히 중간에 다음 문장을 읽을 때에는 '적대감'마저 느끼게 되어 사뭇 놀라웠습니다.
조엘의 논조가 너무 비판적이어서 마지막에 TAOUP에 대해 언급한 장점이 오히려 비아냥거림으로 들릴 정도였습니다.
저는 TAOUP를 읽어보지도 않았고, 에릭 레이몬드에 대해서도 아는 바가 없었는데, 조엘과 에릭 둘 중에 누군가가 심하게 편향적이거나, 혹은 둘 사이가 몹시 좋지 않다는 것은 짐작할 수 있겠습니다.
지금 다시 읽어 보니, 이런 문구들도 있네요.
이 글에 대한 다른 사람들의 생각이 어떤지 궁금해서 그의 블로그에 가 보았으나, 블로그에 댓글을 달 수가 없습니다.--;
http://www.joelonsoftware.com/articles/Biculturalism.html
<더불어 살기>라는 제목의 글인데 원어로는 Biculturalism이군요.
시작은 Unix와 Windows의 차이점에서 시작을 했는데,
이내 The Art of Unix Programming (에릭 S. 레이몬드 저)이라는 책이 중심이 됩니다.
전체적인 이야기의 흐름은, TAOUP를 읽고 난 후의 감상문(?) 정도의 글입니다.
하지만 TAOUP에 대해 소개하는 부분과 글의 마지막 부분 정도를 제외하면 꽤 비판적인 어조로 글을 썼습니다. 특히 중간에 다음 문장을 읽을 때에는 '적대감'마저 느끼게 되어 사뭇 놀라웠습니다.
미네소타의 도시 세인트 폴을 한번도 벗어나보지 못한 촌뜨기 미국아이처럼 단일 문화 성향을 보이는 프로그래머가 너무도 많은데, 이런 프로그래머는 문화적인 가치와 핵심적인 인간 가치에 놓인 차이점 조차 제대로 구분하지 못합니다. 저는 윈도우가 미개하며 멍청하다고 생각하면서 윈도우 프로그래밍을 비웃는 유닉스 프로그래머를 많이 만나봤습니다. 레이몬드 또한 종종 배경을 무시한 채 다른 문화의 가치를 얕보는 함정에 빠져 있습니다.
조엘의 논조가 너무 비판적이어서 마지막에 TAOUP에 대해 언급한 장점이 오히려 비아냥거림으로 들릴 정도였습니다.
저는 TAOUP를 읽어보지도 않았고, 에릭 레이몬드에 대해서도 아는 바가 없었는데, 조엘과 에릭 둘 중에 누군가가 심하게 편향적이거나, 혹은 둘 사이가 몹시 좋지 않다는 것은 짐작할 수 있겠습니다.
지금 다시 읽어 보니, 이런 문구들도 있네요.
종종 물의를 일으키는 에릭 S. 레이몬드가...
그런데 레이몬드의 논조가 너무 극우주의(Anti-Idiotarian)에 가까워서...조엘이 에릭을 꽤 싫어하나 봅니다.
이 글에 대한 다른 사람들의 생각이 어떤지 궁금해서 그의 블로그에 가 보았으나, 블로그에 댓글을 달 수가 없습니다.--;
http://www.joelonsoftware.com/articles/Biculturalism.html
2013년 1월 2일 수요일
iPhone vs. Android Phone
기껏해야 일주일 남짓, 구닥닥리가 된 iPhone 3GS만을 사용해 보고 느낀 점....아니,
상상해 본 것이 하나 있습니다.
몇가지 어플을 설치해서 사용해 보았는데,
우연히 Square Enix의 Symphonica라는 게임을 접하게 되었고, 무척 마음에 들어서 틈만 나면 즐기고 있었습니다.
게임의 제목에 일러스트만 보아도 알 수 있는 쟝르의 게임입니다.
네, 이 게임은 리듬액션 게임이고, 특히 클래식 음악을 대상으로 하는 리듬액션 게임입니다.
아이폰의 터치 스크린과 리듬액션 게임을 접목하여 다양한 터치 방식을 취하고 있으며, 귀에 익숙한 클래식 음악들을 즐길 수 있고, 각 음악과 터치액션이 적절하게 조화를 이루어 지휘자가 된 듯 한 느낌도 잘 살린 게임이었습니다.
이 게임도, 여러번 반복해서 즐길 수 있도록 각 곡마다 랭크(성취도)를 평가하게 되어 있습니다.
C < B < A < S < SS < SSS
최저의 C Rank 부터 최고인 SSS Rank까지 존재하는데, 아직까지 평가의 기준이 무엇인지는 알아내지 못했습니다.
게임 중에 화면의 액션 노트와 터치의 타이밍에 따라서 Bravo - good - ok - miss의 네가지 평가가 주어집니다. 그리고 miss 없이 연속하여 터치 액션을 한 횟수를 combo라 하고 최대 combo의 수가 얼마인지도 평가에 포함됩니다.
곡마다 Skill Level이 존재해서 Level 1이 가장 쉽고 Level이 올라갈 수록 어려워 집니다.
지금까지 알게 된 바로는, Rank를 결정 짓는 요소는 miss가 얼마나 적은가와 최대 Combo가 얼마나 큰가로 결정 되는 것 같습니다. Bravo와 good, ok의 비중은 상관이 없지 않나 생각됩니다.
이 글의 제목과 상당히 동떨어진 얘기를 했습니다만, 이제부터 시작입니다.
높은 Rank를 받기 위해 열심히 반복을 하다보니 짜증나는 문제가 보이기 시작했는데,
간혹 곡이 빨라지고, 입력해야 할 액션 노트가 많아지면 게임이 끊어지는 문제가 발생을 하더군요. 제 모델이 이 게임을 즐길 수 있는 가장 하위모델이라 그런지 모르겠는데, 이러다보니 최고 Rank를 받는 건 거의 불가능에 가깝습니다.
그리고 이 게임에 대해 검색을 해 보니, Android Phone용으로는 출시를 하지 않았더군요.
잠시 생각해보니, Android 진영은 Android OS만이 공통일 뿐, 사용되는 CPU나 디스플레이 등이 모두 다를 수 있겠더군요. 반면에 iPhone은 모델이 몇가지 있긴하나 극히 제한된 종류이고 그 사양이 어떤지도 알 수 있습니다.
저야 비록 맛보기 무료버전으로 이 게임을 즐겼지만, 정식으로 구입을 하면 $15 정도인 것으로 알고 있습니다.
적지 않은 금액을 지불하고 구입한 게임에서 저와 같은 불편함을 호소하는 사용자가 많아진다면 제작사의 입장에서도 매우 난처하지 않을까 싶습니다. 자칫 자사의 이미지에 안좋은 영향을 끼칠 수도 있으니 말입니다.
이런 문제점을 고려한다면, 다양한 기기와 다양한 환경으로 리스크가 큰 Android 진영보다는 어디부터 어디까지 가능할지 예측이 가능한 iPhone이 리스크가 적은 시장이 아닐까 생각됩니다.
이런 리스크의 문제, 즉 무질서하고 다양한 바다와 같은 Android와 잔잔한 호수이거나 일정한 방향으로 흘러가는 강과 같은 iPhone의 차이 때문에, 이 게임은 iPhone용으로만 출시된 것이 아닐까요?
실제 그 내막이나 배경이 무엇인지는 모르겠습니다만, 어쩌면? 하는 생각에 두서없이 적어 보았습니다.
상상해 본 것이 하나 있습니다.
몇가지 어플을 설치해서 사용해 보았는데,
우연히 Square Enix의 Symphonica라는 게임을 접하게 되었고, 무척 마음에 들어서 틈만 나면 즐기고 있었습니다.
게임의 제목에 일러스트만 보아도 알 수 있는 쟝르의 게임입니다.
![]() |
| Symphonica의 일러스트 |
![]() |
| Symphonica의 게임 화면 |
아이폰의 터치 스크린과 리듬액션 게임을 접목하여 다양한 터치 방식을 취하고 있으며, 귀에 익숙한 클래식 음악들을 즐길 수 있고, 각 음악과 터치액션이 적절하게 조화를 이루어 지휘자가 된 듯 한 느낌도 잘 살린 게임이었습니다.
이 게임도, 여러번 반복해서 즐길 수 있도록 각 곡마다 랭크(성취도)를 평가하게 되어 있습니다.
C < B < A < S < SS < SSS
최저의 C Rank 부터 최고인 SSS Rank까지 존재하는데, 아직까지 평가의 기준이 무엇인지는 알아내지 못했습니다.
게임 중에 화면의 액션 노트와 터치의 타이밍에 따라서 Bravo - good - ok - miss의 네가지 평가가 주어집니다. 그리고 miss 없이 연속하여 터치 액션을 한 횟수를 combo라 하고 최대 combo의 수가 얼마인지도 평가에 포함됩니다.
곡마다 Skill Level이 존재해서 Level 1이 가장 쉽고 Level이 올라갈 수록 어려워 집니다.
지금까지 알게 된 바로는, Rank를 결정 짓는 요소는 miss가 얼마나 적은가와 최대 Combo가 얼마나 큰가로 결정 되는 것 같습니다. Bravo와 good, ok의 비중은 상관이 없지 않나 생각됩니다.
이 글의 제목과 상당히 동떨어진 얘기를 했습니다만, 이제부터 시작입니다.
높은 Rank를 받기 위해 열심히 반복을 하다보니 짜증나는 문제가 보이기 시작했는데,
간혹 곡이 빨라지고, 입력해야 할 액션 노트가 많아지면 게임이 끊어지는 문제가 발생을 하더군요. 제 모델이 이 게임을 즐길 수 있는 가장 하위모델이라 그런지 모르겠는데, 이러다보니 최고 Rank를 받는 건 거의 불가능에 가깝습니다.
그리고 이 게임에 대해 검색을 해 보니, Android Phone용으로는 출시를 하지 않았더군요.
잠시 생각해보니, Android 진영은 Android OS만이 공통일 뿐, 사용되는 CPU나 디스플레이 등이 모두 다를 수 있겠더군요. 반면에 iPhone은 모델이 몇가지 있긴하나 극히 제한된 종류이고 그 사양이 어떤지도 알 수 있습니다.
저야 비록 맛보기 무료버전으로 이 게임을 즐겼지만, 정식으로 구입을 하면 $15 정도인 것으로 알고 있습니다.
적지 않은 금액을 지불하고 구입한 게임에서 저와 같은 불편함을 호소하는 사용자가 많아진다면 제작사의 입장에서도 매우 난처하지 않을까 싶습니다. 자칫 자사의 이미지에 안좋은 영향을 끼칠 수도 있으니 말입니다.
이런 문제점을 고려한다면, 다양한 기기와 다양한 환경으로 리스크가 큰 Android 진영보다는 어디부터 어디까지 가능할지 예측이 가능한 iPhone이 리스크가 적은 시장이 아닐까 생각됩니다.
이런 리스크의 문제, 즉 무질서하고 다양한 바다와 같은 Android와 잔잔한 호수이거나 일정한 방향으로 흘러가는 강과 같은 iPhone의 차이 때문에, 이 게임은 iPhone용으로만 출시된 것이 아닐까요?
실제 그 내막이나 배경이 무엇인지는 모르겠습니다만, 어쩌면? 하는 생각에 두서없이 적어 보았습니다.
2013년 1월 1일 화요일
화성인 아키텍트?
꽤 인기가 있었던 [조엘 온 소프트웨어]를 읽다 보니, 14장의 <화성인 아키텍트를 조심하세요>라는 이야기가 있습니다.
요점만 말하면 추상적인 아키텍트와 관련된 많은 노력의 산물들이 끊임없이 고안되고 새로운 이름을 붙여서 나오지만, 현실성이 부족한 [화성인]스러운 개념으로 인해 정작 쓸모는 적고 투자해야 할 시간과 노력은 많으니, 너무 현혹되지 말라는 이야기입니다.
장의 제목이나, 이야기의 처음 시작은 추상화된 아키텍트에 관한 듯 보이지만, 조엘 스폴스키가 예를 든 분야는 분산형 컴퓨팅 시스템의 오랜 숙제인 이기종 RPC/CORBA와 관련이 있습니다.
이 기술은 다양한 컴퓨팅 환경으로 인해 상호 호환성이 떨어지는 문제를 극복하자는 취지에서 시작된 것으로 알고 있습니다.
문득, 이 장을 읽다보니, 컴퓨터와 전자기기 분야에서 오래되어 온 [표준화]와 비슷한 경우가 아닌가 하는 생각이 듭니다.
초기의 8 bit 개인용 컴퓨터의 시대가 시작하면서, 세상에는 참으로 다양한 컴퓨터가 탄생하였습니다. Apple과 Commodore, Tandy Radio Shack, Sinclare, Sharp 등등... 마치 중국의 춘추전국시대 마냥 무수히 많은 기업들이 각자의 컴퓨터를 만들었습니다.
그리고 얼마 가지 않아 사용들은 너무 많은 비슷한 컴퓨터들 사이에 혼란을 느꼈고, 호환되지 않는 소프트웨어에 불만을 가지게 되었습니다.
그리고 이런 자연스러운 요구에 부흥하여 미국의 Microsoft와 일본의 ASCII가 손을 잡고 MSX라는 표준 컴퓨터를 발표하였으나, 일본과 한국 등의 일부 국가에서만 호응을 얻었고, 그나마도 게임용 컴퓨터로 활용되어 애초의 취지는 안드로메다로 가버리고 말았습니다.
게임기의 세계에서도 이러한 노력이 있었습니다.
언제나 몇 개의 게임기 업체가 경쟁을 하는 구도를 이어가자, 사용자들은 유명한 게임을 자신의 게임기에서 즐기지 못하는 불만을 가질 수 밖에 없었고,
이러한 사용자들의 욕구를 감지한 미국의 Electronic Arts에서 3DO interactive라는 회사를 만들고, 3DO라는 게임기를 설계해 여러 회사와 콘소시엄을 체결해 일종의 공동 개발/협력을 할 수 있는 계기를 만들고자 했습니다.
하지만, 참여 업체들이 업계의 마이너 후발주자였고, 소니의 새로운 게임기 출시 등으로 제대로 빛을 보지 못하고 사그라져 버렸습니다.
어쩌면 이런 노력들은 여러 분야에서 항상 존재해 왔던 게 아닌가 싶습니다.
지금은 유물이 되어버린 VTR(Video Tape Recorder)의 VHS와 Beta 방식도 그랬고,
최근에는 표준화가 되어 실생활로 다가온 디지털 TV도 초기 아날로그 방식에서는 NTSC와 PAL로 양분되어 있었죠.
하지만 반대의 경우도 있으니,
한때 윈텔이라 불리던 Intel 기반의 IBM 호환 PC와 Microsoft의 MS-Windows 운영체제가 독점에 가까운 점유율을 보인 적도 있으나,
획일화에 염증을 낸 사용자들 덕분인지 Linux가 활성화되고 매킨토시가 다시 점유율을 높이는 것을 보면,
획일화와 다양화를 반복하는 것이 인간의 본성이 아닌가 하는 생각도 듭니다.
요점만 말하면 추상적인 아키텍트와 관련된 많은 노력의 산물들이 끊임없이 고안되고 새로운 이름을 붙여서 나오지만, 현실성이 부족한 [화성인]스러운 개념으로 인해 정작 쓸모는 적고 투자해야 할 시간과 노력은 많으니, 너무 현혹되지 말라는 이야기입니다.
장의 제목이나, 이야기의 처음 시작은 추상화된 아키텍트에 관한 듯 보이지만, 조엘 스폴스키가 예를 든 분야는 분산형 컴퓨팅 시스템의 오랜 숙제인 이기종 RPC/CORBA와 관련이 있습니다.
이 기술은 다양한 컴퓨팅 환경으로 인해 상호 호환성이 떨어지는 문제를 극복하자는 취지에서 시작된 것으로 알고 있습니다.
문득, 이 장을 읽다보니, 컴퓨터와 전자기기 분야에서 오래되어 온 [표준화]와 비슷한 경우가 아닌가 하는 생각이 듭니다.
초기의 8 bit 개인용 컴퓨터의 시대가 시작하면서, 세상에는 참으로 다양한 컴퓨터가 탄생하였습니다. Apple과 Commodore, Tandy Radio Shack, Sinclare, Sharp 등등... 마치 중국의 춘추전국시대 마냥 무수히 많은 기업들이 각자의 컴퓨터를 만들었습니다.
그리고 얼마 가지 않아 사용들은 너무 많은 비슷한 컴퓨터들 사이에 혼란을 느꼈고, 호환되지 않는 소프트웨어에 불만을 가지게 되었습니다.
그리고 이런 자연스러운 요구에 부흥하여 미국의 Microsoft와 일본의 ASCII가 손을 잡고 MSX라는 표준 컴퓨터를 발표하였으나, 일본과 한국 등의 일부 국가에서만 호응을 얻었고, 그나마도 게임용 컴퓨터로 활용되어 애초의 취지는 안드로메다로 가버리고 말았습니다.
![]() |
| MSX (사진은 후기형 기종인 MSX Turbo-R) |
게임기의 세계에서도 이러한 노력이 있었습니다.
언제나 몇 개의 게임기 업체가 경쟁을 하는 구도를 이어가자, 사용자들은 유명한 게임을 자신의 게임기에서 즐기지 못하는 불만을 가질 수 밖에 없었고,
이러한 사용자들의 욕구를 감지한 미국의 Electronic Arts에서 3DO interactive라는 회사를 만들고, 3DO라는 게임기를 설계해 여러 회사와 콘소시엄을 체결해 일종의 공동 개발/협력을 할 수 있는 계기를 만들고자 했습니다.
하지만, 참여 업체들이 업계의 마이너 후발주자였고, 소니의 새로운 게임기 출시 등으로 제대로 빛을 보지 못하고 사그라져 버렸습니다.
어쩌면 이런 노력들은 여러 분야에서 항상 존재해 왔던 게 아닌가 싶습니다.
지금은 유물이 되어버린 VTR(Video Tape Recorder)의 VHS와 Beta 방식도 그랬고,
최근에는 표준화가 되어 실생활로 다가온 디지털 TV도 초기 아날로그 방식에서는 NTSC와 PAL로 양분되어 있었죠.
하지만 반대의 경우도 있으니,
한때 윈텔이라 불리던 Intel 기반의 IBM 호환 PC와 Microsoft의 MS-Windows 운영체제가 독점에 가까운 점유율을 보인 적도 있으나,
획일화에 염증을 낸 사용자들 덕분인지 Linux가 활성화되고 매킨토시가 다시 점유율을 높이는 것을 보면,
획일화와 다양화를 반복하는 것이 인간의 본성이 아닌가 하는 생각도 듭니다.
2012년 12월 31일 월요일
입력장치의 출력기능?
버티고 버티다 이제야 겨우 옆에 두게 된 스마트폰을 쓰다 보니,
신기하고 편리한 장점들을 비집고 불편한 점이 고개를 내밀기 시작합니다.
그 가운데에서 (아마도 많은 분들이 이미 오래전부터 수없이 지적했으리라 생각되는)
문제점은 입력의 어려움이 아닐까 싶습니다.
가상 키보드를 통한 문자의 입력과,
게임 등에서 조이스틱/조이패드를 흉내낸 가상패드에 의한 입력이 그것인데요...
이러한 가상의 입력장치들이 문제가 되는 원인을 생각하다 보니,
스마트폰 혹은 터치스크린의 크기 제약에 따른 문제점이 아니라,
출력기능의 부족(?)이 원인이 아닌가 하는 생각이 들었습니다.
좀 헷갈릴 수도 있는데, 우선 정보의 전달 방향에 따라 다음과 같이 정의를 해 보겠습니다.
[입력]은 (사람 -> 장치)
[출력]은 (장치 -> 사람)
스마트폰의 가상키보드는 [입력] 기능에 [출력] 기능이 보태어져 있습니다.
위의 사진에서 보듯, 눌린 키가 어떤 것인지 시각적으로 보여주는 것이 [출력] 기능입니다.
(메시지 입력란에 출력된 문자는 가상키패드의 출력이 아니라 메시지앱의 처리 결과이므로 별개의 성격입니다.)
게임의 가상조이패드를 보면 문제가 더 명확해지는데, 이 조이패드의 [출력] 기능은 눌려진 방향으로 패드 중앙의 원이 움직이는 것인데, 통상 두툼한 엄지손가락에 가려져 잘 보이지 않아 출력 기능이 매우 취약한 편입니다.
그렇다면 원래 입력장치인 이런 장치들의 모범적인 [출력] 기능은 무엇일까요?
바로 "촉각"입니다.
데스크탑/노트북 컴퓨터에서 사용하는 키보드는 강도와 특성에 차이는 있지만 "키감"이라는 느낌을 [출력]하고 있습니다. (장치에 따라서는 소리도 한 몫 할 수 있습니다.)
조이스틱 혹은 조이패드는 이 촉각의 출력이 매우 명확하기에 사용자가 신뢰하는 장치가 되었는지도 모르겠습니다.
스마트폰 이전에는 고유한 [입력] 장치로만 인식되었던 키보드와 조이스틱/조이패드가, 사실은 그 위치를 유지할 수 있었던 것이 그들의 [출력] 기능 때문이 아니었나 새삼 돌아보게 됩니다.
신기하고 편리한 장점들을 비집고 불편한 점이 고개를 내밀기 시작합니다.
그 가운데에서 (아마도 많은 분들이 이미 오래전부터 수없이 지적했으리라 생각되는)
문제점은 입력의 어려움이 아닐까 싶습니다.
가상 키보드를 통한 문자의 입력과,
게임 등에서 조이스틱/조이패드를 흉내낸 가상패드에 의한 입력이 그것인데요...
![]() |
| 캡콤의 레지던트이블 (좌측 하단이 가상 조이패드) |
이러한 가상의 입력장치들이 문제가 되는 원인을 생각하다 보니,
스마트폰 혹은 터치스크린의 크기 제약에 따른 문제점이 아니라,
출력기능의 부족(?)이 원인이 아닌가 하는 생각이 들었습니다.
좀 헷갈릴 수도 있는데, 우선 정보의 전달 방향에 따라 다음과 같이 정의를 해 보겠습니다.
[입력]은 (사람 -> 장치)
[출력]은 (장치 -> 사람)
스마트폰의 가상키보드는 [입력] 기능에 [출력] 기능이 보태어져 있습니다.
위의 사진에서 보듯, 눌린 키가 어떤 것인지 시각적으로 보여주는 것이 [출력] 기능입니다.
(메시지 입력란에 출력된 문자는 가상키패드의 출력이 아니라 메시지앱의 처리 결과이므로 별개의 성격입니다.)
게임의 가상조이패드를 보면 문제가 더 명확해지는데, 이 조이패드의 [출력] 기능은 눌려진 방향으로 패드 중앙의 원이 움직이는 것인데, 통상 두툼한 엄지손가락에 가려져 잘 보이지 않아 출력 기능이 매우 취약한 편입니다.
그렇다면 원래 입력장치인 이런 장치들의 모범적인 [출력] 기능은 무엇일까요?
바로 "촉각"입니다.
데스크탑/노트북 컴퓨터에서 사용하는 키보드는 강도와 특성에 차이는 있지만 "키감"이라는 느낌을 [출력]하고 있습니다. (장치에 따라서는 소리도 한 몫 할 수 있습니다.)
조이스틱 혹은 조이패드는 이 촉각의 출력이 매우 명확하기에 사용자가 신뢰하는 장치가 되었는지도 모르겠습니다.
스마트폰 이전에는 고유한 [입력] 장치로만 인식되었던 키보드와 조이스틱/조이패드가, 사실은 그 위치를 유지할 수 있었던 것이 그들의 [출력] 기능 때문이 아니었나 새삼 돌아보게 됩니다.
2012년 12월 14일 금요일
GTK+ on MS-Windows
MS-Windows에서 GUI를 작성하는 방법은 Win32 SDK를 근본으로 합니다.
Win32 SDK에서 파생된 것으로 Microsoft의 MFC가 있으며, 그 외에도 여러가지 GUI 라이브러리들이 존재하는데, Linux에서 시작된 GTK+라는 라이브러리를 이용하는 방법을 알아보고자 합니다.
GTK+는 Gimp Tool Kit의 약자로 Gimp라는 유명한 공개 Graphic Software가 있는데,
아마도 이 software를 개발하면서 만든 라이브러리를 범용으로 확장한 것이 아닌가 추측이 됩니다.
Gimp의 특징은 Linux / MS-Windows / Mac 등에서 모두 사용이 가능하다는 점과 C 언어 인터페이스를 제공하므로 C와 C++에서 모두 사용이 가능하는 장점이 있습니다.
홈페이지는 http://www.gtk.org 입니다.
MS-Windows용 라이브러리는 다음에서 받을 수 있습니다.
http://www.gtk.org/download/win32.php
GTK+는 여러가지 라이브러리가 모여서 하나의 패키지를 이루고 있습니다.
이 모든 것을 별도로 받을 수도 있으나 번거로우므로 all-in-one bundle을 제공합니다.
http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.24/gtk+-bundle_2.24.10-20120208_win32.zip
다운로드 받아서 적당한 폴더에 압축을 풀면 다음과 같은 형태의 파일과 폴더가 나옵니다.
저기에 보이는 README 파일을 읽어 보면 해야할 일이 간단하게 나옵니다.
1) bin 폴더를 PATH에 추가한다.
2) "pkg-config --cflags gtk+-2.0"를 수행했을 때 적절한 문자열이 나오는지 확인한다.
3) "gtk-demo"가 제대로 수행되는지 확인한다.
4) MS-Windows theme engine을 사용하려면, etc/gtk-2.0/gtkrc에
gtk-theme-name = "MS-Windows"
라는 줄을 넣어 준다.
2번의 pkg-config는 여러가지 옵션이 있는데, 자세한 사용법은 "pkg-config --help"로 찾아 볼 수 있습니다.
몇가지 사용 결과는 다음과 같습니다.
3번의 gtk-demo를 수행하면 다음과 같이 실행이 됩니다.
여러가지 GUI component에 대한 예제를 볼 수 있으며 그 소스도 참조가 가능합니다.
그런데 이 데모를 수행하면서 다음과 같은 경고/에러 메시지가 나오는군요.
라이브러리 소스를 따로 받아서 확인해야 할 듯 합니다.
4번째의 Theme Engine이라는 것은 효과가 있는지 없는지 아직은 잘 모르겠습니다.
이제는 실제 코딩하여 빌드하는 것이 가능한지 확인해 보겠습니다.
Code:Blocks에서 Project 종류로 GTK+를 선택하면 몇가지 설정 중, GTK+의 경로를 물어보는 과정이 있습니다.
그리고 GTK+를 처음 사용하는 것일 경우에는 다음과 같이 GTK+에 대한 Global Variable 설정을 해 주어야 합니다.
여기에 base, include, lib를 지정해 주고, cflags는 "pkg-config --cflags gtk+-2.0"에서 나온 문자열을 넣어 줍니다. (cflags는 효과가 있는지 의심스럽습니다.)
이렇게 만들어진 기본 소스를 빌드해 보면 헤더파일을 찾지 못해서 에러가 수없이 나오게 됩니다.
그 원인을 찾아 보니 프로젝트가 만들어지면서 GTK와 관련된 헤더파일의 경로가 자동으로 추가되는데 몇개의 경로는 추가가 안되기도 하고 쓸데없는 경로가 추가되는 등, 좀 어처구니 없이 만들어집니다.
아마도 이것은 Code:Blocks의 오류인 듯 싶습니다.
앞서의 Global Variable 설정에서 cflags에 있는 대로 여기에 경로가 추가되었다면 문제가 없었을 것인데, Code:Blocks 내부에서 임의로 경로를 추가하는 게 아닌지 의심스럽습니다.
암튼, 이렇게 수정하고 나면 문제 없이 빌드되고 다음과 같이 실행도 됩니다.
Win32 SDK에서 파생된 것으로 Microsoft의 MFC가 있으며, 그 외에도 여러가지 GUI 라이브러리들이 존재하는데, Linux에서 시작된 GTK+라는 라이브러리를 이용하는 방법을 알아보고자 합니다.
GTK+는 Gimp Tool Kit의 약자로 Gimp라는 유명한 공개 Graphic Software가 있는데,
아마도 이 software를 개발하면서 만든 라이브러리를 범용으로 확장한 것이 아닌가 추측이 됩니다.
Gimp의 특징은 Linux / MS-Windows / Mac 등에서 모두 사용이 가능하다는 점과 C 언어 인터페이스를 제공하므로 C와 C++에서 모두 사용이 가능하는 장점이 있습니다.
홈페이지는 http://www.gtk.org 입니다.
MS-Windows용 라이브러리는 다음에서 받을 수 있습니다.
http://www.gtk.org/download/win32.php
GTK+는 여러가지 라이브러리가 모여서 하나의 패키지를 이루고 있습니다.
이 모든 것을 별도로 받을 수도 있으나 번거로우므로 all-in-one bundle을 제공합니다.
http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.24/gtk+-bundle_2.24.10-20120208_win32.zip
다운로드 받아서 적당한 폴더에 압축을 풀면 다음과 같은 형태의 파일과 폴더가 나옵니다.
![]() |
| GTK+ 압축을 푼 결과 |
저기에 보이는 README 파일을 읽어 보면 해야할 일이 간단하게 나옵니다.
1) bin 폴더를 PATH에 추가한다.
2) "pkg-config --cflags gtk+-2.0"를 수행했을 때 적절한 문자열이 나오는지 확인한다.
3) "gtk-demo"가 제대로 수행되는지 확인한다.
4) MS-Windows theme engine을 사용하려면, etc/gtk-2.0/gtkrc에
gtk-theme-name = "MS-Windows"
라는 줄을 넣어 준다.
2번의 pkg-config는 여러가지 옵션이 있는데, 자세한 사용법은 "pkg-config --help"로 찾아 볼 수 있습니다.
몇가지 사용 결과는 다음과 같습니다.
![]() |
| pkg-config 사용 예 |
3번의 gtk-demo를 수행하면 다음과 같이 실행이 됩니다.
여러가지 GUI component에 대한 예제를 볼 수 있으며 그 소스도 참조가 가능합니다.
그런데 이 데모를 수행하면서 다음과 같은 경고/에러 메시지가 나오는군요.
라이브러리 소스를 따로 받아서 확인해야 할 듯 합니다.
4번째의 Theme Engine이라는 것은 효과가 있는지 없는지 아직은 잘 모르겠습니다.
이제는 실제 코딩하여 빌드하는 것이 가능한지 확인해 보겠습니다.
Code:Blocks에서 Project 종류로 GTK+를 선택하면 몇가지 설정 중, GTK+의 경로를 물어보는 과정이 있습니다.
그리고 GTK+를 처음 사용하는 것일 경우에는 다음과 같이 GTK+에 대한 Global Variable 설정을 해 주어야 합니다.
![]() |
| GTK+에 대한 설정 화면 |
이렇게 만들어진 기본 소스를 빌드해 보면 헤더파일을 찾지 못해서 에러가 수없이 나오게 됩니다.
그 원인을 찾아 보니 프로젝트가 만들어지면서 GTK와 관련된 헤더파일의 경로가 자동으로 추가되는데 몇개의 경로는 추가가 안되기도 하고 쓸데없는 경로가 추가되는 등, 좀 어처구니 없이 만들어집니다.
![]() |
| 처음에 만들어졌을 때, 추가된 헤더파일의 경로 |
![]() |
| 추가된 헤더파일의 경로를 수정한 결과 |
앞서의 Global Variable 설정에서 cflags에 있는 대로 여기에 경로가 추가되었다면 문제가 없었을 것인데, Code:Blocks 내부에서 임의로 경로를 추가하는 게 아닌지 의심스럽습니다.
암튼, 이렇게 수정하고 나면 문제 없이 빌드되고 다음과 같이 실행도 됩니다.
피드 구독하기:
글 (Atom)






















