FvwmRearrange and EwmhBaseStruts + CreateConditionMask error

[dumblob]

Hi there,

sorry for posting here, but I haven’t found any better place. I’m having problem which appeared after installation of the newest FVWM 2.6.3.

It seems, the module FvwmRearrange started to take the EwmhBaseStruts values in account. Am I right? Till now, I’ve been using the offset coordinates and the bounding box coordinates for “simulating” the proper EwmhBaseStruts behaviour.

Another thing I’m experiencing, newly created windows no more respect the EwmhBaseStruts area. I have no better description for that.

I use my configuration with minor changes for a longer time than 2 years. And I’m experiencing such a “non-trivial” problem for the first time.

Anyway, there is one more thing worth mentioning. FVWM gives me the following warning:

[fvwm][CreateConditionMask]: <<DEPRECATED>> Use comma instead of whitespace to separate conditions

for this syntax:

+ I Prev (CurrentGlobalPage, AnyScreen, !Iconic, !Sticky, !Layer $[fvwm_transient_layer]) \ Prev (CurrentGlobalPage, AnyScreen, !Iconic, !Sticky, !Layer $[fvwm_fullscreen_layer]) EWMHActivateWindowFunc
I can’t find anything about this in man pages. And I was too lazy to inspect the source code of FVWM.

Imho the best option would be, if the test-conditions could be used more than once in the Test command, e.g.

+ I Prev (CurrentGlobalPage, AnyScreen, !Iconic, !Sticky, \ !Layer $[fvwm_transient_layer], !Layer $[fvwm_fullscreen_layer]) \ EWMHActivateWindowFunc
This is now unfortunately impossible.

I would really appreciate your help.

[thomasadam]

@dumblob

It seems, the module FvwmRearrange started to take the EwmhBaseStruts values in account. Am I right?

No. You’re wrong. See:

mail-archive.com/fvwm-worker … 02603.html

– Thomas Adam

[dumblob]

Hi Thomas,

thank you for an answer. I knew it yet before, what the changes in the Move command were. Unfortunately I don’t see any connection with the FvwmRearrange module, neither with the “placing newly created windows not respecting the EwmhBaseStruts”.

What am I missing? Could you please shortly look at my configuration (grep -i -r ‘fvwmrearrange’ common.lib; etc.)?

Formerly I’ve used this:

PipeRead 'echo Module FvwmRearrange -tile -noanimate -nomaximize \ -mn 2 -noraise -s -sp -sd -u -m -resize -nostretch \ $[fvwm_left_blank_area]p $[fvwm_top_blank_area]p \ $\(\($[vp.width]-$[fvwm_right_blank_area]\)\)p \ $\(\($[vp.height]-$[fvwm_bottom_blank_area]\)\)p'
But now I’m using this instead:

PipeRead 'echo Module FvwmRearrange -tile -noanimate -nomaximize \ -mn 2 -noraise -s -sp -sd -u -m -resize -nostretch 0p 0p \ $\(\($[vp.width]-$[fvwm_right_blank_area]-$[fvwm_left_blank_area]\)\)p \ $\(\($[vp.height]-$[fvwm_top_blank_area]-$[fvwm_bottom_blank_area]\)\)p'
Btw what do you think about the CreateConditionMask warning?

[thomasadam]

Try this:

github.com/ThomasAdam/fvwm/comm … a5b0.patch

Alternatively you can just clone my repo and checkout the “ta/fix-fvwmrearrange-with-ewmhiwa” branch and build that. This will mean you no longer need the PipeRead to do all those calculations.

– Thomas Adam

[thomasadam]

Try the CVS version (branch-2_6) – I’ve merged this to CVS.

– Thomas Adam

[dumblob]

Thank you for your patch. I’ve tried it and now I’m using the new -ewmhiwa option to simulate the old behaviour (PipeRead…), because the following command tiles windows so, that their parts are beyond the EwmhBaseStruts area.

