Hi Dominik et al,
This post follows on from the previous "ModuleListenOnly command"
which was getting a bit off-topic.
> > As a hack/compromise, maybe we could modify AddToFunc to keep track
> > of whether or not it uses a "mouse modifier" & only then grab the
> > X server, in execute_complex_fu
Hi Dominik,
> That's just one purpose of the command. I was always fond of the
> idea to prototype or even implement modules as shell scripts.
Yes, that would be cool. IMHO, I think it would be prudent to create
"bashlib" (akin to perllib), instead of adding ModuleListenOnly command.
But I sup
On Thu, Jun 15, 2006 at 09:30:17AM +0200, Dominik Vogt wrote:
> It actually wasn't this bad. The idea behing the test in the
> ButtonReleasee handler was to make sure the window is snapped if
> the window did not move before, but the pointer position in the
> release event moved the window.
>
> I
On Sun, Jun 25, 2006 at 02:09:49PM -0500, Jacob Bachmeyer wrote:
> Is it not possible to determine whether a function must grab as it is
> defined? Couldn't adding a line with a modifier that needs a grab set
> a "this function might need a grab" flag?
You want to read this thread (it's long):
ht
Dominik Vogt wrote:
On Sun, Jun 25, 2006 at 07:18:30PM +1000, Scott Smedley wrote:
Having just looked into how Schedule & execute_complex_function() work,
I'm not prepared to blame Schedule just yet.
In my opinion, I don't think FVWM should grab the X server everytime it
executes a complex f
On Sun, Jun 25, 2006 at 07:18:30PM +1000, Scott Smedley wrote:
> Hi Dominik,
>
> Are you enjoying the World Cup?
>
> > Two reasons: (1) "Schedule" is an unreliable hack and (2) this
> > starts a shell every 15 seconds and my goal was to waste as little
> > cpu as possible (as it interferes with
Hi Dominik,
Are you enjoying the World Cup?
> Two reasons: (1) "Schedule" is an unreliable hack and (2) this
> starts a shell every 15 seconds and my goal was to waste as little
> cpu as possible (as it interferes with certain time-critical
> applications - okay - games).
Hehe. :)
Re: (2)
>Fr
