GNOME이 서버 사이드 데코레이션(SSD)을 지원해야 하는 이유와, 이에 대한 반론 및 가능한 구현 방향을 정리한다.
* [English](https://blister.zip/)
2022-01-25 Blisterexe
이 글은 프랑스어로도 제공됩니다.
이 글에는 꽤 많은 기술 용어가 등장한다. 다음 단락들에서 이를 설명할 것이며, 이미 이러한 용어에 익숙한 사람은 다음 섹션으로 건너뛰어도 된다. 리눅스와 그 데스크톱 환경에 대한 기본적인 이해를 전제로 한다.
서버 사이드 데코레이션(SSD, Server Side Decorations)은 애플리케이션의 제목 표시줄(titlebar)을 시스템이 그려주는 경우를 말하고, 클라이언트 사이드 데코레이션(CSD, Client Side Decorations)은 애플리케이션이 스스로 제목 표시줄을 그리는 경우를 말한다. KDE는 전자를 선호하고 GNOME은 후자를 선호한다. KDE와 대부분의 다른 데스크톱 환경은 둘 다 지원하지만, GNOME은 CSD만 지원한다.
SSD는 애플리케이션이 아니라 데스크톱이 그리기 때문에, 이를 사용하는 앱은 분리된 제목 표시줄(아래)을 가지는 반면, CSD를 중심으로 설계된 앱은 제목 표시줄이 통합된 형태(위)를 갖는 경향이 있다.
분리된 제목 표시줄(아래) vs 통합된 제목 표시줄(위)
이미지 출처: Tobias Bernard
단순화를 위해, 이 글에서는 mutter 컴포지터를 GNOME으로, 컴포지터 전반을 “시스템”으로, gtk4/libadwaita 앱을 GNOME 앱으로 지칭하겠다.
서론은 이쯤 하고, 제목의 질문으로 들어가 보자.
여러 이유가 있다.
일부 애플리케이션은 SSD 없이는 제대로 동작하지 않는다. 이런 앱은 제목 표시줄이 아예 없거나 이상한 형태가 되어, 사용자가 창을 쉽게 이동하거나 크기를 조절하기 어려워진다. 대표적인 예로 Davinci Resolve가 있지만, 이것만 그런 것은 아니다.
GNOME은 리눅스 데스크톱에서 충분히 큰 비중을 차지하기 때문에, SSD 데코레이션을 전제로 설계된 대부분의 애플리케이션은 GNOME에서 깨지지 않도록 우회책을 구현한다. 보통 그 우회책이 libdecor다.
겉보기엔 괜찮아 보이지만, libdecor는 사실 양쪽의 최악을 결합한 것이다. 전통적인 제목 표시줄의 공간 비효율과 통합 부족은 그대로인데, 여기에 통합형 제목 표시줄의 불일치와 사용자 커스터마이징 부재까지 더해진다.
libdecor가 제공하는 제목 표시줄이 시각적으로 서로 다른 세 개의 애플리케이션
이는 libdecor 개발자들의 잘못이 아니다. 더 큰 문제를 임시로 때워주는 반창고(bandaid)식 해결책이기 때문이다.
SSD를 지원하면 이 문제가 해결된다. CSD를 쓰고 싶지 않은 모든 애플리케이션은 일관된 음영, 색상, 모서리 반경을 가진 깔끔한 네이티브 제목 표시줄을 얻게 되고, 개발자도 더 적은 작업과 좌절만 겪으면 된다.
Windows와 macOS에서는 어떤 애플리케이션이든 자체적으로 CSD를 구현하면서도, 해당 플랫폼이 제공하는 SSD에 준하는 제목 표시줄 버튼의 간격, 위치, 외형을 따를 수 있다.
리눅스에서 문제가 되는 점은, 제목 표시줄 디자인이 데스크톱 환경에 따라 너무 크게 달라 “네이티브처럼 느껴지는” CSD를 만드는 것이 상당히 승산 없는 싸움이 되기 쉽다는 것이다. GNOME에서 비(非)GNOME 앱에 SSD를 선택지로 제공하고, 반대로 다른 환경에서도 GNOME 앱에 SSD를 선택지로 제공하는 것은, 이런 ‘네이티브 감’에 가치를 두는 사용자에게 앱이 더 자연스럽게 느껴지도록 하는 데 큰 도움이 될 것이다.
다른 데스크톱 환경의 많은 사용자는 GNOME 앱이 SSD를 지원하지 않아, SSD를 강제로 활성화하면 앱이 깨지는 점에 불만을 가진다.
지원되지 않는 동작을 사용자가 했을 때 앱이 깨지는 것이 당연히 개발자의 잘못은 아니지만, GNOME 앱이 선택적으로 SSD를 지원한다면 다른 데스크톱 사용자는 정말로 기뻐할 것이다.
GNOME 앱에 왜 SSD를 적용하고 싶어하는지 궁금할 수 있다. 어떤 사람들은 개별 앱의 디자인보다 제목 표시줄의 일관성을 더 중요하게 여긴다. 또 일부 사용자는 SSD를 접근성 기능으로 보기도 한다.
리눅스는 이미 작은 시장이다. 그런데 GNOME이 사실상의 표준인 xdg-decoration을 지원하지 않는 것은 파편화를 키워 리눅스 데스크톱에 해를 끼칠 뿐이다.
이 파편화는 리눅스 데스크톱을 개발자에게 덜 매력적으로 만들고, 더 중요하게는 애플리케이션 개발자가 Wayland 같은 더 현대적인 표준을 채택할 가능성을 낮춘다.
GNOME이 SSD를 구현해야 하는 이유에 대한 많은 논의는 찬성 논거에서 멈추지만, 물론 SSD 지원에 반대하는 논거도 있다. 그렇지 않았다면 GNOME은 이미 SSD를 구현했을 것이다.
예를 들면 다음과 같은 주장들이다.
이는 GNOME 개발자들이 SSD를 지원하지 않는 이유로 가장 많이 드는 주장이다. 사실이다. xdg-decoration은 “불안정(unstable)” 프로토콜이고, Wayland는 원래 CSD만을 염두에 두고 설계되었다. 하지만 Wayland는 처음에는 화면 공유나 전역 키바인드(global keybinds)도 없이 설계되었고, GNOME은 그 표준들을 결국 채택했다.
또한 이 표준은 시스템 트레이 같은 표준이 야기하는 종류의 보안/디자인 문제를 똑같이 일으키지도 않는다.
사실은 GNOME의 mutter를 제외한 모든 실사용 가능한(production-ready) 데스크톱 컴포지터가 이를 채택하고 있으며, 애플리케이션 및 데스크톱 개발자들이 모두 의존하고 있다. 즉 널리 채택된 사실상의 표준(de facto standard)이다.
말하자면, xdg-decoration은 기술적으로는 스펙 밖이지만, “스펙 안(in spec)”인 어떤 Wayland 프로토콜과의 차이를 만드는 유일한 요소는 GNOME이 이를 지원하지 않는다는 점뿐이다.
많은 개발자와 사용자는 제목 표시줄을 데스크톱의 일부로 보지만, 어떤 이들은 이에 동의하지 않는다. 이는 문제가 아니라 철학의 차이일 뿐이다.
진짜 문제는 GNOME 프로젝트가 첫 번째 집단을 배려해서는 안 된다는 생각이다. 이는 GNOME이 xdg-file-chooser를 지원하지 않으면서 각 앱이 파일 선택기를 반드시 자체 제공해야 한다고 말하는 것과 비슷하다. 하지만 GNOME은 이를 지원하고, 자체 파일 선택기를 구현하고 싶은 앱만 그렇게 한다.
두 접근 방식이 모두 쓰이고 선호되는 이상, 각 접근의 잡다한 장단점은 중요하지 않으며, 디자인 관련의 다른 주장들도 마찬가지로 중요하지 않다. 그래서 이 글에서는 그런 주장들을 꺼내지 않았다.
이제 GNOME이 서버 사이드 데코레이션을 채택하는 것이 왜 가치 있는지에 대해 요지는 전달했다고 바라지만, 여전히 질문이 남는다.
이 글 전반에서 SSD 구현이 어떤 모습일지 몇 차례 언급했지만, 완전히 설명하지는 않았다. 그래서 정리해 보자.
당연히 GNOME은 관련 프로토콜을 구현하고, SSD를 명시적으로 요청하지 않는 모든 애플리케이션에 서버 사이드 데코레이션을 활성화해야 한다. 이는 SSD를 지원하지 않는 컴포지터에서의 폴백으로 CSD만 제공하는 앱들에도 SSD가 적용되도록 하기 위함이다.
분명히 하자면, 이는 GNOME 앱처럼 통합된 헤더바(united headerbar)를 전제로 설계된 앱에는 적용되지 않을 것이다.
하지만 다른 데스크톱 환경에서는, GNOME 앱이 계속해서 SSD가 적용되지 않기를 요청할 것이며, 이 선호는 모든 주류 데스크톱에서 존중된다. 유일한 차이는 사용자가 GNOME 앱에 제목 표시줄을 강제로 붙일 수 있는 선택지를 갖게 된다는 것이다. 이 시나리오에서 GNOME 앱은 통합된 창 제목과 컨트롤을 제거하게 된다.
이는 양쪽 모두에 최선이다. GNOME 사용자는 서드파티 앱에서 더 일관된 제목 표시줄과 창 그림자를 누릴 수 있고, 다른 데스크톱의 사용자는 원한다면 GNOME 앱에 SSD를 적용할 수 있게 된다.
내 생각에 GNOME이 서버 사이드 데코레이션을 지원하지 않는 것은 지금 GNOME 데스크톱 환경의 단일 최대 문제다. 그래서 이 글이 구현을 촉진하는 계기가 되기를 진심으로 바란다.
도움을 주고 싶다면, 이 글을 공유해 달라.