Focus

[newpers]

I am trying to setup my desktop so that all windows require a click to focus, except for when they load, in which they automatically receive focus. How do I do this?

[theBlackDragon]

@newpers

I am trying to setup my desktop so that all windows require a click to focus, except for when they load, in which they automatically receive focus. How do I do this?

From the manpage:

          Grabbing the focus when a new window is created

          New  normal or transient windows with the FPGrabFocus or FPGrab-
          FocusTransient style automatically receive the focus  when  they
          are  created.   FPGrabFocus  is the default for windows with the
          ClickToFocus style.

[morbusg]

Thank you, thank you, and once more thank you! I actually had a function for that until now…

[newpers]

morbusg, can you please post your function or let me know what you did to get it to work without your function. i can’t seem to get this to work. thanks?

[newpers]

I have it working now. thomas_adam gave me a link to some code, which he told me to change up a little. Here’s the code:

DestroyModuleConfig AW-event: *
*AW-event: Cmd Function
*AW-event: add_window FuncNewWindow

DestroyFunc FuncNewWindow
AddToFunc   FuncNewWindow
+ I ThisWindow (AcceptsFocus) FlipFocus NoWarp

Module FvwmEvent AW-event

[digiot]

Thanks for posting that newpers. After I spent probably hours messing with every focus setting I could think of trying to figure out what was breaking FPGrabFocus, I came here, found this, and it works.

Could you or ThomasAdam or anybody explain what FPGrabFocus actually does. Or is it broken or what? Or do I have it misconfigured?

There’s a detail or two on a per window basis I’ll be bumping into, but I’m really happy with my basic focus policy now - FPReleaseFocus seems to work like it ought to and this

Style * FPClickRaisesFocused
Style * FPIgnoreRaiseClickMotion

simply rules. Click on a window for an easy raise but be able to drag-copy from a window without raising it. But that FPGrabFocus to give newly created windows the focus just didn’t want to work.

Also - sorry if I should start a new thread rather than crashing this one, but it seems on topic - something in the man page confuses me:

Are ClickToFocus, MouseFocus, SloppyFocus (and even the NeverFocus command in a sense) general focus policies that can be ‘augmented’ with FP* or are they old settings to be replaced by FP*? Because I can’t tell a difference between ‘Style * SloppyFocus’ being commented out or not, as long as I’ve got

Style * FPEnterToFocus
Style * !FPLeaveToUnfocus

Similarly,

Style * MouseFocusClickRaises

seems redundant with

Style * FPClickRaisesFocused

There’s a lot of this in the man pages, where there are two competing syntaxes and it’s not always clear which is which or what the exact relationship is.

– EDIT: Oops. Typo and a clarification.

[thomasadam]

FPGrabFocus is the default FP applied when windows are used with ‘ClickToFocus’ – essentually, any window created will receive the focus automatically. FPGrabFocus is the same as ‘GrabFocus’, btw.

@digiot

Style * FPClickRaisesFocused
Style * FPIgnoreRaiseClickMotion

As you have it there – the style options for FPs (Focus Policies) are not ORed (as they are with some other style options) which means the last one encountered is used. So in the above, it is FPIgnoreRaiseClickMotion which is used and not FPClickRaisesFocused.

@digiot

Are ClickToFocus, MouseFocus, SloppyFocus (and even the NeverFocus command in a sense) general focus policies that can be ‘augmented’ with FP* or are they old settings to be replaced by FP*? Because I can’t tell a difference between ‘Style * SloppyFocus’ being commented out or not, as long as I’ve got

Style * FPEnterToFocus
Style * !FPLeaveToUnfocus

They’re still focus policies – nothing general about them. The reason why there’s a whole bunch of FP* policies is because focus policies beginning with FP* can be used ordinarily with Style lines. There’s also a “FocusStyle” command which allows only focus directives to be used:

FocusStyle * EnterWindow

For instance. They’re both the same.

@digiot

Similarly,

Style * MouseFocusClickRaises

seems redundant with

Style * FPClickRaisesFocused

Again – see above. They’re contradictory, and it is the last statement read that is used. It’s fine (and perfectly possible) to have different focus policies for different windows – but you have a clash with what you’re wanting to apply – you have two style commands there – but it doesn’t make sense that both focus policies can work, hence it is always the last one that gets used.

