On Sat, Sep 03, 2011 at 08:48:29PM +0200, Markus Hutmacher wrote:
> DestroyFunc FvwmAkregator
> AddToFunc FvwmAkregator
> + I exec akregator
>
> DestroyFunc FvwmAkregatorClose
> AddToFunc FvwmAkregatorClose
> + I All ("akregator") Delete
>
> I execute them in ~/.fvwm/config with
>
> FvwmAkregator
> FvwmAkregatorClose
Ah -- this is flawed for a few reasons.
Firstly, if these are plonked in your config like this directly:
FvwmAkregator
FvwmAkregatorClose
Then you do not guarantee that FVWM will run them in order -- I mean to say
that the functions will probably run in order, but the immediate (+ I)
actions on them might not. Consider what happens if running "akregator"
takes longer than the time FvwmAkregatorClose is run. FVWM won't block on
running either of those, so the timing is going to be crucial.
What it actually translates in to doing is this:
DestroyFunc FvwmAkregator
AddToFunc FvwmAkregator
+ I Exec akregator
+ I All (akregator) Delete
But there's a problem here. Firstly, if you wanted to ensure ordering of
this you would need to force FVWM to wait for akregator to load -- and by
that we typically mean the window to have been mapped. You can use the Wait
command to enforce this, like this:
DestroyFunc FvwmAkregator
AddToFunc FvwmAkregator
+ I Exec akregator
+ I Wait akregator
+ I All (akregator) Delete
This assumes the application in question actually maps a window called
akregator; otherwise FVWM would block indefinitely waiting for it to appear.
And of course even if it does, the "All" conditional is the wrong one to be
using.
Why? Well, what if you already had a akregator window which you'd dealt
with, and was open. The second instance of it introduced by FvwmAkregator
would also affect the first one, because you used "All". In instances where
you're referring to the instance you've just launched, you almost always
want to use the conditional command "Next", as in:
DestroyFunc FvwmAkregator
AddToFunc FvwmAkregator
+ I Exec akregator
+ I Wait akregator
+ I Next (akregator) Delete
So that should solve your ordering problem if nothing else. You might not
want or need them in one function like this, but I'd recommend it for the
reasons list above.
The other problem to note here is the use of "+ I Exec". When you do this:
Exec foo
FVWM does this:
$SHELL -> foo
Leaving the subshell used to spawn "foo" kicking about. You want to use
this:
+ I Exec exec foo
Because now, the second "exec" is at the shell-level and will replace the
shell with "foo", just like the exec builtin at the shell does.
> Both work as expected, but the "FvwmAkregatorClose" function not
> automatically. I thought that it must be possible to execute the
> "FvwmAkregatorClose" function while FVWM starts and that the
> akregator Window is closed directly after it's created (leaving the
> icon in the tray). Manually it's no problem, akregator is started
> when FVWM starts, but I have to close the Window manually (or with
> the function via menu).
And what you're doing here is called "gross cheating". There is no
guarantee that windows understand the "Delete" protocol, and worse yet, what
you're doing is relying on the application to know to simply unmap itself
because it has a systray running somewhere. Frequently, applications which
provide systray functionality but which also allow you to turn off the
systra icon, and which then receive (and expect to handle) a Delete request,
simply exit.
You should not even be doing this; not to any application, Markus. If the
application in question doesn't have an option to hide itself when it first
starts -- *and* has the ability to register with a systray program, then
file an enhancement request.
But this is not the job of a window manager.
A safer way if you can't live without it is to set the "StartIconic" style
instead, and forget about your FvwmAkregator entirely.
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