Module FvwmRearrange -tile -noanimate -nomaximize \ -mn 2 -noraise -s -sp -sd -u -m -resize -nostretchI don’t know why the Move command does that, because I’ve tested it only with

EwmhBaseStruts 0 0 40 0 Which means, the tiled windows were beyond the viewport only at the bottom. Nowhere else.
I’ve looked at the FvwmRearrange source code and it seems to be OK. There must be something wrong with the Move command, but I haven’t found anything suspicious.

Anyway, I’ve investigated the second problem with the PositionPlacement and realized, this

Style * PositionPlacement 50-50w 35-50w command does not respect the EwmhBaseStruts settings likewise. But this time it does not respect the 40 pixels from the top either. Weird.

If you have any ideas, could you please share them?

[thomasadam]

@dumblob

Thank you for your patch. I’ve tried it and now I’m using the new -ewmhiwa option to simulate the old behaviour (PipeRead…), because the following command tiles windows so, that their parts are beyond the EwmhBaseStruts area.

Module FvwmRearrange -tile -noanimate -nomaximize \ -mn 2 -noraise -s -sp -sd -u -m -resize -nostretchI don’t know why the Move command does that, because I’ve tested it only with

EwmhBaseStruts 0 0 40 0 Which means, the tiled windows were beyond the viewport only at the bottom. Nowhere else.
I’ve looked at the FvwmRearrange source code and it seems to be OK. There must be something wrong with the Move command, but I haven’t found anything suspicious.

That’s because it’s always worked that way. It’s doing the right thing here.

@dumblob

Anyway, I’ve investigated the second problem with the PositionPlacement and realized, this

Style * PositionPlacement 50-50w 35-50w command does not respect the EwmhBaseStruts settings likewise. But this time it does not respect the 40 pixels from the top either. Weird.

Sure it does. The window is being placed exactly where you’ve asked it to be placed. Again, remember that PositionPlacement just uses the move code under the hood. You can add any other options such as “ewmhiwa” at the end.

– Thomas Adam

[dumblob]

Sure it does. The window is being placed exactly where you’ve asked it to be placed. Again, remember that PositionPlacement just uses the move code under the hood. You can add any other options such as “ewmhiwa” at the end.

Hm, how is it then, that the initial window placement behaves the same with or without “ewmhiwa” specified?

EwmhBaseStruts 0 0 40 0 Style * PositionPlacement 50-50w 35-50wis the same as

EwmhBaseStruts 0 0 40 0 Style * PositionPlacement 50-50w 35-50w ewmhiwa
Btw do you have any idea how to get rid of the warning message I’ve mentioned in the first post?

[thomasadam]

@dumblob

Sure it does. The window is being placed exactly where you’ve asked it to be placed. Again, remember that PositionPlacement just uses the move code under the hood. You can add any other options such as “ewmhiwa” at the end.

Hm, how is it then, that the initial window placement behaves the same with or without “ewmhiwa” specified?

EwmhBaseStruts 0 0 40 0 Style * PositionPlacement 50-50w 35-50wis the same as

EwmhBaseStruts 0 0 40 0 Style * PositionPlacement 50-50w 35-50w ewmhiwa

It doesn’t. The two windows are placed differently, depending on whether you supply the “ewmhiwa” option. Oddly enough, in your case, there’s a 40 pixel difference between where the two windows are placed – one is lower (without the “ewmhiwa” option, because the position of the window uses that as the basis for the window offset), and the other is higher (because the offset is from 0,0).

How is this not what you were expecting? I suspect you’ve got something else weird going on.

@dumblob

Btw do you have any idea how to get rid of the warning message I’ve mentioned in the first post?

Nope, because you’ve managed to drown it out with all the other different questions. Start a separate thread for that.

– Thomas Adam

[thomasadam]

@dumblob

[fvwm][CreateConditionMask]: <<DEPRECATED>> Use comma instead of whitespace to separate conditions

for this syntax:

+ I Prev (CurrentGlobalPage, AnyScreen, !Iconic, !Sticky, !Layer $[fvwm_transient_layer]) \ Prev (CurrentGlobalPage, AnyScreen, !Iconic, !Sticky, !Layer $[fvwm_fullscreen_layer]) EWMHActivateWindowFunc
I can’t find anything about this in man pages. And I was too lazy to inspect the source code of FVWM.

Simple: $[fvwm_transient_layer] is expanded to nothing, leaving “, Layer” which will fall-through with that error.

I’ll fix up the parsing to be a little more robust in a moment.

– Thomas Adam

[dumblob]

It doesn’t. The two windows are placed differently, depending on whether you supply the “ewmhiwa” option. Oddly enough, in your case, there’s a 40 pixel difference between where the two windows are placed – one is lower (without the “ewmhiwa” option, because the position of the window uses that as the basis for the window offset), and the other is higher (because the offset is from 0,0).

This is exactly what I’ve expected, but it is unfortunately not what I get. I’m trying to find some syntax/semantics bug in my configuration, but can not find anything. I’m using this configuration since version 2.5.27 without any problem. That is why I am asking for help.

I suspect you’ve got something else weird going on.

Any ideas where? I apologize, but my imagination is exhausted.

[thomasadam]

@dumblob

It doesn’t. The two windows are placed differently, depending on whether you supply the “ewmhiwa” option. Oddly enough, in your case, there’s a 40 pixel difference between where the two windows are placed – one is lower (without the “ewmhiwa” option, because the position of the window uses that as the basis for the window offset), and the other is higher (because the offset is from 0,0).

This is exactly what I’ve expected, but it is unfortunately not what I get. I’m trying to find some syntax/semantics bug in my configuration, but can not find anything. I’m using this configuration since version 2.5.27 without any problem. That is why I am asking for help.

So send me your config – and double check you’re really running the version of FVWM you think you are, as well as looking in the logs (~/.xsession-errors) for anything.

But seriously, the more you mention this, the more I’m assuming you’ve done something odd.

– Thomas Adam

[dumblob]

Simple: $[fvwm_transient_layer] is expanded to nothing, leaving “, Layer” which will fall-through with that error.