HTH,

– Thomas Adam

[digiot]

@ThomasAdam

FPGrabFocus is the default FP applied when windows are used with ‘ClickToFocus’ – essentually, any window created will receive the focus automatically. FPGrabFocus is the same as ‘GrabFocus’, btw.

To make sure I get this - because I use (or try to use) mouse focus, FPGrabFocus doesn’t work, because it’s intended for ClickToFocus?

@digiot

Style * FPClickRaisesFocused
Style * FPIgnoreRaiseClickMotion

As you have it there – the style options for FPs (Focus Policies) are not ORed (as they are with some other style options) which means the last one encountered is used. So in the above, it is FPIgnoreRaiseClickMotion which is used and not FPClickRaisesFocused.

So in that, FPClickRaisesFocused is implied by FPIgnoreRaiseClickMotion and specifying both is redundant? I mean, I can strip FPClickRaisesFocused without any effect?

@digiot

Are ClickToFocus, MouseFocus, SloppyFocus (and even the NeverFocus command in a sense) general focus policies that can be ‘augmented’ with FP* or are they old settings to be replaced by FP*? Because I can’t tell a difference between ‘Style * SloppyFocus’ being commented out or not, as long as I’ve got

Style * FPEnterToFocus
Style * !FPLeaveToUnfocus

They’re still focus policies – nothing general about them. The reason why there’s a whole bunch of FP* policies is because focus policies beginning with FP* can be used ordinarily with Style lines. There’s also a “FocusStyle” command which allows only focus directives to be used:

FocusStyle * EnterWindow

For instance. They’re both the same.

Yeah, I (think) I got that part. I think that’s a big part of my problem with configuring fvwm. I want flexibility in the results, not in the syntax. I find the excess of synonyms (and apparently hidden antonyms) confusing. Especially in the ordering. 'Style ’ seems sufficient to me and, if necessary, a StyleFocus implying Focus is a subset of Style. Having both and having it phrased FocusStyle is just confusing and unhelpful to me. So, if possible, I’d prefer to ignore all FocusStyle phrasings and even all non-FP phrasings if I could do everything with FP*. That’s another aspect of the man page that confused me:

FocusStyle stylename options
works exactly like the Style command, but accepts
only the focus policy related styles beginning with
“FP”. The prefix can be removed, but at the cost
of a little bit of time. FocusStyle is meant to
make the configuration file more readable.

Does this mean the cost of parsing time? And which prefix? Focus is a ‘prefix’ to Style when used as ‘FocusStyle’ as much as FP is a prefix to FPFoo. And you remove either to get the other.
(Focus)Style Foo
Style (FP)Foo
FocusStyle doesn’t make it at all more readable to me but if it makes it more efficient, that’d be a rationale for using it.

@digiot

Similarly,

Style * MouseFocusClickRaises

seems redundant with

Style * FPClickRaisesFocused

Again – see above. They’re contradictory, and it is the last statement read that is used. It’s fine (and perfectly possible) to have different focus policies for different windows – but you have a clash with what you’re wanting to apply – you have two style commands there – but it doesn’t make sense that both focus policies can work, hence it is always the last one that gets used.

HTH,

– Thomas Adam

Thanks - it does help in that it lets me know I was even more confused than I thought I was. But you say they are contradictory - I thought they were identical - FPClickRaises|Focused[byMouse or otherwise]=MouseFocusClickRaises. It’d stil get overridden by the last specified, it seems, but…

Hm. Well, it’s just weird that I can aparrently have my syntax all wrong, not know why I’ve got it wrong, and still have it act mostly right. I’d like to understand it and have sensible configs and not just get the effect I want by accident. (And, naturally, then have no idea what to do when I don’t get the desired effect.)

[digiot]

Just to be complete, at the risk of embarassing myself, here’s what I’ve actually got uncommented in my config, with the function tacked on.

#=============================================================================
# Focus Policy
#=============================================================================
Style * FPEnterToFocus
Style * !FPLeaveToUnfocus
Style * !FPSortWindowlistByFocus
Style * FPClickRaisesFocused
Style * FPIgnoreRaiseClickMotion
Style * FPGrabFocus
Style * FPReleaseFocus

