GUI 표시 용도로 쓰이는 폰트

컴퓨터에서 폰트, 글꼴이라는 건 말 그대로 사람이 읽는 문자를 찍는 용도로 널리 쓰인다.
그런데 그것만이 전부가 아니다. 문자는 그 자체로 생각보다 굉장히 정교한 그래픽 데이터이며, 그걸 빠르게 보기 좋게 찍어 주는 소프트웨어는 매우 강력한 벡터 그래픽 엔진에 속한다. 이걸 다른 그래픽 요소를 출력하는 용도로 얼마든지 활용할 수 있다.

1. Marlett

단적인 예로 Windows의 경우.. 95부터 7까지 15년 가까이 존속했던 '고전 테마'의 GUI 요소들은 상당수가 글꼴 출력이었다.
체크 박스의 체크 표시, 라디오 버튼의 동그라미, 창의 최소화/최대화/닫기 버튼, 콤보 상자 오른쪽에 붙은 ▼ 모양 말이다.

이것들의 정체는 Marlett이라는 트루타입 글꼴에 들어있는 글립이다. 다음 그림은  이 글꼴에 들어있는 글립들을 표시한 것이다. 모양들이 다들 기억에 남아 있고 익숙할 것이다.
하드코딩된 비트맵이 아니라 이렇게 윤곽선 글꼴로 처리하면 다양한 크기에 대응 가능하다는 이점이 생긴다.

사용자 삽입 이미지

겨우 27,724바이트밖에 하지 않는 아담한 크기이며, 제공되는 글립은 저게 전부이다. Windows 95내지 NT4 이래로 내용이 한 번도 바뀐 적이 없는 듯하다.
라디오 버튼은 잘 알다시피 흑백 음영이 져 있는데, 왼쪽 절반은 흰색으로, 오른쪽 절반은 검정으로 그려서 구현했다는 것을 쉽게 유추할 수 있다. 더구나 응용 프로그램이 크기 조절이 가능한 상태라고 우측 하단에 표시되는 빗금무늬도 알고 보니 이 글꼴의 글자였다.

그런데 어지간한 프로그램의 글꼴 목록에서 Marlett이라는 이름의 글꼴을 본 적이 있는 분은 별로 없을 것이다. 얘는 일반적인 한글 내지 영문용 글꼴이 아니라 Wingding 같은 심벌 전용 특수 글꼴이기 때문에 그렇다.

지금이야 저런 dingbat 심벌들을 모두 독립된 코드값을 부여해서 새로운 문자로 만들어 주는 시대이지만, 옛날에는 유니코드는커녕 2바이트 문자 코드조차도 생소했다. 그러니 기성 문자 코드에 없는 custom 그림문자들은 아스키 코드 번호에다가 글꼴만 달리해서 찍는 게 불가피한 관행이었다. 또한, 그런 용도로 만들어진 심벌 전용 글꼴은 언어별로 필터링을 해서 글꼴 목록을 출력하는 프로그램에서는 이름이 조회되지 않았던 것이다.

Marlett은 MS Sans Serif, System (-_-;; ), Wingding처럼 16비트 Windows 시절부터 존재했던 글꼴도 아니니.. 이름이 더욱 생소할 수밖에 없다. 이 글꼴의 존재를 확인하려면 '문자표'처럼 진짜로 원초적인 글꼴들을 몽땅 나열해 주는 프로그램을 써야 한다.

아직도 잊혀지지 않는데.. 과거에 Windows 95는 알 수 없는 이유로 인해 주기적으로(몇 달 간격?) 글꼴 시스템이 맛이 가곤 했다. 그래서 창의 최소/최대화 버튼처럼 Marlett 글꼴을 써서 출력되던 GUI 요소들이 깨져서 Small Fonts 기준의 숫자나 알파벳으로 바뀌어 찍혔다. 원인은 잘 모르겠지만 운영체제를 강제로 '안전 모드'로 몇 번 재부팅을 해 주면 문제가 해결되었다.

그리고 요즘은 반대로.. 일반적인 숫자와 문자로 찍혀야 할 문자열들이 Marlett 기준으로 엉뚱하게 깨져서 찍히는 문제가 발생하기도 하는가 보다. 난 직접 본 적은 없다.

사용자 삽입 이미지

오늘날의 Windows에서는 고전 테마가 공식적으로는 사라졌지만, 고전 테마 형태의 GUI 요소를 그려 주는 DrawFrameControl 같은 함수는 여전히 존재한다. 그게 없어질 수는 없다. 그러니 Marlett 폰트도 legacy 명목으로 언제까지나 남아 있을 것으로 보인다.

2. 설치 프로그램/부팅 화면에서 쓰이는 폰트

운영체제는 GUI를 제공하는 셸이란 걸 갖추고 있는데, 사실은 그 전에 운영체제의 설치 프로그램도 동일한 셸을 기반으로 GUI를 제공해야 한다.
그렇기 때문에 Windows 원본 디스크의 내부를 뒤져 보면 *.ttf 파일이 존재하는 걸 볼 수 있다. Windows를 다 설치했을 때와 동일한 규모는 아니고, 그냥 설치 프로그램 GUI를 표시하는 데 필요한 정도만 존재한다.

Windows XP쯤부터는 쌩 텍스트 모드라는 게 없어졌다. 그래서 시꺼먼 배경의 명령 프롬프트 전체 화면에서도 한글이 언제나 16*16 비트맵 글꼴로 찍힌다.
그리고 Vista부터는 16*16 비트맵 글꼴이 찍히는 명령 프롬프트 전체 화면이라는 게 없어졌다. 그 대신, 부팅이나 설치 중간에 시꺼먼 배경의 전체 화면이 필요할 때 표시되는 글자들이 16픽셀이 아니라 24픽셀 이상으로 커졌다.

사용자 삽입 이미지

이것들은 다 kor_boot라는 트루타입 글꼴에 포함돼 있는 비트맵 글립이다. 다만, 영문은 설치 때는 똑같은 굴림 계열이고, 설치 후의 부팅 관리자에서는 Lucida Console로 차이가 나는 것 같다.
그리고 하나 더..
Windows 8부터는 운영체제의 부팅이나 설치/업데이트 작업이 진행 중일 때 동그라미 5개가 뱅글뱅글 돌아가는 애니메이션이 나오기 시작했다.

사용자 삽입 이미지

이 애니메이션의 기술 기반은 gif나 avi 따위가 아니라.. 역시 글꼴이다!
malgun_boot라는 글꼴 파일을 보면 U+E000대 사용자 정의 영역에 110프레임이 넣는 각 모양들이 일일이 그려져 있다. 이 글자들을 짧은 시간 동안 연달아 찍게 하면 동그라미 5개가 뱅글 돌면서 들어갔다가 나오는 애니메이션이 그려진다.

위의 움짤은 저 폰트의 글립을 연달아 찍고 화면을 캡처해서 저장하는 프로그램을 본인이 직접 작성하고 돌려서 20분 만에 만든 것이다.

사용자 삽입 이미지

