Re: FVWM: window resize in 2.5.7

From: Dominik Vogt <fvwm_at_fvwm.org>
Date: Fri, 1 Aug 2003 09:09:53 +0200

On Thu, Jul 31, 2003 at 10:45:12PM +0200, Olivier Chapuis wrote:
> On Thu, Jul 31, 2003 at 04:44:48PM +0200, Dominik Vogt wrote:
> > On Thu, Jul 31, 2003 at 03:47:56PM +0200, Olivier Chapuis wrote:
> > > On Thu, Jul 31, 2003 at 11:51:59AM +0200, Dominik Vogt wrote:
> > > > Somethimes I feel like talking to a wall. See my previous mails.
> > >
> > > I think that you do not understand me. I see bugs that I can reproduce
> > > easily and I want to found a solution. I really care that fvwm can
> > > work well with certain applications (e.g., Mozilla and gkrellm). And
> > > what about all your work on autohide with the Schedule command and
> > > FvwmEvent (via WindowShade)?
> >
> > I'm talking only about not grabbing the pointer in complex
> > functions. Argue as much as you want, it does not work because it
> > can not work reliably under X, for example because of the way
> > EnterNotify and LeaveNotify events work.
>
> 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.

> 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.

> I've suggested the converse: added a ForceGrab and
> ForceFastGrab "dummy command" because again I cannot reproduce
> (or even get one problem with my logic).
>
> > If you don't like it,
> > all you can do is to delay function execution until the pointer
> > can be grabbed (i.e. loop forever in certain places). But - this
> > may generate a deadlock with applications that grab the pointer
> > and then expect that the window manager processes requests.
> >
>
> Do not underestimate my understanding of fvwm and X (however, I am not
> (yet?) a big specialist of complex functions).
 
> In a certain sense fvwm already "freeze" when grabbing fail: when
> grabbing fail when you execute a complex function fvwm freeze for a few
> seconds in GrabEm and in fact this cause the problem with gkrellm: If
> you try to grab only once when executing complex function and abort if
> this fail gkrellm can be moved smoothly.

It's a gkrellm problem. Period. Not every bug in applications
can be circumvented by the window manager.

> > > You give an example and I study it carefully and found some strange
> > > behavior in the current code.
> > >
> > > You claim that my ideas can give raise to some bug. I cannot reproduce
> > > any one but I trust you.
> > >
> > > I say that I am ready to work on any other idea.
> > >
> > > Now you say that I am a wall! This is funny. Maybe you should read my
> > > mail
> >
> > 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.

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 - 02:10:14 BST

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