[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sheets in GNUstep

From: Fred Kiefer
Subject: Re: sheets in GNUstep
Date: Sat, 21 Mar 2015 19:49:29 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

Am 21.03.2015 um 16:26 schrieb Fred Kiefer:
> Am 20.03.2015 um 19:59 schrieb Eric Wasylishen:
>> Just to give my 2c: the EWMH spec has window-modal dialogs:
>> "_NET_WM_STATE_MODAL indicates that this is a modal dialog box. If the
>> WM_TRANSIENT_FOR hint is set to another toplevel window, the dialog is
>> modal for that window; if WM_TRANSIENT_FOR is not set or set to the root
>> window the dialog is modal for its window group." -
>> http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html
>> Not sure how widely that is implemented in WM's. But I'd vote for
>> keeping sheets as windows in the backend, and passing the information to
>> the backend that it is a sheet and which window is the parent.
>> There would still need to be emulation of "window-modalness" in gui
>> since not all WM's (including win32) will implement it.
>> I'm not sure how close this is to what we currently have!
> In GNUstep back we already use WM_TRANSIENT_FOR via XSetTransientForHint.
> We also define an atom new_wm_state_modal_atom (mistype for
> net_wm_state_modal_atom) for _NET_WM_STATE_MODAL, but don't seem to be
> using this state. It looks like you added that four years ago, but
> didn't get around to put any functionality behind it. I will try to use
> this (renamed) feature in orderWindow::: and see how the result behaves
> on my KWM. If it isn't worse than before I will commit the change for
> others to test.

I completely failed with this attempt. My window manager doesn't even
report the new state for the window. I committed it anyway for others to
try out.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]