이렇듯, 부팅 때 잠깐 쓰이는 (1) 한글 비트맵 글꼴과 (2) 동그라미 애니메이션용 글꼴이 거론되었는데.. 얘들은 설치 프로그램뿐만 아니라 설치가 완료된 Windows 자체도 사용하는 폰트이다. 하지만 Windows에서 _boot이라는 이름을 가진 폰트 파일이 딱히 조회되지는 않는다.

고전 테마 GUI 글꼴은 앞서 살펴본 바와 같이 Marlett이라고 알려져 있으며, FixedSys, System, MS Sans Serif 같은 옛날 티 팍팍 나는 초 구닥다리 글꼴들도 다 C:\Windows\Fonts에 *.fon이라는 파일 형태로 존재한다. 그럼 저것들은 어디에 콕 짱박혀 있는지, 실체가 어디에 존재하는지가 매우 궁금해진다.

사용자 삽입 이미지

Windows Vista/7부터 마소에서는 Segoe UI라는 이름의 폰트 시리즈를 밀기 시작했다.
처음에는 본편만 있다가 8부터는 Segoe UI Symbol이라는 게 추가됐으며, 얘의 PUA 영역에는 위에서 보다시피 체크박스, 컴퓨터 전원 버튼, 웹브라우저 뒤로-앞으로 버튼, 그리고 좌우상하 방향, 배터리 충전 상태 등...

어지간한 도구모음줄 버튼 아이콘까지 다 폰트 형태로 제공되기 시작했다.
단색으로 단순화됐으면서 크기 조절은 마음대로 되니까.. 폰트가 괜찮은 선택인 셈이다.
원래는 이모지까지 담고 있다가 이모지가 단독으로 워낙 방대해지니 이건 Segoe UI Emoji라는 전용 폰트로 분리되어 나갔다. 한 8.1이나 10쯤부터?

3. 나머지

운영체제뿐만 아니라 응용 프로그램도 자신만의 UI 요소를 간편하고 깔끔하게 출력하기 위해 폰트를 사용한다.
예를 들어 Visual Studio IDE의 경우, 각종 창들을 사용할 때만 툭 튀어나오게 하거나, 아니면 붙박이로 고정(pin)시킬 수 있는데, 그 상태를 나타내는 아이콘이 바로 자체 폰트이다.

초창기 버전인 Visual Studio .NET은 이를 위해 VisualUI라는 폰트를 임시 등록하곤 했다.
아래의 글립들을 보시라. 0x5부터 0x7의 자리에 있는 주사기 비스무리한 아이콘이 바로 저것이다.

사용자 삽입 이미지

.NET의 초기 버전은 자기가 실행돼 있는 동안 VisualUI 폰트가 시스템 전체에 등록되어서 이름을 조회할 수 있었다. 이는 불필요한 side effect이므로 후대 버전에서는 그렇게 되지 않게 바뀌었다.

또한 Outlook도 자체 UI를 표시하기 위한 폰트를 구비하고 있었다. MS Outlook이라는 폰트가 있는데, 아래와 같은 글립만 들어있는 작고 단촐한 폰트이다.

사용자 삽입 이미지

이것도 후대 버전에서부터는 티가 나지 않기 시작했다. 참고로 폰트를 시스템 전체가 아니라 자기 프로세스 내부에만, 더구나 디스크 상의 파일이 아니라 메모리 데이터만으로 간편하게 임시 등록하는 함수는 Windows 2000에서부터 처음으로 추가됐다(AddFontMemResourceEx). 자기들도 프로그램 만들 때 필요하니까 추가한 것이 분명해 보인다.

그럼, 개인적으로 하나 궁금한 것을 예를 들면서 글을 맺도록 하겠다.
저런 기하학적인 UI 이미지 중에는 뭔가 공간이 부족한 환경에서 "나머지도 마저/모두 표시"(Show all / More)라는 의미를 갖고 있는 이중 갈매기(angled bracket) 마크가 있다. >> 요거 말이다. 오른쪽을 가리키고 있는 게 제일 많으며 드물게 아래로 향할 때도 있다.
부등호와 비슷하게 생겼지만 명칭이 부등호는 절대 아니다. 이건 마이너스(빼기)와 dash/hyphen이 다른 것만큼이나 다르며, 번호 #과 조표 #이 다른 것만큼이나 다르다.

사용자 삽입 이미지

이렇듯, 요 마크는 사용자가 심심찮게 접한 적이 있을 것이다.
어째 공교롭게도 Windows XP 시절의 옛날 UI에서 더 눈에 많이 띄는 것 같다만.. 그래도 저 표시가 옛날 UI의 전유물인 것은 아니다.

더구나 Windows 9x 초창기부터 존재했던 물건도 아니다. 그렇기 때문에 의외로 Marlett 폰트에는 존재하지 않는다. 딱 거기 있을 법해 보이는데도 불구하고 말이다.
아래로 향하는 모양은 Windows 2000/ME 시절, 딱 저 personalized menu 때문에 즐겨 쓰였고, 오른쪽으로 향하는 모양도 저렇게 90년대 말이나 2000년대 초부터 등장한 것같다.

본인은 이것도 뭔가 모처의 폰트를 사용해서 출력하는 것이지, 비트맵은 아닐 거라고 생각한다. 하지만 정확한 출처를 발견하지 못했다. comctl32나 shell32 내부에 비트맵으로라도 존재하지 않을까 생각했지만 그런 건 없었다. 그 출처가 궁금하다. 빨리 감기/되감기 버튼처럼 채워진 삼각형이 두 개 붙은 모양은 각종 심벌 글꼴에 아주 흔하게 존재하는 반면에 저 모양은 유난히 눈에 띄지 않더라.

참고로 MFC에서는 하드코딩된 비트맵 형태인 게 맞다. MS Office의 외형을 흉내 내는 기능이 있으니 저런 마크를 출력하는 기능도 응당 있을 텐데.. 소스를 들여다보니 그냥 비트맵이었다. 약간 허무함이 느껴졌다. 명칭은 afxmenuimages.h에 선언돼 있는 IdArrowShowAll (아래), IdMoreButtons (오른쪽)이다.

사용자 삽입 이미지

Posted by 사무엘

2020/01/11 08:33 2020/01/11 08:33
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1704

1. 테두리

GUI 프로그램에서 대화상자를 만들다 보면 단순히 글과 그림, 목록, 버튼 같은 것만 집어넣는 게 아니라 그 컨트롤들을 성격별로 분류하는 구획 경계선, 테두리 같은 걸 그어야 할 때가 있다.
그런 게 필요하면 static 컨트롤을 쓰면 된다. Visual C++의 리소스 에디터 상으로는 Static text와 Picture control이 서로 다른 항목으로 나뉘어 있지만, 둘 다 운영체제의 윈도우 클래스 이름은 동일하게 "Static"이다.