DestroyModuleConfig AW-event: *
*AW-event: Cmd Function
*AW-event: add_window FuncNewWindow

DestroyFunc FuncNewWindow
AddToFunc   FuncNewWindow
+ I ThisWindow (AcceptsFocus) FlipFocus NoWarp

Module FvwmEvent AW-event 

As I say, this seems to mostly do what I want, but I gather it’s completely wrong?

[thomasadam]

@digiot

To make sure I get this - because I use (or try to use) mouse focus, FPGrabFocus doesn’t work, because it’s intended for ClickToFocus?

Not quite – FPGrabFocus will work, but it works by default with ClickToFocus – that is, an implication.

@digiot

So in that, FPClickRaisesFocused is implied by FPIgnoreRaiseClickMotion and specifying both is redundant? I mean, I can strip FPClickRaisesFocused without any effect?

They’re not an implication, no. But because you have two focus models both competing against a Style of ‘*’ they both contradict each other – they won’t both work, so only the last one is used. So, yes, you can safely comment out / remove “Style * FPClickRaisesFocused” as it isn’t even applied in this instance.

@digiot

Yeah, I (think) I got that part. I think that’s a big part of my problem with configuring fvwm. I want flexibility in the results, not in the syntax.

Which is why such options within parsing FVWM configs are good – unless you really care about what (and why) is happening, you’ll never know the difference…

@digiot

I find the excess of synonyms (and apparently hidden antonyms) confusing. Especially in the ordering. ‘Style *’ seems sufficient to me and, if necessary, a StyleFocus implying Focus is a subset of Style.

It can get confusing – but the separation is a logical one.

@digiot

Having both and having it phrased FocusStyle is just confusing and unhelpful to me. So, if possible, I’d prefer to ignore all FocusStyle phrasings and even all non-FP* phrasings if I could do everything with FP*. That’s another aspect of the man page that confused me:

Same difference – they’re for your own convenience. I would imagine (and this is just speculative on my part) that at some point in the future – the FP* policies won’t be able to be applied vi “Style” lines – the focus (no pun intended) will be with using FocusStyle exclusively for focus-policy issues.

@digiot

FocusStyle stylename options
works exactly like the Style command, but accepts
only the focus policy related styles beginning with
“FP”. The prefix can be removed, but at the cost
of a little bit of time. FocusStyle is meant to
make the configuration file more readable.

Does this mean the cost of parsing time? And which prefix? Focus is a ‘prefix’ to Style when used as ‘FocusStyle’ as much as FP is a prefix to FPFoo. And you remove either to get the other.

It refers to the “FP” prefix. I wont bore you with the low-level details as to why.

@digiot

Thanks - it does help in that it lets me know I was even more confused than I thought I was. But you say they are contradictory - I thought they were identical - FPClickRaises|Focused[byMouse or otherwise]=MouseFocusClickRaises. It’d stil get overridden by the last specified, it seems, but…

They’re different. MouseFocusClickRaises works depending on which focus model you’re using (SloppyFocus, for instance, it won’t work with).

@digiot

Hm. Well, it’s just weird that I can aparrently have my syntax all wrong, not know why I’ve got it wrong, and still have it act mostly right. I’d like to understand it and have sensible configs and not just get the effect I want by accident. (And, naturally, then have no idea what to do when I don’t get the desired effect.)

See above – the parsing of the fvwm config file is quite good and tries to help, rather than hinder.

– Thomas Adam

[digiot]

@ThomasAdam

@digiot

So in that, FPClickRaisesFocused is implied by FPIgnoreRaiseClickMotion and specifying both is redundant? I mean, I can strip FPClickRaisesFocused without any effect?

They’re not an implication, no. But because you have two focus models both competing against a Style of ‘*’ they both contradict each other – they won’t both work, so only the last one is used. So, yes, you can safely comment out / remove “Style * FPClickRaisesFocused” as it isn’t even applied in this instance.

This isn’t correct. In my new config, I had no focus setting but FPIgnoreRaiseClickMotion and clicking the window did not raise it. Adding FPClickRaisesFocused restores the desired behavior.

