Re: [gtk-list] Re: Ignoring keypresses

[Kevin Handy <kth srv net>]

If you really need to deiconify it, wouldn't it be better to de-iconify
it, 
but don't make it the current window? Then you don't have to eat some
users work, forcing him to go back to his window and try to type it in
again, only to have another window pop up and eat it again.

I personally hate the MS-Windows usual procedure of popping up windows 
at random times while I'm doing something completely  unrelated to 
the pop-ups, then eating all my keystokes and selecting options
based on what I was trying to type into a word processing document.

Anders Melchiorsen wrote:
> 
> Havoc Pennington <hp@redhat.com> wrote:
> 
> > Anders Melchiorsen <and@kampsax.dtu.dk> writes:
> > > Is there a better way to achieve the effect that I want?
> > >
> >
> > I think the moral of the story is, "deiconifying your app without the
> > user expecting it is a bad idea."
> >
> > Maybe you should pop up just a dialog, that says "application needs
> > attention, would you like to deiconify it?"
> 
> This is an instant messaging system. If the user said he wanted the
> window deiconified, he really wanted it. And yes, he really *does*
> expect it to deiconify if a new message appears. No need to confirm
> that fifty times a day. If he did not want it to deiconify, he would
> have turned the option off.
> 
> Let's not spend time discussing if this is proper UI behavior. I am
> absolutely certain that this is how my users want this handled. If you
> do not agree, let us just *assume* that I am right.
> 
> With this in mind, _is there a better way to do it than what I posted
> previously_? I am thinking of adding a keyboard handler that ignores
> everything and another handler that is activated after some (short)
> time and disables the first handler.
> 
> (BTW, popping up the dialog that you suggest is no better than my way
> of doing it since the user will be happily typing without looking at
> the screen and thus will randomly select Yes or No in that dialog)