Then it is some bug in my configuration. The strange thing is, that `env | grep transient’ gives me exactly this variable, but with a value.

I’ll fix up the parsing to be a little more robust in a moment.

You don’t have to make it more robust, rather tell me please, why the $[fvwm_transient_layer] expands to nothing when it is properly set.

I’ve posted link to my configuration yet in the first post. Here it is.. I’m sorry for bothering you on the weekend.

Thank you very much for your answers.

[dumblob]

I’m currently running

fvwm 2.6.4 (from cvs) compiled on Oct 15 2011 at 12:28:22 with support for: ReadLine, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLSAnd my .xsession-errors.

[thomasadam]

@dumblob

I’m currently running

fvwm 2.6.4 (from cvs) compiled on Oct 15 2011 at 12:28:22 with support for: ReadLine, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLSAnd my .xsession-errors.

OK. So I took a look…

Your config is an absolute mess! I’ve never seen anything so unnecessarily complicated and all over the place.

I need you to strip it all down, and give me a config – a single file – where that configuration shows me the problems you’re having. Even with me hand-bodging your config, and getting it running, my issuing the EwmhBaseStrut commands still gives me the results I expect, and neither can I reproduce any of the CreateCondtionMask errors you’ve been seeing using your config.

So there’s something else going on with you – but until you can strip your mess of a config to something which shows the problems you’re having, there’s nothing more I can do to help you – FVWM though, is doing the Right Thing.

– Thomas Adam

[dumblob]

Your config is an absolute mess!

I’m sorry for that, but it is because I use it on many different computers and it needst to be completely portable. Of course, there are default options in my config, because 2 years ago I thought, the defaults will rapidly change.

unnecessarily complicated and all over the place.

Modularity takes its tax.

I need you to strip it all down, and give me a config – a single file – where that configuration shows me the problems you’re having.

I’ll do.

Even with me hand-bodging your config, and getting it running

Not necessary, the only thing one must do is running fvwm -f /path/to/the/unpacked/tarball/directory/init.conf

my issuing the EwmhBaseStrut commands still gives me the results I expect, and neither can I reproduce any of the CreateCondtionMask errors you’ve been seeing using your config.

Oh, I’m sorry for that. First you must add a new page by hitting L-Alt+c on dvorak or L-Alt+i on us keyboard. That will add a new Page right after the current one and open the root menu. Switching between pages could be done with the mouse wheel or with h n keys on dvorak and j l on us layout. For catching the CreateConditionMask error, you need at least one window on each of the two pages, you are switching between. Then, after switch, the error comes up.

So there’s something else going on with you – but until you can strip your mess of a config to something which shows the problems you’re having, there’s nothing more I can do to help you – FVWM though, is doing the Right Thing.

Ok, thank you. I’ll try to make a minimal fvwm configuration simulating this behaviour.
Anyway thank you for your time! I’ll let you know.

[thomasadam]

@dumblob

Your config is an absolute mess!

I’m sorry for that, but it is because I use it on many different computers and it needst to be completely portable. Of course, there are default options in my config, because 2 years ago I thought, the defaults will rapidly change.

unnecessarily complicated and all over the place.

Modularity takes its tax.

I’ll address the problems with what you’ve tried to do at a later time.

@dumblob

Even with me hand-bodging your config, and getting it running

Not necessary, the only thing one must do is running fvwm -f /path/to/the/unpacked/tarball/directory/init.conf

I’m not an idiot. That is not good enough because you have this in your config:

PipeRead 'echo SetEnv FVWM_USERDIR \
  \\""${XDG_CONFIG_HOME-\'$[HOME]/.config\'}/fvwm"\\"'

Furthermore, you then change the semantics for how you Read your individual settings files, which meant even though I deliberately set FVWM_USERDIR before starting FVWM, it was not being honoured because you unconditionally rewrite it. Never do this. Ever.

So from the get-go, this is not even portable. But anyway, this is just one example of the things I had to change by hand – it’s not relevant to anything else other than for you to kindly provide me with a more minimal config file.

– Thomas Adam

[dumblob]

Furthermore, you then change the semantics for how you Read your individual settings files, which meant even though I deliberately set FVWM_USERDIR before starting FVWM, it was not being honoured because you unconditionally rewrite it. Never do this. Ever.

So from the get-go, this is not even portable. But anyway, this is just one example of the things I had to change by hand

I apologize, my fault. As you’ve surely discovered, this configuration has 2 parts. The main part should be e.g. somewhere in /etc/ and the second part in FVWM_USERDIR, which depends on the XDG specification and not the user variable. I thought, this will correspond to XDG specification more than letting user change this variable. And the second part (http://dumblob.hy.cz/pub/fvwm-user.tar.bz2) is the true user configuration.

– it’s not relevant to anything else other than for you to kindly provide me with a more minimal config file.

I’ll surely do, but it will take me some time to figure out such a mini fvwm configuration.

[dumblob]

There it is - http://dumblob.hy.cz/pub/fvwm-mini.tar.bz2.

I tried to strip it down as much as possible while keeping menus and mouse settings (for better control). Both “problems” are still there (initial PositionPlacement and the CreateConditionMask warning).

wc fvwm-mini/* 223 738 6302 fvwm-mini/common.lib 85 192 1968 fvwm-mini/init.conf 56 152 1683 fvwm-mini/menus 15 26 358 fvwm-mini/modules.conf 41 261 1466 fvwm-mini/mouse 420 1369 11777 total

I’m not sure, if it helps. But I would appreciate any hint you come up with.

[thomasadam]

@dumblob

There it is - http://dumblob.hy.cz/pub/fvwm-mini.tar.bz2.

Your domain is not up, so I can’t access that file.

– Thomas Adam