Cinnamon

Cinnamon의 역사는 사용자 인터페이스를 유지하려는 선택과 이를 뒷받침할 기술적 독립성을 확보하는 과정이 맞물려 있다. 초기에는 GNOME Shell 위에서 기존 작업 흐름을 재현했으나, 이후 셸과 창 관리자뿐 아니라 파일 관리자·세션·설정 서비스까지 자체적으로 관리하게 되었다. 전통적인 외형의 유지와 내부 구현의 보수적 고정은 같은 의미가 아니며, Cinnamon은 기본적인 조작 방식을 유지하면서 그래픽 합성, JavaScript 실행 환경과 디스플레이 프로토콜을 계속 변경해 왔다.

GNOME 2에서 GNOME 3으로의 전환

GNOME 2 계열에서 널리 사용된 데스크톱 구성은 응용 프로그램 메뉴, 패널의 실행 아이콘, 열린 창 목록과 작업 공간 전환기를 중심으로 했다. 화면의 고정된 위치에서 프로그램을 실행하고, 최소화한 창을 다시 선택하며, 여러 작업 공간으로 창을 나누는 방식이었다. 2011년 GNOME 3와 GNOME Shell의 등장은 이러한 기능을 활동 개요와 새로운 창 탐색 구조로 재구성하는 변화였다. Linux Mint는 새로운 GNOME 기술을 사용하면서도 기존 이용자가 익숙한 작업 방식을 유지하는 방향을 모색했다.^[7]

여기서 구별해야 할 것은 코드의 계보와 사용자 경험의 계승이다. Cinnamon이 유지하려던 것은 메뉴·패널·창 목록 중심의 조작 방식이지만, 최초 Cinnamon 코드가 직접 갈라져 나온 대상은 GNOME 2가 아니라 GNOME Shell 3.2.1이었다. GNOME 2 코드 자체를 계승하는 MATE와 Cinnamon을 동일한 포크 계열로 설명하면 두 프로젝트의 출발점과 창 관리자·설정 도구의 차이를 놓치게 된다.^[8]

Linux Mint는 한쪽에서 MATE를 지원하고 다른 쪽에서 GNOME Shell 기반의 새 환경을 개발했다. 이 선택은 기존의 조작 방식을 유지하는 데 반드시 오래된 그래픽 기술만 사용해야 하는 것은 아니라는 방향을 보여 준다. Cinnamon에서 합성 효과와 창 미리 보기를 사용하면서도 전통적인 작업 표시줄을 유지하는 구성은 이러한 설계 목표의 연장선에 있다.

Mint GNOME Shell Extensions

Mint GNOME Shell Extensions, 약칭 MGSE는 Linux Mint 12 시기에 GNOME Shell에 추가하던 확장 기능의 집합이다. 하단 패널, 응용 프로그램 메뉴와 창 목록 등 전통적인 데스크톱에 가까운 요소를 보충하여 GNOME Shell을 기존 작업 흐름에 맞추려 했다. 기존 셸을 그대로 사용하면서 확장 기능으로 필요한 부분을 추가한다는 점에서, 셸 자체의 코드를 직접 관리하는 이후 Cinnamon과 구현 방식이 달랐다.^[9]

확장 기능은 상위 셸이 제공하는 객체, 이벤트와 내부 인터페이스를 이용한다. 따라서 셸의 레이아웃이나 내부 구조가 변경되면 확장을 조정해야 하고, 확장만으로 제어할 수 있는 범위도 상위 프로젝트의 구조에 영향을 받는다. Linux Mint가 원하는 인터페이스를 일관되게 유지하려면 단순히 메뉴 하나를 추가하는 수준을 넘어 창 전환과 패널, 설정까지 함께 조정할 필요가 있었다.

Cinnamon으로의 전환은 이 제어 범위를 셸 자체로 넓힌 선택이었다. 이후에는 Linux Mint가 셸의 변경 시점과 기능을 직접 결정할 수 있게 되었고, 애플릿과 확장 기능도 독자적인 API를 사용하는 생태계로 발전했다. MGSE는 이러한 전환의 출발점이지만 현재의 Cinnamon Spices와 같은 배포 체계를 뜻하지 않으며, GNOME Shell용 확장과 Cinnamon 확장을 서로 바꾸어 설치하는 근거가 되지도 않는다.

Cinnamon 1.x

Cinnamon 소스 저장소의 최초 변경 기록은 2011년 12월 20일의 1.0.0이며 GNOME Shell 3.2.1을 기반으로 했다고 명시한다. 이어지는 초기 기록에는 패널 실행기와 기본 테마, 창 관리 및 셸 기능을 조정하는 작업이 남아 있다. 2012년 1월의 공식 소개에서는 기존의 데스크톱 조작 방식과 새 그래픽 기술을 결합하는 프로젝트의 방향이 설명되었다.^[10][11]

1.x 시기의 중요한 변화는 포크한 셸을 하나의 데스크톱 제품으로 구성하는 일이었다. 패널과 메뉴가 보이는 것만으로는 완성된 환경이 되지 않으므로, 프로그램 실행·창 전환·설정과 확장 관리가 함께 마련되어야 했다. 창 관리자 Muffin과 파일 관리자 Nemo 같은 별도 프로젝트의 발전은 셸 밖의 동작까지 일관되게 관리하는 기반이 되었다.^[12]

이 시기부터 Cinnamon의 이름은 두 범위로 사용되었다. 좁게는 패널과 메뉴를 구현하는 셸 소프트웨어를, 넓게는 Muffin·Nemo·설정과 세션 서비스를 포함한 데스크톱 환경을 의미한다. 이후 릴리스 기록이나 패키지를 해석할 때에도 Cinnamon 셸의 버전과 전체 배포판 구성을 구분해야 하는 이유가 여기에 있다.

Cinnamon 2.0과 독립 데스크톱 환경

Cinnamon 2.0은 2013년 등장한 릴리스로, Cinnamon을 GNOME Shell을 수정한 외형이 아니라 독립된 데스크톱 환경으로 구성하는 데 중요한 단계였다. 세션 시작과 설정 적용 등 셸 밖의 기능을 Cinnamon 계열 구성 요소로 운영하게 되면서, GNOME의 데스크톱 전체를 설치하고 그 위에서 Cinnamon을 덧붙이는 방식과는 다른 패키지 구성이 가능해졌다.^[13][14]

독립성은 GTK, GLib, GObject 같은 라이브러리와의 단절을 의미하지 않는다. 실제 Cinnamon은 GNOME 계열에서 발전한 공통 기반을 계속 사용하면서 세션 관리자, 창 관리자, 파일 관리자와 설정 도구의 정책을 직접 관리한다. 공통 라이브러리를 사용하는 것과 특정 데스크톱 셸에 종속되는 것은 구분되는 관계다.

이 구조에서는 배포판이 Cinnamon의 구성 요소를 선택하여 자체 로그인 관리자와 오디오·네트워크 서비스를 결합할 수 있다. 반대로 구성 요소가 나뉘어 있으므로 버전의 호환성, 설치 경로와 자동 시작 항목도 함께 맞추어야 한다. 독립 프로젝트가 된다는 것은 다른 프로젝트를 사용하지 않는다는 뜻보다, 데스크톱의 조합과 변경을 자체적으로 결정할 수 있다는 의미에 가깝다.

Cinnamon 3.x와 4.x

3.x와 4.x 시기에는 이미 갖추어진 패널·메뉴·파일 관리자 체계를 바탕으로 설정의 세분화와 창 탐색 방식이 발전했다. 패널의 크기와 표시 동작을 조절하고, 여러 모니터에서 창을 찾으며, 테마와 UI 자원을 다양한 화면 밀도에 맞추는 일은 단순한 외형 변경보다 데스크톱 전체의 배치 계산과 설정 체계에 영향을 주는 작업이었다.^[15]

4.x 계열에서 두드러진 변화 가운데 하나는 Grouped Window List를 중심으로 한 응용 프로그램별 창 그룹화였다. 전통적인 창 목록이 창 하나마다 항목을 만드는 데 비해 그룹화된 목록은 프로그램별 아이콘 아래 여러 창을 모으고 미리 보기로 원하는 창을 선택한다. 실행기를 고정하는 동작과 이미 실행 중인 창을 전환하는 동작이 같은 패널 항목에 결합되는 구성이다.

이러한 변화가 전통적 창 목록의 모든 사용 방식을 없애는 것은 아니다. Cinnamon의 패널은 애플릿을 조립하는 구조이므로 같은 셸에서도 표시 방식과 클릭 동작을 다르게 구성할 수 있다. 이후의 Grouped Window List 설정에는 그룹화 여부, 제목 표시, 창 수 배지, 클릭·휠 동작과 모니터별 표시 범위가 따로 존재한다. 기본 배치의 변화와 사용자가 선택할 수 있는 기능의 범위를 구별할 필요가 있다.^[16]

Cinnamon 5.x와 6.x

5.x와 6.x에서는 기존 작업 흐름을 유지하면서 셸 내부의 실행 환경, 설정 관리, 그래픽 표시와 파일 작업을 개선하는 변화가 이어졌다. 사용자에게는 같은 패널과 메뉴가 계속 보이더라도 JavaScript 엔진, 네이티브 라이브러리와 화면 배율 처리가 바뀔 수 있다. 특히 6.x의 Wayland 작업은 창·입력·캡처·잠금 화면의 구현 경로를 함께 변경하는 일이었다.^[17]

2026년 10월 11일 확인한 6.6 유지보수 브랜치의 최상단 기록은 2026년 7월 20일의 6.6.9였다. 이 기록에는 달력 서비스의 ICal 4.0 허용과 Spices 다운로드에서 Content-Length 헤더가 없는 경우의 처리가 포함되어 있다. 앞선 6.6.8 기록에는 CJS 140 지원이 들어가며 CJS를 해당 계열로 올리면 Cinnamon도 다시 빌드해야 한다는 설명이 있다. 유지보수 릴리스에서도 상위 런타임과의 호환성이 중요한 작업임을 보여 준다.^[18]

같은 날 확인한 master의 최상단 변경 기록은 2026년 9월 22일의 6.7.8이었다. 6.7 개발 계열에는 모니터별 배경 화면, 화면 캡처 도구, 입력기와 화면 잠금, 달력 백엔드 및 창 미리 보기의 변경이 기록되어 있다. 이 문서에서 6.7을 언급하는 대목은 이러한 개발 코드의 상태를 설명하며, 각 배포판의 안정 패키지에 모두 적용되었다는 의미로 사용하지 않는다. 변경 기록의 버전은 배포판이 실제 설치하는 패키지의 버전과 별도로 확인해야 한다.^[19]

Wayland 지원의 개발

Cinnamon의 Wayland 지원은 오랫동안 X11을 전제로 구현했던 기능을 새로운 그래픽 세션 구조로 옮기는 작업이다. 단순히 로그인 목록에 세션 하나를 추가하는 것과 달리 창을 식별하는 방법, 입력 초점, 화면 캡처, 키보드 배열, 그래픽 배율과 잠금 화면이 모두 관련된다. 같은 JavaScript UI를 재사용하더라도 그 아래에서 창과 장치 정보를 제공하는 계층은 달라진다.^[20]

6.7.2와 6.7.3 기록에는 cinnamon-screenshot 도입과 화면·창 선택, Wayland의 전체 모니터 촬영 및 클립보드 처리가 나타난다. 6.7.5에는 Wayland 세션에서 fcitx5를 연결하고 가상 키보드와 확대기의 입력 처리를 조정한 기록이 있으며, 6.7.7에는 배경 데몬과 모니터별 배경 화면이 추가되었다. 개별 기능이 다른 시점에 구현되므로 하나의 지원 여부만으로 전체 완성도를 설명하기 어렵다.

6.7.3에서 세션 이름의 experimental 표기가 제거된 기록과 6.7.7에서 Wayland의 분수 배율 컨트롤을 숨긴 기록도 구분해서 읽어야 한다. 세션의 표시 이름이 바뀌는 것은 모든 출력·입력 기능이 X11과 같아졌다는 증거가 아니다. 화면 배율, 외부 잠금 프로그램, 화면 공유처럼 구체적인 기능은 해당 구현과 배포판의 버전을 기준으로 설명하는 것이 정확하다.

개발 중인 화면 잠금 컨트롤러에서는 Wayland에 내부 화면 차폐를 사용하고, X11에는 내부 구현 또는 별도 cinnamon-screensaver를 선택할 수 있도록 한다. 또한 Wayland에서 외부 잠금 명령을 무시하며 별도 세션 잠금 프로토콜 지원이 필요하다는 주석이 있다. 이처럼 Wayland 이식은 보이는 UI뿐 아니라 인증 상태와 입력을 누가 통제하는지까지 재구성한다.^[21]

Cinnamon을 이해할 때는 소스 저장소의 구분, 설치 패키지의 구분, 실행 중인 프로세스의 구분을 서로 동일시하지 않아야 한다. Muffin과 CJS는 독립 프로젝트이지만 Cinnamon은 해당 라이브러리에 연결하여 실행하며, 모든 구성 요소가 별도 데몬으로 하나씩 실행되는 것은 아니다. 반면 설정 창과 파일 관리자, 세션 서비스는 별도의 프로그램으로 동작할 수 있다.^[22]

Cinnamon Shell

Cinnamon Shell은 데스크톱의 패널, 응용 프로그램 메뉴, 알림, 작업 공간 개요, 창 전환과 각종 팝업을 구현하는 계층이다. 일반 응용 프로그램이 자신의 창 안을 그리는 것과 달리, 셸은 실행 중인 프로그램과 시스템 상태를 한 화면에서 조작할 수 있도록 연결한다. 예를 들어 메뉴에서 프로그램을 실행하면 창 관리자에 나타난 새 창을 창 추적 계층이 식별하고, 창 목록 애플릿이 이를 패널 항목으로 보여 준다.

구현은 JavaScript만으로 이루어진 웹 페이지가 아니다. Cinnamon의 빌드 정의에는 CJS, libmuffin, Muffin의 Clutter·Cogl 계열 라이브러리, GTK, GIO와 GObject Introspection 관련 의존성이 있다. JavaScript UI는 이러한 네이티브 계층 위에서 객체를 만들고 입력·창 상태의 변화를 처리한다. 셸의 St 위젯 계층과 GTK 설정 창도 같은 방식으로 그려지는 UI가 아니라 서로 다른 역할을 가진다.^[23]

이벤트 처리의 관점에서는 프로그램 실행, 창 생성, 포커스 변경, 모니터 연결과 사용자 설정 변경이 각각 UI 갱신의 입력이 된다. 창 목록은 창 생성·종료에, 패널은 화면 크기와 배치에, 사운드 애플릿은 오디오 서비스의 상태에 반응한다. 따라서 Cinnamon의 동작을 설명할 때 화면 요소의 모양뿐 아니라 어떤 상태를 관찰하고 어떤 동작을 요청하는지를 함께 보아야 한다.

셸 안에서 실행되는 확장 코드는 이 UI 객체와 이벤트 흐름에 직접 관여한다. 확장에서 오래 걸리는 동기 작업을 수행하거나 제거된 객체의 시그널을 정리하지 않으면 다른 셸 동작에도 영향을 줄 수 있다. Spices의 호환성 검토와 Looking Glass를 통한 오류 확인이 중요한 것은 이처럼 확장이 데스크톱의 실행 경로와 가깝게 결합되기 때문이다.^[24]

Muffin

Muffin은 Mutter에서 파생된 Cinnamon의 창 관리·합성 기반이다. 창의 위치와 크기, 입력 초점, 최대화·최소화, 작업 공간 배치와 최종 화면 합성에 필요한 정보를 관리한다. Cinnamon의 빌드에서는 libmuffin-0와 Muffin의 Clutter·Cogl 구성 요소에 연결하므로, Muffin을 반드시 Cinnamon 밖에서 따로 돌아가는 창 관리 데몬으로 이해할 필요는 없다.^[25]

창 관리 정책과 셸 표현은 긴밀하게 연결되지만 같은 작업은 아니다. 창 관리 계층이 어떤 창이 활성화되었는지를 결정하면 창 목록이 그 창을 강조하고, 창의 작업 공간이 바뀌면 Expo의 배치가 달라진다. 창을 화면 가장자리로 옮기는 입력은 Muffin의 타일링 정책과 연결되고, 패널이 차지하는 영역은 최대화된 창이 사용할 수 있는 작업 영역에 영향을 준다.

Cinnamon의 창 설정은 이러한 정책 일부를 org.cinnamon.muffin과 org.cinnamon.desktop.wm.preferences의 키로 조절한다. 창 배치 모드, 모달 대화상자 연결, 타일링, 창 테두리의 조절 가능 폭 등이 구체적인 예다. 설정 UI는 값을 바꾸는 인터페이스이며 실제 창 배치와 입력 초점의 적용은 창 관리 계층에서 이루어진다.^[26]

X11에서는 별도 X 서버와 창 관리자·합성기가 협력하지만 Wayland에서는 합성기가 화면 출력과 입력 전달의 중심이 된다. 그러므로 같은 Muffin 계열이라도 세션에 따라 창 식별과 화면 촬영, 전역 단축키의 구현 경로가 달라진다. Cinnamon의 Wayland 개발 기록을 Muffin과 분리된 단순한 UI 변경 목록으로만 읽을 수 없는 이유다.

CJS

CJS는 Cinnamon에서 JavaScript와 네이티브 GObject 라이브러리를 연결하는 실행 환경이다. SpiderMonkey 계열 JavaScript 엔진과 GObject Introspection을 이용하여 C로 정의된 객체, 속성과 시그널을 JavaScript 코드에서 다룰 수 있게 한다. 셸 코드에서 imports.gi로 가져오는 Gio, GLib, Meta, St 등의 객체가 이러한 연결 방식의 예다.^[27][28]

웹 브라우저와 달리 CJS 환경에는 웹 문서의 DOM을 중심으로 한 실행 모델이 적용되지 않는다. JavaScript 문법을 사용할 수 있다는 것과 브라우저의 window나 document, Node.js의 모듈·파일 API를 그대로 쓸 수 있다는 것은 별개다. Cinnamon 확장은 셸이 제공하는 모듈과 GObject 라이브러리를 이용해 UI와 시스템 서비스를 연결한다.

네이티브 객체와 JavaScript 객체의 수명도 함께 고려해야 한다. 이벤트 핸들러가 이미 제거된 UI 객체를 참조하거나, 타이머와 파일 모니터가 확장 제거 뒤에도 실행되면 오류가 발생할 수 있다. 메모리 관리는 JavaScript 엔진의 가비지 컬렉션만으로 끝나는 것이 아니라 시그널 연결과 네이티브 객체의 참조 관계까지 포함한다.

실제 버전 호환성은 빌드에도 드러난다. Cinnamon 6.6의 빌드 정의는 CJS 버전에 따라 GObject Introspection 라이브러리 선택을 달리하며, 6.6.8 변경 기록은 CJS 140으로 업그레이드할 때 Cinnamon 재빌드가 필요하다고 설명한다. CJS의 교체는 언어 문법 추가뿐 아니라 네이티브 바인딩의 호환성과 연결되는 변경이다.^[29][30]

Cinnamon Session

Cinnamon Session은 로그인 이후 필요한 데스크톱 구성 요소를 시작하고 사용자 세션의 종료 흐름을 관리한다. 디스플레이 관리자가 사용자를 인증하고 선택된 세션을 실행하면, 세션 관리자는 해당 환경에서 요구하는 프로그램과 자동 시작 항목을 구성한다. 로그인 화면 자체를 그리는 프로그램과 이미 로그인한 사용자의 데스크톱을 운영하는 프로그램은 서로 다른 역할이다.

6.6 계열의 세션 정의에는 cinnamon, org.cinnamon.ScreenSaver, nemo-autostart, cinnamon-killer-daemon 등이 RequiredComponents로 기록된다. 여기에 빌드 설정에 따라 NetworkManager의 외부 애플릿을 요구하는 항목이 삽입될 수 있다. 세션 이름은 단순한 표시 문자열만이 아니라 필요한 프로그램 조합을 가리키는 설정이기도 하다.^[31][32]

사용자 자동 시작 항목과 데스크톱의 필수 구성 요소도 구별된다. 문서 편집기나 메신저를 로그인할 때 실행하는 것은 개인 설정이지만, 창 관리와 셸을 제공하는 구성 요소가 시작되지 않는 것은 데스크톱 자체의 구성 문제다. 같은 프로그램이 세션 정의와 사용자 자동 시작 양쪽에 중복 등록되면 두 번 실행되는 등의 현상을 일으킬 수 있다.

