| 211 | | * user. The prompt may choose to ignore this information or use it in whatever |
| 212 | | * way it sees fit. |
| | 211 | * user. The prompt may choose to ignore this information or use it in |
| | 212 | * whatever way it sees fit. |
| | 213 | * |
| | 214 | * Note that Gdk itself does not have a notion of window handles. The X11 |
| | 215 | * backend does allow some level of interprocess interaction via XIDs, and |
| | 216 | * so backend-specific code may use XIDs converted to strings as the |
| | 217 | * value of caller-window; note that both the caller and the prompt |
| | 218 | * implementation must conform to this convention. Alternately, utility |
| | 219 | * functions gcr_prompt_util_mock_id_of_window and |
| | 220 | * gcr_prompt_util_window_of_mock_id are provided in gcr-prompt-dialog.h |
| | 221 | * so that this facility can be used at least within a single process |
| | 222 | * regardless of the backend. |
| | 223 | * |
| | 224 | * There does not appear to be any reasonable way to allow interprocess |
| | 225 | * interaction via window handles in some Gdk backends, e.g. the quartz |
| | 226 | * backend. |
| | 227 | * |
| | 228 | * All uses of caller_window within the gcr library write XIDs if the X11 |
| | 229 | * backend is in use and otherwise write mock handles; and conversely, when |
| | 230 | * reading a handle, first try to interpret it as an XID and failing |
| | 231 | * that as a mock handle. Note that the mock handles are designed so that |
| | 232 | * they can never accidentally appear to be XIDs. |