Picture 컨트롤을 삽입한 뒤 속성에서 Type을 Etched Vert으로 고르면 세로줄이 만들어지며, Etched Horz를 고르면 가로줄이 만들어진다. 그리고 Type을 Frame으로 지정하고 Color를 Etched로 지정하면 사각형 테두리를 만들 수 있다.
선을 단순히 단색으로 그리는 게 아니라 음각으로 파인 듯이 3D 입체 효과(?)가 나게 그리기 때문에 etched라는 단어가 자꾸 나온다.

그런데 Picture 컨트롤만 있는가 하면 그렇지는 않다. 우리가 잘 아는 Group box라는 컨트롤도 있어서 사각형 테두리를 친다는 점에서는 Picture하고 거의 같은 역할을 한다.
단, Group box는 테두리의 좌측 상단에 간단한 텍스트를 찍을 수 있다. 그래서 이 테두리 안에 속한 컨트롤들의 전체 제목이나 카테고리 이름을 넣을 수 있기 때문에 더 유용하다.

또한, 이런 이유로 인해 Group box는 테두리의 윗변은 무작정 맨 위쪽이 아니라, 그 텍스트의 중앙 라인에 맞춰서 그어진다. 아래 그림을 보면 이게 무슨 말인지를 알 수 있다. (크기가 서로 동일한 Group box와 Picture frame이 화면에 실제로 보이는 형태)

사용자 삽입 이미지

Group box는 말 그대로 한 그룹에 속하는 컨트롤들(특히 라디오/체크 박스)의 가로· 세로 경계선과 제목 텍스트까지 한큐에 표시해 주기 때문에 굉장히 유용하다. 그런데 프로그램들에 따라서는 static text 옆에다가 가로줄 하나만 추가해 넣어서 Group box의 간소화 버전인 일종의 Group line을 넣기도 한다. 이 역시 위의 그림에 형태가 묘사되어 있으며, 독자 여러분도 이런 GUI를 많이 보신 적이 있을 것이다.

본인은 새로운 대화상자를 디자인할 때 Group box를 쓸지 Group line을 쓸지를 종종 고민하곤 한다. 가끔은 line이 box보다 더 깔끔하게 느껴질 때도 있다. line은 추가적인 좌우 여백을 소모하지 않기 때문에 공간 활용면에서도 좋다.

하지만 line은 group과는 달리, 텍스트와 가로줄을 서로 폭을 정확하게 계산해서 그려 주는 컨트롤이 없기 때문에 만들기가 불편하다. static text 따로, 가로줄 따로 두 컨트롤을 일일이 만들어야 한다. 텍스트의 글꼴이나 내용이 바뀌면 가로줄의 위치와 길이도 프로그램이 수동으로 업데이트해야 하니 번거롭다.

개인적인 생각은 (1) 길쭉하게 만들어 놓은 static 컨트롤에다가 텍스트를 찍은 뒤 나머지 오른쪽 여백에다가는 글자 크기 기준으로 중앙에 etched 가로줄을 자동으로 그려 주는 옵션을 추가하거나, (2) 기존 group box 컨트롤에 사각형 테두리가 아니라 가로줄만 찍는 옵션이 좀 있어야 한다고 본다. group box를 크기를 줄인다고 해서 group line로 만들 수는 없기 때문이다.

하지만 어느 것도 갖춰져 있지 않기 때문에 심지어 마소에서 만드는 프로그램들도 대화상자를 Spy++로 들여다보면 Group line은 별 수 없이 텍스트+가로줄로 수동으로 구현돼 있다. 아쉬운 점이 아닐 수 없다.
그래서인지.. MS Office 제품 중에서 운영체제의 대화상자를 사용하지 않고 자체 GUI를 사용하는(너무 역사가 길어서) Word와 Excel은 서식 대화상자 같은 걸 보면 group line이 상대적으로 많이 쓰였고, PowerPoint, Access, Publisher처럼 상대적으로 늦게 개발된 프로그램들은 group box를 더 많이 볼 수 있다.

내 심증은.. Word와 Excel은 한 개체만으로 간단하게 제목과 가로줄까지 group line을 표시해 주는 GUI 컨트롤/위젯을 자체적으로 보유하고 있는 것으로 보인다. 그 증거로는 Excel과 PowerPoint의 '화면 확대 배율' 대화상자 스크린샷이다. PowerPoint는 진짜 운영체제의 static 컨트롤 가로줄이지만 Excel은 그게 아니기 때문에 가로줄의 색깔이 두 프로그램이 서로 다른 걸 알 수 있다.

사용자 삽입 이미지

같은 제품 안에도 프로그램끼리 이렇게 미묘하게 일관성이 없는 부분이 존재한다.
그 뿐만이 아니다. 고전 테마에서는 group box의 선 모양과 static 컨트롤의 etched 선이 저렇게 똑같지만, 다른 테마가 적용되고 나면 둘의 선 모양이 달라진다. XP 시절의 Luna 테마든, 그 뒤의 Aero든.. 마찬가지다. 어느 것이든 group box의 선이 통상적인 etched 선보다 더 연해진다.

사용자 삽입 이미지

더욱 놀라운 사실은 따로 있다. 사실 group box는 윈도우 클래스가 Static이 아니라 Button이다. 이 정도로 Static 컨트롤과는 애초부터 기술적인 연결 고리가 없었다.
check나 radio 버튼은 비록 push 버튼과는 성격이 다르지만 그래도 BN_CLICKED라는 이벤트를 날려 준다는 공통점이 있으니 같은 버튼이라는 게 이해가 된다만.. group box는 포커스도 안 받고 이벤트도 없고.. 버튼과는 하등 공통점을 찾을 수 없는 static 장식품에 불과한데 도대체 왜 얘까지 Static이 아닌 버튼 소속인 걸까?

(더구나 라디오 버튼의 소속을 분류하는 것도 그 컨트롤들이 자체적으로 갖고 있는 WS_GROUP 스타일로 하지, 딱히 group box가 기여하는 건 없다. group box 안 만들어도 "1~3 중 택일, 4~7 중 택일" 같은 라디오 버튼들의 선택 영역 구분은 얼마든지 할 수 있다.)

Windows에서는 같은 버튼이라는 클래스인데 스타일을 무엇을 주느냐에 따라서(BS_GROUPBOX) 외형과 동작이 완전히 다른 윈도우가 되는 것이다. 먼 옛날 1.0 시절에는 리소스가 하도 부족해서 기본 윈도우 클래스를 새로 등록하는 것조차도 부담스러워서 가능한 한 같은 클래스에다가 여러 기능을 구겨넣기라도 해야만 했는가 보다. 하지만 group box가 왜 버튼 출신이며 기존 etched 선과 괴리가 생겼는지는 여전히 내 머릿속에 이해되지 않는 의문으로 남아 있다.

2. 버튼

말이 나왔으니 다음으로 버튼 얘기를 더 계속해 보도록 하자.
아래 그림은 평범한 라디오/체크/푸시 버튼과 탭 컨트롤을 고전 테마 기준으로 집어넣어 표시한 모습이다.

사용자 삽입 이미지

