For most users of the Elementary API, the Elm_Win widget has a lot more functions than what they need.
In general, a developer will create a window, set some content on it and forget about it for the rest of its program's life, letting whatever Window Manager is there to handle the window. Here, however, we are going to show how to generally manage a window.
We'll have a bit more than the usual includes here, since part of the example requires some low level fiddling.
The program then, consists of one window with two lists of buttons, each of which operates on another two windows. One of them is a normal window, the other has the override
flag set so the Window Manager ignores it.
Pressing each button will call the corresponding function to act on the corresponding window. These are pretty self explanatory, so we'll show them in one batch.
Next, we handle the main window closing. We have a "delete,request"
callback set to ask if really want to quit. If so, we end the main loop, otherwise just delete the popup message and continue running normally.
The non-managed window, being completely ignored by the Window Manager, is likely to never receive keyboard focus, even if we click on its entry to write something. So we have a button on it that will forcefully focus it by using some lower level functions to act directly on the X window. Then, each time one of the window is focused, we print some message on a console to show this more clearly.
And to finalize, the main function creates a window to hold all the action buttons and another two to show how (and what) works on each of them.
First, the main window will be a normal window, we'll enable the focus highlight regardless of how it is configured so it's easier to navigate the window with the keyboard. Then we hook our focus and delete callbacks and set up the rest of the window's content.
The first of our sub-windows is the managed one. We'll create it as a dialog, which should make the Window Manager treat it as a non-resizable window. We are also setting the window to be auto-deleted when the close button in the titlebar is pressed.
Now, we added an icon to the window as a resize object. We also set this icon to not scale, and no weight size hints have been set for it. This way, even if we hadn't created the window as a dialog, it would still not be resizable. The window size is defined by its content, so it would never be smaller than the smallest of its resize objects, and for it to be resizable, all of those objects have to allow it.
Next, we add the buttons with the actions to perform on this window. Using a macro saves us typing and makes the world a happier place.
The maximize one is likely to not work, because the Window Manager will probably not enforce it upon a window that states its maximum size, much less a dialog. But that can be changed by editting the example to use ELM_WIN_BASIC when creating the window and adding the following line to the icon set as content
Lastly, the second sub-window will have it's override flag set. In it we have a label with some text, and entry and a button. The entry can be clicked normally to set focus on it, but whether it actually gets keyboard input will also depend on the window getting focus, and since the window is an override one, it will probably not gain it by normal means. The button is there to force the focus at the X level to go to our window. And to finish, another list of buttons with actions to perform on this last window. Remember that most of them are requests or hints for the Window Manager, so they are likely to do nothing on this window. Similarly, there won't be any way to move it or resize it, because we haven't implemented that kind of control on this example and that's something controlled by Window Managers on windows they are tracking, which is not the case with this one.
The full code listing of this example can be found at win_example.c.