On Thu, Sep 01, 2011 at 03:55:41PM +0200, Pierre Frenkiel wrote: > On Thu, 1 Sep 2011, Thomas Adam wrote: > > >On 1 September 2011 10:39, Pierre Frenkiel <pierre.frenk...@gmail.com> wrote: > >>hi everybody, > >>I added the parameter StayOnTOP to Style line for xclock, and that doesn't > > > >It's 'StaysOnTop'; note the extra 's' there. > > thanks, it's OK now. > > At my 1st attempt, I copied the xclock line from an other one, so the > parameter was the good one, and didn't work, but I noticed afterwards > that to make the change effective, it's not enough to restart fvwm, I must > also restart xclock.
What version of FVWM are you using? It used to be the case long ago that the Style command didn't apply immediately; the window had to be recaptured. But this doesn't happen anymore. Styles are applied as soon as they're encountered for the matched window(s), even if they're running. But the tell-tale sign here suggests you're adding these Style entries to your .fvwm2rc file and restarting FVWM each time. Is that correct? Only you shouldn't be doing that. You should instead use FvwmConsole and add all of the entries to that until you get what you want, and only then should you add them to your .fvwm2rc file. Here's some text I posted to Google+ which you might find interesting [1]: ---------------------------------------------------------------------- Testing FVWM without pulling your hair out... So I do a lot of work with people on IRC in #fvwm on freenode. Often people have a question which doesn't require too much in the way of practical solutions from me, but more recently that's changed. I don't mind, it keeps me on my toes. :) But what's more interesting is that more and more people are simply adding in whatever function snippet I give them, or mouse binding, to their config and restarting FVWM. But this is bad and wasteful. There's no need for it. As per the FAQ entry I added a while back (http://fvwm.org/documentation/faq/#3.29) the use of FvwmConsole to try out changes before adding them to your .fvwm2rc file is certainly the first thing you should try. But there might be instances where even this is a pain -- for example, let's say you wanted to try out messing with mouse bindings which would affect the ones currently defined: Mouse 1 I A FuncFoo And you wanted to change FuncFoo -- you would have to find some way of either saving FuncFoo's definition, or simply overriding the binding and putting it back afterwards. Depending on how your config is structured, if it's been separated out into different files, with bindings in one of them, then you could mess around with the above binding all you like and simply get FVWM (via FvwmConsole of course) to read those definitions in again: Read my-mouse-bindings This is a pretty peculiar case though, and for 90% or so of cases where you want to test FVWM config changes as it's running, is to use FvwmConsole directly. If that's too annoying you could define a file (~/.fvwm/debug) which you could use solely for messing about with and then issuing: Read debug in FvwmConsole time and again. Alternatively for larger changes, there's always the use of Xnest or Xephyr (http://www.freedesktop.org/wiki/Software/Xephyr) which is what I use when hacking on FVWM, so I can run FVWM inside FVWM and check my changes, without breaking the running instance of FVWM -- but its use here can also be applied when wanting to try out different sets of config changes if those changes are sufficiently large: fvwm -f ~/path/to/config So, no more constantly restarting FVWM, please. These are the alternatives. :) Enjoy. :) ----------------------------------------------------------------------- -- Thomas Adam [1] https://plus.google.com/u/1/100692260234415059882/posts/YqzdH3jeAEg