그런데, 라디오와 체크 버튼은 Button 출신답게 자기 자신도 버튼처럼 표시되게 하는 옵션이 있다. 바로 BS_PUSHLIKE 스타일. (BS_PUSHBUTTON은 윈도우의 동작 자체를 푸시 버튼으로 결정하는 스타일이니 혼동하지 말 것.)

사용자 삽입 이미지

저렇게 하니 라디오/체크도 푸시 버튼과 외형이 거의 똑같아진다. 그래도 키보드 포커스를 받았을 때 라디오/체크 버튼은 푸시 버튼처럼 테두리가 굵어진다거나 하지는 않기 때문에 실제로 조작해 보면 푸시 버튼과는 뭔가 다른 게 느껴진다.
라디오와 체크 버튼은 자신이 클릭된 경우 자신이 눌러지고 선택된(체크된) 상태로 바뀌는 반면, 진짜 푸시 버튼은 선택된 상태 같은 건 존재하지 않는다. 눌러도 다시 도로 튀어 올라온다는 차이점이 있다.

한편, 위의 그림에서 나오듯, 사실은 탭 컨트롤도 경계선 없이 각각의 탭의 이름만을 버튼처럼 표시하는 옵션이 있다(TCS_BUTTONS).
탭 버튼은 라디오 버튼과 비슷하지만 키보드로 조작할 경우, 화살표 키만 누른다고 해서 선택이 바로 이동하지 않는다. Space를 눌러서 선택을 확인해 줘야만 바뀐다는 차이가 있다.

도대체 이런 기능이 왜 존재하나 싶겠지만, 이 물건은 우리에게 아주 친숙하다. 먼 옛날, Windows 95의 작업 표시줄이 바로 탭 컨트롤에다가 이 스타일을 써서 구현돼 있었다. 물론 지금이야 작업 표시줄은 독자적인 비주얼과 기능이 너무 많이 들어갔기 때문에 진작에 자체 구현으로 바뀌었다.

이로써, 푸시 버튼처럼 생긴 놈이 푸시 버튼 자체뿐만 아니라 최소한 세 종류가 더 있을 수 있다는 뜻인데..
얘들도 테마를 변경하면 사정이 좀 달라진다.
Button들은 테마가 적용되어 버튼이 알록달록하게 바뀌지만 탭 컨트롤의 버튼들은 변화가 없다. 작업 표시줄 말고는 딱히 쓸 일이 없어져서 그런 듯하다. 글쎄, MDI 에디터 같은 데서 문서 탭을 나타낼 때 쓸 수도 있지 않으려나 모르겠다만..

사용자 삽입 이미지

이로써 버튼이 전혀 아니지만 클래스가 Button인 놈(group box), 버튼처럼 생겼지만 버튼이 아닌 놈(탭 버튼)을 모두 살펴보았다.
Windows XP~7이라는 과도기를 거쳐 8~10까지 나온 마당에 이제 운영체제에서 고전 테마는 더욱 보기 어려워지고 마치 XP Luna만큼이나 역사 속으로 사라져 가고 있다.
하지만 지금 생각해 봐도 고전 테마는 단순하면서도 굉장히 철저한 원칙 하에 세심하게 디자인된 것 같다. 화면에 표시만 하는 놈은 회색, 사용자와 interation을 하는 부분은 흰색에다가 두꺼운 입체 테두리, 포커스를 받은 아이템은 점선, 실제로 선택된 아이템은 highlight 색 등등..

그렇게도 사용자 감성, 인터페이스를 중요시한다면서 애플 맥 진영은 옛날에 GUI가 어떠했나 모르겠다. 안 그래도 마소가 애플의 GUI를 베꼈다고 험담이 많이 나돌던데.
그렇게 고전 테마 때 일관되게 형성되었던 GUI 가이드라인이 오히려 테마가 적용되면서, 당장 겉으로 드러나는 비주얼은 더 화려해졌을지 모르나, 그런 질서가 좀 무너진 듯한 것도 보여서 아쉬움이 남는다. 아무래도 고전 테마를 처음 만들던 때와 지금, 개발자가 세대 교체가 돼서 그런 것일 수도 있고.
그나저나 group line은 세대를 초월하여 진짜로 운영체제 차원에서 기능이 좀 있었으면 좋겠다.;;

Posted by 사무엘

2016/08/20 08:38 2016/08/20 08:38
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1263

사용자의 마우스 클릭에 동작하는 GUI 요소들은 일단은 버튼의 down이 아니라 up 시점 때 반응을 한다. 모든 버튼(push, check, radio 공히)이나 하이퍼링크들이 이렇게 동작하며, 우클릭 메뉴도 오른쪽 버튼을 뗐을 때 튀어나온다. 그리고 이 타이밍 때 그 이름도 유명한 BN_CLICKED라는 notify 메시지가 부모 윈도우에 전달된다.

그에 반해, down 때 바로 반응을 하는 것은 스크롤 바나 슬라이더나 스핀(옆의 숫자를 증가시키거나 감소시키는 up-down 컨트롤)처럼 누르고 있는 동안 '연타'의 여지가 있는 버튼, 아니면 어떤 명령이 즉시 실행되는 게 절대로 아님이 보장되는 첫 단계 메뉴(파일, 편집, 보기) 정도로 국한된다.

그런데 이건 어떨까? 버튼인데, 사용자가 누르고 있는 동안만 풍선 도움말이나 다른 추가적인 정보가 튀어나오고, 버튼을 떼면 그것들이 사라진다. down과 up만 감지하면 되고 그 사이에 연타 개념은 없다.
이건 일단 Windows의 표준 컨트롤에는 없는 기능인 듯하다. 하지만 의외로 요런 UI가 쓰인 경우가 존재한다.

가장 먼저 떠오르는 예는 2007 버전이 나오기 전, 과거의 MS Excel이다. 선에 안티앨리어싱이 없는 건 그렇다 치더라도 색깔이 요즘 것에 비해서 우중충하고 덜 예뻐 보인다.

사용자 삽입 이미지

옛날에 엑셀에는 차트 마법사를 통해서 차트를 만들곤 했다. 1단계는 차트의 종류를 고르는 단계였는데, 아래의 길쭉한 버튼을 살포시 누르고 있으면 지금 사용자의 데이터가 어떤 형태의 차트로 표시되는지 preview를 잠시 볼 수 있었다.
버튼을 한번 눌렀다 뗄 때마다 preview 모드와 선택 모드가 toggle 형태로 바뀌는 게 아니라는 점을 주목하자. 상당히 독특한 UI가 아닐 수 없다. 왜 이렇게 만들었을까?

어지간하면 그냥 대화상자의 왼쪽에 차트의 type과 sub-type을 트리 컨트롤 같은 걸로 모두 때려박고, 오른쪽 전체에 preview 화면을 할당해도 될 듯하지만 그렇게 하기에는 오버헤드가 너무 크고, 또 차트의 타입 자체를 그림으로 표시하기 위한 공간도 많이 필요하니 이런 식으로 preview는 필요할 때 잠깐만 볼 수 있게 UI를 만든 듯하다.

