Re: MODAL should not be a window state



On Saturday 10 March 2007 23:03, Dana Jansens wrote:
> Hello,
>
> I'd like to bring to light a misnomer in the current EWMH spec.
>
> The various _NET_WM_STATEs are for states that can be enabled and
> disabled on a window, typically by a user:
[snip]
> Modality is the only one in this list which does not change over the
> life of a window.
>
> How the major toolkits implement modality:
>
> QT 4.2: http://doc.trolltech.com/4.2/qdialog.html

Actually, modality is implemented at the widget level in Qt 
(http://doc.trolltech.com/4.2/qwidget.html#windowModality-prop)

> Again, modality is selected before the window is presented to the
> user, and is for dialog type windows.
>
> Can someone think of a situation where a window would change its
> modality while it is being used?

I can't remember the exact circumstances, but I have seen it happen (got a bug 
report about it). Applications tend to do strange things sometimes :)

> Also, it's clear from these API's that modality is expected to be used
> only on DIALOG typed windows. The EMWH already reinforces this notion:
> "_NET_WM_STATE_MODAL indicates that this is a modal dialog box." The
> MODAL state is clearly not meant to be used on other types of windows.
> According to past discussions in this forum, a DIALOG type window
> should be made transient for its entire group when the TRANSIENT_FOR
> property is not set. The MODAL state now specifies the same thing.

I don't think they specify the same thing, but that the MODAL state's 
definition depends on what WM_TRANSIENT_FOR is. The WM needs to know which 
windows are modally shadowed, and this is the WM_TRANSIENT_FOR window.

> I propose that _NET_WM_STATE_MODAL should be instead changed to be
> _NET_WM_WINDOW_TYPE_MODAL_DIALOG. This would not take away from the
> intended functionality of modal windows, nor how they are provided in
> toolkits and applications, and would provide a more consistant
> interface for toolkits and window managers alike to use.
>
> I realize that the _NET_WM_STATE_MODAL has been somewhat widely
> deployed, but in terms of applications it's really in two places, Qt
> and GTK. It would be okay to check if the window manager supported the
> new _NET_WM_WINDOW_TYPE_MODAL_DIALOG, and fall back to
> _NET_WM_STATE_MODAL, if people felt that was necessary.

Considering that we allow modality on any window type, I'm not too keen on 
this change. Perhaps I'm missing some deeper meaning, but it seems like 
you're just wanting to move the MODAL state into it's own window type, 
nothing more? If there was more behind the desire to change it (such as 
defining the semantics of a modal window/dialog), I'd certainly be willing to 
discuss it, though :)

-- 
Bradley T. Hughes - bhughes at trolltech.com
Trolltech ASA - Sandakervn. 116, P.O. Box 4332 Nydalen, 0402 Oslo, Norway



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