로그아웃과 시스템 종료 역시 같은 동작은 아니다. 로그아웃은 해당 사용자 환경을 정리하는 과정이고, 시스템 종료·재시작·절전은 시스템의 세션·전원 서비스에 요청한다. 응용 프로그램의 저장되지 않은 작업이나 종료 지연과 같은 상태를 처리하는 것도 이 흐름과 연결되므로, 세션 관리는 프로그램 목록을 한 번 실행하는 스크립트 이상의 역할을 갖는다.

Cinnamon Settings Daemon

Cinnamon Settings Daemon은 데스크톱이 실행되는 동안 설정을 시스템 기능에 연결하는 구성 요소다. 키보드와 마우스, 미디어 키, 전원과 디스플레이처럼 설정 창을 닫은 뒤에도 유지되어야 하는 기능을 담당한다. 사용자가 슬라이더나 선택 상자를 조작하는 화면과, 그 결과를 장치와 세션에 적용하는 백그라운드 구성은 분리되어 있다.^[33]

예를 들어 미디어 키를 눌렀을 때 음량을 바꾸려면 키 이벤트를 처리하고 현재 오디오 서비스에 요청하며 화면에 상태를 표시하는 연결이 필요하다. 전원 설정을 적용하려면 배터리와 전원 공급 상태를 읽는 서비스 및 시스템의 절전 기능과 협력해야 한다. 이 과정에서 Cinnamon 자체 설정과 하부 운영체제의 권한·장치 상태가 함께 사용된다.

Settings Daemon이라는 프로젝트 이름을 모든 기능이 반드시 하나의 단일 프로세스에 들어 있다는 의미로 해석해서는 안 된다. 기능은 플러그인과 실행 구성으로 나뉠 수 있으며 구체적인 프로세스 구성은 버전과 배포판 패키징에 따라 확인해야 한다. 프로젝트의 역할과 실행 중인 서비스 이름을 구별하면 설정 문제의 원인을 더 정확하게 찾을 수 있다.

또한 Cinnamon 설정이 다른 데스크톱의 모든 장치 설정을 일괄 지배하는 것은 아니다. 여러 환경을 함께 설치한 시스템에서는 공통 라이브러리나 시스템 서비스를 공유하면서도 각 데스크톱이 다른 설정 키와 자동 시작 구성을 사용할 수 있다. 설정 창은 보이지만 적용되지 않는 경우에는 해당 세션의 서비스가 실제로 실행되었는지와 하부 서비스의 상태를 함께 살펴야 한다.

Cinnamon Settings와 Cinnamon Control Center

Cinnamon Settings는 여러 설정 모듈을 모아 사용자가 데스크톱의 외형과 동작을 바꾸도록 하는 통합 인터페이스다. 실제 Python 모듈에는 이름, 범주, 검색 키워드와 설명이 정의되고, 창 설정은 제목 표시줄·동작·Alt-Tab·타일링을 별도 페이지로 구성한다. 단순한 체크 상자 모음이 아니라 서로 다른 설정 공급자를 하나의 진입점으로 연결하는 구조다.^[34]

많은 항목은 GSettings 키와 UI 위젯을 연결하여 구현한다. 창 포커스 모드는 org.cinnamon.desktop.wm.preferences에, 패널 크기와 숨김 동작은 org.cinnamon에, 최근 파일 기록은 org.cinnamon.desktop.privacy에 연결된다. 화면에 표시되는 메뉴 분류와 설정이 실제로 저장되는 스키마는 일대일 관계가 아니며, 하나의 설정 화면에서도 여러 구성 요소의 키를 다룰 수 있다.

Cinnamon Control Center는 GNOME Control Center에서 파생된 설정 구성 요소의 계보와 연결된다. Cinnamon Settings와 명칭이 비슷하더라도 Python 설정 모듈 전체와 같은 대상을 가리킨다고 단정할 수 없다. 프로젝트별 라이브러리·설정 패널과 배포판이 설치하는 모듈을 구분해야 하며, Cinnamon Settings가 관련 패널을 통합하여 보여 주는 사용자 인터페이스라는 관점이 유용하다.^[35]

개인정보 모듈은 GSettings뿐 아니라 NetworkManager 클라이언트도 사용한다. 최근 파일 보관 기간은 설정 키로 저장하지만 인터넷 연결 검사 스위치는 libnm를 통해 해당 서비스에 요청한다. 같은 설정 창 안에서도 저장 방식과 적용 주체가 다르므로 설정 백업이나 문제 분석에서 모든 항목을 하나의 파일로 취급해서는 안 된다.^[36]

Cinnamon Desktop

Cinnamon Desktop은 데스크톱 관련 공통 라이브러리와 데이터·설정 기반을 제공하는 프로젝트다. 이름에 Desktop이 들어간다고 Cinnamon 전체 환경이나 셸의 모든 UI를 포함하는 저장소를 뜻하지 않는다. 여러 구성 요소에서 재사용하는 기능을 분리하고 공통 자료형과 설정 체계를 공유하도록 하는 것이 핵심이다.^[37]

공통 기반이 필요한 이유는 설정 화면과 실제 기능의 소비자가 서로 다른 프로그램이기 때문이다. 창 설정 화면에서 선택한 값을 창 관리 계층이 같은 의미로 읽고, 여러 도구가 같은 데스크톱 열거형과 속성을 이용하려면 정의를 공유해야 한다. 예를 들어 Cinnamon의 창 설정 모듈은 CDesktopEnums를 가져와 새 창 포커스 관련 값을 처리한다.^[38]

배포판 패키징에서는 이러한 프로젝트를 런타임 라이브러리, 개발 헤더, Introspection 데이터와 공통 데이터 패키지로 나누어 제공할 수 있다. 일반 사용자는 런타임만 필요할 수 있지만 Cinnamon이나 관련 프로그램을 빌드하려면 개발 파일도 필요하다. 실행 파일 하나가 설치되어 있다는 사실만으로 필요한 스키마와 typelib까지 모두 갖추었다고 볼 수는 없다.

Cinnamon Desktop의 버전도 셸과의 조합 안에서 해석해야 한다. 같은 사용자 인터페이스가 보이더라도 공통 라이브러리의 자료형이나 설정이 달라지면 하부 코드의 호환성에 영향을 준다. 개별 패키지 이름과 전체 데스크톱의 제품명을 분리하는 것은 Cinnamon의 소스 구조를 이해하는 기본적인 구분이다.

Cinnamon Screensaver

Cinnamon Screensaver는 유휴 상태에서의 화면 표시와 사용자 세션 잠금을 담당하는 구성 요소다. 화면을 어둡게 하거나 그림을 표시하는 기능과, 인증 전에는 세션으로 입력을 보내지 않도록 보호하는 기능은 관련되지만 동일하지 않다. 잠금 상태에서는 비밀번호 입력·인증 결과·화면 차폐와 세션 상태를 일관되게 관리해야 한다.

6.6의 세션 정의에는 별도 ScreenSaver 구성 요소가 포함된다. 반면 6.7 개발 계열의 컨트롤러는 내부 화면 차폐 구현과 별도 cinnamon-screensaver를 선택하는 경로를 갖는다. Wayland에서는 내부 구현을 사용하고, X11에서는 설정에 따라 내부 구현 또는 외부 프로세스의 서비스를 이용한다. 따라서 모든 Cinnamon 버전의 잠금을 같은 프로세스 구조로 설명해서는 안 된다.^[39][40]

개발 컨트롤러는 잠금·잠금 해제 시그널을 받아 상태를 갱신하고, 외부 서비스가 사용될 때에는 서비스 이름의 소유자가 바뀌는 것도 관찰한다. 사용자 전환이나 로그아웃과 달리 잠금에서는 기존 프로그램을 계속 유지해야 하므로, 잠금 상태를 저장하거나 셸 재시작 뒤 복원하는 경로도 중요하다. 코드에는 X11에서 셸 재시작 후 잠금을 복원하는 경우와 Wayland에서 재시작을 같은 방식으로 처리하지 않는 경우가 구분되어 있다.

사용자 정의 잠금 명령 역시 세션에 따라 의미가 다르다. 확인한 개발 코드에서는 Wayland의 외부 잠금 명령을 무시하며 별도 세션 잠금 프로토콜이 필요하다고 설명한다. 단순히 전체 화면 프로그램을 띄우는 것을 데스크톱 잠금과 동등하게 취급할 수 없는 이유는 인증 전의 입력과 출력을 누가 통제하는지가 다르기 때문이다.

Nemo

Nemo는 Cinnamon의 파일 관리와 데스크톱 파일 표현을 담당하는 별도 프로그램이다. Nautilus에서 파생되었으며 파일·폴더 탐색, 탭과 추가 탐색 창, 책갈피, 파일 작업과 플러그인 기능을 제공한다. Cinnamon Shell이 프로그램 실행과 창 탐색의 공통 UI를 제공한다면 Nemo는 저장소 안의 파일과 그 작업을 다루는 역할에 집중한다.^[41]

Nemo의 파일 관리 창과 데스크톱 아이콘 담당 기능도 구분된다. 데스크톱에 파일을 놓거나 휴지통과 장치를 표시하는 것은 Cinnamon의 패널 애플릿을 늘리는 방식과 다르다. 셸의 메뉴, Nemo의 문맥 메뉴, 운영체제의 파일 권한은 서로 다른 계층이지만 사용자는 같은 화면에서 연결된 기능으로 경험한다.

Nemo는 자체 릴리스와 변경 기록을 갖는다. 6.6.0 기록에는 파일 작업의 일시 중지·재개, 정규식 파일명 검색, 검색 도우미와 MIME 처리 개선, 문서 템플릿 관리와 추가 탐색 영역 전환 버튼이 포함된다. Cinnamon의 버전만 보고 이러한 파일 관리자 기능을 모두 추정할 수 없는 이유다.^[42]

확장 관점에서는 Nemo의 플러그인 인터페이스와 .nemo_action 형식의 Action을 구별한다. 플러그인은 파일 관리자의 객체와 메뉴를 확장하고, Action은 선택 조건과 실행 명령을 선언하여 문맥 메뉴 작업을 추가한다. Cinnamon Spices에 Action이 포함되어도 그것이 Cinnamon 셸 내부에서 실행되는 JavaScript 애플릿과 같은 종류의 구성 요소가 되는 것은 아니다.^[43]

구성 요소 간 연동

로그인부터 파일 실행까지의 흐름은 구성 요소의 관계를 보여 준다. 로그인 관리자는 인증된 사용자의 세션을 시작하고, Cinnamon Session은 세션 정의에 있는 셸과 필요한 프로그램을 준비한다. Cinnamon은 연결된 Muffin과 CJS 기능을 사용해 창 관리·그래픽 합성·JavaScript UI를 구성한다. Nemo는 파일 관리와 데스크톱 항목을 제공하고 설정 서비스는 장치와 세션 상태를 유지한다.^[44][45]

사용자가 메뉴에서 앱을 실행하면 실행 항목의 정보가 프로그램 실행으로 이어지고, 생성된 창은 창 관리 계층에 등록된다. 창 목록은 애플리케이션별 창을 묶고 활성 창 상태를 표시한다. 사용자가 다른 작업 공간으로 창을 이동하면 창의 배치 상태가 바뀌고 해당 공간의 개요와 패널 표시가 갱신된다. 이 과정은 앱 자체의 문서 데이터 처리와는 독립적으로 이루어진다.

설정 변경은 다른 흐름을 따른다. 창 포커스나 패널 크기는 해당 스키마에 기록된 뒤 창 관리 계층과 셸에 반영되고, Spices의 인스턴스별 설정은 별도의 xlet 설정 API가 관리한다. 오디오·네트워크처럼 외부 서비스와 연결되는 항목은 프로세스 간 통신도 필요하다. 모든 구성 요소가 직접 함수 호출로 연결되거나, 반대로 모두 D-Bus를 거친다고 일반화할 수 없다.^[46][47]

이 구조에서는 화면 증상과 원인이 다른 계층에 있을 수 있다. 패널의 네트워크 아이콘 문제는 애플릿·서비스·권한 중 어느 쪽에도 있을 수 있고, 파일이 열리지 않는 문제는 Nemo의 연결 프로그램이나 파일 접근 권한과 관련될 수 있다. 구성 요소 간 연동을 구분하면 데스크톱 전체를 하나의 프로그램으로 취급할 때보다 문제의 범위를 정확히 설명할 수 있다.

Cinnamon의 사용자 인터페이스는 프로그램을 찾고 실행하는 메뉴, 실행 중인 창을 고르는 창 목록, 파일을 놓는 데스크톱과 시스템 상태를 보여 주는 패널을 연결한다. 같은 기본 구조 안에서도 애플릿, 창 전환 방식과 작업 공간 표시 정책을 바꾸어 다른 작업 흐름을 만들 수 있다. 따라서 Linux Mint의 기본 화면은 Cinnamon으로 구성할 수 있는 대표적인 배치이지, 모든 Cinnamon 설치에서 고정되는 유일한 모습은 아니다.

데스크톱 메타포

Cinnamon은 파일과 폴더를 아이콘으로 표현하는 바탕 화면, 프로그램별 창, 응용 프로그램 메뉴와 작업 표시줄을 사용하는 데스크톱 메타포를 따른다. 프로그램을 실행하는 위치와 실행 중인 창을 다시 찾는 위치를 지속적으로 표시하여, 활동 개요 화면으로 전환하지 않고도 기본 작업을 수행할 수 있다. 메뉴와 창 목록은 패널에 배치되지만 서로 독립된 기능 요소다.^[48]

예를 들어 편집기와 브라우저를 실행하면 사용자는 두 창을 나란히 배치하고 패널에서 활성 창을 확인할 수 있다. 편집기에 문서를 여러 개 열었을 때 창마다 버튼을 표시하거나 프로그램 아이콘 하나 아래 묶어 보여 주는 방식도 선택할 수 있다. 전통적인 데스크톱이라는 설명은 이러한 기능이 단순하다는 뜻이 아니라, 창과 파일을 직접 조작하는 기본 단위를 유지한다는 뜻이다.

바탕 화면의 파일 아이콘, 패널에 고정한 실행기, 실제 실행 중인 창은 같은 아이콘을 사용할 수 있어도 다른 객체다. 파일 아이콘은 저장된 파일을 열고, 실행기는 프로그램을 시작하며, 창 목록은 이미 존재하는 창을 활성화한다. Grouped Window List는 실행기와 창 목록을 한 항목에 결합하지만 설정에 따라 클릭의 의미를 달리할 수 있다.^[49]

이 모델에 작업 공간과 Overview·Expo를 더하면 화면에 보이는 창만으로 작업을 제한하지 않고 여러 작업 집합을 유지할 수 있다. 기본 패널을 그대로 두고 단축키와 개요 화면을 적극적으로 사용하는 방식, 패널을 여러 개 만들고 상태 애플릿을 분리하는 방식 등도 같은 Cinnamon 환경 안에서 구성된다.

패널

패널은 메뉴·실행기·창 목록·시계·상태 정보를 배치하는 컨테이너다. 가로 패널에서는 왼쪽·가운데·오른쪽 영역으로, 세로 패널에서는 위·가운데·아래 영역으로 구분해 구성 요소를 배치한다. 프로그램 창과 달리 패널은 화면 가장자리에 붙어 데스크톱의 공통 조작 영역을 제공한다.^[50]

표시 방식에는 항상 표시, 자동 숨김과 지능적 숨김이 있다. 자동 숨김을 사용하면 화면 공간을 더 확보할 수 있지만 포인터가 가장자리에 도달했을 때 패널을 다시 표시하는 동작이 필요하다. 표시 지연과 숨김 지연은 별도 항목이므로, 패널이 너무 쉽게 나타나거나 사라지는 상황을 따로 조정할 수 있다. 확인한 6.6 설정 모듈은 지연을 밀리초 단위로 다룬다.

패널의 전체 높이와 패널 안의 아이콘 크기는 같은 설정이 아니다. 영역별로 글꼴 크기, 전체 색상 아이콘 크기와 심벌 아이콘 크기를 정할 수 있고, 색상 아이콘을 패널 크기에 정확히 또는 적절하게 맞추는 방식도 있다. 큰 앱 실행 아이콘과 작은 상태 아이콘을 같은 패널에 배치하면서도 서로 다른 비율을 유지할 수 있는 구조다.

복수의 패널은 각각 식별자를 갖고 위치·모니터·크기·숨김 정책을 저장한다. 설정 화면에서 이전·다음 패널을 선택하는 인터페이스가 존재하는 이유도 모든 패널에 같은 값 하나를 적용하는 구조가 아니기 때문이다. 화면 연결 상태가 바뀌면 패널의 위치를 복원하고 작업 영역을 다시 계산해야 하며, 관련 처리는 Cinnamon의 다중 모니터 변경 기록에서도 개선 대상으로 나타난다.^[51]

응용 프로그램 메뉴

응용 프로그램 메뉴는 설치된 프로그램의 데스크톱 항목을 읽어 이름과 아이콘, 분류 정보를 사용자에게 보여 준다. 사용자는 범주를 탐색하거나 검색어를 입력하여 실행 대상을 찾고 자주 사용하는 프로그램을 즐겨찾기에 배치한다. Cinnamon의 빌드 정의에는 메뉴 처리용 libcinnamon-menu-3.0가 포함되어 있어 메뉴가 파일 시스템의 실행 파일을 무작정 나열하는 기능과는 다름을 보여 준다.^[52]

메뉴에서 보이는 이름과 실제 실행 명령, 패널에서 창을 묶는 식별자는 서로 다를 수 있다. 하나의 프로그램이 여러 데스크톱 실행 항목을 제공하거나, 실행기가 별도 프로세스를 통해 창을 만드는 경우가 있기 때문이다. 사용자가 메뉴의 표시 이름을 바꾸는 것과 실행 중인 창의 애플리케이션 식별을 바꾸는 것이 반드시 같은 결과를 만들지는 않는다.

검색 결과에 최근 문서와 즐겨찾기를 함께 제공하면 실행할 프로그램과 다시 열 파일이 같은 목록에 나타날 수 있다. Cinnamon 6.7.8의 변경 기록은 앱과 즐겨찾기를 최근 문서보다 먼저 보여 주도록 순서를 조정했다고 설명한다. 이는 검색이 단순 문자열 포함 여부뿐 아니라 서로 다른 종류의 결과를 어떤 우선순위로 제공할지도 포함하는 기능임을 보여 준다.^[53]

기본 메뉴 역시 패널 애플릿이므로 다른 메뉴 구현으로 교체할 수 있다. 이때 전체 Cinnamon 세션이나 창 관리자를 교체하는 것은 아니며, 앱을 탐색하고 실행하는 진입점만 달라진다. 추가 메뉴 애플릿의 기능과 설정은 Cinnamon 기본 메뉴의 지원 범위와 구분해서 설명해야 한다.

창 목록과 작업 표시줄

창 목록은 실행 중인 프로그램의 창을 지속적으로 표시하는 기능이다. Grouped Window List는 같은 응용 프로그램에 속하는 여러 창을 한 항목으로 묶고, 아이콘 위에 창 수와 알림 배지를 표시하거나 미리 보기에서 개별 창을 선택하도록 한다. 프로그램을 고정해 실행기로 사용하는 기능과 이미 실행된 창을 전환하는 기능을 같은 패널 항목에 결합한다.^[54]

조작 방식은 하나로 고정되지 않는다. 왼쪽 클릭은 마지막 활성 창을 전환하거나 그룹의 창을 순환하는 방식으로 정할 수 있으며, 가운데 클릭은 새 인스턴스 실행 또는 그룹의 마지막 활성 창 닫기 등으로 지정할 수 있다. 마우스 휠도 아무 동작을 하지 않거나 앱 사이, 창 사이를 순환하는 방식으로 선택한다. 고정한 실행기를 누르는 동작과 여러 창이 열린 그룹을 누르는 동작을 구분해야 설정의 의미가 명확해진다.

미리 보기에는 표시 여부, 세로 배치, 정렬, 최근 활성 창 강조, 클릭으로 표시할지 여부와 지연 등이 설정된다. Hover Peek는 특정 창을 임시로 확인하도록 다른 창의 시각적 표현을 바꾸는 기능과 연결되며, 들어갈 때와 나올 때의 시간 및 투명도 설정이 별도로 존재한다. 버튼의 텍스트도 숨기기, 앱 이름, 창 제목, 활성 창에만 제목 표시 등으로 구성할 수 있다.