참고로 Office 2007과 그 이후부터는 전통적인 차트 마법사가 없어지긴 했지만, 차트의 종류를 선택하는 대화상자 자체는 남아 있다. 단, 이렇게 버튼을 누르고 있는 동안 preview를 잠깐 보는 기능은 없어졌다.

원래 운영체제의 표준 버튼은 아까도 얘기했듯이 눌렀다 뗀 뒤의 BN_CLICKED 이벤트만 있지, 저렇게 눌러진 것에 대한 이벤트는 제공하지 않는다. 그러니 저런 기능을 구현하려면 일반적으로는 윈도우 프로시저를 서브클래싱하여 마우스 좌클릭과 Space/Enter 누름을 감지해서 좀 불편하게 구현해야 한다.
하지만 MS Office 제품 중에 Word와 Excel은 대화상자 컨트롤들을 운영체제 함수 대신 자체 GUI 엔진으로 구현했기 때문에 편법 없이 저런 기능들이 처음부터 자연스럽게 구현이 가능했을 것이다.

그리고 또 다른 예는 아주 최신 프로그램이다. 바로 Internet Explorer 11.

사용자 삽입 이미지

IE는 최신 버전이자 아마 마지막 버전이 될 것으로 보이는 11이 굉장한 쇄신을 한 것 같다. 예전보다야 가벼워지고 속도가 빨라지고, 텍스트 입력란이 TSF A급으로 바뀌고, 굴림체로 찍히던 기본 글꼴이 맑은 고딕으로 바뀌는 등 변화가 많다.

얘는 웹사이트 내부의 입력란에서 ID와 비번을 입력하기 시작했을 때 오른쪽에 자그마한 버튼이 뜬다. ID 입력란의 오른쪽 끝에는 X 버튼이 생겨서 이걸 누르면 ID가 싹 다 지워진다. 물론 지우는 동작은 눌렀다가 '뗐을 때' 행해진다.
그런데, 비번 입력란의 오른쪽에는 눈알 모양의 버튼이 생기며, 이 버튼을 누르고 있으면 동그라미로 표시되는 암호 문자열의 실제 문자열이 잠시 보인다. 이것 역시 마우스 버튼을 떼는 순간 원상복귀된다!

(1) 엑셀의 차트 미리보기와, (2) IE에서 비번 훔쳐보기가 이 동작에 상당히 적절하게 배치된 경우라고 생각된다. peek라는 동작을 표현한다고나 할까. 이것 말고 요런 동작이 유용하게 쓰일 만한 상황이나 이미 적용된 예가 무엇이 있는지 궁금하다.

마우스 포인터를 갖다대고 있는 동안 뭔가 도움말이나 추가 정보가 나타나는 UI는 그리 새삼스러운 물건이 아니다. 이미 20년 전부터 툴팁이라고 불리는 풍선 도움말이 그 역할을 하고 있으니 말이다.
단, 터치스크린에서는 click과 hover가 구분이 없기 때문에 저렇게 가리키고 있는 것을 표현할 수 없으니 누르고 있는 동안만 뭔가 추가 정보를 표시하는 기능이 더욱 필요할 것이다.

이렇게 글을 바로 맺기는 아까우니 MS Office에서만 볼 수 있는 독특한 UI를 두 가지 좀 늘어놓도록 하겠다.

1. 먼저, 탭 컨트롤의 각각에 Alt 액셀러레이터가 붙은 모양이다. 난 워드나 엑셀을 쓸 때마다 늘 신기하다고 생각해 왔다.

사용자 삽입 이미지

Alt 액셀러레이터는 IsDialogMessage라는 대화상자 전용 메시지 처리 함수가 구현해 주는 것이고, Alt는 윈도우 텍스트를 기반으로 한 윈도우당 한 글자씩만 배당된다. 그러므로 저게 정석적으로 가능하려면 각각의 탭 헤더가 마치 라디오 버튼처럼 독립된 윈도우를 구성하고 있어야 하나, 운영체제의 탭 컨트롤은 그런 구조를 하고 있지 않다.

Alt+단축키를 눌렀을 때 탭 컨트롤의 탭이 어떻게든 전환되게 하는 것 자체는 불가능하지 않다. 하지만 그러려면 윈도우 프로시저 수준이 아니라 해당 응용 프로그램의 메시지 loop 차원에다가 예외적인 처리가 필요하다. MFC로 치면 해당 대화상자의 PreTranslateMessage 함수를 굳이 새로 구현해야 한다.
그래서 본인은 MS Office의 저런 프로퍼티 시트 대화상자를 보면 신기하다는 생각이 든다.

2. 그리고, 라디오 버튼을 더블 클릭하면 대화상자가 OK(확인)으로 종료되는 것도 꽤 독특하다.
요즘 Office 프로그램들이야 워낙 기능이 방대하기 때문에 공간을 아끼기 위해 콤보 박스를 주로 쓰지, 라디오 버튼을 보기는 힘들지만.. 대표적으로 '화면 확대'라든가 탭의 종류를 고르는 화면에서 이를 확인할 수 있다.
아.. 그러고 보니 리스트 박스에서 아이템을 더블 클릭했을 때 대화상자가 재량껏 OK로 종료되는 건 생소하지 않다. 하지만 라디오 버튼을...? 한번 생각해 보시기 바란다.

Posted by 사무엘

2015/07/13 08:45 2015/07/13 08:45
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1115

맥 OS는 화면 상단에 붙박이로 메뉴가 있어서 모든 프로그램들이 동일한 메뉴 표시줄을 공유한다. 이게 Windows로 치면 응용 프로그램의 메뉴 겸 작업 표시줄의 시작 메뉴, 그리고 심지어 시스템 트레이의 역할까지 한다.
그러나 Windows는 각각의 창이 자신의 고유한 메뉴 표시줄을 갖는 구조이다. 이건 맥과 Windows가 무려 1.0 시절부터 서로 다르게 설계한 디자인이다.

그래서 Windows에는 응용 프로그램의 기본 메뉴뿐만이 아니라 어떤 창이라면 공통으로 갖는 창 자체에 대한 메뉴도 있는데, 이것을 '시스템 메뉴'라고 한다. 창 자체를 이동하거나 크기를 조절하고, 최소화/최대화를 시키거나 닫는 고정적인 명령들이 있다. 마우스로는 좌측 상단에 있는 해당 프로그램의 아이콘을 클릭하면 되고, 키보드로는 Alt+Space를 누르면 된다.

옛날에 3.x 시절에는 '작업 목록(지금으로 치면 작업 관리자와 비슷)'을 꺼내는 명령도 시스템 메뉴에 있었는데 그건 Windows 95부터 없어졌다. 그땐 시작 메뉴나 작업 표시줄 같은 게 없었기 때문에 Alt+Tab 외에 응용 프로그램간 전환을 하는 방법을 그런 식으로 마련해 놓을 필요가 있었던 것이다.