This is what I mean - it’s not at all clear what is implied, contradictory, additive, or whatever. When the man page explicitly says things like ‘Note that this style forces that the initial click is passed to the application,’ it is clear and, indeed, it’s only logical that, in order for a copy action to be initiated on the initial click/drag, that would have to be the case. But in general, it’s rarely that clear.

FWIW, I’ve now built back up to this currently:

Style * !FPLeaveToUnfocus
Style * FPClickRaisesFocused
Style * FPIgnoreRaiseClickMotion
Style * FPGrabFocus
Style * FPReleaseFocus

FPEnterToFocus (mouse-centric focussing) is the default, so it’s not necessary to specify (though I tested it in to see if it was the problem and removing it the solution - no difference either way), but removing FPReleaseFocus or !FPLeaveToUnfocus leaves me with the root window or nothing focussed when I close an app without the cursor over some other window. Without FPClickRaisesFocused, I can’t click in the app window to raise. And FPIgnoreRaiseClickMotion doesn’t work by itself but does do a very cool job of letting me copy from a window without raising it.

And, strangely, FPGrabFocus is now working. It must have been something else in my old config completely (apparently) unrelated to FP because now I have the exact same functionality I had before.

Still don’t know what blew it out but at least I know what they all do and don’t do at the moment and they all do what I want.

[thomasadam]

@digiot

In my new config, I had no focus setting but FPIgnoreRaiseClickMotion and clicking the window did not raise it. Adding FPClickRaisesFocused restores the desired behavior.

Ues, that sounds right to me.

@digiot

This is what I mean - it’s not at all clear what is implied, contradictory, additive, or whatever. When the man page explicitly says things like ‘Note that this style forces that the initial click is passed to the application,’ it is clear and, indeed, it’s only logical that, in order for a copy action to be initiated on the initial click/drag, that would have to be the case. But in general, it’s rarely that clear.

How else can I make it clearer, do you think?

@digiot

And, strangely, FPGrabFocus is now working. It must have been something else in my old config completely (apparently) unrelated to FP because now I have the exact same functionality I had before.

Well, I don’t know enough about your config to say – assuming fvwm logs to ~/.xsession-errors for you, that might help.

– Thomas Adam

[digiot]

@ThomasAdam

How else can I make it clearer, do you think?

I’m confused - do you mean how can you clarify the man page for me here or do you mean you wrote the man page? For some reason that question made me think that you contributed the man page. I’m not sure the man page can be perfectly clear, since it’s really the configuration syntax that’s kind of… odd… and the man page has to describe that. What I’d say would depend on whether we were talking about rewriting the man page or not.

Well, I don’t know enough about your config to say – assuming fvwm logs to ~/.xsession-errors for you, that might help.

– Thomas Adam

I redirect fvwm output to a logfile. And all I get out of fvwm is mostly

_cdim: --- not moved 0x08169b70 '~/.fvwm +SAT'
[FVWM][__execute_function]: <<ERROR>> No such command 'MiniIcon'

which is not real useful when talking about rox and is helpful for reminding me I forgot the ‘style’ prefix but hasn’t enlightened me about the actual difficulties I’ve had so far.

[thomasadam]

@digiot

I’m confused - do you mean how can you clarify the man page for me here or do you mean you wrote the man page?

Heh. I meant is what I’m describing unclear. I didn’t write the man page, no. But trying to rephrase/paraphrase it can be quite difficult at times, for the more trickier concepts.

@digiot

For some reason that question made me think that you contributed the man page. I’m not sure the man page can be perfectly clear, since it’s really the configuration syntax that’s kind of… odd… and the man page has to describe that. What I’d say would depend on whether we were talking about rewriting the man page or not.

It’s not a bad man page to be fair – and it’s certainly the more lengthier ones. As for the syntax – yeah, it can be odd at times.

@digiot

I redirect fvwm output to a logfile. And all I get out of fvwm is mostly

_cdim: --- not moved 0x08169b70 '~/.fvwm +SAT'
[FVWM][__execute_function]: <<ERROR>> No such command 'MiniIcon'

which is not real useful when talking about rox and is helpful for reminding me I forgot the ‘style’ prefix but hasn’t enlightened me about the actual difficulties I’ve had so far.

Those are normal output sequences for 2.5.X – as it’s the unstable release, the debugging output is outputted by default.

– Thomas Adam

[digiot]

