Re: Any more features?

[Owen Taylor <otaylor redhat com>]

Matthias Ettrich <ettrich@troll.no> writes:

> > But, my general feeling is that session-management issues
> > should be dealt with separately or left to a later version
> > of the spec. and I'd consider PING/PID/INSTANCE_ID
> > to be session-management issues.
> 
 
> I almost agree, apart from PING. What has PING to do with session
> management?  PING addresses the embarrassing fact that a ICCCM
> compliant window manager cannot offer a reasonable working close
> button to the user.
> 
> IMHO closing windows is one of the key issues in window
> management. Not addressing that in version 1 of the specs is a bit
> strange. I can't see how the PING protocol can be designed better or
> easier than what I proposed. If anybody has any ideas or arguments
> why my proposal is wrong or were the shortcomings are, I will be
> happy to delay the decision to a later version of the specs.

Well, as a fixup to the WM_DELETE_WINDOW protocol, it's reasonable.
Though there are things that it won't get right. There are basically
three classes of apps that aren't going to respond properly to
WM_DELETE_WINDOW:

 - Apps that are processing X events, and support the protocol,
   but are (due to poor design or a bug) are ignoring the message.

 - Apps that are hung up making X calls but not processing events.

 - Apps that are neither making X calls nor processing events.

Your proposal only catches the second, while I'd guess the
third is most common. (XKillClient is not going to kill a
program doing while (1);).

To handle all these cases well, you basically need a user-friendly
'top' ... something that will integrate the information from
the SM, the list of X clients, and whatever information is 
available from /proc (or equivalent) and give the user the chance
to see what is going on in more detail and make an informed
decision.  And that definitely is straying into SM territory.

So, perhaps I was thinking a bit ahead of your actual proposal,
which seems sound as far as it goes. And it certainly is 
easy to implement from the toolkit end.

Regards,
                                        Owen