그런데 창의 시스템 메뉴는 기본 메뉴의 연장선의 성격을 지님과 동시에 한편으로 우클릭 팝업 메뉴의 형태로도 부를 수 있다. Alt나 F10을 눌러서 기본 메뉴를 열어서 좌우 화살표 키를 누르면 기본 메뉴와 더불어 시스템 메뉴로도 순환이 된다.
그러나 창의 제목 표시줄을 우클릭하면 창의 시스템 메뉴만 따로 우클릭 메뉴의 형태로 꺼낼 수 있으며, 이때는 좌우 화살표를 눌러도 기본 메뉴가 표시되지는 않는다. 사실, 시스템 메뉴를 우클릭 메뉴 형태로 꺼내는 건 Windows 95에서부터 추가된 새로운 UI이긴 하다.

그리고 Windows 95에서는 메뉴의 아이템들 중 하나를 default로 지정하여 진하게 강조되어 출력하는 UI가 추가되었다. 당장 시스템 메뉴에서 확인할 수 있는데, 이것은 디자인 컨셉상 우클릭 메뉴에서 쓰라고 도입되었다.
화면에서 어떤 개체를 더블 클릭했을 때 취해지는 default 동작이 해당 개체의 우클릭 메뉴에 포함되어 있다면, 그 동작에 해당하는 메뉴 아이템을 진하게 출력하면 된다.

그래서 파일 열기 대화상자에서 파일이나 디렉터리를 우클릭하면, 탐색기에서 파일/디렉터리를 우클릭했을 때는 없던 '선택/Select'라는 명령이 추가되고 이것이 진하게 표시된 것을 확인할 수 있다.
또한 똑같이 창의 시스템 명령을 꺼냈더라도 아이콘을 클릭했을 때는 '닫기'가 진하게 나오고, 제목 표시줄을 우클릭했다면 '최대화' 명령이 진하게 나오는 것을 알 수 있다. 창의 해당 부위를 더블 클릭하면 실제로 그 동작이 행해지기 때문이다. 우클릭 메뉴의 default 아이템에는 이런 의미가 있는 것이다.

사용자 삽입 이미지사용자 삽입 이미지

그런데 운영체제의 이런 동작에는 버그가 있다.
최대화된 프로그램의 제목 표시줄을 우클릭하면 '이전 크기로'가 진하게 나와야 하고, 최대화되지 않은 프로그램의 제목 표시줄을 우클릭하면 '최대화'가 진하게 나와야 한다.
그러나 탐색기, IE, MS 오피스 프로그램, Media Player 등, 마소에서 개발한 프로그램들은 그렇게 동작하지 않으며, 언제나 '닫기'만이 진하게 나온다. 시스템 메뉴를 직접 꺼냈을 때처럼 말이다.
그 반면, 메모장이나 <날개셋> 편집기 같은 프로그램은 바르게 동작한다. 어찌 된 일일까?

사용자 삽입 이미지사용자 삽입 이미지

여러 프로그램들의 동작을 관찰해 보면, 차이는 단 하나뿐이라는 걸 알 수 있다.
바르게 동작하는 프로그램은 운영체제의 기본 메뉴를 사용하는 프로그램이다. 그 반면, 자체적으로 구현한 메뉴를 사용하느라 기본 메뉴를 사용하지 않는 프로그램은 제목 표시줄을 우클릭했을 때 default 아이템이 제대로 처리되지 않고 언제나 '닫기'만 진하게 나온다. 신기하지 않은가?

Windows라는 운영체제는 창을 생성할 때 또는 아예 창의 클래스를 등록할 때 메뉴 핸들을 같이 전달할 수도 있을 정도로 메뉴 처리를 각별히 신경 써서 만들어졌음에도 불구하고, 이젠 마소에서 자체 기본 메뉴를 구시대 물건으로 치부하고 매우 천대하고 있다. 이것은 어제오늘 트렌드가 아니다. 마소에서 직접 만드는 네임드급 프로그램들 중에 기본 메뉴를 사용하는 프로그램이라고는.. 거의 없다. 자체 메뉴를 쓰는 것도 모자라서 그걸 다 리본 UI로 대체하거나, 아니면 탐색기나 IE의 경우 Alt를 눌렀을 때에만 메뉴가 잠깐 나타난다. 그러니 제목 표시줄을 우클릭했을 때 '최대화'가 진하게 나오는 광경을 보기가 더욱 힘들어지고 있는 것이다.

게다가 본인이 확인한 바로는 이건 거의 Windows 98때부터 동일하게 이러고 있다. 크기 조절과 최소화· 최대화가 가능한 프로그램 윈도우치고 어떤 형태로든 메뉴가 없는 창은 보기가 힘들다. 그러니 이런 버그가 상대적으로 눈에 잘 안 띄었던 것인지도 모르겠다. Windows 95때는 컴의 성능도 열악하고, 그 시절에는 마소에서 만든 프로그램들도 거의 다 기본 보급 메뉴를 썼기 때문에 확인이 쉽지 않다.
아무튼 이거 굉장히 흥미로운 현상이다. 구닥다리 레거시 코드에 존재하고 딱히 심각한 문제도 아니니, 앞으로도 안 고쳐질지도 모르겠다.

Posted by 사무엘

2015/06/15 19:24 2015/06/15 19:24
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1105

자, 오늘은 아주 간단한 Windows API 프로그래밍 퀴즈를 하나 내겠다.
다음과 같은 창을 만들려면 어떻게 해야 할까? (닫기 X 버튼이 사용 불가)

사용자 삽입 이미지

닫기 버튼 말고 최소화 및 최대화 버튼이야 윈도우의 스타일이라는 형태로 지정 가능하다.
WS_MINIMIZE/WS_MAXIMIZE와 WS_MINIMIZEBOX/WS_MAXIMIZEBOX가 있는데, BOX가 붙은 비트는 이 창에 해당 버튼과 기능을 제공하라는 뜻이다. 그리고 BOX가 없는 비트는 이 창이 현재 실제로 최소화됐거나 최대화돼 있음을 나타낸다.

즉, 프로그램이 지정하는 속성 정보와, 사용자가 변경하는 상태 정보가 비트값만 달리하여 동일 스타일에 한데 담겨 있다. 이건 개인적으로는 좀 이상한 설계라고 생각한다. 뭐 그건 그렇고...

그런데 닫기 버튼은 이런 스타일의 형태로 존재하지 않는다.
사실, UI 디자인 상으로도 응용 프로그램은 사용자에게 뭔가 강압적인 요소를 가능한 한 만들지 않아야 하며, 모든 창은 사용자가 언제라도 닫을 수 있어야 한다. [X] 버튼이 없는 창을 접할 일은 극히 드물다. 이는 오늘날처럼 언제라도 task switch가 가능한 선점형 멀티태스킹 환경에서는 더욱 그러하다.

창에 시스템 메뉴 자체를 완전히 없애서 [X]버튼을 없애는 것 말고 저렇게 [X] 버튼을 disable만 시키는 간단한 방법은 시스템 메뉴에서 SC_CLOSE를 없애거나 disable시키는 것이다. 창의 WM_CREATE 메시지에서 이렇게 해 주면 된다.