표시 범위는 작업 공간과 모니터를 함께 고려한다. 현재 작업 공간만 볼지 전체 작업 공간을 볼지, 다른 모니터의 창도 표시할지, 창 목록이 없는 모니터의 창만 가져올지 등을 정할 수 있다. 모니터마다 패널을 두는 구성에서는 모든 패널에 모든 창을 중복 표시하는 방식과 각 화면의 작업을 분리하는 방식 사이에서 선택할 수 있다. Super와 숫자 키를 이용한 실행·전환도 별도 설정으로 제공된다.

시스템 트레이와 상태 Applet

패널의 시스템 영역은 네트워크, 사운드, 전원과 입력기 등 지속적으로 확인할 상태를 모은다. Cinnamon 자체 애플릿이 시스템 서비스의 정보를 표시하는 경우와 응용 프로그램이 자신의 상태 아이콘을 제공하는 경우가 함께 존재한다. 아이콘이 같은 영역에 놓였다고 해서 모두 같은 프로그램이나 같은 통신 방식을 사용하는 것은 아니다.

네트워크 구성은 이 차이를 잘 보여 준다. Cinnamon의 빌드 옵션에는 내장 NetworkManager 에이전트, 외부 에이전트 또는 NetworkManager 지원 비활성화가 있다. 내장 구성을 선택하면 libnm와 비밀 저장 관련 라이브러리에 연결하고, 외부 구성을 선택하면 세션 정의에서 별도 애플릿을 요구할 수 있다. 네트워크 표시를 Cinnamon이 제공한다는 설명과 실제 연결 서비스를 Cinnamon 자체가 구현한다는 설명은 구별된다.^[55][56]

전통적인 트레이 아이콘과 상태 알림용 인터페이스는 응용 프로그램의 구현에 따라 다르게 사용된다. 따라서 아이콘이 보이지 않는 문제를 단순히 패널 색상이나 테마 문제로만 볼 수 없고, 프로그램이 어떤 인터페이스를 사용하는지와 세션에 이를 표시하는 구성 요소가 있는지를 함께 확인해야 한다. 배포판이 추가한 업데이트 관리자나 동기화 프로그램도 Cinnamon 기본 기능과 별도의 앱이다.

6.6 유지보수 기록에는 일부 기본 애플릿의 XApp 심벌 아이콘 전환과 IBus 애플릿 표시 관련 변경이 들어 있다. 상태 영역의 구현은 UI 아이콘 자원, 입력기 통합과 서비스 중복 표시를 함께 다루는 분야라는 점을 보여 준다. 특정 배포판 화면에 보이는 모든 아이콘을 Cinnamon 본체의 고정 구성으로 설명하는 것은 이러한 차이를 반영하지 못한다.^[57]

알림

데스크톱 알림은 응용 프로그램이 작업 완료, 메시지 도착이나 장치 상태 변화를 사용자에게 전달하는 방식이다. Cinnamon은 알림을 화면의 팝업과 알림 관련 UI로 표시하며, 알림을 보내는 프로그램과 알림을 그리는 셸은 역할이 분리되어 있다. 알림이 표시되었다고 해서 해당 프로그램의 창이 반드시 활성화되는 것은 아니며, 창이 주의를 요청하는 상태와 화면 팝업도 구분되는 기능이다.

알림의 동작은 내용뿐 아니라 표시 시간과 위치, 사용자가 나중에 확인할 수 있는 방식에 영향을 받는다. 짧게 나타났다 사라지는 메시지는 작업을 덜 방해하지만 놓치기 쉽고, 계속 남는 알림은 중요한 상태를 유지하는 대신 화면을 더 점유한다. 실제 제공되는 옵션과 기본값은 설치된 Cinnamon 버전 및 알림을 생성한 앱의 요청을 함께 확인해야 한다.

Grouped Window List에는 알림 배지를 표시하는 설정이 따로 있다. 이는 창 목록 항목에 프로그램의 주의 상태를 표시하는 기능이며, 패널의 모든 알림 표시를 하나의 전역 스위치로 관리한다는 뜻이 아니다. 알림 팝업, 앱 버튼의 배지와 프로그램 자체의 상태 아이콘이 각각 사용자에게 다른 정보를 제공할 수 있다.^[58]

외형은 Cinnamon 셸 테마와 연결된다. 알림의 배경, 텍스트 대비, 모서리와 여백은 셸의 시각적 표현에 속하며 GTK 응용 프로그램의 위젯 테마와 동일한 설정이 아니다. 알림이 안 보이거나 읽기 어려운 경우에는 알림의 생성·표시 정책과 테마의 가독성을 나누어 살펴야 한다.^[59]

작업 공간

작업 공간은 하나의 로그인 세션 안에서 창을 여러 집합으로 나누는 가상 데스크톱 기능이다. 사용자는 편집과 빌드, 웹 탐색, 메시지 확인처럼 서로 다른 작업에 필요한 창을 다른 공간에 배치할 수 있다. 창의 실행 상태와 문서는 유지하면서 현재 화면에 어떤 창 집합을 보여 줄지를 전환하는 방식이다.

작업 공간의 구분과 패널의 표시 범위는 독립적으로 설정될 수 있다. 현재 작업 공간의 창만 창 목록에 표시하면 그 공간에서 작업 중인 프로그램을 중심으로 볼 수 있고, 전체 작업 공간의 창을 표시하면 어느 공간에 있는 창인지와 관계없이 전환할 수 있다. Grouped Window List와 Alt-Tab 설정에는 전체 작업 공간의 창을 포함하는 옵션이 각각 존재한다.^[60][61]

한 창을 모든 작업 공간에 나타나게 하는 것과 창을 항상 위에 놓는 것도 다른 정책이다. 앞의 정책은 어느 작업 공간에서 보이는지를, 뒤의 정책은 같은 공간 안에서 다른 창과 어떤 쌓임 순서를 갖는지를 다룬다. Cinnamon의 제목 표시줄 동작 목록에도 이 두 동작이 구분되어 있다. 여러 창을 정리할 때 공간, 활성 상태와 쌓임 순서를 각각 생각하면 동작이 명확해진다.

작업 공간은 보안 격리 단위가 아니다. 서로 다른 작업 공간의 앱도 같은 사용자 권한과 세션의 서비스를 이용한다. 별도 계정이나 컨테이너, 가상 머신이 필요한 작업을 작업 공간 배치만으로 격리했다고 볼 수는 없으며, Cinnamon의 작업 공간은 주로 화면 탐색과 작업 정리를 위한 기능이다.

Expo와 Overview

Expo와 Overview는 열린 작업을 화면 전체의 미리 보기로 탐색하는 인터페이스다. Expo는 여러 작업 공간의 관계와 창 배치를 보는 데, Overview는 열린 창을 찾아 선택하는 데 초점을 둔다. 패널에서 프로그램 이름이나 아이콘을 선택하는 방식에 비해 창의 실제 시각적 내용을 이용해 대상을 구별할 수 있다.

미리 보기는 일반 프로그램 창을 새로 복제해 실행하는 것이 아니라 기존 창과 그 그래픽 표현을 이용한다. 창의 위치, 크기와 모니터 정보가 바뀌면 개요 화면의 배치도 갱신되어야 한다. 공간 간 창 이동과 창 선택이 실제 창 관리 상태에 연결되므로 셸 애니메이션과 Muffin의 창 정보를 함께 다룬다.

6.7 개발 기록에는 Expo와 Overview의 객체·애니메이션 처리 정비, 작업 공간 순서 변경, 창을 다른 공간으로 옮길 때의 중복 표시 방지와 배경 음영 처리 변경 등이 나타난다. 화면에 창을 축소해서 나열하는 기능 뒤에는 드래그 상태, 창의 원래 위치, 이벤트 시점과 배율을 일치시키는 작업이 있다는 것을 보여 준다.^[62]

키보드의 Alt-Tab 전환기와 이들 화면은 서로 보완적인 수단이다. Alt-Tab은 최근 창 사이를 빠르게 이동하는 데 적합하고, 개요 화면은 어떤 창을 선택할지 시각적으로 탐색하는 데 유용하다. 사용자는 단축키·핫 코너·패널 애플릿 등 여러 진입점을 이용해 같은 작업 공간과 창 상태에 접근할 수 있다.

핫 코너

핫 코너는 포인터가 화면의 모서리에 도달했을 때 개요 화면이나 지정한 작업을 호출하는 입력 방식이다. 메뉴를 클릭하거나 키 조합을 누르는 대신 화면 경계라는 위치를 사용한다. 마우스 이동으로 창 개요를 빠르게 열 수 있다는 점에서 창 목록과 단축키에 추가되는 탐색 경로다.

핫 코너의 동작을 이해하려면 물리적 모니터의 모서리와 논리적 화면 배치의 경계를 구분해야 한다. 두 모니터가 맞닿아 있으면 한쪽 화면의 경계가 포인터 이동의 끝이 아니라 다른 화면으로 이어지는 통로가 된다. 해상도와 화면 배치가 다른 경우 모서리의 접근 방식도 달라지므로, 다중 모니터 설정과 핫 코너는 서로 독립된 문제로만 다룰 수 없다.

의도하지 않은 활성화와 빠른 호출 사이의 균형도 중요하다. 창 닫기 버튼이나 화면 가장자리의 프로그램 UI를 조작하는 움직임과 개요 화면 호출이 겹칠 수 있기 때문이다. 사용하지 않는 모서리의 동작을 끄거나 키보드·패널의 진입점을 이용하는 식으로 작업 방식에 맞추어 구성할 수 있다. 설정 항목과 지원되는 동작의 종류는 설치한 셸 버전을 기준으로 확인한다.

내부적으로는 화면 배치와 포인터 이벤트를 처리하는 Cinnamon의 셸 기능에 속한다. 6.7 개발 기록에 포인터 장벽 위치와 패널·모니터 상호작용 조정이 함께 나타나는 것은 화면 경계에서의 입력 처리가 단순한 좌표 비교만으로 끝나지 않음을 보여 준다.^[63]

창 배치와 타일링

Cinnamon은 일반적인 겹침형 창 관리에 화면 가장자리 배치 기능을 결합한다. 사용자가 창을 화면 경계로 이동하면 정해진 영역에 맞추어 배치할 수 있으며, 최대화와 타일링의 동작을 설정으로 구분한다. 확인한 창 설정 모듈에는 가장자리 타일링 활성화와 상단 경계로 끌 때 타일링 대신 최대화하는 옵션이 있다.^[64]

새 창의 최초 위치는 가장자리 타일링과 별도의 문제다. Cinnamon의 설정은 자동 배치, 포인터 위치, 수동 배치와 가운데 배치를 선택지로 제공한다. 프로그램이 새 창을 만들 때 적용하는 위치 정책과 사용자가 이미 열린 창을 옮겨 정렬하는 동작을 구분하면, 창이 예상한 위치에 나타나지 않는 현상을 더 정확하게 설명할 수 있다.

수정키를 누른 채 창을 이동하거나 크기를 조절하는 방식도 제공된다. 창 설정에는 해당 수정키를 선택하는 항목과 크기 조절에 사용되는 테두리 폭을 조정하는 항목이 있다. 화면에서 보이는 테두리가 얇더라도 포인터로 잡을 수 있는 영역을 넓히면 고해상도 모니터에서 창을 조절하기 쉬워진다. 시각적 테두리와 입력을 받는 영역이 반드시 같은 폭일 필요는 없다.

이 기능은 모든 창을 자동으로 분할 트리에 배치하는 전용 타일링 창 관리 방식과 다르다. Cinnamon은 창을 자유롭게 겹쳐 놓는 기본 모델을 유지하고 필요한 창에 배치 편의를 제공한다. 타일링을 활성화해도 창의 최소 크기, 대화상자의 성격과 화면의 작업 영역 같은 제약은 각각 적용된다.

화면 잠금과 세션 종료

화면 잠금, 사용자 전환, 로그아웃과 시스템 종료는 서로 다른 동작이다. 잠금은 기존 앱을 유지한 채 입력을 보호하고, 사용자 전환은 다른 로그인 환경으로 이동하며, 로그아웃은 현재 세션을 정리한다. 시스템 종료·재시작·절전은 그보다 아래의 운영체제 상태를 바꾸는 요청이다. 비슷한 메뉴에 놓여 있어도 실행 결과와 보존되는 작업 상태가 다르다.

잠금에서는 화면 차폐와 인증 상태가 일치해야 한다. 비밀번호를 검사하는 동안 입력을 어떻게 처리할지, 모니터가 연결되었을 때 잠금 화면이 어디까지 덮을지, 셸 상태 변화 후 잠금이 유지되는지 등이 실제 구현의 일부다. Cinnamon의 개발 변경 기록에는 인증 처리 중 입력 차단과 잠금 컨트롤러·화면 차폐 개선이 포함된다.^[65]

로그아웃에서는 응용 프로그램의 저장되지 않은 상태와 종료 순서가 중요하다. 화면을 잠그는 것처럼 앱을 그대로 두는 과정이 아니므로 사용자에게 확인을 제공하는 대화상자와 종료 요청의 결과를 구분해야 한다. 6.6 유지보수 기록에는 절전·최대 절전 선택 직후 종료 대화상자를 닫는 동작을 조정한 내용도 있어, 메뉴 선택과 실제 시스템 동작 완료가 같은 순간이 아님을 보여 준다.^[66]

Wayland에서는 합성기가 입력과 출력을 통제하므로 외부 프로그램을 전체 화면으로 띄우는 방식만으로 잠금을 대체할 수 없다. 확인한 개발 컨트롤러가 Wayland의 외부 잠금 명령을 무시하는 것은 이러한 구현 차이를 반영한다. X11에서 사용하던 잠금 명령을 다른 세션에 그대로 적용하는 것보다, Cinnamon이 해당 세션에 제공하는 잠금 경로를 기준으로 동작을 설명해야 한다.^[67]

다중 모니터와 화면 배율

다중 모니터 환경에서는 출력 장치의 해상도와 회전뿐 아니라 논리적 위치, 주 모니터, 패널과 창의 소속을 관리한다. 해상도가 다른 모니터를 연결하면 화면 경계의 높이가 달라지고, 창을 옮길 때의 크기와 미리 보기 배치도 영향을 받는다. 물리적으로 왼쪽에 놓인 모니터가 설정상 오른쪽에 있으면 포인터 이동과 창 배치가 실제 책상 배치와 어긋난다.

창 탐색 UI는 모니터 구성에 별도의 정책을 제공한다. Alt-Tab은 주 모니터와 현재 활성 모니터 중 어느 쪽에 표시할지 선택할 수 있으며, 현재 모니터의 창만 포함하는 옵션도 있다. Grouped Window List에는 다른 모니터의 창을 표시하는 범위가 존재한다. 출력 배치를 바꾸는 설정과 창 목록이 어느 화면의 창을 보여 주는지 정하는 설정은 다른 계층이다.^[68][69]

배율에서는 UI의 논리적 크기와 실제 픽셀 크기를 구별한다. 고밀도 모니터에서 글자가 작게 보이는 문제를 해결하기 위해 UI를 확대하면 창의 사용 가능한 논리적 작업 영역은 줄어들 수 있다. 서로 다른 배율의 모니터를 함께 사용하는 경우에는 창을 이동할 때 텍스트·아이콘·미리 보기를 어떤 해상도로 그릴지도 고려해야 한다.

6.7 개발 기록에는 자원 배율 API 대응, St 이미지·아이콘과 키보드 표시의 배율 처리, 패널 배치 복원과 모니터별 배경 화면이 기록되어 있다. 다중 모니터 지원은 해상도 목록에 장치가 나타나는 수준을 넘어 셸의 여러 UI 요소가 새 좌표와 배율을 일관되게 적용하는 문제다.^[70]

접근성

Cinnamon의 접근성은 화면 확대와 고대비 표현, 키보드 탐색, 화면 키보드와 보조 기술의 정보 접근을 포함한다. 셸 버튼이 화면에 그려지는 것과 그 버튼의 이름·상태·동작을 보조 기술이 이해하는 것은 별도의 조건이다. 네이티브 접근성 라이브러리와 GTK·GObject 기반 UI가 제공하는 정보가 함께 사용되며, Cinnamon의 빌드 정의에도 접근성 브리지 의존성이 포함된다.^[71]

화면 키보드는 문자 버튼을 모아 놓은 그림 이상이다. 확인한 6.6 구현에는 Esc, Tab, 방향키, Ctrl·Alt와 레이아웃 전환, 길게 누르기와 화면 위치·크기 관련 설정이 있다. 텍스트 필드의 포커스와 입력 소스에 맞추어 키를 전달해야 하고, 암호 입력과 일반 텍스트 입력의 처리도 구별해야 한다.^[72]

키보드 접근에서는 메뉴와 대화상자를 포인터 없이 선택할 수 있는지, 포커스가 어디에 있는지 명확하게 표시되는지가 중요하다. 화면 확대에서는 확대된 영역과 실제 입력 좌표를 일치시켜야 한다. Wayland 이식 기록에 확대기의 포인터 이벤트와 입력기·가상 키보드 연동 수정이 나타나는 것은 이러한 기능도 세션 구조의 변화에 직접 영향을 받기 때문이다.^[73]

접근성의 범위는 데스크톱 패널에만 머물지 않는다. 잠금 화면에서 인증할 수 있어야 하고, 설정 창과 파일 관리자에서도 필요한 정보가 전달되어야 하며, 사용자가 설치한 애플릿도 적절한 이름과 포커스 동작을 제공해야 한다. 따라서 Cinnamon 본체가 접근성 기반을 갖추었다는 사실과 모든 외부 응용 프로그램·Spices가 같은 수준으로 접근 가능하다는 주장은 구분해야 한다.

Cinnamon의 사용자화는 테마를 교체하는 작업과 창 관리 정책을 바꾸는 작업, Spices를 설치하는 작업이 함께 포함된다. 설정의 저장 방식도 하나가 아니다. 셸·데스크톱 기본 설정은 GSettings 스키마를 사용하고, xlet의 인스턴스별 설정은 별도 API가 관리하며, 네트워크 등의 일부 항목은 시스템 서비스에 직접 요청한다. 이 차이는 설정 이전과 백업, 문제 분석에서도 중요하다.

Cinnamon Settings

Cinnamon Settings는 설정 모듈을 범주와 검색 키워드로 정리하는 사용자 진입점이다. 창 설정에는 제목 표시줄·행동·Alt-Tab·타일링 페이지가 있고, 패널 설정은 현재 선택한 패널과 각 영역을 구분한다. 하나의 설정 창에서 여러 기능을 다루더라도 사용자가 실제로 변경하는 대상은 창 관리자·셸·외부 서비스 등으로 나뉜다.^[74][75]

설정 간 의존성도 UI에 반영된다. 예를 들어 포커스 모드에 따라 자동 올리기 항목을 보여 주고, 패널을 항상 표시할 때에는 숨김 지연처럼 의미가 없는 항목의 표시를 조절한다. 최근 파일 기록을 끄면 보관 기간을 다루는 하위 설정도 함께 감춘다. 설정 모듈은 값을 나열하는 것뿐 아니라 어떤 조합에서 각 항목이 유효한지를 표현한다.

즉시 적용되는 설정과 재시작이 필요한 변경은 구분해야 한다. 스키마 값을 관찰하는 셸 기능은 변경 직후 갱신될 수 있지만, 외부 라이브러리 교체나 세션 구성을 바꾸는 일은 같은 수준의 설정 변경이 아니다. 배포판 패키지를 업데이트하는 동작과 Cinnamon Settings에서 개인 설정을 바꾸는 동작도 서로 다른 관리 경로다.

백업에서는 기본 설정, 추가 Spices의 코드, 인스턴스 설정과 실제 테마·이미지 파일을 함께 생각해야 한다. 설정 값에 테마 이름만 남아 있고 대상 테마가 새 시스템에 없으면 같은 화면이 재현되지 않는다. 설정의 복원은 이름과 값뿐 아니라 그 값이 참조하는 자원이 존재하는지까지 포함한다.

Theme

