2018년 6월 6일 수요일

Firefox CSD 기능을 쓰려고 시작한 모험

CSD란?

client-side decoration이라고 해서, 창 관리자가 그려주는 창 테두리와 버튼들 대신 프로그램이 직접 그런 부분들을 창 안에 표시하는 기능이 있다. decoration을 없애는 거야 일찌감치 가능했다. Openbox 같은 경우엔 창 메뉴를 열어서 "Un/Decorate" 기능으로 끄고 켤 수 있다. 프로그램이 창을 띄울 때 undecorate 창이라고 선언할 수도 있다. (wmctrl로도 될 줄 알고 찾아봤는데 그런 거 없나보다)

그렇게 없앤 영역이 담당해야 할 기능 그러니까 창의 크기를 바꾸고 창을 닫거나 옮기는 걸 어떻게 처리하는지가 문제가 되는 건데, 개별 프로그램들이 알아서 잘 할 방법을 찾아보자는 얘기가 본격적으로 나오는 거다.

CSD 도입 상황

얼마전까지 CSD가 두드러지게 적용된 건 구글 크롬이었다. 처음 깔았을 때는 탭이 맨 위에 오는 크롬 특유의 모습이지만 설정에서 '시스템 제목 표시줄 및 테두리 사용' 옵션을 켜면 창 관리자가 그려주는 테두리가 붙는 걸 볼 수 있다.

그리고 csd에 대한 건 아니지만 gtk3에 (OS X의 동작 같이) '창 메뉴바를 분리해서 최상단 패널에 몰아서 보여주는' 패치가 들어간 것도 맥을 같이 하는 흐름이었다고 생각한다. 그 뒤로 Unity나 gnome-shell이 '창 관리자' 역할을 넘어 프로그램 안쪽의 기능들과 긴밀하게 연계하면서 창 관리자가 중간에 끼는 게 데스크탑 환경을 만들어가는 입장에서 거추장스럽게 느껴졌을 것 같기도 하다.
 그러다가 (클라이언트 창이 뜰 수 있도록 해주는 공간 자체를 만들어내는 게 서버인데) 창 시스템 서버가 X, X.org의 틀을 벗어나 Wayland라는 걸로 넘어가면서 CSD를 진지하게 다뤄야 하는 상황이 되었나보다. 아래는 참고할만한 글이다.
  • (영어) https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/
  • (영어) https://blog.martin-graesslin.com/blog/2018/01/server-side-decorations-and-wayland/
  • (영어) https://kver.wordpress.com/2014/10/25/presenting-dwd-a-candidate-for-kde-window-decorations/
  • (한국어) https://nemoux00.wordpress.com/2014/10/29/wayland-csd-ssd-dwd/

사실 윈도우 동네에서는 WIN16 API 운운하는 시절부터도 이미 나온 얘기였다. 윈도우 환경이 제공하는 기본 모양이 워낙 고정적이다 보니 프로그램마다 자기 취향대로 창을 그려대는 통에 전반적인 통일감이 없고 사용성이 떨어지고 윈도우가 발전해도 개별 프로그램은 발전을 따라가지 못해 구닥다리가 된다는 거였다. 꼭 데스크탑 얘기만이 아니라 웹이나 모바일 앱 환경에서도 OS가 제공하는 환경을 따를지 말지에 대해서 논란이 많다.

Firefox와 CSD

한편, 이런 '주어진 환경을 따를지 아니면 직접 해결할지'를 더 많이 고민해온 게 Firefox 같이 여러 환경을 지원하는 프로그램이다. 크롬이야 워낙 독창적인 인터페이스를 들고 나왔기 때문에 모든 걸 무시하고 바닥부터 시작할 수 있었지만 파이어폭스는 오랜 기간을 거치면서 그때그때 OS의 변화와 UI의 유행을 고스란히 따라와야 했다.

그리고 드디어 파이어폭스가 CSD 옵션을 포함한 게 60 버전부터다. 방침이나 당부를  따지지 않더라도, 어떤 식으로 동작할지 궁금하긴 했다. 실은 58 버전 정도부터도 개발 버전에는 들어갔었기 때문에 일찌감치 깔아서 CSD 옵션을 켜봤지만 왜인지 탭이 있는 줄의 공간 배치가 조금 변하는 것 말고 실제로 창 테두리가 없어지거나 하지는 않았다.

Openbox 때문일 거라고 생각하지는 않았다. 그냥 아직 도입 초반이니까 뭔가 문제가 있는 거라고만 짐작했다. 하지만 정식 버전에 포함이 된 뒤에도 여전히 창 테두리가 남아있는 건 이상했다.

CSD 적용된 Firefox를 향한 모험