HMENU h = ::GetSystemMenu(hWnd, FALSE);
::RemoveMenu(h, SC_CLOSE, MF_BYCOMMAND);

요렇게 해 주면 캡션에 달린 [X]버튼도 같이 영향을 받게 된다. [X]버튼뿐만 아니라 시스템 메뉴를 더블클릭해도 창이 닫히지 않는다.

그런데, 외형상 닫기 버튼을 없애는 것은 마우스를 통한 닫기 동작을 차단해 주는 반면, 키보드 Alt+F4를 차단하지는 못한다.
물론, 이런 메시지가 왔을 때 닫는 반응을 안 하도록 WM_CLOSE 메시지나 IDCANCEL을 차단하는 식으로 별도의 처리를 할 수도 있지만, 운영체제 차원에서 창을 닫으려는 시도를 원천차단하는 방법은 따로 있다.

이것은 윈도우의 스타일에 있는 게 아니라, 윈도우 클래스의 스타일에 있다.
바로 CS_NOCLOSE 되시겠다.
아무 창에나 쉽게 쓰이는 속성이 아니라고 판단되었는지 윈도우의 스타일이 아니라 클래스의 스타일로 분류되었다. 뭐, 역사적으로는 [X] 버튼 자체가 윈도 95/NT에서 처음 등장한 것이기 때문에 최소화/최대화 버튼하고는 API가 들어갈 위치가 다르기도 했고 말이다.

윈도우 클래스를 등록할 때 저 스타일을 준 윈도우는 윈도우 프로시저에서 WM_CREATE 때 시스템 메뉴 조작 같은 걸 하지 않아도 시스템 메뉴에 '닫기' 명령이 등재되지 않으며, [X] 버튼이 자동으로 흐리게 표시된다. 그리고 Alt+F4를 눌러도 자동으로 닫히지 않는다.
응용 프로그램이 직접 제공하는 '종료' 명령으로 WM_CLOSE 메시지를 날려 줘야만 닫을 수 있다. 아니면 프로세스를 강제로 죽이든가.

MDI 차일드 윈도우도 이런 스타일이 지정된 클래스에 소속된 놈으로 지정할 수 있다. 그렇기 때문에 MDI 창들 중에도 절대로 닫히지 않고 언제나 떠 있어야 하는 고정 붙박이 윈도우는 요렇게 따로 배치하는 게 가능하다.

화면을 다 차지한 채 Z-순서가 바뀌지도 않고(WS_EX_TOPMOST) 닫히지도 않는 창이 떠 있다면, 거기에다 키보드/마우스/메시지 훅만 추가해서 다른 프로그램으로 작업 전환도 되지 않게 해서 포커스를 특정 프로그램이 사실상 독점할 수도 있다. 특정 프로그램만 뜬 채로 통제를 벗어나지 않아야 하는 공공장소의 특수 목적 PC에서 돌아가는 프로그램은 이런 기능을 활용하면 만들 수 있을 듯하다.

16비트 윈도 시절에는 특정 프로그램이 시스템의 자원을 독점하기가 훨씬 더 쉬웠고 그때는 그냥 modal이 아니라 system modal이라는 기능이 버젓이 존재했다. 이 창을 닫기 전에는 아예 다른 프로그램으로 Alt+Tab 작업 전환도 안 되는 거다.

물론 이런 강압적인 기능은 32비트 이후부터는 공식적으로 삭제되었지만 이것의 영향을 받았는지 윈도 NT 계열과는 달리 9x 계열은 메시지 대화상자에도 그 잔재가 여전히 남아 있었다. 취소 버튼이 없이 '확인'만 있는 메시지 박스는 시스템 메뉴에 '닫기'가 존재하지 않았으며 [X] 버튼이 클릭 가능하지 않았다. 단, 그래도 키보드의 ESC나 Alt+F4는 동작한다.

사용자 삽입 이미지


Posted by 사무엘

2014/02/07 08:38 2014/02/07 08:38
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/928

큼직한 그래픽 화면에서 마우스로 조작하는 컴퓨터-사용자 인터페이스를 일명 GUI라고 부른다.
매킨토시가 원조라고 하는 이런 환경에서는 대화상자가 라벨, 입력란, 리스트박스, 버튼 같은 몇몇 기초 UI 요소들로 구성되며, 이 구성요소들을 윈도우 프로그래밍에서는 ‘컨트롤’이라고 부른다. GUI에서 일종의 부품과도 같다.

이런 GUI와는 달리, 그냥 전통적인 선택 막대만으로 각종 기능을 선택하고 옵션을 설정하는 단순한 인터페이스도 있는데, 과거의 도스용 아래아한글이 대표적인 예였다.
단순한 인터페이스는 말 그대로 너무 단조로워 보이기는 하지만, 다른 건 몰라도 화면 차지 면적이 작다는 장점 하나는 독보적이기 때문에 요즘은 스마트폰의 UI에서 제 위치를 찾은 것 같다.

이 글의 주제는 윈도우 GUI 컨트롤이므로 다시 GUI로 화제를 바꾸기로 한다.
아까 말했던 입력란(edit box), 라벨, 리스트박스, 버튼(체크, 라디오 등도 포함) 같은 건 기본 중의 기본 필수 요소이며, 까놓고 말해 윈도우 1.0 시절부터 존재했던 녀석이다. 해당 컨트롤의 기능은 운영체제와 완전히 일심동체가 되어 깊숙이 박혀 있다.
비단 운영체제의 GUI뿐만이 아니라 어느 GUI 툴킷을 보더라도 저런 컨트롤이 빠진 물건은 없다.

그런데 세월이 흐르다 보니 좀 더 새끈하고 산뜻한 컨트롤이 필요해졌다.
그래서 1990년대 후반, 윈도우 NT 3.51, 그리고 윈도우 95에서부터 운영체제 차원에서 새로운 컨트롤들이 여럿 도입되었다.
이름하여 공용 컨트롤(common control). 윈도우 1.0 때부터 있었던 innate한 선배들 system control과 구분하기 위해 붙은 이름이다.

무엇이 추가되었냐 하면,
트리 컨트롤: 계층 구조, 목차 따위를 표시할 수 있다.
리스트 컨트롤: 수많은 개체를 단순히 리스트 형태뿐만이 아니라 아이콘 모양으로도 표시할 수 있고, 개체의 특성을 여러 칼럼으로 분할해서 표현할 수 있어서 유용함.
도구모음줄(toolbar)과 상태표시줄(status bar)
탭 컨트롤
진행 상황 게이지 컨트롤(progress bar)

나름 쓸모 있는 것들이 많다. 특히 윈도우 95의 탐색기는 죄다 이 새로운 컨트롤을 잔뜩 우려먹어서 만든 것이다.
리스트 컨트롤과 기존 리스트박스는 하는 역할이 일면 비슷하다 할 수 있으나, 아이템을 추가하거나 정보를 얻어 오는 프로그래밍 인터페이스는 서로 완전히 다르다. 새로운 녀석이 기능이 워낙 많다 보니 훨씬 더 복잡하다. 게다가 둘은 사용법도 차이가 있다. 가령, 아이템을 복수 선택할 때 기존 리스트박스는 Shift+F8과 Space를 사용하지만, 리스트 컨트롤은 Ctrl+화살표와 Ctrl+Space를 사용한다.