Cinnamon의 테마 설정은 셸 테마, GTK 응용 프로그램 테마, 아이콘과 커서 테마를 구분한다. 셸 테마는 패널·메뉴·알림처럼 Cinnamon이 그리는 요소에 적용되고, GTK 테마는 해당 툴킷을 사용하는 응용 프로그램의 위젯에 적용된다. 둘의 이름이 같거나 한 배포판이 하나의 조합으로 제공하더라도 실제 적용 대상은 다르다.^[76]

확인한 설정 모듈에는 Style·Mode·Variant 구조가 있으며 하나의 스타일에서 GTK, 아이콘, Cinnamon과 커서 테마를 조합할 수 있다. 사용자가 색상이나 밝고 어두운 모드를 선택하는 단순한 UI 뒤에 여러 테마 이름을 묶는 데이터가 존재하는 것이다. 개별 항목을 직접 선택하는 방식과 배포판이 준비한 스타일 조합을 선택하는 방식은 같은 결과를 다른 수준에서 구성한다.

설치된 테마를 찾을 때에는 사용자 홈의 전통적인 테마 디렉터리와 XDG 사용자 데이터 경로, 시스템 데이터 경로를 탐색한다. GTK 테마의 경우 해당 GTK 변형이 있는지 확인하고, Cinnamon 테마는 cinnamon 디렉터리를 기준으로 찾는다. 폴더 이름이 테마처럼 보여도 필요한 내부 구조가 없으면 올바른 선택 대상으로 인식되지 않을 수 있다.

일관된 화면을 만들려면 파일 관리자·설정 창·셸 팝업과 다른 툴킷 앱의 차이를 구별해야 한다. Cinnamon에서 테마를 바꾸었다고 독자적으로 렌더링하는 모든 응용 프로그램의 내부 화면까지 바뀌는 것은 아니다. 테마 설정의 범위와 응용 프로그램 자체의 색상·UI 설정을 분리하면 어떤 부분을 조정해야 하는지 명확해진다.

아이콘과 커서

아이콘 테마는 응용 프로그램, 폴더, 장치와 상태를 나타내는 자원을 제공한다. 메뉴와 파일 관리자, 패널의 여러 요소가 같은 아이콘 이름을 요청하더라도 표시 크기와 상태에 따라 다른 자원이 선택될 수 있다. 패널의 전체 색상 아이콘과 심벌 아이콘 크기를 별도로 설정하는 이유도 서로 다른 시각적 역할을 갖기 때문이다.^[77]

테마 검색은 사용자 경로와 시스템 경로를 함께 사용한다. Cinnamon의 테마 설정은 .icons, XDG 사용자 데이터의 icons 경로와 시스템 데이터 경로를 탐색하고, index.theme의 정보 등을 확인하여 선택 가능한 테마를 구성한다. 같은 이름의 테마가 여러 위치에 있을 수 있으므로 시스템 패키지의 테마와 사용자 설치본의 우선순위를 구별할 필요가 있다.^[78]

커서 테마는 일반 포인터뿐 아니라 텍스트 선택, 창 크기 조정, 작업 중 상태 등 서로 다른 입력 상태를 표현한다. 고밀도 모니터에서 커서가 지나치게 작거나 흐리게 보이면 이미지 배율과 사용 가능한 자원의 해상도를 함께 생각해야 한다. 커서가 앱 창 위와 셸 영역에서 다르게 보이는 경우에는 해당 프로그램의 툴킷·세션 경로도 관련될 수 있다.

아이콘 변경은 프로그램 자체를 교체하는 작업이 아니다. 같은 앱의 런처 아이콘과 실행 중인 창의 아이콘이 다르면 테마 자원의 유무뿐 아니라 앱 식별과 창 추적의 문제일 수도 있다. 그래픽 자원을 바꾸는 설정과 응용 프로그램이 자신을 어떤 이름으로 등록하는지는 별도의 정보다.

패널 구성

패널 구성에서는 먼저 어느 모니터의 어느 가장자리에 패널을 둘지, 그다음 어떤 애플릿을 어느 영역에 배치할지를 정한다. 하나의 패널에 메뉴·창 목록·상태를 모두 넣을 수도 있고, 프로그램 실행과 시스템 상태를 다른 패널에 나눌 수도 있다. 배치가 바뀌어도 개별 애플릿의 역할과 인스턴스 설정은 별도로 유지된다.

6.6 설정 모듈은 패널별 숨김 모드와 지연, 크기를 관리하며 영역별 글꼴·색상 아이콘·심벌 아이콘 설정을 JSON 구조로 다룬다. 가로 패널과 세로 패널에서 영역의 표시 이름과 크기 설명을 다르게 제공한다. 패널을 옆으로 옮기는 것은 단순히 전체 화면을 회전하는 일이 아니라 영역의 방향과 애플릿 표시 조건을 바꾸는 작업이다.^[79]

패널 높이를 늘렸는데 아이콘이 같은 크기라면 아이콘의 고정 크기 설정이 적용되었을 수 있다. 반대로 테마가 글꼴 크기를 정하도록 두면 패널 자체 크기와 텍스트 크기가 같은 비율로 변하지 않을 수 있다. 전체 컨테이너의 크기, 영역별 자원 크기와 테마의 여백을 각각 이해해야 원하는 배치를 만들 수 있다.

여러 패널에 같은 애플릿을 추가할 때에는 설치된 종류와 실행 중인 인스턴스 수를 구분해야 한다. 애플릿 파일은 하나여도 패널마다 다른 설정을 가진 인스턴스가 존재할 수 있고, 모든 애플릿이 무제한 다중 인스턴스를 지원하는 것은 아니다. 인스턴스 구분은 xlet 설정 API에서도 UUID와 인스턴스 식별자를 별도로 다루는 형태로 나타난다.^[80]

키보드 단축키

키보드 단축키는 응용 프로그램 실행, 창 전환, 작업 공간 이동과 화면 촬영 같은 데스크톱 동작에 키 조합을 연결한다. 사용자에게는 한 번의 키 입력이지만 내부에서는 창 관리자에 등록된 동작, 셸의 JavaScript 핸들러, 애플릿의 단축키 또는 외부 프로그램 실행으로 나뉠 수 있다. 예를 들어 내장 녹화기는 toggle-recording 동작에 처리 함수를 연결한다.^[81]

Alt-Tab 전환기는 표시 스타일뿐 아니라 목록의 범위와 등장 지연도 설정한다. 아이콘만, 미리 보기만, 아이콘과 창 미리 보기, Coverflow·Timeline 등의 스타일을 선택할 수 있으며 현재 모니터의 창만 포함하는 정책도 있다. 같은 키 조합을 사용해도 설정에 따라 전환 대상과 시각적 피드백이 달라진다.^[82]

Grouped Window List의 Super와 숫자 키 조합은 패널의 앱 순서와 연결된다. 이는 최근 사용 순서를 중심으로 전환하는 Alt-Tab과 다른 탐색 방식이며, 앱 순서를 잠시 보여 주는 단축키와 표시 시간 설정도 존재한다. 자주 사용하는 앱을 고정된 위치에 두는 구성에서는 패널 순서를 기억하여 실행·전환할 수 있다.^[83]

전역 단축키와 앱 내부 단축키, 입력기 전환 키는 서로 영향을 줄 수 있다. 키보드 배열이 바뀌거나 입력기가 조합 중이면 같은 물리 키가 다른 의미를 가질 수도 있다. Wayland 이식에서는 합성기가 입력을 중재하므로 기존 X11 프로그램의 전역 키 처리와 동일하게 가정하지 않고, Cinnamon이 제공하는 동작과 각 입력기 경로를 기준으로 설명해야 한다.

창 동작

창 동작 설정은 포커스, 새 창 배치, 제목 표시줄 조작과 창 전환을 다룬다. 포커스 모드에는 클릭으로 활성화하는 방식, 포인터가 들어오면 활성화하는 sloppy 방식, 포인터가 떠나면 초점을 해제하는 mouse 방식이 구분되어 있다. 포커스를 받는 것과 창을 다른 창 앞으로 올리는 것은 별도의 동작이므로 자동 올리기 설정도 따로 존재한다.^[84]

제목 표시줄에는 더블 클릭, 가운데 클릭과 오른쪽 클릭에 서로 다른 동작을 지정할 수 있다. 최대화, 수평·수직 최대화, 접기, 모든 작업 공간에 표시, 항상 위에 표시, 최소화와 메뉴 등이 구현에 나열된다. 스크롤로 접기를 전환하거나 투명도를 조절하는 선택도 있어, 제목 표시줄을 단순히 창을 끄는 손잡이로만 사용하지 않을 수 있다.

창 장식 버튼의 배열도 설정 대상으로 제공된다. 최소화·최대화·닫기 버튼의 좌우 배치를 바꾸거나 일부 버튼만 사용하는 구성이 가능하며, 오른쪽에서 왼쪽으로 쓰는 UI에서는 표시 방향을 고려한 선택지를 구성한다. 다만 클라이언트가 자신의 제목 표시줄을 그리는 창까지 모든 버튼이 동일하게 바뀐다고 일반화할 수는 없다.

새 창의 초기 포커스, 터미널에서 실행한 프로그램에 포커스를 줄지, 주의를 요청하는 창을 현재 작업 공간으로 가져올지, 모달 대화상자를 부모 창에 연결할지도 별도 정책이다. 이러한 설정은 사용자가 작업 중인 창을 방해하지 않는 것과 새 작업을 즉시 사용할 수 있게 하는 것 사이의 동작을 조정한다. 이름이 비슷한 항목이라도 창 생성·활성화·배치·쌓임 순서 가운데 무엇을 바꾸는지 구분하는 것이 중요하다.

배경 화면

배경 화면 설정은 그림 선택뿐 아니라 이미지의 비율과 화면 크기가 다를 때 어떻게 배치할지를 다룬다. 확인한 6.6 모듈에는 이미지 없음, 반복 배치, 가운데 배치, 비율을 유지한 크기 조절, 늘리기, 확대와 여러 화면에 걸친 표시가 구분되어 있다. 단색과 가로·세로 그라데이션도 별도 배경 표현으로 제공된다.^[85]

비율 유지 맞춤은 이미지 전체를 보이게 하는 대신 빈 영역을 남길 수 있고, 확대하여 화면을 채우는 방식은 일부를 잘라낼 수 있다. 늘리기는 화면을 채우지만 원래 비율을 바꿀 수 있다. 동일한 사진이 모니터마다 다르게 보이는 현상을 설명할 때는 이미지 파일뿐 아니라 선택한 배치 방식을 함께 확인해야 한다.

설정 모듈은 디렉터리와 XML 기반 이미지 모음을 구분하고 사용자 배경 모음의 정보를 설정 경로에 저장한다. 미리 보기 생성에는 이미지의 EXIF 방향 정보도 고려된다. 사진 파일을 파일 관리자에서 열었을 때와 배경 선택 화면에서 볼 때 방향이 일치하려면 이러한 메타데이터 처리가 필요하다.

6.7.7의 모니터별 배경 화면과 새 배경 데몬은 앞의 여러 화면에 걸친 표시와 같은 기능이 아니다. 하나의 이미지를 논리적 전체 화면에 펼치는 것과 각 모니터에 다른 이미지를 지정하는 것은 데이터 모델과 갱신 경로가 다르다. 문서에서 모니터별 배경을 설명할 때에는 개발 계열의 해당 변경과 기존 안정 계열의 배치 옵션을 구분해야 한다.^[86]

글꼴과 화면 표시

글꼴 설정은 본문과 인터페이스의 문자 모양·크기를 다루지만, 화면 전체 배율과는 별도 계층이다. 텍스트만 키우면 아이콘과 버튼의 기본 크기는 유지될 수 있고, 전체 UI 배율을 높이면 창과 패널이 차지하는 논리적 작업 영역도 달라진다. 글자가 작다는 문제를 해결할 때 어떤 요소를 확대하려는지 구분해야 한다.

패널에서는 영역별 글꼴 크기를 직접 정하거나 테마가 결정하도록 할 수 있다. 글꼴 크기가 같아도 패널 높이, 줄 높이와 여백에 따라 시계나 창 제목의 실제 배치가 달라진다. 창 목록의 버튼 텍스트를 앱 이름으로 할지 창 제목으로 할지에 따라서도 필요한 폭이 달라진다.^[87][88]

다국어에서는 글꼴에 없는 문자의 대체 표시와 조합 문자, 문자별 실제 폭이 레이아웃에 영향을 준다. Cinnamon 개발 기록에는 문자 메트릭 때문에 전환기 배치가 어긋나는 문제와 배율 관련 수정이 포함되어 있다. 셸 UI가 영문 이름으로 정상 표시된다는 것만으로 긴 프로그램 이름과 여러 문자 체계에서도 같은 폭과 높이를 유지한다고 볼 수 없다.^[89]

HiDPI에서는 글꼴 외에도 이미지와 아이콘을 적절한 해상도로 준비해야 한다. 논리적 크기와 실제 렌더링 자원의 배율을 구분하지 않으면 텍스트만 선명하거나 일부 아이콘만 흐린 화면이 만들어질 수 있다. Cinnamon의 화면 표시를 설명할 때 글꼴 설정, 테마 자원과 합성기의 배율 처리를 함께 다루어야 하는 이유다.

사운드와 알림

사운드 애플릿은 사용자가 패널에서 음량과 장치 상태, 미디어 재생 정보를 다루도록 한다. 실제 오디오 스트림의 혼합과 장치 제어는 하부 오디오 서비스의 역할이며, 패널에 같은 볼륨 UI가 보이더라도 배포판에 따라 PulseAudio 또는 호환 인터페이스를 제공하는 PipeWire 구성이 사용될 수 있다. Cinnamon의 UI와 오디오 서버의 구현은 구분되는 계층이다.

출력 장치의 시스템 음량, 개별 응용 프로그램의 음량, 마이크 입력과 재생기의 자체 음량은 같은 값이 아니다. 소리가 작거나 녹음 입력이 들리지 않는 경우에는 어느 단계의 값이 낮아졌는지를 구분해야 한다. 알림 효과음도 음악 스트림이나 마이크 입력과 다른 경로를 사용할 수 있으며, 화면 알림을 끄는 것과 오디오 전체를 음소거하는 것은 다른 설정이다.

Cinnamon 개발 기록에는 과증폭 허용을 끌 때 100%보다 높았던 음량을 조정하는 처리와 사운드 애플릿의 상태 관리가 나타난다. 사용자 설정의 허용 범위가 바뀌었을 때 현재 서비스에 적용된 값도 함께 바꾸어야 한다는 예다. 100%라는 UI 표시는 물리적인 장치 출력의 모든 특성을 나타내는 절대적인 음량 기준은 아니다.^[90]

미디어 재생 정보는 플레이어가 제공하는 제어 인터페이스와 연결된다. 모든 프로그램이 같은 수준의 곡 정보나 재생 제어를 제공하지는 않으므로, 패널에서 재생 상태가 보이지 않는 상황을 곧바로 오디오 출력 실패로 볼 수 없다. 소리의 전달과 플레이어 상태 정보의 전달은 별개의 기능이다.

개인정보와 세션 설정

Cinnamon의 개인정보 모듈은 최근 접근 파일의 기록 여부와 보관 기간을 구체적으로 다룬다. org.cinnamon.desktop.privacy의 remember-recent-files와 recent-files-max-age를 사용하며, 기록을 활성화했을 때 기간 설정을 보여 준다. 확인한 구현은 1일부터 365일까지의 입력과 무기한 보관을 구분하고, 무기한 상태에는 별도 값을 사용한다.^[91]

최근 파일 기록을 사용하지 않는 것과 실제 파일을 삭제하는 것은 다르다. 이 설정은 데스크톱이나 관련 앱이 최근 항목을 제공하는 동작과 연결되며, 문서 자체와 프로그램 내부의 별도 기록까지 모두 제거한다고 볼 수 없다. 브라우저 방문 기록이나 편집기의 자체 작업 목록처럼 앱이 독립적으로 관리하는 데이터는 해당 앱의 정책에 따른다.

개인정보 화면은 NetworkManager가 지원할 때 인터넷 연결 검사도 제어한다. 이 기능은 네트워크가 외부 인터넷에 도달할 수 있는지 확인하여 캡티브 포털을 찾는 데 도움을 주지만 주기적인 네트워크 통신을 발생시킨다. 모듈은 GSettings 키만 바꾸는 대신 libnm로 실제 연결 검사 상태를 조회하고 변경한다. 사용자가 보는 한 설정 화면 안에서도 적용 대상이 서로 다름을 보여 준다.

세션 설정과 자동 시작은 로그인할 때 어떤 프로그램을 구동할지를 다룬다. 자동 시작을 끄는 것은 프로그램의 설치 제거와 다르고, 현재 실행 중인 앱을 반드시 즉시 종료하는 것도 아니다. 개인 자동 시작 항목과 Cinnamon의 필수 세션 구성 요소를 구분하면 불필요한 앱 실행을 줄이면서도 셸·파일 관리자와 필요한 서비스는 유지할 수 있다.^[92]

Cinnamon Spices는 데스크톱을 확장하는 요소를 배포·설치·갱신하는 생태계다. Applet·Desklet·Extension·Theme·Action은 같은 웹사이트에서 제공되지만 실행 위치와 적용 방식이 다르다. 특히 JavaScript로 셸 안에서 동작하는 확장과 Nemo가 외부 명령을 실행하는 Action, 스타일 자원을 제공하는 Theme을 모두 같은 종류의 플러그인으로 취급하면 설정·호환성·실행 권한의 차이를 놓치게 된다.^[93]

Applet

Applet은 패널의 일정한 영역에 배치되는 기능 요소다. 기본 메뉴, 창 목록과 시계처럼 데스크톱의 핵심 조작을 담당할 수도 있고, 날씨나 시스템 정보처럼 추가 상태를 표시할 수도 있다. 패널은 애플릿의 위치와 크기를 관리하고, 애플릿은 해당 공간에서 자신이 필요한 UI와 입력 처리를 구성한다. 따라서 패널을 새로 만드는 것과 애플릿을 새로 설치하는 것은 다른 작업이다.

설치된 애플릿 종류와 패널에 추가한 인스턴스도 구분된다. 코드와 메타데이터는 UUID로 식별되지만 같은 애플릿을 여러 패널에 배치하면 각 인스턴스가 다른 설정을 가질 수 있다. Cinnamon의 설정 API는 UUID와 인스턴스 식별자를 함께 다루며, 다중 인스턴스를 지원하지 않는 xlet에는 다른 식별 방식을 적용한다.^[94]

애플릿의 설정 화면은 settings-schema.json 같은 정의를 바탕으로 구성할 수 있다. Grouped Window List의 실제 정의에는 페이지·섹션 구성, 체크 상자, 선택 상자, 단축키와 수치 입력 등이 들어 있다. 기본값과 설명, 선택 가능한 값 및 설정 간 의존성을 선언하여 UI와 실행 코드의 설정을 연결한다.^[95]

동작 중에는 패널 방향·크기와 모니터 상태가 달라질 수 있고, 사용자가 애플릿을 제거하거나 비활성화할 수도 있다. 타이머·네트워크 요청·시그널을 사용하는 애플릿은 이러한 수명 주기에 맞추어 정리해야 한다. 패널에 작은 아이콘 하나만 보이더라도 내부에서는 장기 실행 코드가 동작할 수 있으므로 시각적 크기와 시스템 자원 사용량이 비례한다고 볼 수 없다.

Desklet

Desklet은 패널이 아니라 바탕 화면의 위치를 사용해 정보를 보여 주는 위젯이다. 시계, 달력, 메모와 시스템 상태처럼 사용자가 자주 확인할 내용을 창을 새로 열지 않고 볼 수 있도록 한다. 패널에 고정된 애플릿과 달리 데스크톱의 특정 위치에 놓이며, 일반 창이 위를 가리면 보이지 않을 수 있다는 점이 사용 방식의 차이다.

Desklet도 코드와 설정을 가진 xlet이며 UUID와 인스턴스를 구분한다. 같은 정보 위젯을 여러 개 놓더라도 표시할 위치나 데이터 공급자, 갱신 주기 등을 다르게 설정할 수 있다. Cinnamon의 xlet 설정 API는 AppletSettings뿐 아니라 DeskletSettings를 위한 공통 기반을 제공하여 설정 값을 객체 속성에 연결하고 변경을 알린다.^[96]