그러다가 Openbox가 아닌 다른 세션을 잠깐 썼을 때 파이어폭스에 온전히 CSD가 적용된 걸 확인했다. gnome-session의 변종으로 존재하는 것들에선 모두 CSD가 잘 동작하는 것 같았다. 특이하다면 어떤 환경에선 (윈도우에서의 크롬처럼) 탭 위에 여백이 하나도 없고 어떤 환경에서는 (OS X에서의 크롬처럼) 약간 여백이 생겼다. 나는 여백이 없는 걸 선호하기 때문에 이것저것 바꿔가면서 띄워봤다.

하지만 그대로 Openbox를 버리고 데스크탑 환경을 갈아타기에도 문제가 있었다. 애초에 단촐한 구성이라 Openbox를 쓰고 있던 터에 다시 이런저런 프로그램이 잔뜩 뜨고 구성에도 제약이 있는 환경으로 가는 게 손에 딱 맞질 않았다.

가장 걸림돌이 된 건 여러 모니터에 배경 화면을 각각 띄울 수 없다는 거로, gnome-shell은 왜인지 배경 화면을 하나로만 제공했다. 아마 Xinerama 같은 걸로 panning 옵션을 통해 모든 화면을 하나로 뭉쳐서 쓰기 위해 그런 것 같았다. 이리저리 뒤져보면 gnome-shell 안에서 panning을 풀어버리는 방법도 있을 거라고 생각은 했지만 시간도 오래 걸리고, 다른 모든 설정 프로그램이 단일한 배경만을 전제하는 상황에서 강제로 환경을 바꾸는 게 얼마나 효과가 있을지도 의문스러웠다.
그리고 이것도 아마 gnome-shell의 특성 때문에 생기는 문제인 듯한데, xrandr에서 여러 모니터 중에 하나를 제대로 사용하지 못하고 꺼버리거나 해상도를 엉뚱하게 맞추는 문제가 있었다. 인텔 내장 그래픽을 쓰기 때문에 어쩔 수 없는 건가(웃음) 싶기도 했다. 찾아보니 EDID나 mode 같은 용어가나오면서 직접 정하라는 얘기도 있었고, gnome-shell이 하드웨어 가속을 쓰려고 하기 때문에 생기는 증상이라는 의심도 들었다. Openbox를 쓰면서는 겪은 적이 없는 상황이었기 때문에 그냥 Openbox로 빨리 전환하는 걸 택했다.

Openbox를 기본으로 띄우고 뭔가 (아마도 XAtom 수준까지 내려가는) 영향을 주는 프로그램을 찾아서 똑같이 띄워주면 Firefox CSD를 그대로 쓸 수 있을까 싶어 ps 명령으로 각 환경마다 어떤 프로세스가떠 있는지도 확인해봤지만 이거다 싶은 게 없었다. 그래서 방법을 바꿨다.

lightdm에서 Openbox를 직접 선택하지 않고 다른 세션 안에서 openbox --replace 명령으로 창 관리자만 바꾸면 원하는 결과물을 만들어낼 수 있을 것 같았다. 실험해보니 파이어폭스는 여전히 CSD가 잘 동작했고, 그러면서도 Openbox의 기능을 쓸 수 있었다.

"apt-cache pkgnames | grep -- -session$" 명령으로 어떤 세션들이 있는지 찾아봤다. openbox-gnome-session 패키지는 혹해서 깔아봤지만 lightdm에서 진입하지 못하고 튕겼다. 찬찬히 보다가 선택한 게 xfce4-session이었다. 너무 요즘 거라서 gnome-shell의 영향을 강하게 받을만한 것도 아니고 적당히 독립적인 노선을 유지하기 때문에 Openbox랑 조합해서 쓸만할 것 같았다. 물론 파이어폭스 CSD도 잘 됐고, 탭 위로 여백도 없었다.

xfce4 환경은 만족스러웠다. lightdm에서 xfce4 세션을 선택하고 진입했을 때 처음 환경은 온통 xfce4 기본 프로그램들로 채워져 있었지만, 얼마든지 교체할 수 있었다. openbox --replace로 창 관리자를 바꾸고, ~/.config/openbox/autostart 명령을 세션 관리자에 등록해서 그동안 Openbox에서 쓰던 초기 실행 명령들을 그대로 살려 쓸 수도 있었다. 바탕화면에 아이콘을 보여주는 xfdesktop4는 삭제를 해도 다른 패키지 의존성에 전혀 영향을 주지 않을 정도였다. xfce4는 오직 세션 매니저만 제공하는 셈이었다.

이렇게 해서 Openbox 환경에 Firefox를 쓰면서 CSD 기능을 쓸 수 있게 되었다.