Re: NotifyUngrab handling

[Felix Bellaby <felix pooh u-net com>]

Owen Taylor writes:
 > Felix Bellaby <felix@pooh.u-net.com> writes:
 > [...]
 > > The problem with doing this is that the menu item selected by the
 > > user to pop down the menu might popup a non-modal dialog which
 > > obscures a dialog generated by another client in response to an
 > > Interact request. (Am I right in thinking that this could happen
 > > under gtk ?). The user would then have to move the offending dialog 
 > > out of the way in order to continue and might easily get the 
 > > impression that the Xserver has frozen.
 > 
 > I don't think this is much of a problem, since user interaction
 > should be rare under most conditions. (The interact_style
 > should be SmInteractErrors unless the user explicitely requested
 > the checkpoint, and if the user requested the checkpoint, he
 > most likely doesn't have another menu up.

I admit this is a rare problem. (:

However, auto-saves might be useful on some systems and I did not 
want to leave a nasty hole with the error dialogs they might produce.

 > Also, the serialization
 > of interact requests makes interaction enough of a pain, that
 > I suspect most apps won't bother)

Carsten and I have tried to make interaction easy for gnome-libs 
clients. The following test code produces two dialogs on the screen 
during the interaction stage in a "save_yourelf" handler (unless 
the style prohibits one or both from being shown):

  GtkWidget *dialog = gnome_dialog_new ("My App", "Save Files", NULL);
  GtkWidget *dialog2 = gnome_dialog_new ("My App", "Save Config", NULL);

  [...]

  gnome_client_save_any_dialog (client, GNOME_DIALOG (dialog));
  gnome_client_save_error_dialog (client, GNOME_DIALOG (dialog2));

You can fill out these dialogs with whatever widgets you choose
and respond to user events using gtk signal handlers. The gnome-libs 
present the dialogs to the user in the order that they were passed
to gnome_client_save_*_dialog() and gnome-session avoids interspersing 
the dialogs for different clients in between each other.

I strongly encourage apps to check what the user wants to save during 
a session shutdown. Doing this properly should reduce the need to 
worry about what is being saved at other times. 

Users should be able to logout and login in the full confidence that 
they will be safely returned to exactly where they were previously.

 > But it does point out a few fine details that are probably
 > worth being noted somewhere:
 > 
 >  - The window manager should not freeze itself, or at least
 >    not until the "phase 2" save-yourself that it is supposed
 >    to request.
 >
 >  - Interaction windows should get the appropriate GNOME wm
 >    hint to put them in a layer over all normal application
 >    windows. 

The second suggestion is a good point. I think that it solves
the problem I was worried about. I will implement this on the
gnome_client_save_*_dialogs and add in a wait to ensure that
gdk_pointer_is_grabbed() is false.

As a result, the WM should not need to grant the user the ability 
to move windows around and your first suggestion does not matter. 
Indeed, keeping the user glued to the interact window would be a 
good idea since it is the only one that can receive input. (:

Thanks,

Felix