#Viewkit sgi book how to
#Viewkit sgi book update
#Viewkit sgi book code
#Viewkit sgi book windows

#Viewkit sgi book how to

“Handling the Window Manager Delete Window Protocol” describes how to implement these handlers.Īnother complication is that the initial values of the XmNargv and XmNargc resources are stored in the application's invisible main window rather than a visible window. To avoid this, you must set each window's XmNdeleteResponse resource to XmDO_NOTHING, and then explicitly handle the window manager's WM_DELETE_WINDOW protocol for each window. One complication when using ApplicationShells is that by default, IRIS IM automatically quits an application when it destroys an ApplicationShell.

#Viewkit sgi book windows

(Another option would be to use TopLevelShells for the visible windows and then explicitly create and set WM_COMMAND and WM_MACHINE properties on the windows.) Then you can set the XmNargv and XmNargc resources on any of them. Because your application's visible windows can be created and destroyed dynamically, you should use ApplicationShells rather than TopLevelShells for your visible windows. Session management requires a realized ApplicationShell widget so that your application can store restart information in its XmNargv and XmNargc resources. You can then create the visible co-primary windows as popup children of this invisible shell. Instead, the best solution in this case is to leave the ApplicationShell returned by XtAppInitialize() unrealized. Presumably, the visible windows can be created and destroyed in any order therefore it is very difficult to use one as a main window and have the others be children of it. This model requires more careful consideration than the other models. Implementing the “Multiple Document, No Visible Main” Model “Session Management” in Chapter 3 of the Indigo Magic User Interface Guidelines provides further guidelines for handling session management. “Handling the Window Manager Save Yourself Protocol” describes what your application needs to do to support session management. XmAddWMProtocolCallback( toplevel, WM_SAVE_YOURSELF, WM_SAVE_YOURSELF = XmInternAtom( XtDisplay(toplevel), Label = XmCreateLabel(toplevel, “saveme”, NULL, 0) Toplevel = XtAppInitialize(&app_context, “SaveYourSelf”,

#Viewkit sgi book update

Printf(“Update state file if needed, then update WM_COMMAND ”) Void saveYourSelfCallback(Widget w, XtPointer client_data, * cc -o saveyourself saveyourself.c -lXm -lXt */

#Viewkit sgi book code

* Example code for handling the window manager's */ Session Management Example Code: saveyourself.c Also, users can launch this control panel from the Icon Catalog's Control Panel page.Įxample 5-1. A user can select explicit, and then press the “Set Home Session” button to save the (current) explicit window configuration. The “Save Windows & Desks” item on the Window Settings Control Panel configures either continuous or explicit session management. From the Toolchest, open the Desktop menu, select “Customize,” and then select “Windows.” The Windows Settings dialog box appears (see Figure 5-1). They can launch this panel via the Toolchest. Users can configure the windows on the desktop by using the Window Settings Control Panel. This is the default setting.Įxplicit session management ignores the windows that were open when the user last logged out and always opens a particular set of windows that the user has chosen. Continuous session management restarts the applications that were running when the user last logged out of the window manager.

The two types of session management include continuous session management and explicit session management. Types of Session Management: Continuous and Explicit You can support this either by providing command-line options to your application or other mechanisms such as a state file that your application reads when it is launched. To support this, you need to design your application so that when the 4Dwm session manager restarts it, it can redisplay any of its co-primary or support windows that were open when the user logged out, reopen any data files that were open, and so on. The 4Dwm window manager keeps a list of the applications and desks that were previously running when the user last logged out and restarts them when the user logs in again.įor your application to be restarted via the 4Dwm session manager, the application must register its initial state with the session manager and make sure the current state is registered at all times.Īdditionally, your application should restart in the same state it was in when the user logged out (for example, the same windows open, the same files open, and so on). Session management allows users to log out, and any applications that are running at logout automatically restart when they log back in.