화면의 배율이나 모니터 배치가 바뀌면 Desklet의 위치와 크기도 의미가 달라질 수 있다. 패널 애플릿은 컨테이너의 영역에 맞추어 배치되지만, 데스크톱 위젯은 사용자가 지정한 좌표와 실제 화면의 사용 가능한 공간을 고려해야 한다. 창을 정리해 바탕 화면을 드러내는 작업과 결합하면 지속적인 정보판처럼 사용할 수 있다.

외부 정보를 표시하는 Desklet에는 데이터의 갱신과 오류 상태도 필요하다. 네트워크가 끊겼을 때 이전 값인지 새 값인지 구별하고, 위젯이 제거되면 반복 작업도 중단하는 것이 구현의 일부다. Cinnamon이 Desklet을 설치할 수 있는 체계를 제공한다는 것과 특정 외부 서비스가 계속 데이터를 제공한다는 것은 별개의 조건이다.

Extension

Extension은 패널이나 바탕 화면에 독립된 표시 요소를 추가하는 것보다 셸의 기존 동작을 바꾸는 데 초점을 둔다. 창 전환 효과, 작업 공간 조작이나 UI 처리 흐름처럼 Cinnamon이 이미 제공하는 기능을 확장할 수 있다. 이 때문에 애플릿보다 화면에서 차지하는 영역이 작거나 아예 독립된 영역이 없더라도 셸 전체의 동작에 관여할 수 있다.

공식 Extensions 저장소는 각 확장을 UUID 디렉터리 아래 관리한다. 루트에는 작성자 등 웹사이트용 정보인 info.json, 설명과 스크린샷을 두고, 실제 설치될 내용은 UUID/files/UUID/ 아래의 metadata.json, extension.js와 자원 파일로 나눈다. 웹사이트에서 보여 주는 정보와 Cinnamon이 실행하는 설치 파일을 구별하는 구조다.^[97]

설치·활성화·실행은 서로 다른 상태다. 확장 파일이 사용자 환경에 존재해도 활성화되지 않으면 기능이 적용되지 않을 수 있고, 지원 버전과 맞지 않거나 실행 중 오류가 생기면 정상 동작하지 않을 수 있다. 확장이 셸 객체나 함수의 동작을 바꾸었다면 비활성화할 때 그 변경을 되돌리고 이벤트 연결을 정리해야 한다.

API 호환성은 특히 중요하다. GNOME Shell과 Cinnamon이 역사적 기반을 공유해도 셸 내부 객체와 모듈은 독립적으로 발전했으므로 확장을 그대로 교환할 수 있다고 가정할 수 없다. Cinnamon 내부에서도 릴리스 간 API나 런타임 변화가 있을 수 있어, 지원 버전과 실제 테스트 결과를 함께 확인하는 방식으로 유지된다.

Theme

Spices의 Theme은 Cinnamon 셸의 시각적 자원을 배포하는 유형이다. 패널, 메뉴, 알림과 각종 셸 요소의 색상·여백·테두리·이미지 등을 정의하며, JavaScript 동작을 추가하는 Extension과 목적이 다르다. 테마 설치가 앱 실행이나 파일 관리 기능 자체를 바꾸는 작업은 아니다.

Cinnamon의 테마 설정은 테마 이름만 읽는 것이 아니라 설치 경로에서 필요한 구조를 찾는다. 셸 테마는 cinnamon 디렉터리의 존재를 기준으로 탐색되고 GTK 테마는 별도의 GTK 변형을 확인한다. Spices에서 셸 테마를 설치했다고 같은 이름의 GTK·아이콘·커서 테마가 모두 함께 설치된다고 추정해서는 안 된다.^[98]

시각 자원도 셸 버전의 영향을 받는다. 새 UI 요소가 추가되거나 위젯의 스타일 이름과 배치가 바뀌면 기존 테마에서 해당 부분의 대비·여백·아이콘 크기가 맞지 않을 수 있다. 따라서 Theme이 실행 코드를 추가하지 않는다는 이유만으로 모든 Cinnamon 버전과 자동 호환된다고 볼 수는 없다.

테마를 평가할 때에는 전체 화면 인상뿐 아니라 선택된 항목과 비활성 항목의 구별, 알림 텍스트 대비, 긴 프로그램 이름과 확대된 글꼴의 배치를 함께 본다. HiDPI에서는 이미지 자원이 확대될 때의 선명도도 중요하다. 배포판의 스타일 조합은 이러한 자원을 한 번에 선택하는 편의를 제공하지만, 각 테마의 실제 구성과 적용 범위는 독립적으로 남아 있다.

Action

Action은 Nemo의 파일·폴더 문맥 메뉴에 작업을 추가하는 선언형 구성이다. .nemo_action 파일은 표시 이름, 실행 명령, 선택 조건과 파일 형식 조건 등을 정의한다. 공식 예제에서는 Name, Exec, Selection이 핵심 항목이며 파일 형식은 Extensions 또는 Mimetypes로 제한할 수 있다. 같은 메뉴라도 파일 하나, 여러 파일, 선택 없음 등 조건에 따라 나타나는 작업을 다르게 만들 수 있다.^[99]

선택한 파일을 명령에 전달하는 토큰은 의미가 다르다. %F는 선택 항목의 경로 목록, %U는 URI 목록, %P는 현재 부모 디렉터리의 경로를 나타낸다. %f와 이전 표기 %N은 첫 파일의 표시 이름을 가리키므로 전체 경로와 혼동하면 안 된다. 로컬 파일의 표시 이름만 받아 동작하는 명령과 SFTP 같은 원격 URI를 처리할 수 있는 프로그램은 요구하는 입력이 다르다.

표시 조건도 확장자가 전부가 아니다. Dependencies로 필요한 실행 파일이나 경로의 존재를 검사하고, Conditions로 데스크톱 위치·이동식 장치·GSettings 값·D-Bus 이름 또는 명령 결과를 확인할 수 있다. UriScheme은 현재 위치의 프로토콜을 제한하며 Locations와 Files는 경로나 이름 패턴을 검사한다. 메뉴 항목이 보이지 않는 현상은 파일 설치 실패뿐 아니라 이 조건 중 하나를 충족하지 못한 결과일 수 있다.

외부 명령은 실제 파일을 변경할 수 있으므로 입력 전달 방식이 중요하다. 공식 예제는 구분자와 인용 방식, 터미널 실행을 구분하며 예전 EscapeSpaces 필드는 더 이상 동작하지 않는다고 설명한다. Action 작성자는 파일명에 공백과 특수 문자가 있는 경우, 복수 선택과 원격 위치에서 명령이 받는 인자를 확인해야 한다. 셸 확장과 달리 Action의 기능은 호출하는 외부 프로그램의 지원 범위에도 직접 의존한다.

다운로드와 업데이트

Spices는 공식 웹사이트에서 내려받거나 Cinnamon 설정의 설치 화면에서 관리할 수 있다. 공식 저장소의 files 디렉터리는 사용자에게 전달되는 ZIP 아카이브의 내용에 해당하며, 그 안에 다시 UUID 디렉터리를 두어 수동 압축 해제에서도 확장의 파일이 적절한 하위 경로에 놓이도록 한다. 저장소의 설명·스크린샷과 실제 설치 파일을 구분하는 이유다.^[100]

갱신은 작성자의 저장소 변경이 검토되어 배포 자료에 반영되고, 사용자 설정 화면에 업데이트로 나타나는 흐름을 갖는다. Cinnamon 본체의 패키지 업데이트와 Spices 업데이트는 별개이며, 확장마다 작성자와 유지보수 주기도 다르다. 셸을 새 버전으로 올렸다고 외부 확장이 그 버전을 지원하도록 자동 수정되는 것은 아니다.

설치된 코드, 활성화된 인스턴스와 사용자 설정도 따로 관리된다. 확장 파일을 갱신하면서 사용자 설정을 유지해야 하므로 메타데이터와 스키마의 변화가 중요하다. 동일한 UUID 아래 여러 인스턴스가 있는 경우에는 코드 한 벌이 갱신되어도 각 인스턴스의 설정은 별도로 적용될 수 있다.^[101]

다운로드 과정에도 예외 처리가 존재한다. Cinnamon 6.6.9 기록에는 Content-Length 헤더가 없는 다운로드에 대한 처리가 포함된다. 서버 응답이나 네트워크 상태가 다르더라도 설치 관리가 적절하게 진행되도록 하는 것으로, 업데이트 화면의 문제와 확장 코드 자체의 문제를 구분해야 한다는 예다.^[102]

호환성과 보안

Cinnamon Spices는 사용자 세션과 가까운 위치에서 동작한다. Applet·Desklet·Extension은 셸 내부 API를 호출할 수 있고 Action은 외부 프로그램에 파일을 전달한다. 이를 웹사이트에서 내려받는 이미지와 같은 수동적인 자료로만 취급할 수 없으며, 기능의 편의성과 함께 어떤 코드가 어떤 권한으로 실행되는지를 구분해야 한다.

공식 Extensions 저장소의 규칙은 신규 제출과 업데이트를 검토하고, Spices 외부에서 추가 코드를 내려받아 실행하거나 기능의 일부를 외부판으로 유도하는 방식을 허용하지 않는다고 설명한다. 사전 컴파일된 코드나 비공개 코드, 설정을 다루는 방법에도 제한을 두며, 설치된 버전이 검토된 전체 기능을 포함해야 한다는 원칙을 사용한다. 이는 해당 저장소의 배포 정책이며 모든 임의의 외부 확장에 같은 검토가 적용된다는 뜻은 아니다.^[103]

시스템 의존성은 별도로 다룬다. 공식 규칙은 배포판 저장소의 프로그램을 패키지 관리자를 통해 설치하도록 안내하는 경우와, 임의 웹사이트에서 코드를 내려받는 경우를 구분한다. 외부 명령이 필요한 확장이라도 의존성을 어떤 경로로 해결하는지에 따라 검토 가능한 범위가 달라진다.

호환성 측면에서는 셸 API, CJS 실행 환경, 그래픽 세션과 파일 관리자 버전을 함께 본다. 확장 자체의 오류뿐 아니라 제거되지 않은 타이머·시그널, 오래 걸리는 작업과 버전별 객체 변경이 셸 안정성에 영향을 줄 수 있다. 공식 구조 검증은 패키지 형식을 확인하는 데 도움이 되지만 기능의 정확성이나 모든 환경의 호환성을 자동으로 증명하는 절차는 아니다.

Nemo는 파일의 탐색과 조작, 데스크톱 아이콘, 원격 위치와 이동식 볼륨을 연결한다. 셸이 창과 프로그램을 관리하는 공통 환경이라면 파일 관리자는 파일 형식과 경로, 연결 프로그램과 저장장치의 상태를 다루는 작업 도구다. Cinnamon의 메뉴·패널과 같은 화면에 통합되어도 실제 파일 작업의 구현과 권한은 별도 계층에 있다.

Nemo

사용자 관점에서 Nemo는 경로를 이동하고 파일을 선택하며 여러 위치 사이에서 작업하는 파일 관리자다. 탭과 추가 탐색 영역을 이용하면 원본과 대상 위치를 함께 열고 복사·이동을 수행할 수 있다. 사이드바의 책갈피와 볼륨, 경로 표시와 파일 목록은 서로 다른 탐색 수단을 제공하며 파일을 여는 기본 응용 프로그램과도 연결된다.^[104]

6.6의 변경 기록에는 추가 탐색 영역의 위치 기억과 전환 버튼, 비활성 영역의 클릭 처리 개선이 들어 있다. 이는 두 위치를 함께 보여 주는 기능이 단순히 창을 둘로 나누는 것만이 아니라 어느 영역이 현재 선택과 명령의 대상인지 관리하는 일임을 보여 준다. 파일 선택이 있는 영역과 사용자가 클릭한 영역이 다를 때 작업 대상을 명확하게 유지해야 한다.^[105]

검색에서는 파일명 일치와 파일 내용 검색을 구분한다. 6.6 기록에는 정규식 파일명 검색, 일반 파일명 검색의 여러 조건을 AND로 결합하는 동작 복원, MIME 형식과 검색 도우미 처리 개선이 나타난다. 파일 이름을 찾는 기능과 문서 내부 내용을 읽는 기능은 비용과 지원 형식이 다르며, 후자는 관련 도우미와 파일 형식 처리기의 영향을 받는다.

템플릿은 빈 파일 하나를 만드는 기능보다 넓은 새 문서 생성 경로다. 지정된 템플릿을 바탕으로 새 파일을 만들 수 있으며, 6.6에서는 문서 템플릿을 별도 설정 탭으로 옮기고 편집 기능을 개선한 기록이 있다. 파일 관리자 안의 검색·템플릿·Action은 서로 다른 작업 확장 경로이므로 하나의 플러그인 기능으로 합쳐 설명하지 않는다.

데스크톱 아이콘

데스크톱 아이콘은 바탕 화면에서 파일과 폴더, 홈·휴지통·장치 같은 위치에 직접 접근하는 기능이다. Cinnamon 구성에서는 Nemo가 이 역할을 담당할 수 있으며, 패널의 실행 아이콘과는 구별된다. 바탕 화면에서 파일을 이동하거나 문맥 메뉴를 여는 동작은 파일 관리자와 연결되고, 앱 실행기의 고정 순서를 바꾸는 동작은 패널과 연결된다.

Nemo의 일반 탐색 창을 닫는 것과 데스크톱 담당 기능을 종료하는 것은 동일하지 않다. 사용자는 파일 관리자 창을 열지 않은 상태에서도 데스크톱 아이콘을 사용할 수 있어야 하며, 세션에는 이를 시작하는 구성 요소가 필요하다. Cinnamon 6.6의 세션 정의에 nemo-autostart가 포함되는 것은 이러한 통합 구조의 일부다.^[106]

데스크톱 배경을 그리는 기능과 파일 아이콘·문맥 메뉴를 제공하는 기능도 다르다. 배경 화면이 보인다고 Nemo의 데스크톱 기능이 정상 실행된다고 단정할 수 없으며, 아이콘 표시를 비활성화하더라도 배경 자체는 유지될 수 있다. Nemo의 6.6 변경 기록에는 데스크톱용 창에서 Action 갱신과 시작 시 메뉴가 존재하도록 하는 처리도 들어 있다.^[107]

파일 아이콘의 실제 위치는 저장소 안의 데이터와 연결된다. 데스크톱 아이콘을 삭제하는 작업과 바로가기 표시만 제거하는 작업의 결과는 대상의 종류에 따라 다르다. 사용자가 어떤 객체를 조작하는지 구별할 수 있도록 파일 이름, 종류와 메뉴 동작이 일관되게 제공되어야 한다.

파일 작업

Nemo의 파일 작업에는 복사, 이동, 이름 변경, 휴지통으로 보내기, 삭제와 속성 확인이 포함된다. 사용자가 같은 드래그 동작을 하더라도 원본과 대상이 같은 파일 시스템인지, 다른 볼륨인지, 원격 위치인지에 따라 실제 처리 방식과 소요 작업이 달라질 수 있다. 화면의 파일 목록과 실제 저장장치의 변경은 연결되어 있지만 같은 순간에 모든 작업이 완료되는 것은 아니다.

6.6.0에서는 파일 작업 일시 중지·재개가 구현되었고 이후 진행률 처리 수정도 이루어졌다. 일시 중지는 작업을 잠시 멈춘 뒤 이어 가는 기능이며 취소와 다르다. 취소하더라도 이미 복사된 파일이나 완료된 일부 작업까지 자동으로 원래 상태로 되돌린다고 일반화할 수는 없다. 진행 상황과 현재 작업 상태를 구별해서 표시하는 이유다.^[108]

접근 권한은 파일 관리자의 버튼이 아니라 파일 시스템과 하부 서비스가 결정한다. 읽기 전용 볼륨에 쓰려는 경우, 다른 사용자가 소유한 경로를 변경하려는 경우와 원격 서버가 작업을 거부하는 경우는 서로 다른 오류다. Nemo가 파일을 보여 준다는 사실만으로 그 위치에 대한 쓰기나 삭제 권한까지 있다는 뜻은 아니다.

미리 보기와 썸네일 생성도 파일 작업과 구별한다. 파일을 선택했을 때 내용을 미리 읽거나 썸네일을 만드는 동작은 저장장치 접근을 발생시키지만 원본을 다른 위치로 복사하는 것은 아니다. 6.6 기록에는 백엔드가 제공한 미리 보기의 처리 개선도 있어, 화면에 보이는 파일 표현이 로컬 파일 형식 처리뿐 아니라 저장소 백엔드가 제공하는 정보에 의존할 수 있음을 보여 준다.

Nemo Extension

Nemo Extension은 파일 관리자의 메뉴와 정보 표시, 작업 기능을 확장하는 인터페이스다. 파일 관리자가 선택한 항목과 현재 위치를 확장에 전달하고, 확장은 그 문맥에 맞는 기능을 제공한다. Cinnamon의 셸 Extension과는 적용 대상과 API가 다르므로 같은 이름의 Extension이라는 이유로 설치 방법이나 지원 버전을 공유한다고 볼 수 없다.^[109]

Nemo의 플러그인, 스크립트, Action과 문서 템플릿은 서로 다른 방식으로 기능을 추가한다. 플러그인은 파일 관리자 인터페이스와 연결되고, Action은 메뉴에 표시할 조건과 명령을 선언하며, 템플릿은 새 파일의 초기 내용을 제공한다. 사용자가 보기에는 모두 문맥 메뉴와 설정 화면에 나타날 수 있지만 작성 방식과 수명 주기, 필요한 의존성이 다르다.

6.6 변경 기록에는 플러그인 설정에서 스크립트 위젯을 제거하고 템플릿을 다루는 UI를 조정한 내용이 있다. Action 레이아웃 편집기도 설정 화면에서 별도로 접근하며 활성화와 순서 편집을 개선했다. 이는 파일 관리자 확장을 관리하는 UI가 계속 정리되고 있다는 의미이며, 예전 설정 화면의 분류를 모든 버전에 그대로 적용해서는 안 된다.^[110]

동작하지 않는 확장을 분석할 때는 코드가 설치되었는지, Nemo의 해당 버전과 호환되는지, 필요한 외부 프로그램이 있는지와 선택 조건이 맞는지를 나누어 확인한다. Action은 정상 설치되어도 조건에 따라 메뉴에서 숨겨질 수 있고, 네이티브 플러그인은 라이브러리 호환성과 로드 상태가 문제가 될 수 있다. 같은 증상이라도 확장 유형에 따라 원인이 다르다.

네트워크와 원격 위치

Nemo는 GIO·GVfs 계열의 파일 접근 기반을 이용하여 로컬 디렉터리 외에 네트워크 위치를 탐색할 수 있다. SMB 공유와 SFTP 등은 필요한 백엔드와 인증 환경이 갖추어졌을 때 파일 관리자의 위치로 다루어진다. 사용자는 로컬 폴더와 유사한 목록을 보지만 실제 파일 읽기·쓰기 요청은 네트워크와 원격 서버를 거친다.^[111]

원격 URI와 로컬 경로는 같은 문자열이 아니다. Action 예제에서 %U와 %F를 구분하고 UriScheme 조건을 제공하는 이유도 외부 명령이 모든 위치를 같은 방식으로 다룰 수 없기 때문이다. URI를 지원하지 않는 프로그램에 원격 위치의 표시 이름만 전달하면 파일을 찾을 수 없을 수 있다. 원격 자료를 처리하는 기능은 파일 관리자의 접근 지원과 호출된 프로그램의 지원을 함께 고려해야 한다.^[112]

인증 실패, 서버 부재와 응답 지연도 서로 다른 상태다. 파일 목록을 요청하는 동안 네트워크가 응답하지 않더라도 UI가 계속 조작 가능해야 하며, 실패 상태를 사용자가 취소하거나 다른 위치로 이동할 수 있어야 한다. Nemo 6.4 변경 기록에는 접근할 수 없는 호스트의 네트워크 위치를 열거나 나열할 때 차단되는 현상에 대한 수정이 포함된다.^[113]

원격 파일 시스템은 권한, 이름 비교, 삭제와 휴지통, 썸네일·메타데이터 제공에서 로컬 파일 시스템과 차이가 날 수 있다. Nemo에서 같은 메뉴가 보인다는 이유로 모든 작업이 같은 원자성이나 복구 가능성을 갖는 것은 아니다. 네트워크 통합은 공통 탐색 UI를 제공하지만 하부 저장소의 성질까지 모두 동일하게 만드는 계층은 아니다.

이동식 장치

