![]() Unlike the MapRequest event, the UnmapNotify event is delivered to the window manager after the fact, and the window manager can only respond to it, not intercept it.Ī reparenting window manager will typically want to reverse the actions it performed in response to MapRequest. hides) a window with XUnmapWindow(), for example in response to the user exiting or minimizing the application, the window manager will receive a UnmapNotify event. In window_manager.cpp: void WindowManager::Run() However, a newly created window is always invisible, so there’s nothing for our window manager to do. When an X client application creates a top-level window ( XCreateWindow()), our window manager will receive a CreateNotify event. With that in mind, let’s dive into the implementation by looking at how our example window manager will handle the life cycle of a client window from creation to destruction. The window manager can respond to such events, but of course cannot change the fact that they have already happened. On the other hand, events with the Notify suffix represent actions that have already been executed by the X server. If the window manager does nothing, the request is implicitly denied. It is important to understand that when a window manager receives such an event, the action it represents has not actually occurred, and it is the responsibility of the window manager to decide what to do with it. Such requests are delivered to a window manager as events with the Request suffix. Recalling our discussion in Part I on substructure redirection, when a client application wants to do something with a window (such as moving, resizing, showing, or hiding), its request is redirected to the window manager, which can grant, modify, or deny the request. This distinction is crucial to our discussion. You may have noticed that some of the events in this diagram have the suffix Request, while others have the suffix Notify. A window manager communicates with client applications via events, which are represented as parallelograms in red. In this diagram, actions initiated by client applications are shown in the yellow box on the left hand side, and actions initiated by users are shown in blue on the right hand side. In general, a window manager must handle two kinds of actions: those initiated by client applications (such as creating new windows), and those initiated by users (such as moving or minimizing windows). You can click through for the full-sized diagram. We’ll be referring to this cheat sheet for window manager event handling throughout this series. To facilitate our discussion, I’ve created a diagram that illustrates the flow of events throughout the lifetime of a client window, and how a window manager might respond to each of them. The interaction between clients, X, and the window manager is fairly complex. Our next step is to start talking to clients and the user via events. Step 4: Interaction with Application Windowsįollowing the steps in Part II of this series, we now have a basic skeleton for our window manager. We will review the fundamentals of window manager implementation, using the implementation in our example non-compositing reparenting window manager, basic_wm, for reference. ![]() In Part III, we will start interacting with client windows and the user through events. In Part II of this series, we discussed X libraries and implementation choices, and examined the basic structure of a window manager. ![]() ![]() Window Manager Technical Notes How X Window Managers Work, And How To Write One (Part III). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |