Re: Modality changes proposal

[Lubos Lunak <l lunak suse cz>]

On Wednesday 08 of October 2003 17:33, Denis O. Mikhalkin wrote:
> On Wed, 2003-10-08 at 16:37, Lubos Lunak wrote:
[snip]
> > > Practical example: developer has a group of windows, then shows modal
> > > dialog for this group, then shows some more windows(they won't be
> > > blocked), then he shows another modal dialog for the group which is
> > > child of previous modal dialog. Right now: there is no way to have this
> > > dialog a child, and actually, there is no way to create such a modal
> > > dialog in _NET, but it is possible to do it on other platforms, WMs and
> > > protocols.
> >
> >  This description looks a bit ambiguous to me, so let's guess:
> >
> >  A A A   B B
> >  \ | /  /   /
> >    C
> >
> >    D
>
> Hmm, to me what I wanted looks like this:
> (I use numbers to show layer in terms that I described in the proposal)
> 0 A A A
> 1   C
> 2 B B B
> 3  D
> So D is above all other windows, Bs are above C and As, C is above As. C
> and D are modal, As and Bs are just regular windows. That's what we
> NEED. Note also that the picture needs to be looked at  sequentially -
> first only windows at 0 layer, then windows of layer 1 are added and so
> on. Think it is possible to do it in a current specification?

 Interesting. I don't remember ever seeing windows created like this. But it 
still doesn't prove in any way that modality and transiency relationships are 
something different. C will be transient for A's group, B's will be transient 
for C, D will be transient for B's. Sure, it may require extending 
WM_TRANSIENT_FOR, but that's about it.

> > > > [Snipped something quite long and complicated.]
> > > >
> > > >  Do you have any real application that actually needs that? I'd like
> > > > to see the reasons for this in practice.
> > >
> > > The actual application is Java API. In Java API it is possible to
> > > create
> >
> >  Well, I don't know Java API.
> >
> > > hierarchies, and to set some of the windows to be modal. We have
> > > requests from the people for having mixed modalities, and to have them
> > > working consistently across platforms. Everything people ask from us is
> > > possible to implement on Windows and impossible on Linux.
> > >
> > > The complexity comes from the fact that in one process several Java
> > > application can be run. Each of the application might want to show
> > > modal dialog - so groups are necessary. Application might want to show
> > > several modal dialogs, all are group-wide, so here comes the need for
> > > layers, right now only ONE group-modal dialog actually works. Some
> > > applications like to have also parent-modal dialogs, for quick and
> > > temporary requests - so here comes the need for correctly mixing
> > > group-wide and
> > > parent-wide.
> >
> >  We already have way to specify parent-modal and group-modal dialogs,
> > with parent and group transiency. I'd say it even works with KDE3.2 KWin.
> > Not that I know any real application using such complicated relations
> > with which I could test it.
>
> Java could be the one, but until I am 100% sure that all _NET WMs
> implement modality similarly and that every situation when parent
> modalities are mixed with group modalities they work equally I don't
> think we'll risk using them both - we need to make sure it works on all
> platforms, on all WMs equally.

 Well, I'm afraid making all WMs out there perfect is scheduled only for year 
2043. No wait, it's actually 2072. Until then, we all have to live with the 
fact that nothing is perfect. If you e.g. look at http://sweb.cz/tripie/
utils/wmctrl/ , you can see that some even quite widely used WMs have poor 
support for this spec, if at all. What makes you think they'll suddenly get 
better, as soon as your modality proposal makes it into the standard?

 What matters on this list is whether something is possible with the 
specification or not, if some WMs don't implement it, don't blame the 
specification. The attached small app models your example according to the 
spec. Ok, there's the small documented ICCCM violation with the root 
transiency, and instead of the group it would be possibly better with 
WM_TRANSIENT_FOR pointing to several windows, but it tells me transiency is 
enough, and that there's no need for any special modality relationships.

 (Actually the practice differs a bit from theory, as the attached test app 
doesn't work perfectly in any of the few WMs I tried. But I guess that's just 
fault of the WMs).

> > > There is a system controlling application, which sometimes
> > > needs to block the input for the whole process - so here comes client
> > > modal dialog.
> >
> >  Yes, I think there's no way how to specify modality for the whole
> > application, if it has several window groups.
>
> So do you agree that it might be reasonable to add it to _NET? Think it
> can be done the way I proposed or do you see a better way?

 Well, yes, I think we could add that.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/

#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/Xatom.h>

#define SET_MODAL

Display* dpy;

Window create_window( Window group, Window transient_for, int type )
    {
    XSetWindowAttributes attrs;
    Window w = XCreateWindow( dpy, DefaultRootWindow( dpy ), 0, 0, 100, 100, 0, CopyFromParent, CopyFromParent,
        CopyFromParent, 0, &attrs );
    XWMHints hints;
    hints.flags = WindowGroupHint;
    hints.window_group = group != None ? group : w;
    XSetWMHints( dpy, w, &hints );
    if( transient_for != None )
        XSetTransientForHint( dpy, w, transient_for );
#ifdef SET_MODAL
    static Atom state = XInternAtom( dpy, "_NET_WM_STATE", False );
    static Atom modal = XInternAtom( dpy, "_NET_WM_STATE_MODAL", False );
    Atom data[ 1 ] = { modal };
    XChangeProperty( dpy, w, state, XA_ATOM, 32, PropModeReplace, (unsigned char *) data, 1 );
#endif
    if( type != 0 )
        {
        static const int col[] = { 0, 0x00ff, 0xff00, 0xffff, 0x8000 };
        XSetWindowBackground( dpy, w, col[ type ] );
        XMapWindow( dpy, w );
        XSelectInput( dpy, w, KeyPressMask );
        }
    return w;
    }

int main( int argc, char* argv[] )
    {
    dpy = XOpenDisplay( NULL );
    Window groupA = create_window( None, None, 0 );
    /*Window A1 =*/ create_window( groupA, None, 1 );
    /*Window A2 =*/ create_window( groupA, None, 1 );
    /*Window A3 =*/ create_window( groupA, None, 1 );
    Window C;
    Window groupB;
    Window B1, B2, B3;
    Window D;
    int mode = 0;
    for(;;)
        {
        XEvent ev;
        XNextEvent( dpy, &ev );
        if( ev.type == KeyPress )
            {
            switch( ++mode )
                {
                case 1:
                    {
                    C = create_window( groupA, DefaultRootWindow( dpy ), 2 );
                    break;
                    }
                case 2:
                    {
                    groupB = create_window( None, None, 0 );
                    B1 = create_window( groupB, C, 3 );
                    B2 = create_window( groupB, C, 3 );
                    B3 = create_window( groupB, C, 3 );
                    break;
                    }
                case 3:
                    {
                    D = create_window( groupB, DefaultRootWindow( dpy ), 4 );
                    break;
                    }
                }
            }
        }
    XCloseDisplay( dpy );
    }