이동식 장치를 연결하면 시스템의 장치·볼륨 서비스가 이를 감지하고 사용자가 접근할 수 있는 위치로 제공한다. Nemo는 볼륨과 마운트 상태를 사이드바나 데스크톱 항목에 표시한다. 물리 장치, 파티션·볼륨과 현재 마운트된 파일 시스템은 구분되는 대상이며, 한 장치에 여러 볼륨이 있을 수도 있다.

꺼내기와 마운트 해제도 장치에 따라 의미가 다르다. 마운트 해제는 파일 시스템의 접근을 정리하는 작업이고, 장치가 제공하는 꺼내기 동작은 추가적인 하드웨어 상태 변경을 포함할 수 있다. Nemo의 변경 기록에는 사이드바에서 가려진 마운트나 볼륨이 없는 마운트를 표시하는 조건과 꺼내기 아이콘의 동작을 조정한 내용이 있다.^[114]

파일 작업이 진행 중이거나 다른 프로그램이 장치를 사용 중이면 분리 요청이 바로 완료되지 않을 수 있다. 쓰기 작업의 진행 표시와 실제 장치를 제거할 수 있는 상태를 구분해야 하며, 파일 관리자에는 실패 또는 사용 중 상태를 사용자에게 알려 줄 필요가 있다. 단순히 파일 목록 창을 닫는 것은 해당 장치를 사용하는 모든 프로그램을 종료하는 동작이 아니다.

자동 마운트와 연결 시 실행할 동작은 배포판의 정책·사용자 세션 설정과 함께 작동한다. Nemo Action도 선택 항목이 이동식 장치인지 검사하는 조건을 사용할 수 있으므로 장치에만 적용할 메뉴 작업을 구성할 수 있다. 데스크톱의 편의 기능과 장치 접근 권한은 별도로 관리된다.^[115]

Cinnamon은 그래픽 클라이언트, 창 관리·합성, 입력과 출력 장치의 연결 위에서 동작한다. X11과 Wayland는 동일한 모양의 셸을 제공할 수 있어도 창과 입력을 관리하는 구조가 다르다. 화면 촬영·녹화·공유, 잠금, 배율과 외부 도구 호환성을 설명할 때에는 어떤 세션과 어떤 구현을 다루는지 명시해야 한다.

X11 세션

X11 세션에서는 X 서버가 클라이언트의 그래픽 자원과 입력·출력 통신을 제공하고, 창 관리자는 창 배치와 포커스 정책을 담당한다. Cinnamon은 Muffin 기반의 창 관리·합성 기능과 셸 UI를 결합하여 이 환경에서 실행한다. 오랫동안 발전해 온 창 식별·화면 촬영과 여러 외부 도구의 동작은 이 구조를 전제로 한다.

일반 응용 프로그램과 데스크톱 셸은 X 서버에 연결된 서로 다른 역할의 클라이언트가 될 수 있다. 창 관리자와 합성 기능을 다시 시작하는 것과 X 서버 자체를 종료하는 것은 결과가 다르다. 다만 셸 재시작이 모든 작업에 영향을 주지 않는다고 일반화할 수는 없으며, 사용 중인 확장과 세션 구성에 따라 상태를 다시 연결하는 과정이 필요하다.

Cinnamon 개발 코드에는 X11 세션에서 셸 재시작 뒤 잠금 상태를 복원하는 처리가 나타난다. 반면 Wayland에서는 같은 재시작 방식을 지원하는 것으로 취급하지 않는다. 이는 X11에서 서버와 창 관리자·셸의 역할이 분리되는 점이 실제 세션 동작에 영향을 준다는 구체적인 예다.^[116]

6.6 빌드 정의에는 X11과 GDK X11 관련 의존성이 명시되어 있고, 기존 녹화기와 세션 정의도 해당 계열의 실행 구조와 연결된다. 코드에 Wayland 옵션이 존재한다는 이유로 모든 X11 의존성이 제거되었다고 볼 수는 없다. 배포판이 어떤 옵션으로 빌드했는지와 실제 로그인한 세션을 함께 확인해야 한다.^[117]

Wayland 세션

Wayland에서는 클라이언트가 그린 표면의 버퍼를 합성기에 전달하고, 합성기가 창 배치와 출력, 입력 전달을 중재한다. 따라서 디스플레이 서버와 창 관리의 경계가 X11과 다르며, Cinnamon의 셸과 Muffin 계층은 화면의 여러 역할을 더 직접적으로 연결한다. XWayland를 사용하는 X11 애플리케이션은 이 환경 안의 호환 경로로 실행될 수 있지만, 이것이 전체 세션을 X11로 바꾸는 것은 아니다.

다른 앱의 창 내용을 읽거나 전역 입력을 관찰하는 기능은 X11에서 사용하던 방법과 다르게 구현해야 한다. 화면 공유·원격 제어·단축키·입력기·잠금 등의 기능은 합성기와 관련 인터페이스의 지원을 확인해야 한다. 특정 프로그램이 Wayland에서 창을 띄울 수 있다는 사실과 Cinnamon 세션의 모든 데스크톱 통합 기능을 사용할 수 있다는 사실은 별개다.

Cinnamon 6.7 개발 계열은 입력 소스와 fcitx5, 화면 키보드, 확대기, 스크린샷과 HiDPI 자원 배율을 계속 수정했다. 또한 Wayland에서 내부 화면 차폐를 사용하고 외부 잠금 명령을 무시하는 경로를 갖는다. 이러한 변화는 단일한 지원 체크 상자보다 기능별 실행 경로와 제약을 통해 설명하는 것이 정확하다.^[118][119]

세션 선택 목록에 나타나는 이름과 실제 제공 기능도 구별해야 한다. 6.7.3의 experimental 표기 제거는 이름의 변경 기록이며, 동시에 진행 중인 다른 기능의 완성 여부를 대신하지 않는다. 배포판은 개발 코드를 언제 채택하고 어떤 기능을 노출할지 별도로 정하므로, 설치된 Cinnamon·Muffin·세션 패키지를 기준으로 상태를 설명해야 한다.

창 관리와 합성

창 관리는 창의 논리적 상태를 결정한다. 위치와 크기, 활성화, 작업 공간 소속, 최대화와 최소화가 여기에 속한다. 합성은 각 창과 셸 요소의 그래픽 버퍼를 최종 화면으로 결합한다. 두 기능은 연결되어 있지만 창이 올바른 작업 공간에 배치되는 문제와 화면이 부드럽게 갱신되는 문제는 다른 원인을 가질 수 있다.

Cinnamon의 빌드 정의는 Muffin의 창 관리 라이브러리와 Clutter·Cogl·Pango 관련 그래픽 구성 요소를 이용한다. 셸 UI는 장면 그래프의 객체로 배치되고, 창 미리 보기와 애니메이션도 같은 화면에 결합된다. GTK로 작성된 설정 창이 보이는 것과 셸 내부의 St 위젯이 그려지는 것은 이러한 그래픽 계층에서 역할이 다르다.^[120]

전체 화면 창을 처리할 때에는 불필요한 합성 단계를 줄이는 방식과 다른 셸 요소를 계속 표시해야 하는 상황을 구분한다. 예를 들어 녹화 중에는 화면 내용을 안정적으로 읽기 위해 평상시의 최적화 경로를 바꾸어야 할 수 있다. 6.6 녹화기 구현은 녹화 시작 시 unredirect를 비활성화하고 종료 시 다시 활성화하는 호출을 포함한다.^[121]

화면 배율과 애니메이션에서는 논리적 좌표와 실제 렌더링 자원의 크기를 맞추어야 한다. 6.7 기록의 자원 배율·할당 API 변경과 팝업 배치 수정은 창이나 UI 요소의 크기 계산 시점이 렌더링에 직접 영향을 준다는 예다. 프레임률 문제를 모두 JavaScript 코드나 GPU 하나의 문제로만 설명하기보다 장면 갱신·버퍼 합성·출력의 흐름을 나누어 보는 것이 적절하다.

입력 장치

키보드, 마우스와 터치패드의 입력은 하부 장치 계층과 그래픽 세션을 거쳐 Cinnamon의 창과 셸로 전달된다. 포인터 이동, 버튼 클릭, 스크롤과 키 이벤트는 해당 창 또는 셸 UI의 포커스와 위치에 따라 처리된다. 모니터 배치와 화면 배율이 바뀌면 입력 좌표도 화면의 실제 배치와 일치해야 한다.

키보드 배열과 입력기는 다른 기능이다. 배열은 물리 키가 어떤 기호와 키 동작에 대응하는지 다루고, IBus·fcitx5 같은 입력 프레임워크는 여러 키 입력을 조합해 문자를 만드는 과정과 후보 선택 등을 처리한다. 한국어를 입력하는 환경에서는 배열 선택, 입력기 활성화와 앱의 입력 연결이 각각 맞아야 한다. 패널의 언어 표시가 바뀌었다는 사실만으로 모든 앱에서 조합 입력이 같은 상태라고 볼 수는 없다.

Cinnamon의 6.6 가상 키보드 구현은 입력 소스와 IBus 관리 계층, 특수키와 레이아웃 전환을 연결한다. 6.7에서는 fcitx5와 Wayland의 입력 소스 관리, 포커스와 화면 키보드 연동이 추가로 개선되었다. 버전별 입력 지원을 설명할 때에는 키보드 배열 목록과 조합 입력 프레임워크, 화면 키보드라는 세 층을 구분해야 한다.^[122][123]

전역 단축키는 앱에 전달되기 전에 셸이 처리할 수 있고, 모달 대화상자와 잠금 화면에서는 입력 전달 정책이 다시 달라진다. 이미 종료된 팝업이 입력을 가로채거나 수정키를 놓는 이벤트가 잘못 처리되면 정상적인 프로그램 입력까지 영향을 받을 수 있다. Cinnamon의 입력 관련 수정은 장치 감지뿐 아니라 이러한 UI 상태와 이벤트 순서를 다루는 작업도 포함한다.

그래픽 드라이버

Cinnamon은 운영체제가 제공하는 그래픽 드라이버와 사용자 공간 그래픽 라이브러리를 사용한다. Linux의 장치 지원과 출력 모드, 하드웨어 가속을 바탕으로 Muffin이 창과 셸을 합성한다. Cinnamon 빌드에 OpenGL과 관련 그래픽 라이브러리가 필요하다는 사실과 특정 제조사의 전용 드라이버만 사용해야 한다는 주장은 같은 의미가 아니다.^[124]

그래픽 문제는 화면 출력, 가속 경로와 데스크톱 정책을 나누어 보아야 한다. 모니터가 감지되지 않는 문제, 창 이동이 느린 문제, 미리 보기만 잘못 표시되는 문제는 같은 화면에서 관찰되더라도 서로 다른 계층에 속할 수 있다. 드라이버와 커널, Mesa 등의 버전은 배포판이 제공하며 Cinnamon 셸의 버전과 독립적으로 변경될 수 있다.

가상 머신이나 원격 세션에서는 물리 GPU와 다른 그래픽 장치가 제공될 수 있고, 하드웨어 가속을 사용할 수 없는 경우에는 CPU 기반 처리 비용이 커질 수 있다. 따라서 물리 장치의 이름만으로 Cinnamon 성능을 단정하거나, 같은 Cinnamon 버전의 두 시스템을 드라이버·해상도·모니터 수 없이 직접 비교하기는 적절하지 않다.

문제 보고에서는 사용 중인 세션이 X11인지 Wayland인지와 출력 장치 구성, 실제 사용 중인 렌더링 경로를 함께 기록하는 것이 유용하다. 특정 창의 표시 문제라면 셸 전체가 아니라 해당 애플리케이션의 툴킷과 하드웨어 가속 설정도 관련될 수 있다. Cinnamon은 그래픽 스택을 이용하는 통합 환경이지 하부 드라이버의 모든 동작을 직접 구현하는 프로젝트는 아니다.

HiDPI와 분수 배율

HiDPI는 높은 픽셀 밀도의 화면에서 UI가 지나치게 작아 보이지 않도록 논리적 크기와 실제 픽셀 크기를 구분하는 표시 방식이다. 예를 들어 같은 논리적 아이콘 크기를 더 많은 픽셀로 그리면 물리적 크기를 유지하면서 세부 표현을 늘릴 수 있다. 글꼴 크기만 키우는 것과 창·패널·아이콘 전체의 배율을 높이는 것은 결과가 다르다.

정수 배율과 분수 배율은 렌더링 자원을 준비하고 화면에 배치하는 방식에서 차이가 있다. 정수 배율에서는 픽셀 대응이 비교적 단순하지만 중간 배율은 재샘플링이나 서로 다른 크기의 렌더링 자원을 조합하는 처리가 필요할 수 있다. 이때 선명도, 메모리·그래픽 처리 비용과 사용 가능한 논리적 작업 영역 사이의 관계가 달라진다.

Cinnamon 6.7 개발 기록에는 St의 이미지·아이콘·텍스트와 UI 할당을 자원 배율 API에 맞추는 작업이 포함된다. 또한 Wayland의 분수 배율 설정을 숨기는 변경이 있다. 이 둘을 합쳐 모든 Cinnamon 세션에서 임의의 분수 배율을 완전히 지원한다는 결론을 내릴 수는 없다. 해당 UI에서 어떤 옵션을 제공하는지와 하부 합성기가 어떤 배율 경로를 구현하는지는 각각 확인해야 한다.^[125]

서로 다른 배율의 모니터 사이로 창을 이동하는 경우에는 앱의 버퍼와 셸의 창 미리 보기, 아이콘을 함께 갱신해야 한다. X11 애플리케이션을 XWayland로 실행하는 경로도 네이티브 Wayland 앱과 같은 처리라고 단정할 수 없다. 문서에서는 단순한 지원 여부보다 세션·앱 종류·모니터 구성별로 어떤 요소가 확대되는지를 구분하는 편이 정확하다.

화면 캡처와 화면 녹화

화면 캡처, 내장 화면 녹화와 외부 앱의 화면 공유는 구분되는 기능이다. 캡처는 특정 시점의 픽셀을 이미지로 얻는 동작이고, 녹화는 연속된 프레임을 파일에 기록하며, 화면 공유는 다른 프로세스에 화면 스트림을 전달하는 경로까지 포함한다. 같은 화면을 대상으로 하더라도 구현과 필요한 라이브러리가 같지 않다.

Cinnamon 6.6에는 자체 녹화기 구현이 존재한다. 빌드 옵션 build_recorder의 기본값은 true이고, 활성화하면 GStreamer와 GStreamer Base에 의존한다. JavaScript의 ScreenRecorder는 Cinnamon.Recorder를 만들고 org.cinnamon.recorder에서 프레임률·파일 확장자·파이프라인 설정을 읽는다. 따라서 Cinnamon의 녹화 기능을 모두 외부 앱이 제공한다고 설명하는 것은 실제 구현과 맞지 않는다.^{[126][127][128]}

확인한 6.6 녹화기 코드는 여러 모니터가 있을 때 주 모니터 영역을 지정하고, 파일 이름에 날짜와 시간을 넣으며, 시작과 종료에 합성기의 unredirect 상태를 조절한다. 설정 문자열이 비어 있으면 기본 파이프라인을 사용하도록 전달한다. 이것은 해당 내장 구현의 동작이며 임의의 화면 선택, 오디오 믹싱과 스트리밍 기능을 모두 제공한다는 뜻은 아니다.

6.7 개발 계열에는 cinnamon-screenshot 도입과 창·영역 선택, 클립보드 저장, Wayland의 전체 모니터 캡처 개선이 별도로 나타난다. 정지 이미지 캡처 도구의 이러한 변경을 앞의 6.6 녹화기와 같은 기능으로 합쳐서는 안 된다. 외부 화상회의나 녹화 앱의 화면 공유는 포털·스트림 인터페이스와 앱의 세션 지원에 의존하므로, 내장 캡처가 동작한다는 사실만으로 해당 경로의 지원을 보장하지 않는다.^[129]

Cinnamon 개발은 셸 UI, 네이티브 라이브러리와 배포판 통합을 함께 다룬다. 파일 하나를 변경하는 작업이라도 CJS와 GObject 바인딩, 설정 스키마, 모니터와 세션 종류에 영향을 받을 수 있다. 소스 저장소의 구조와 실제 설치 자원의 관계를 이해하면 셸 기능·Spices·Nemo의 확장을 각각 적절한 계층에서 구현할 수 있다.

소스 코드

Linux Mint는 Cinnamon, Muffin, CJS, Nemo와 관련 세션·설정 프로젝트를 별도 저장소로 관리한다. Cinnamon 저장소 안에서도 네이티브 소스, JavaScript 모듈, 설치할 Python 도구와 애플릿, 번역·설정 데이터가 나뉜다. 별도 저장소라는 사실은 독립 실행 프로세스라는 뜻이 아니며, 빌드 의존성을 통해 하나의 실행 파일과 라이브러리 조합으로 연결될 수 있다.^[130][131]

Cinnamon에서 확인할 수 있는 주요 소스 구성

• Cinnamon 저장소
  • meson.build 및 meson_options.txt — 빌드 의존성과 기능 선택
  • src — 네이티브 구현
  • js — 셸과 보조 JavaScript 모듈
    • ui — 설정·창 전환·녹화 등 UI 기능
  • files — 설치 경로에 배치할 프로그램과 자원
    • usr/share/cinnamon — 설정 모듈과 기본 애플릿
  • data — 스키마와 공통 데이터
  • docs/reference — API 문서 구성
  • po — 번역 자원

js는 설치 데이터 경로에 복사되고 일부 설정 파일은 빌드 중 생성된다. files 아래는 설치할 파일 시스템 구조를 반영하며, 설정 모듈과 애플릿 자원이 이 경로에 포함된다. 따라서 저장소의 Python 파일을 읽을 때 사용하는 import 경로와 실제 설치 뒤의 경로를 구분해야 한다. 빌드가 성공해도 필요한 데이터가 다른 위치에 설치되면 런타임에서 문제가 발생할 수 있다.

유지보수 브랜치와 master를 섞어서 조사하면 같은 파일명이 다른 구현을 가리킬 수 있다. 이 문서의 창·패널·테마 설정과 녹화기 설명은 주로 6.6-maintenance 코드를, 새 잠금 컨트롤러와 일부 Wayland 기능은 master의 6.7 개발 계열을 기준으로 한다. 구체적인 동작을 인용할 때는 프로젝트 이름뿐 아니라 브랜치와 대상 파일을 함께 기록하는 것이 유용하다.

프로그래밍 언어

Cinnamon의 구현은 C (프로그래밍 언어), JavaScript, Python을 주요 언어로 사용한다. C는 네이티브 객체와 시스템·그래픽 라이브러리 연결에, JavaScript는 셸 UI와 애플릿·확장에, Python은 설정 도구와 보조 프로그램에 널리 사용된다. 한 기능이 한 언어로만 구현된다고 가정할 수 없으며, 화면 녹화기처럼 JavaScript에서 C 객체를 만들고 네이티브 처리에 전달하는 경우도 있다.^[132][133]

JavaScript와 C 사이에는 GObject Introspection과 CJS가 연결된다. JavaScript에서 불러온 객체가 실제로는 네이티브 라이브러리의 객체일 수 있으므로 객체의 속성·시그널과 수명 주기를 함께 이해해야 한다. 단순한 스크립트 변수 변경이 네이티브 UI 상태의 변경이나 파일·서비스 접근으로 이어질 수 있다.

Python 설정 모듈도 Gtk와 Gio 등 Introspection 인터페이스를 사용한다. 창 설정은 GTK 위젯을 만들고 GSettings 키에 연결하며, 개인정보 모듈은 필요에 따라 NetworkManager의 클라이언트를 가져온다. Python은 셸의 모든 화면을 그리는 주 언어라기보다 별도 설정 앱과 보조 기능을 구현하는 수단이다.^[134][135]

확장 개발에서는 언어 문법만큼 실행 환경을 확인해야 한다. 브라우저용 JavaScript 코드나 일반 Python 프로그램이 Cinnamon의 모듈 경로와 API에서 그대로 동작한다고 볼 수는 없다. CJS 버전, GObject 자료형과 설치된 라이브러리의 바인딩을 기준으로 사용할 기능을 정해야 한다.

빌드 시스템

확인한 Cinnamon 6.6-maintenance는 Meson을 빌드 시스템으로 사용한다. 프로젝트 정의는 C 언어와 버전을 선언하고, CJS·Muffin·Clutter·Cogl·GTK·GIO·GObject Introspection·XApp 등의 라이브러리를 의존성으로 찾는다. 네이티브 코드 컴파일과 함께 구성 헤더, JavaScript 설정 파일, 세션 정의와 설치할 데이터 경로를 생성한다.^[136]