@ThomasAdam

Heh. I meant is what I’m describing unclear. I didn’t write the man page, no. But trying to rephrase/paraphrase it can be quite difficult at times, for the more trickier concepts.

Oh, okay. I didn’t think anyone here was officially involved with the fvwm project in a developer/documenter sense but I suddenly got the idea you might be. When I mentioned things being ‘not at all clear’, I was referring to parts of the man page rather than your rephrasing/paraphrasing.

It’s not a bad man page to be fair – and it’s certainly the more lengthier ones. As for the syntax – yeah, it can be odd at times.

No definitely not. I think there’s at least one outright error (related to when you can use BorderWidth) and quite a few typos but I think the man page gets an A+ for thoroughness and usually does a good job of explaining things. Just sometimes not and I question some of the arrangement. But still, not bad at all. As I say, my main trouble is with what the man page has to describe, more than how. The problems with ‘how’ mostly follow along from the ‘what’.

So, as far as what I wasn’t clear on, I guess you touched on it with things that ‘aren’t ORed’. The idea of competing focus models. If I issue ‘ClickToFocus’ and ‘MouseFocus’, I think it’s very clear that I’m using two incompatible models and only one can work. But ‘SloppyFocus’ seems to be a grab-bag for several more explicit settings. What it and other grab bags atomically break down to (and thus what’s redundant, compatible, or contradictory) is confusing. And, even if I use none of those, with some of the less precise phrasings (FPClickRaisesFocused is explicit in ‘ClickRaises’ but doesn’t seem to indicate anything about how it’s been Focused) it can also be confusing.

Really, what I’d prefer is to do away with fuzzy concepts like ‘SloppyFocus’ and just have a bunch ‘Focus/Raise, [Mouse|Key][Click|Drag|Release]/Create/Close, Enter/Exit’ set of atomic elements.
FocusOnMouseEnter=true
FocusOnMouseExit=true
FocusOnCreation=true
FocusOnDestruction=true
RaiseOnKeyClick=true
RaiseOnMouseDrag=false
And that’s it - you have your actions like Raise and Focus and your fundamental events like MouseEnter, MouseExit, KeyClick, Mouse Drag, KeyRelease, whatever. And then your bool or int or whatever. And it’s a single syntax. Something like that.

Ah well - back on one thing you said earlier and I think I’ll let this go.

@ThomasAdam

@digiot

Does this mean the cost of parsing time? And which prefix? Focus is a ‘prefix’ to Style when used as ‘FocusStyle’ as much as FP is a prefix to FPFoo. And you remove either to get the other.

It refers to the “FP” prefix.

So if I use FocusStyle * foo instead of Style * FPFoo, it’ll speed up initialization? Like I say, I don’t much care for it - too fine-grained compared to a comprehensive Style but too coarse otherwise, but if it’s more efficient I can adapt to it.

[thomasadam]

@digiot

Oh, okay. I didn’t think anyone here was officially involved with the fvwm project in a developer/documenter sense but I suddenly got the idea you might be.

I am. I have submitted patches from time to time.

@digiot

As I say, my main trouble is with what the man page has to describe, more than how. The problems with ‘how’ mostly follow along from the ‘what’.

As with many things, it’s often the case of trial and error where the manpage falls short of an adequate explanation.

@digiot

So, as far as what I wasn’t clear on, I guess you touched on it with things that ‘aren’t ORed’. The idea of competing focus models. If I issue ‘ClickToFocus’ and ‘MouseFocus’, I think it’s very clear that I’m using two incompatible models and only one can work. But ‘SloppyFocus’ seems to be a grab-bag for several more explicit settings. What it and other grab bags atomically break down to (and thus what’s redundant, compatible, or contradictory) is confusing.

Right. Well, sloppyfocus is (more or less) unique to fvwm. As for it being a “grab bag” – there are several other focus policy commands (those that begin with FP) which can be used atop of that. I can’t recall if it is in the man page, but one thing to remember (and I should have mentioned it sooner) is that once you have used a command such as “!FP…” to turn off a focus policy, resetting a style back again (as in using ‘SloppyFocus’) won’t turn on the default FP’s with it, unless you restart fvwm.

