어쨌든 맨손 프로토콜 수준 API로 수행하려는 작업이 아닙니다. 풍부한 GUI를 원한다면, 모든 어려운 작업을 수행하는 툴킷을 사용하십시오. Xlib/XCB는 오히려 단순한 창에서 잘 작동하는 기본 도구 만 제공합니다. 심지어 나는 카이로와 같은 것을 사용하지 않고 프로젝트를 시작하지 않을 것입니다.
물론 창문으로해야 할 일이 많지만, 창을 만들고 표시하는면에서 그렇습니다.
X 서버는 프로세스에 대해 상관하지 않는다 통지되어 있다고 가정 할 수 있습니다. 응용 프로그램
?
응용 프로그램을 창 관리자와 독립적으로 실행하면 안됩니까?
글쎄, 맞아.하지만 현실적으로 윈도우 매니저의 수명은 X 서버의 수명과 같습니다. 사람들은 보통 윈도우 매니저를 바꾸지 않습니다. X 서버가 없으면 모든 X 클라이언트가 사라집니다.
이론적으로 완전히 독립적입니다. 그러나 현실은 그러한 구분을 할 실질적인 이유가 없다는 것입니다. 즉, 창 관리자가 종료 되더라도 분기 된 프로세스가 그대로 유지되도록 응용 프로그램을 시작하는 몇 가지 방법을 제공하는 모든 창 관리자가이를 포크하고 있습니다.
나는 창 관리자의 소스 코드를 많이 읽었으며 초보자라고 불렀지 만 응용 프로그램이 자신의 창을 그리는 방법과 직접적인 관련이있는 것은 아무것도 보지 못했습니다.
왜냐하면 창 관리자는 렌더링 창과 관련이 없기 때문입니다. 창 관리자는 창은 존재하고 추상 속성을 관리한다는 것을 알고 있지만 모든 창 관리자가 알고있는 창은 몇 가지 속성이있는 사각형입니다.
실제로 윈도우에 렌더링하는 것은 X 클라이언트가 X 서버에서 직접 수행하는 것입니다.
일반적으로 창 관리자가 참여하는 렌더링 유형 중 하나는 장식 렌더링 (창 테두리 및 제목 등)입니다. 그러나 창 관리자는 단지 X 클라이언트이기 때문에 이와 관련하여 뭔가 다른 것을 렌더링하는 응용 프로그램입니다 (일반적으로 창 관리자는 이러한 장식을 자신이 만든 프레임 창 (소위 창 관리자 창 관리자)으로 렌더링합니다. 첫 번째 주석 후
업데이트 : (창을 만들려고합니다) X 클라이언트는 X 서버에 이러한 요청을 (/지도 창을 만들 수) 보냅니다. X는 이런 일이 어떻게 일어나는지 여러 구현을 제공합니다. 오늘날 리눅스 시스템에서 가장 일반적인 경우는 유닉스 소켓입니다.
X에는 클라이언트가 선택할 수있는 여러 이벤트가 있습니다. 이러한 이벤트 유형 중 하나는 하위 구조 리디렉션입니다. 즉, 클라이언트가 X 서버에 일부 창, 예를 들어 하위 창을 생성 할 때마다 통보하도록 요청할 수 있음을 의미합니다.
루트 창은 단지 하나의 창이지만 항상 존재하며 닫을 수 없다는 것과 같은 고유 한 속성이 있습니다. 하나의 X 클라이언트 만 루트 창에서 하위 구조 리디렉션을 선택할 수 있습니다. 이렇게하면 창 관리자가 창 관리자가됩니다.
이제 루트 윈도우 (우리의 WM)에 하위 구조 리디렉션을 사용하는 X 클라이언트가 생겼습니다. 이제 클라이언트가 윈도우를 매핑하도록 요청할 때마다 X 서버는 (MapRequestEvent를 통해)이 요청을 윈도우 관리자 클라이언트로 리디렉션하고 거기서 멈추게됩니다. 만 예외는 창 관리자 자체에서 오는 맵 요청입니다. X 서버가 처리합니다 (모든 영원을 위해 창 관리자와 핑퐁을 재생하지 않기 위해).
이것은 기본적으로 개입 루프를 설정합니다. 클라이언트 요청 X 서버는 창을 맵핑하고, X 서버는 창 관리자에게 요청을 전달하고, 창 관리자는 창에 대한 맵 요청을 서버로 다시 보내도록 선택할 수 있으며, 서버는 맵 요청은 창 관리자에서 왔기 때문에
그리고 그게 전부입니다. 이것이 윈도우 매핑의 방법입니다.
내 창 관리자는 창 만들기 및 매핑시기를 어떻게 알리는가?
창 관리자는 클라이언트에게 수행 할 작업을 지시하지 않습니다. 고객이 원하는 것을 어떻게 알 수 있습니까? 그것은 반대입니다. 클라이언트는 물건을 만들고 창 관리자는 개입하고 반응합니다 (어떤면에서는 창 관리자가 결코 X 서버를 완전히 제어 할 수 없습니다).
사건 루프를 만들 필요가 있습니까 (X 서버에서 창을 생성하라는 요청이있는 곳)?
위에서 설명한 바와 같이, 창을 생성 할 시점을 결정하는 것은 클라이언트에게 달려 있습니다. 하지만 그렇습니다. X 클라이언트의 핵심 개념은 이벤트 루프를 설정해야한다는 것입니다.
예를 들어 창을 매핑하는 경우 : 클라이언트가지도 요청을 보내고 창 관리자가 요청 거부를 선택할 수 있기 때문에 창을 매핑해야한다고 생각해서는 안됩니다. 클라이언트는 자신의 윈도우가 매핑되었다는 것을 알고 있습니다. X 서버가 발생하면 MapEvent를 만들어 클라이언트에 전송하기 때문입니다.
창 관리자는 클라이언트의지도 요청을 거부 할 수있을뿐만 아니라 클라이언트의지도 요청을받지 못한 창도지도로 표시 할 수 있습니다. 따라서 클라이언트는 항상 이러한 이벤트를 기다려야하고 창 중 하나가 매핑 된 경우 그에 따라 대응해야합니다.
클라이언트에게 중요한 이벤트가 많이 있습니다. 특히 클라이언트에게 윈도우의 일부분을 다시 그려야한다고 알리는 Expose 이벤트가 있습니다.
응답 해 주셔서 감사합니다. 나는 아직도 당신이 다른 프로세스가 창을 띄울 곳을 어디에서 그리고 어떻게 창출 하는지를 보지 못하고있다. 이것은 내가 알고있는 두 가지 기능을 언급했지만 윈도우를 만들 때 어떻게 알 수 있을까? 정말 뒤에있는 과정을 이해하려고합니다. 응용 프로그램을 실행하면 해당 응용 프로그램에 대한 창이 만들어집니다. 내 창 관리자는 창을 만들고 맵핑 할시기를 어떻게 알 수 있습니까? 분명히 어떤 종류의 IPC가 관련되어야합니까? 사건 루프를 만들 필요가 있습니까 (X 서버에서 창을 생성하라는 요청이있는 곳)? – oldjohn1994
@ oldjohn1994 의견에 맞지 않으므로 추가 설명으로 답변을 수정했습니다. –
창 관리자가 X에서 작동하는 방식에 대한 잘 설명 된 설명도 찾을 수 있습니다. https://seasonofcode.com/posts/how-x-window-managers-work-and-how-to-write-one-part -i.html –