기능 선택은 meson_options.txt에서 확인할 수 있다. 문서 빌드, 내장 녹화기, NetworkManager 에이전트 방식, Wayland 지원과 일부 설정 모듈의 포함 여부가 별도 옵션이다. 같은 소스 버전이라도 배포판의 빌드 옵션에 따라 설치 결과가 달라질 수 있다. 기능의 소스 코드가 저장소에 있다는 사실만으로 배포된 바이너리에 포함되었다고 추정해서는 안 된다.^[137]

설치 대상에는 실행 파일뿐 아니라 GSettings 스키마, D-Bus 관련 서비스 파일, X11·Wayland 세션 파일, JavaScript 모듈과 Python 프로그램, 번역 자원과 매뉴얼도 포함된다. 개발자가 로컬 빌드를 실행할 때 라이브러리만 새 버전이고 데이터 경로는 시스템 설치본을 참조하면 서로 다른 버전이 섞일 수 있다. 독립된 설치 경로나 테스트 환경을 사용할 때에도 이 자원들의 참조 관계를 맞추어야 한다.

6.6 빌드 정의는 CJS 버전에 따라 Introspection 의존성을 다르게 선택한다. 녹화기를 활성화하면 GStreamer 계열 의존성이 추가되고, 내장 네트워크 에이전트를 선택하면 libnm와 libsecret이 필요하다. 따라서 빌드 실패를 모든 환경에서 같은 패키지 하나가 빠진 문제로 단정하기보다 선택한 옵션과 의존성 검사를 함께 보는 것이 정확하다.

JavaScript API

Cinnamon의 JavaScript API는 셸 UI 객체, 애플릿·데스크릿, 팝업과 설정, 창과 작업 공간의 상태에 접근하는 인터페이스를 제공한다. imports.ui 계열의 셸 모듈과 imports.gi를 통한 네이티브 객체를 함께 사용할 수 있다. 웹 페이지의 DOM을 중심으로 하는 API가 아니라 Cinnamon의 UI와 시스템 통합을 위한 API다.^[138][139]

xlet 설정 API는 설정 값을 JavaScript 객체의 속성과 연결한다. bind는 설정 키와 속성 이름, 선택적인 변경 콜백을 연결하며 bindWithObject는 다른 객체를 지정하는 형태다. 내부적으로 속성 접근을 설정 데이터의 읽기·쓰기에 연결하고 필요한 값을 파일에 저장하도록 한다. 설정 창에서 값이 바뀌면 확장 코드의 동작도 그 변화에 반응할 수 있다.

이 API는 키가 존재하는지, 지원되는 설정 유형인지, 필요한 필드가 있는지를 검사한다. 체크 상자, 텍스트 입력, 파일·아이콘 선택, 색상과 글꼴 선택, 단축키, 선택 상자와 수치 범위 등의 유형이 정의되어 있다. 설정 정의에 없는 키를 코드에서 참조하거나 유형이 맞지 않으면 오류를 기록하도록 되어 있어, 스키마와 실행 코드의 일치가 중요하다.

이전 API와 현재 권장 방식도 구별된다. 확인한 settings.js는 BindingDirection의 의미가 3.2 이후 폐기되었다고 설명하고, bindProperty를 bind로 연결하는 하위 호환 래퍼로 유지한다. 오래된 애플릿 예제를 그대로 복사하기보다 해당 Cinnamon 버전의 API 주석과 기본 애플릿을 참고해야 한다. API가 남아 있다는 사실과 새 코드에서 권장된다는 사실은 같지 않다.

C API

Cinnamon과 Muffin의 네이티브 계층은 창·그래픽 객체, 입력·설정과 시스템 라이브러리의 연결을 제공한다. 공개되는 일부 GObject 객체는 Introspection 자료를 통해 JavaScript나 Python에서 접근된다. C API를 사용하는 코드와 그 객체를 스크립트에서 사용하는 코드가 같은 기능의 서로 다른 계층에 존재할 수 있다.

대표적인 예로 6.6 녹화기는 JavaScript에서 Cinnamon.Recorder를 생성하고 프레임률, 출력 이름, 영역과 파이프라인을 설정한 뒤 네이티브 녹화 동작을 호출한다. JavaScript가 각 프레임의 인코딩을 직접 수행하는 구조가 아니다. UI와 상태 제어는 스크립트가 맡고 그래픽·미디어 처리의 하부 기능을 네이티브 계층에 위임한다.^[140]

헤더와 공유 라이브러리, Introspection 메타데이터의 버전은 서로 맞아야 한다. 컴파일할 때 보이는 함수와 실행 중 로드한 라이브러리의 심벌이 다르거나, 스크립트가 사용하는 typelib이 다른 버전이면 빌드 성공과 무관하게 실행 문제가 발생할 수 있다. Cinnamon의 빌드가 Muffin의 typelib 경로를 가져와 정의에 사용하는 것도 네이티브 라이브러리와 바인딩 자료를 함께 다루기 때문이다.^[141]

프로젝트의 내부 함수와 외부 개발자가 장기적으로 사용할 공개 API를 구분하는 것도 중요하다. 저장소에서 호출할 수 있는 함수가 보인다는 사실만으로 버전 간 안정성이 보장되는 것은 아니다. 확장이 네이티브 객체의 내부 구조에 더 가깝게 결합할수록 셸·Muffin·CJS 변경에 맞추어 검토할 범위도 넓어진다.

Applet과 Extension 개발

Spices 개발은 식별자와 설치 구조, 설정 정의, UI 객체의 수명 주기를 함께 구성하는 작업이다. UUID는 확장을 구별하는 이름이며 파일 경로와 메타데이터에 일관되게 사용된다. 공식 Extensions 저장소는 웹사이트용 정보와 실제 설치 파일을 분리하고, files 아래에 UUID 디렉터리 하나만 두도록 요구한다.^[142]

구현에서는 먼저 필요한 UI를 만들고 입력·상태 변경에 반응하며, 제거될 때 연결과 자원을 정리한다. 애플릿은 패널 방향과 크기에 맞추어 표시를 바꾸고, 셸 동작을 바꾸는 Extension은 활성화 시 적용한 변경을 비활성화 시 되돌릴 수 있어야 한다. 네트워크 요청과 반복 타이머, 파일 모니터·시그널 연결은 화면 객체와 별도로 남을 수 있으므로 수명 관리를 명시적으로 다루는 것이 중요하다.

사용자 설정은 Cinnamon의 xlet 설정 인터페이스로 관리한다. 공식 Extensions 규칙은 별도 GSettings 스키마를 추가하거나 Cinnamon의 JSON 파일을 직접 편집하는 대신 제공된 설정 인터페이스를 사용하도록 한다. 설정 키와 UI 정의를 작성하고 API의 바인딩을 통해 코드의 속성·콜백과 연결하면 다중 인스턴스와 갱신을 같은 체계에서 관리할 수 있다.^[143][144]

공식 저장소의 validate-spice는 구조를 검사하고 test-spice는 로컬 시험용 복사본을 설치하는 경로를 제공한다. 시험 복사본에는 devtest- 접두사를 사용하여 일반 설치본과 구별할 수 있게 한다. 구조 검사를 통과한 뒤에도 UI 조작, 활성화·비활성화 반복, 설정 변경, 여러 모니터와 지원하는 세션에서 실제 동작을 확인해야 한다. 검증 스크립트와 사람이 수행하는 기능 검토는 서로 보완적인 절차다.

번역

Cinnamon의 메뉴·설정·오류 메시지는 gettext 계열의 번역 자료와 연결된다. 소스 코드의 원문 문자열에서 번역 템플릿을 만들고 각 언어의 번역을 제공하여 설치된 언어 환경에 맞는 문구를 표시한다. 셸과 설정 프로그램, 파일 관리자와 독립 Spices는 다른 저장소와 번역 주기를 가질 수 있다.

Spices Extensions 저장소는 cinnamon-spices-makepot 스크립트로 번역 템플릿을 갱신하고 로컬 번역 시험을 돕는다. 번역 파일은 설치되는 UUID 디렉터리 안의 po 경로와 연결되며, 번역 상태 표를 생성하여 새 문자열과 미번역 항목을 확인할 수 있도록 한다. 확장 기능이 동작한다는 사실과 모든 언어에서 설명과 설정이 번역되었다는 사실은 별개다.^[145]

번역에서는 문자열의 문맥과 자리 표시자를 유지해야 한다. 버튼의 짧은 명령과 설명 문장은 같은 단어라도 다른 표현이 필요할 수 있고, 파일명·숫자·프로그램 이름이 삽입되는 위치를 잘못 바꾸면 오류나 부자연스러운 UI가 생긴다. 긴 번역문이 설정 페이지의 폭과 패널 배치에 미치는 영향도 확인해야 한다.

오른쪽에서 왼쪽으로 쓰는 인터페이스와 여러 문자 체계는 단순한 문자열 교체 이상의 처리를 요구한다. Cinnamon 창 설정 모듈은 텍스트 방향에 따라 제목 표시줄 버튼 위치의 표시를 고려한다. 글꼴 대체와 문자 폭, 단축키 표현·입력기 지원도 지역화된 데스크톱의 사용성과 연결된다.^[146]

버그 추적과 기여

버그는 화면에서 나타난 위치뿐 아니라 기능을 담당하는 프로젝트를 기준으로 분류한다. 패널과 메뉴·셸 팝업은 Cinnamon, 창 관리와 합성은 Muffin, 파일 탐색·파일 작업은 Nemo, 특정 Spices만의 문제는 해당 확장의 유지보수 경로가 중심이 된다. 공통 라이브러리나 배포판 패치가 원인일 수도 있으므로 한 구성 요소로 바로 단정하기보다 재현 조건을 정리한다.^[147]

재현 정보에는 Cinnamon과 관련 패키지 버전, 배포판, X11·Wayland 세션, 모니터 구성, 사용 중인 Spices와 문제를 일으키는 조작 순서가 유용하다. 설정을 바꾼 뒤 생기는 문제라면 해당 값과 기본값에서의 차이를 기록한다. 창 목록의 문제라면 앱 식별과 창 개수, 작업 공간·모니터 범위도 포함하면 원인을 좁히는 데 도움이 된다.

Spices의 기여는 작성자와 타인의 변경을 구분한다. 공식 Extensions 규칙은 작성자 소유의 확장만 바꾸었는지, 구조를 지켰는지, 환경에 부정적인 코드를 넣지 않았는지 등을 확인한다. 타인이 기능이나 외형을 바꾸는 경우에는 원 작성자의 검토를 기다리는 흐름을 두며, 버그 수정과 번역 등 일부 변경은 별도의 기준을 적용한다.^[148]

디버깅에서는 Looking Glass와 관련 로그, 구성 요소의 시험 도구를 이용할 수 있다. Nemo Action 예제는 NEMO_DEBUG의 Actions 범주와 디버그 실행을 안내하고, Cinnamon 개발 기록에는 Looking Glass의 세션 표시와 합성 디버그 기능이 추가된 내용이 있다. 오류 메시지와 실제 기능의 계층을 연결하여 검토하는 것이 단순히 화면이 멈췄다는 설명보다 재현과 수정에 유용하다.^[149][150]

릴리스와 버전 관리

Cinnamon이라는 제품명 아래에도 셸·Muffin·CJS·Nemo·세션 도구는 각각의 버전과 변경 기록을 가진다. 전체 배포판은 검증한 조합을 패키지로 제공하며, 일부 보안·호환성 수정만 기존 버전으로 가져올 수도 있다. Cinnamon Shell의 버전 하나로 파일 관리자와 JavaScript 런타임의 모든 기능을 결정할 수는 없다.

2026년 10월 11일 확인한 Cinnamon 6.6-maintenance의 최상단 기록은 6.6.9이고 master는 6.7.8이다. 이 값들은 해당 브랜치에서 확인한 변경 기록이며 모든 저장소·배포판의 최신 설치 가능 버전을 뜻하지 않는다. 안정 계열에서의 CJS 140 대응처럼 유지보수 작업과 개발 계열에서의 새 화면 잠금·배경 처리처럼 기능 재구성은 다른 목적의 변경이다.^[151][152]

버전 비교에서는 배포판 패치와 빌드 옵션도 기록해야 한다. 내장 녹화기나 네트워크 에이전트, Wayland 관련 설치 파일은 빌드 구성의 영향을 받는다. 소스에 기능이 존재하는 상태, 바이너리에 포함된 상태, 사용자가 해당 세션에서 활성화한 상태는 각각 다른 단계다.^[153]

Spices는 또 다른 갱신 주기를 갖는다. 본체 업데이트 후 특정 애플릿만 오류가 나는 경우에는 셸의 변경과 확장의 지원 버전을 함께 확인해야 한다. 반대로 확장을 갱신했다고 하부 CJS나 Muffin의 버그가 자동으로 수정되는 것은 아니다. 구성 요소와 배포 경로별 버전을 분리해 기록하면 릴리스 문서와 사용자 문제 보고가 더 정확해진다.

Cinnamon은 Linux Mint의 주요 개발·통합 환경에서 출발했지만 독립적으로 패키징할 수 있는 데스크톱이다. 배포판은 셸과 필수 구성 요소에 로그인 관리자, 오디오·네트워크 서비스, 테마와 기본 앱을 조합한다. 같은 Cinnamon을 사용하더라도 설치 프로그램, 업데이트 정책과 기본 응용 프로그램까지 동일해지는 것은 아니다.

Linux Mint

Linux Mint의 Cinnamon Edition은 Cinnamon을 중심으로 데스크톱을 구성하는 대표적인 배포 형태다. 셸과 Nemo, 설정 도구에 Mint의 테마와 소프트웨어·업데이트 관리 도구, 기본 응용 프로그램을 결합한다. 사용자는 설치 직후 하나의 통합 환경을 사용하지만 그 안에는 Cinnamon 자체와 배포판이 별도로 관리하는 도구가 함께 들어 있다.^[154]

Cinnamon과 Linux Mint를 구분하는 것은 기능 설명에서 중요하다. 메뉴와 패널, 창 관리가 Cinnamon에 속하더라도 업데이트 정책과 시스템 패키지의 배포, 설치 프로그램과 저장소 구성은 Linux Mint 운영체제의 영역이다. Mint의 소프트웨어 관리자를 다른 Cinnamon 배포판에서 기본으로 제공한다고 가정할 수 없으며, 반대로 Mint 도구의 변경을 Cinnamon 셸의 새 기능으로 분류해서도 안 된다.

배포판 통합은 구성 요소의 버전 선택에도 영향을 준다. Linux Mint는 안정적인 기반 위에 Cinnamon 관련 패키지를 결합하며, 해당 릴리스에서 검증한 라이브러리와 테마·설정 조합을 제공한다. 개발 저장소의 최신 변경을 즉시 모두 적용하는 것과 배포판 사용자에게 안정 업데이트를 제공하는 것은 다른 작업이다.

Cinnamon을 체험할 때 Linux Mint의 기본 화면은 프로젝트의 대표적인 사용자 경험을 보여 주지만, 기본 앱 목록과 패널 배치까지 Cinnamon의 필수 사양으로 해석할 필요는 없다. 다른 배포판이나 사용자 설정에서도 같은 셸·확장 체계를 바탕으로 다른 데스크톱을 구성할 수 있다.

Linux Mint Debian Edition

Linux Mint Debian Edition, 약칭 LMDE는 Ubuntu를 거치지 않고 Debian을 직접 기반으로 Linux Mint의 데스크톱 경험을 제공하는 계열이다. Cinnamon을 기본 환경으로 사용하며, 같은 Mint 계열의 테마와 도구를 Debian 패키지 기반과 결합한다. Cinnamon이 Ubuntu의 특정 설치 형태만을 전제로 하는 소프트웨어가 아님을 보여 주는 배포 사례다.^[155]

일반 Linux Mint와 UI가 비슷하더라도 하부 패키지의 출처와 버전 조합은 다를 수 있다. 커널·드라이버·시스템 라이브러리와 패키지 의존성은 기반 배포판의 영향을 받으며, Cinnamon의 같은 설정 화면에서도 장치 지원이나 외부 프로그램의 버전이 달라질 수 있다. 바탕 화면의 유사성과 전체 운영체제 기반의 동일성을 구분해야 한다.

LMDE에서 Cinnamon을 운영하려면 Debian 기반 위에 필요한 Cinnamon 구성 요소와 Mint 통합 도구를 조합한다. 셸·파일 관리자·세션 서비스의 역할 자체는 바뀌지 않지만, 패키지 유지보수와 업데이트의 경로가 일반판과 다르다. 다른 배포판에 Cinnamon을 이식하는 일이 셸 바이너리 하나를 옮기는 작업만은 아니라는 점을 보여 준다.

문제 보고에서도 LMDE인지 Ubuntu 기반 일반판인지 구체적으로 밝히는 것이 유용하다. 같은 Cinnamon 문제처럼 보여도 기반 라이브러리, 장치 서비스와 배포판 패치의 차이로 재현 조건이 달라질 수 있기 때문이다. Cinnamon 버전과 운영체제 기반을 함께 기록하면 어느 프로젝트의 변경과 연결되는지 구별하기 쉬워진다.

Debian과 Ubuntu 계열

Debian은 Cinnamon을 설치할 수 있는 패키지 구성을 제공하며 cinnamon-core와 cinnamon-desktop-environment 같은 메타패키지로 설치 범위를 구분한다. 핵심 데스크톱 구성과 일반 응용 프로그램을 포함하는 더 넓은 환경은 같은 의미가 아니다. 메타패키지는 기능을 직접 구현하는 하나의 대형 실행 파일이 아니라 필요한 패키지 조합을 설치하는 진입점이다.^[156][157]

기존 시스템에 Cinnamon을 추가하면 패널·창 관리자와 세션 구성이 설치되더라도 기본 앱·로그인 관리자·오디오·네트워크 도구는 기존 구성의 영향을 받을 수 있다. 완성된 데스크톱 메타패키지를 사용하는 방식과 최소 구성 위에 필요한 프로그램을 직접 선택하는 방식의 차이다. 어떤 프로그램이 함께 설치되는지는 해당 배포판 버전의 의존성과 추천 패키지를 기준으로 확인한다.

Ubuntu 계열에서도 Cinnamon 관련 패키지를 이용해 데스크톱을 구성할 수 있다. Ubuntu 기반이라는 사실만으로 Linux Mint의 테마·도구·패키지 버전까지 자동으로 따라오는 것은 아니다. 배포판 저장소의 Cinnamon 패키지와 Linux Mint가 자체적으로 제공하는 패키지는 업데이트 경로와 기본 설정을 구분해서 다루어야 한다.

다른 저장소의 Cinnamon 구성 요소를 섞으면 라이브러리와 스키마, 세션 파일의 버전이 어긋날 수 있다. 설치의 기준은 이름이 비슷한 패키지를 모으는 것보다 배포판이 제공하는 호환 조합을 선택하는 데 있다. 이식성이 있다는 설명은 모든 Debian·Ubuntu 기반 시스템에서 임의의 상위 패키지를 같은 방식으로 혼합할 수 있다는 뜻이 아니다.

Fedora

Fedora의 Cinnamon Spin은 Fedora의 시스템 기반 위에 Cinnamon을 기본 데스크톱으로 구성한 배포 형태다. Fedora의 패키지 관리와 시스템 서비스·보안 정책을 유지하면서 패널과 메뉴, 창 관리와 파일 탐색에 Cinnamon 계열 도구를 사용한다. Linux Mint의 사용자 인터페이스를 그대로 복제하는 제품이라기보다 같은 데스크톱을 다른 배포판 기반에 통합한 사례다.^[158]

기본 테마·응용 프로그램·패키지 이름과 업데이트 주기는 Fedora의 구성에 따른다. Cinnamon의 설정 화면이 같아도 소프트웨어 설치와 시스템 업데이트를 담당하는 도구는 배포판 차원에서 달라질 수 있다. Fedora의 기반 라이브러리가 변경되면 Cinnamon 패키지를 그 환경에 맞추어 빌드하고 검증하는 작업도 필요하다.