이들 공용 컨트롤들은 어차피 MS가 오피스 같은 선구자적(?) 제품에서 자체 구현해 놓고 쓰던 컨트롤들을 운영체제 차원에서 정형화해 놓은 게 많았다.
예를 들어 도구모음줄과 상태표시줄은 어느 응용 프로그램들이나 자체적으로 구비해 놓던 GUI 요소였는데 그걸 다루기 쉬운 정식 컨트롤로 만들어 놨다. MFC도 16비트 시절에는 CToolBarCtrl이 도구 아이콘을 그리고 관리하는 자체 구현이었지만, 32비트부터는 공용 컨트롤에다 요청만 하는 형태로 바뀌었다.

윈도우 3.x의 매체 재생기는 자체 구현한 slider로 재생 위치를 표시했지만, 윈도우 95의 매체 재생기(지금 있는 Media Player의 전신)는 공용 컨트롤에 있는 slider를 썼다.
윈도우 3.x 시절의 설치 프로그램들은 자체 구현한 게이지로 설치 진행 상황을 표시했지만, 윈도우 95의 설치 프로그램은 공용 컨트롤에 있는 게이지를 쓴다. 컨트롤들의 재사용성이 향상된 셈.
비주얼 C++ 4.x의 예제 프로그램 중에는 이런 공용 컨트롤들을 다루는 모습만 시연해 놓은 놈도 있을 정도였다. 아래 그림을 참고하라.

사용자 삽입 이미지

공용 컨트롤들은 시기적으로 나중에 추가된 만큼, 기존 시스템 컨트롤만치 운영체제와 뗄레야 뗄 수 없는 일심동체 형태는 아니었다. 시스템 컨트롤들의 코드가 운영체제의 3대 요소 중 하나인 user(32)에 통합되어 있다면, 공용 컨트롤은 comctl32라는 고유한 라이브러리에 따로 들어있었다. 그리고 이들 컨트롤을 쓰려면 응용 프로그램이 comctl32.dll을 로딩하고 InitCommonControls 같은 함수도 호출해 줘야 했다.

실제로, ListBox, ComboBox, Edit 같은 시스템 컨트롤들은 언제라도 GetClassInfo 함수로 컨트롤의 정체성 정보를 확인할 수 있는 반면 SysListView32, msctls_statusbar32 같은 공용 컨트롤은 comctl32.dll을 별도로 읽어들이고 나야 정보를 얻을 수 있다. 운영체제와 완전한 일심동체가 아니라는 말이 이런 의미인 것이다.

다만, 굳이 InitCommonControls 초기화를 할 필요는 없이 그 DLL을 LoadLibrary만 해 줘도 되는 듯하다.
또한, 이들 컨트롤을 운영체제의 대화상자에서 쓴다면, 어차피 DialogBox 같은 함수가 comctl32.dll의 로딩과 공용 컨트롤의 초기화 정도는 알아서 해 주는 것 같다. 따라서 현실적으로는 응용 프로그램 개발자가 일일이 InitCommonControls를 호출은 안 해도 된다.

공용 컨트롤 라이브러리는 저렇게 새로운 컨트롤만 부품 차원에서 제공하는 게 아니라, 이들 컨트롤을 이용한 자체 UI 기능도 함수 형태로 제공한다. 탭 컨트롤을 이용한 Property Sheet와, ‘이전, 다음’ 형태인 Wizard가 대표적인 예이다. 이것도 윈도우 3.x 시절부터 자체 구현이 하도 유행으로 뜨다 보니까 운영체제 차원에서 자동화 기능을 넣어 준 셈이다.

윈도우 95 이후로 공용 컨트롤 라이브러리는 윈도우 XP에서 또 큰 변화를 겪었다. 이는 물론 테마라는 기능이 추가되었기 때문이다.
컨트롤을 그리는 방식이 예전과는 근본적으로 완전히 다르게 바뀌었기 때문에, 예전 라이브러리를 고칠 수는 없어서 그건 호환성 차원에서 그대로 두고 새 라이브러리를 덧씌우는 방식이 채택되었다. 바로 윈도우 XP에서 추가된 DLL side-by-side assembly 매니페스트 방식으로 말이다.

윈도우 시스템 디렉터리에 있는 comctl32.dll은 이제 구형이다. 윈도우 비스타나 7에서도 이놈의 제품 버전은 6.x이지만 파일 버전은 5.8x에서 멈춰 있음을 알 수 있다. 그 반면, 새로운 comctl32.dll은 Windows\winsxs 같은 완전히 다른 곳에 숨어 있다.
새로운 comctl32는 원래 user32에 있던 기존 컨트롤들을 테마가 적용된 자기 걸로 다 대체해 버린다. 그래서 Spy++ 같은 프로그램으로 확인해 보면, Edit· Button 같은 시스템 컨트롤들도 클래스 스타일에 CS_GLOBALCLASS 같은 플래그가 있다.

또한, URL 링크 같은 새로운 공용 컨트롤이 XP에서 추가되었는데, 이런 것들은 응용 프로그램이 6.0 버전 이상의 새로운 공용 컨트롤 라이브러리를 사용하겠다는 표식을 명시적으로 해야만 사용 가능하다. 나중에 새롭게 추가된 기능은 호환성을 지키기 위해 옛날 프로그램들에게는 바로 노출되지 않으며, 접근 내지 사용하가 이런 식으로 더욱 까다로워진다는 걸 알 수 있다.

이거 지정을 위해 예전에는 개발자가 매니페스트 xml 문서를 직접 써 줘야 했지만 비주얼 C++ 2005부터는 #pragma comment(linker, ...) 한 줄로 손쉽게 할 수 있다. 사실, 2005부터는 MFC와 C 라이브러리 DLL 지정도 이런 방식으로 바뀌었고, 2008부터는 윈도우 비스타에서 추가된 응용 프로그램 권한 등급 지정도 이렇게 할 수가 있다는 것도 잘 알려진 사실이다.

윈도우 비스타에서부터 추가된 UI 기능인 Task dialog 역시 comctl32.dll에 기능이 구현되어 있으며, 공용 컨트롤 6.0 이상이 지정된 응용 프로그램에서만 사용 가능하다. 쉘(shell32)이나 공용 대화상자(comdlg32) 계층에 구현되어 있지 않나 생각했는데 그렇지는 않다.

닷넷 프레임워크에서는 저런 운영체제의 지저분한 버전 별 디테일을 전혀 신경 쓸 필요가 없다는 게 좋은 점 중 하나이겠다.

Posted by 사무엘

2011/02/26 08:12 2011/02/26 08:12
, , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/471


블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2020/02   »
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29

Site Stats

Total hits:
1333580
Today:
154
Yesterday:
526