Re: FVWM: window resize in 2.5.7

From: Dominik Vogt <fvwm_at_fvwm.org>
Date: Fri, 1 Aug 2003 14:15:54 +0200

On Fri, Aug 01, 2003 at 11:56:20AM +0200, Olivier Chapuis wrote:
> On Fri, Aug 01, 2003 at 09:09:53AM +0200, Dominik Vogt wrote:
> > On Thu, Jul 31, 2003 at 10:45:12PM +0200, Olivier Chapuis wrote:
> > > Please give an example I can reproduce. I think there is some but I would
> > > like to see one which is reproducible. The example you give cannot
> > > happen I think (and there are problems in the code with this example).
> > > Note, again, that aborting complex function can _also_ break things!
> >
> > There have been several examples in the past. Search the mailing
> > list for them and use the old tarball they appeared in. Please
> > don't waste my time generating artificial buggy situations for
> > you.
> >
>
> The only example I found is the well known "rxvt selection problem"
> and ... it happens on "H"old. We are not agree on a problem it seems
> to me that you can make an effort and give me an example (as I said I
> worked hard on this, this last few days). Or should claim that there
> is no to see one?

I already explained the problem with Enter- and LeaveNotify events
and SloppyFocus. You don't even need an external application to
get problems with scripts that warp the pointer and change the
focus. There have been several patches in the past with a fix
following soon.

> > > It is clear that you can do too much things with complex function to
> > > have a default regarding grabbing. My hope is/was that this can be
> > > detected in the average and add a special stuff for the unlikely
> > > case.
> >
> > It can't.
> >
> > > I think that Dan idea is ok (I do not want to fight too much
> > > more).
> >
> > I don't. Sometimes it's better to live without certain "features"
> > for the sake of code maintenance.
> >
>
> There is no reason for a function of the form
>
> AddToFunc I FvwmEventHandle_config_window Echo "config_window"
>
> to be aborted because the pointer is grabbed. Again a complex func can
> do so many things that controling the grabbing is necessary IMO.

Predicting whether the grab is necessary or not is impossible.
This may depend on the output of external commands, other complex
functions, the behaviour of other applications, and so on.

> > It's a gkrellm problem. Period. Not every bug in applications
> > can be circumvented by the window manager.
>
> Yes it is a gkrellm problem (and maybe a gtk 2.2 problem). The problem
> I've with my "old" gkrellm come from FvwmEvent. What about the others
> examples I give with FvwmEvent?

I repeat, I'm talking only about the complex function grab. We
must either live with the problems that come from it or find a
different way to get around them.

> > > > I spend much more time reading list mail carefully than you think
> > > > (and than I should spend, for that matter).
> > >
> > > My previous and _complex_ previous long mail as the following date (I
> > > spent one day to write it, reading the code an your mails, make some
> > > experience ...etc):
> > >
> > > On Thu, Jul 31, 2003 at 11:32:05AM +0200, Olivier Chapuis wrote:
> > >
> > > Your answer arrived 20 minutes later ... :o)
> >
> > Well, good job in writing that mail. Although it was long, it was
> > easy to understand.
>
> My feeling is that you do not want to do something (on this subject)
> whatever the problems we can discover with the current code, whatever
> I can or any body else can say and whatever the solution we can propose
> (an optional pre cmd) ...etc.

Yes, I hope I made it clear that I consider getting rid of the
grab is the wrong way to go. Other than that I hope we can do
without further sarcasm, finger pointing, flaming, etc.

Bye

Dominik ^_^ ^_^
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Fri Aug 01 2003 - 07:16:15 BST

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:55 BST