Think of it like this… you have your basic [1] focus models, such as: sloppyfocus, FocusFollowsMouse, ClickToFocusRaises, etc. Associated with that, and what you can define on top of that, are various FP* commands that will… enhance that focus model for you.

@digiot

And, even if I use none of those, with some of the less precise phrasings (FPClickRaisesFocused is explicit in ‘ClickRaises’ but doesn’t seem to indicate anything about how it’s been Focused) it can also be confusing.

OK, so several focus policies, have FP* commands associated, implicitly with them.

@digiot

Really, what I’d prefer is to do away with fuzzy concepts like ‘SloppyFocus’ and just have a bunch ‘Focus/Raise, [Mouse|Key][Click|Drag|Release]/Create/Close, Enter/Exit’ set of atomic elements.

I must admit to not liking this idea at all – it’s inflexible in associating it across windows. Plus, it would require a rewrite of the config parser.

@digiot

So if I use FocusStyle * foo instead of Style * FPFoo, it’ll speed up initialization? Like I say, I don’t much care for it - too fine-grained compared to a comprehensive Style but too coarse otherwise, but if it’s more efficient I can adapt to it.

Yes, it will speed it up – but IMO, you won’t hardly notice it at all. If you want my advice, I’d go with using ‘FocusStyle’, if only because it’s the way forward…

– Thomas Adam

[digiot]

@ThomasAdam

I can’t recall if it is in the man page, but one thing to remember (and I should have mentioned it sooner) is that once you have used a command such as “!FP…” to turn off a focus policy, resetting a style back again (as in using ‘SloppyFocus’) won’t turn on the default FP’s with it, unless you restart fvwm.

It is in the man page but it was one of those things I filed away in my head and didn’t access the file when I needed it. I bet that was what was blowing out FPGrabFocus. No way to tell for sure now, but I suspect it was. As I say, I don’t use anything but explicit FP* commands but I’m sure I did play around with some of the others either through FvwmConsole or in the config directly while configuring this stuff. I’m going to say that’s what it was so it’ll stop bugging me. Thanks.

Think of it like this… you have your basic [1] focus models, such as: sloppyfocus, FocusFollowsMouse, ClickToFocusRaises, etc. Associated with that, and what you can define on top of that, are various FP* commands that will… enhance that focus model for you.

Okay. That is what the man page says - ‘augments’ - and I get that. I think I was just mainly thrown by things not working how it seemed they ought to but, as above, I suspect it was just a secondary glitch that made me question the whole model.

@digiot

Really, what I’d prefer is to do away with fuzzy concepts like ‘SloppyFocus’ and just have a bunch ‘Focus/Raise, [Mouse|Key][Click|Drag|Release]/Create/Close, Enter/Exit’ set of atomic elements.

I must admit to not liking this idea at all – it’s inflexible in associating it across windows. Plus, it would require a rewrite of the config parser.

Well, it’s not a serious developmental proposal (I can’t implement much of anything if I can’t do it in shell ) but I don’t see it being inflexible - FocusBlah is still applied generically like FocusStyle * Blah and you could still set ‘XClock FocusOnMouseEnter=false’. But specifics aside, I just think fvwm tries too much for ‘natural language’ keywords/command names and has too much fuzzy overlap and inconsistency - We’ve got This and NoThis and IgnoreThis and HonorThis and SkipThis and HitThis and ThisOn and ThisOff and sometimes This and !That.

Yes, it will speed it up – but IMO, you won’t hardly notice it at all. If you want my advice, I’d go with using ‘FocusStyle’, if only because it’s the way forward…

– Thomas Adam

Okay - I tried Nick Fortune’s profiling of the config file (modified to measure nanoseconds) and it didn’t seem to indicate much except that maybe functions and complicated window dressings were the big things. With this cleaner config I don’t notice any special delay and wasn’t expecting much improvement either way, but I’d just prefer it in principle - and if that’s how things are tending anyway, then sure. Thanks again.

[thomasadam]

@digiot

Okay - I tried Nick Fortune’s profiling of the config file (modified to measure nanoseconds) and it didn’t seem to indicate much except that maybe functions and complicated window dressings were the big things.

It’s generally not a bad profiler, but for a sense of timing its very inaccurate. Not for the way its written but just in how fvwm does things internally.

– Thomas Adam