Cinnamon Spin을 설치하는 것과 기존 Fedora에 Cinnamon 패키지를 추가하는 것은 초기 구성의 범위가 다르다. Spin은 처음부터 사용할 데스크톱 조합을 제공하고, 기존 시스템에 추가하는 방식은 이미 설치된 로그인 관리자·프로그램·자동 시작 항목과 공존한다. 여러 데스크톱을 설치한 경우 로그인 화면의 세션 선택이 실제 사용할 셸을 결정한다.

Fedora에서 발생한 문제를 Linux Mint의 같은 Cinnamon 버전과 비교할 때에는 시스템 라이브러리와 세션 종류, 배포판 패치와 기본 앱도 함께 기록해야 한다. 같은 상위 프로젝트를 사용한다는 사실은 원인 분석의 출발점이지만 모든 패키지와 설정이 같다는 전제는 아니다.

Arch Linux 계열

Arch Linux에서는 Cinnamon 관련 패키지를 설치하고 로그인 관리자와 필요한 응용 프로그램·서비스를 조합하여 데스크톱을 구성할 수 있다. 사용자가 전체 운영체제 구성을 직접 선택하는 방식과 결합되므로 Cinnamon 셸의 설치, 로그인 세션 준비, 오디오·네트워크와 기본 앱의 구성은 서로 다른 단계로 다루어진다.^[159]

롤링 릴리스의 패키지 갱신 주기는 Linux Mint의 안정 릴리스와 다르다. Cinnamon뿐 아니라 CJS·GTK·그래픽 라이브러리가 갱신될 수 있어 하부 의존성과의 호환성 검증이 중요하다. 특정 시점의 설치 버전을 확인하지 않고 항상 어느 배포판이 더 최신이라고 단정하기보다 실제 패키지 조합과 변경 기록을 비교해야 한다.

최소 구성에서는 파일 관리자와 세션은 설치되어도 사용자가 기대하는 모든 일반 앱이 함께 제공되지 않을 수 있다. 웹 브라우저, 문서 편집기와 터미널, 파일 형식별 연결 프로그램은 별도로 선택할 수 있으며 Cinnamon이 이들을 자체 구현하는 것은 아니다. UI의 기본 틀과 작업에 필요한 앱 집합을 분리하여 구성하는 방식이다.

문제 분석에서는 배포판 패키지의 갱신 시점과 로컬 설정, 사용 중인 Spices를 함께 살펴본다. 상위 Cinnamon 버그인지 새 라이브러리와의 호환 문제인지, 또는 개인 확장이 내부 API를 따라가지 못하는지에 따라 수정 경로가 달라진다. ArchWiki의 설치·설정 안내와 실제 패키지 정보는 배포판 통합 부분을 확인하는 자료다.

openSUSE와 기타 배포판

Cinnamon의 배포 범위는 Linux Mint·Debian·Fedora·Arch Linux에 한정되지 않는다. openSUSE를 비롯한 다른 배포판에서도 공식 또는 커뮤니티 패키지 조합으로 제공되어 왔다. 이때 중요한 것은 Cinnamon이라는 이름의 패키지 존재뿐 아니라 해당 배포판 릴리스에서 누가 어떤 구성 요소를 유지하고 어떤 저장소를 통해 제공하는지다.^[160]

배포판에 통합하려면 셸과 Muffin·CJS의 라이브러리 조합, Nemo와 설정·세션 프로그램, GSettings와 번역 자원, 로그인 관리자에서 선택할 세션 파일을 맞추어야 한다. 필요에 따라 자체 테마와 앱을 결합하고 NetworkManager 에이전트 등의 빌드 옵션을 선택할 수 있다. Cinnamon의 이식성은 이러한 구성 요소가 공개적으로 관리되고 공통 Linux 사용자 공간 기반을 사용한다는 데 있다.^[161]

기본 배포판에 Cinnamon 전용 설치 이미지가 없더라도 패키지를 통해 사용할 수 있는 경우가 있다. 반대로 커뮤니티 저장소에 패키지가 존재한다고 해서 모든 버전에서 동일한 유지보수 수준과 기능을 제공한다고 볼 수는 없다. 배포판의 기본 에디션, 추가 공식 패키지와 개인 저장소는 지원 경로를 구분해서 설명해야 한다.

Cinnamon의 기본 UI와 Mint 전용 관리 도구도 별도로 선택될 수 있다. 다른 배포판에서 Cinnamon을 사용한다는 것은 Linux Mint 운영체제 전체를 내부에 설치한다는 뜻이 아니며, 저장소·패키지 관리자·업데이트 정책은 원래 배포판의 체계를 따른다. 이 구분이 배포판을 넘어서는 데스크톱 환경으로서 Cinnamon의 성격을 설명한다.

설치와 세션 선택

설치는 일반적으로 배포판의 Cinnamon 패키지 또는 데스크톱 메타패키지를 선택하고, 필요한 구성 요소와 로그인 세션을 준비하는 순서로 이루어진다. 사용자가 기대하는 범위가 핵심 셸인지 일반 앱을 포함한 전체 데스크톱인지에 따라 선택이 달라진다. Debian의 core와 desktop-environment 구분은 이 설치 범위를 명시적으로 나눈 사례다.^[162][163]

설치 후 로그인 화면에서 Cinnamon을 선택하면 해당 세션의 실행 정의를 사용한다. Cinnamon 빌드에는 X11과 Wayland 세션 디렉터리 및 세션 파일 생성 과정이 존재하고, Wayland 옵션에 따라 설치되는 구성이 달라질 수 있다. 로그인 목록에 나타나는 선택지는 배포판이 설치한 파일과 로그인 관리자의 표시 방식에 따른다.^[164]

터미널에서 설정 창 하나를 실행하는 것과 Cinnamon 전체 세션에 로그인하는 것은 다르다. 기존 GNOME 세션 안에서 Cinnamon 설정 프로그램을 열었다고 창 관리자와 패널이 Cinnamon으로 바뀌는 것은 아니다. 실제 데스크톱 전환은 선택된 사용자 세션과 시작된 구성 요소를 기준으로 이해해야 한다.

첫 로그인 후에는 패널과 메뉴, 파일 관리자, 네트워크·오디오 상태와 기본 프로그램 연결이 의도대로 동작하는지 확인할 수 있다. 세션 선택에 성공했지만 일부 도구가 없는 경우에는 핵심 셸 설치와 전체 데스크톱 묶음의 차이일 수 있다. 설치된 패키지, 실행 중인 서비스와 사용자 설정을 나누어 살펴보면 빠진 구성을 구체적으로 찾을 수 있다.

다른 데스크톱 환경과의 공존

한 Linux 시스템에 여러 데스크톱 환경을 설치하고 로그인할 때 세션을 선택할 수 있다. 프로그램과 파일은 공통 사용자 환경을 이용하면서 패널·창 관리자·세션 서비스는 선택한 데스크톱의 구성을 사용한다. 다른 데스크톱을 설치하는 작업은 기존 사용자 데이터 전체를 새 운영체제로 옮기는 작업과 다르다.

공통 자원을 공유하는 만큼 설정도 일부 영향을 줄 수 있다. GTK 테마와 기본 앱 연결, 사용자 자동 시작 항목은 여러 환경에서 읽힐 수 있지만 Cinnamon의 패널과 xlet 설정은 Cinnamon 고유 체계를 따른다. 한 데스크톱에서 바꾼 모든 설정이 다른 환경으로 전파되는 것도 아니고, 완전히 독립적이라고 볼 수도 없다.^[165][166]

파일 관리자와 알림·인증 에이전트 같은 프로그램을 사용자 자동 시작에 중복 등록하면 선택한 세션이 원래 시작하는 구성과 충돌할 수 있다. 여러 프로그램이 같은 데스크톱 아이콘을 관리하려 하거나 상태 아이콘이 두 번 나타나는 경우가 예다. 배포판의 세션 정의와 사용자 추가 항목을 구분하면 필요한 프로그램을 유지하면서 중복 실행을 줄일 수 있다.

동일 사용자 계정을 사용하는 시험은 실제 작업 설정의 영향을 받기 쉽고, 별도 사용자 계정의 시험은 개인 설정과 기본 패키지 문제를 구분하는 데 도움이 된다. 어떤 방식으로 비교하든 Cinnamon 버전과 세션 종류, 설치된 확장 및 공유 설정을 함께 기록하면 환경 간 차이를 더 정확하게 해석할 수 있다.

데스크톱 환경을 비교할 때에는 패널과 메뉴의 외형뿐 아니라 셸·창 관리자·툴킷·파일 관리자·설정·확장 체계의 관계를 살펴야 한다. 두 환경을 비슷하게 꾸밀 수 있어도 내부 API가 호환되는 것은 아니며, 다른 툴킷을 사용한다고 같은 응용 프로그램을 실행할 수 없는 것도 아니다. Cinnamon은 GNOME 계열 기술에서 출발하여 독립적인 셸과 구성 요소를 발전시킨 환경이다.

GNOME

GNOME은 Cinnamon의 직접적인 기술적 출발점이다. 최초 Cinnamon이 GNOME Shell 3.2.1을 기반으로 했고 Muffin이 Mutter에서 파생되었다는 계보는, Cinnamon이 단순히 다른 테마를 적용한 GNOME Shell이라는 설명과는 구별된다. Cinnamon은 자체 셸과 세션·설정·파일 관리자 및 확장 생태계를 관리한다.^[167][168]

사용자 경험에서는 Cinnamon이 지속적으로 보이는 패널과 응용 프로그램 메뉴·창 목록을 중심에 둔 반면 GNOME Shell은 활동 개요를 중심으로 한 탐색 방식을 발전시켰다. 다만 개요 화면을 사용한다고 패널 기능이 사라지는 것은 아니며, Cinnamon도 Expo·Overview와 단축키를 제공한다. 차이는 특정 기능의 단순한 유무보다 기본 조작 흐름과 통합 방식에 있다.

GTK·GLib·GObject와 Introspection 같은 기반을 공유하므로 많은 GNOME 계열 응용 프로그램을 Cinnamon에서도 사용할 수 있다. 그러나 앱의 실행과 데스크톱 셸 확장의 호환성은 다른 문제다. GNOME Shell Extension이 Cinnamon의 imports.ui 객체와 같은 API를 제공받는다고 볼 수 없으며, Cinnamon Spices는 자체 메타데이터와 설정 인터페이스를 사용한다.^[169][170]

두 프로젝트의 그래픽 지원도 독립적으로 확인해야 한다. 공통 조상과 라이브러리가 있다는 이유만으로 GNOME의 특정 Wayland·입력·화면 공유 기능이 같은 시점에 Cinnamon에 적용된다고 추정할 수 없다. Cinnamon의 개발 기록과 실제 구성 요소를 기준으로 기능을 설명하는 것이 정확하다.

MATE

MATE와 Cinnamon은 전통적인 데스크톱 작업 방식을 유지한다는 점에서 자주 함께 비교되며 Linux Mint에서도 별도의 데스크톱 선택지로 제공되어 왔다. 그러나 MATE는 GNOME 2 계열 코드를 계승하는 방향이고 Cinnamon은 GNOME Shell 3 계열에서 출발했다. 비슷한 메뉴와 패널 배치가 곧 같은 내부 아키텍처를 뜻하지는 않는다.^[171][172]

Cinnamon은 CJS와 JavaScript 셸, Muffin을 연결하며 Nemo와 자체 설정 서비스를 결합한다. MATE는 다른 패널·창 관리와 파일 관리 구성 요소를 사용한다. 동일한 배포판이 두 환경에 같은 테마와 기본 앱을 조합해도 셸 내부 확장과 설정 API는 공유되지 않는다.

선택의 차이를 단순히 외형이나 가벼움 한 가지로만 설명할 필요는 없다. 사용자가 원하는 창 전환, 패널 설정, 접근성과 지원 하드웨어, 배포판의 유지보수와 설치 앱이 모두 영향을 준다. 메모리와 반응성 비교도 같은 앱·해상도·효과·서비스 구성을 맞춘 뒤 해야 하며 배포판 이름만으로 수치를 정할 수는 없다.

Cinnamon의 애플릿과 Extension을 MATE의 패널 애플릿처럼 설치하거나 그 반대로 사용할 수 있다고 가정해서는 안 된다. 반면 웹 브라우저와 문서 편집기 등 일반 앱은 데스크톱 표준과 툴킷 기반으로 함께 사용할 수 있다. 데스크톱 내부 확장과 독립 실행 앱의 이식성을 구분하는 것이 두 환경의 관계를 설명하는 핵심이다.

Xfce

Xfce와 Cinnamon은 모두 패널·메뉴·파일 관리자와 일반적인 창 조작을 제공하지만 구성 방식이 다르다. Cinnamon은 Muffin과 CJS 기반의 셸 통합을 중심으로 설명할 수 있고, Xfce는 패널·창 관리자·파일 관리자 등 분리된 구성 요소의 조합을 강조하는 환경이다. 둘의 기본 화면을 비슷하게 구성해도 내부 확장 인터페이스와 설정 경로는 별개다.^[173][174]

Cinnamon의 패널은 JavaScript 애플릿과 xlet 설정 체계를 사용하며 창 목록의 동작도 해당 API에 연결된다. Xfce의 패널 플러그인을 같은 종류의 파일로 취급하여 Cinnamon에 추가할 수 있는 것은 아니다. 파일 관리자의 문맥 메뉴와 플러그인 역시 각 프로젝트의 구현에 따른다.

Linux Mint가 두 환경을 별도 에디션으로 제공하는 것은 같은 패키지 기반과 Mint 도구를 다른 데스크톱 구성에 결합할 수 있음을 보여 준다. 운영체제의 저장소·업데이트 정책과 데스크톱 셸을 분리해 비교하면 어떤 차이가 Cinnamon 자체에서 오는지, 기본 앱과 서비스에서 오는지 구별하기 쉽다.^[175]

자원 사용은 데스크톱 이름 외에도 합성 효과, 애플릿 수와 갱신 주기, 해상도·모니터 수, 시작 프로그램과 드라이버에 영향을 받는다. Cinnamon에 많은 정보 애플릿을 설치한 구성과 최소한의 다른 데스크톱을 비교하는 것은 셸 구현만의 비교가 아니다. 실제 측정 조건을 함께 제시하는 방식이 적절하다.

KDE Plasma

KDE Plasma는 Qt·KDE Frameworks를 중심으로 셸과 위젯을 구성하고 KWin 계열의 창 관리·합성과 결합하는 데스크톱 환경이다. Cinnamon은 CJS와 GObject 계열, Muffin을 중심으로 다른 소프트웨어 계층을 사용한다. 패널·앱 메뉴·위젯과 사용자화 기능이라는 공통된 개념이 있어도 구체적인 구현과 API는 독립적이다.

Cinnamon의 Spices와 Plasma의 위젯은 서로 같은 패키지 체계를 사용하지 않는다. Cinnamon의 xlet 설정 API와 JavaScript 모듈을 사용하는 확장을 Plasma에 그대로 올릴 수 있다고 볼 수 없으며, 반대 방향도 마찬가지다. 테마 역시 적용 대상과 스타일 시스템이 달라 이름이나 외형만으로 호환성을 판단하지 않는다.^[176][177]

일반 응용 프로그램은 다른 문제다. Cinnamon에서 Qt 앱을 실행하거나 Plasma에서 GTK 앱을 사용할 수 있으며, 앱 실행 가능성과 테마·파일 선택·알림 등의 통합 수준을 구분해야 한다. 데스크톱이 사용하는 주 툴킷이 모든 응용 프로그램에 같은 툴킷을 강제한다는 뜻은 아니다.

비교에서는 창 관리 정책, 기본 작업 흐름, 설정의 범위와 확장 방식, 실제 세션 기능을 각각 살펴야 한다. 어느 환경의 기능이 더 많다는 단일한 표현보다 사용자가 필요한 기능이 어떤 모듈과 설정으로 제공되는지 보는 편이 구체적이다. 그래픽·입력·화면 공유 지원도 각 합성기와 배포판의 버전을 기준으로 설명해야 한다.

Budgie

Budgie는 패널과 애플릿을 활용하는 독립적인 데스크톱 프로젝트로, GNOME 계열 기술과 연결된 역사를 가진다는 점에서 Cinnamon과 함께 언급될 수 있다. 그러나 Cinnamon의 하위 변형이나 동일한 셸 코드의 배포판별 테마로 취급할 수는 없다. 두 프로젝트는 별도의 셸 구현과 개발·릴리스 경로를 가진다.

패널 중심의 기본 화면은 사용자에게 익숙한 작업 방식을 제공하지만, 그 안에서 메뉴·상태 표시·창 관리·알림을 결합하는 방법은 다르다. Cinnamon의 애플릿은 Cinnamon의 모듈과 xlet 설정을 이용하고, 다른 셸의 애플릿은 그 셸이 제공하는 인터페이스를 이용한다. 같은 JavaScript나 GNOME 라이브러리와 관련된 기술이 쓰였다는 사실만으로 확장 호환성이 생기지는 않는다.^[178]

일반 앱과 데스크톱 자체를 분리해서 보면 두 환경에서도 공통 앱을 사용할 수 있지만, 패널 위젯과 설정 도구는 각 환경을 따른다. 배포판의 기본 테마와 프로그램 구성이 외형 차이의 일부를 만들기도 하므로, 화면 사진만 보고 모든 기능과 구현 차이를 판단하기는 어렵다.

프로젝트의 그래픽 기반과 개발 방향은 독립적으로 변할 수 있다. 따라서 Budgie의 특정 버전에서 일어난 변화가 Cinnamon의 현재 기능을 설명하는 근거가 되거나 그 반대가 되지는 않는다. Cinnamon 문서에서는 공통된 사용자 인터페이스 개념과 역사적 기술 관계를 설명하되, 기능별 상태는 Cinnamon의 해당 버전과 구성 요소를 기준으로 다룬다.

Cinnamon은 GNOME 3 전환 이후 전통적인 메뉴·패널·창 목록 중심의 작업 방식을 독립적인 데스크톱으로 지속시킨 사례다. 사용자의 기본 조작 방식을 유지하면서 합성 창 관리와 확장 체계, 현대적인 JavaScript 실행 환경을 결합했다. Linux Mint의 대표적인 사용자 경험을 형성하는 동시에 다른 배포판에서도 패키징되는 데스크톱으로 발전했다.^{[179][180][181]}

설계상 특징은 익숙한 기본 화면과 상세한 설정을 함께 제공한다는 데 있다. 패널 영역별 아이콘·글꼴, 창 목록의 클릭·휠·미리 보기, 포커스와 창 배치, 최근 파일 기록과 Spices의 인스턴스 설정이 구체적으로 나뉜다. 사용자가 기본 배치를 그대로 사용할 수도 있고 작업 방식에 맞추어 여러 층의 동작을 조절할 수도 있다.^[182][183]

Spices는 사용자화의 범위를 넓히지만 셸 내부 코드와 API의 안정성도 중요한 과제로 만든다. 테마만 바꾸는 설정과 사용자 세션에서 실행되는 확장을 같은 위험·호환성 범위로 볼 수 없으며, 공식 검토 절차와 작성자의 유지보수가 함께 필요하다. Nemo Action처럼 파일을 직접 다루는 확장에서는 경로와 URI, 선택 조건·의존 프로그램까지 기능 설명에 포함되어야 한다.^[184][185]

Wayland 전환은 외형을 유지하면서 내부 구조를 계속 발전시키는 특성을 보여 준다. 화면 캡처와 자체 녹화, 외부 공유, 잠금·입력기·배율은 서로 다른 경로로 구현되므로 단순한 지원 여부로 묶기 어렵다. 6.6 유지보수와 6.7 개발 기록을 구분하면 이미 배포된 동작과 새 구현의 상태를 함께 설명할 수 있다.^[186][187]

성능과 안정성은 셸뿐 아니라 하부 그래픽 스택, 해상도·모니터, 설치된 애플릿과 기본 앱에 영향을 받는다. 이 문서의 기능과 구조 설명은 특정 배포판·하드웨어에서의 벤치마크나 모든 사용자 환경의 동일한 결과를 뜻하지 않는다. Cinnamon의 평가는 전통적인 UI라는 외형, 독립된 구성 요소의 설계, 실제 배포판의 통합과 사용자가 선택한 확장을 함께 고려하는 방식으로 이루어질 수 있다.

• 데스크톱 환경
• Linux Mint
• Linux 배포판
• Linux
• Debian
• Ubuntu
• Fedora
• Arch Linux
• C (프로그래밍 언어)
• JavaScript
• Python