FvwmRearrange example

[rasatpc]

Tiling example for /Wiki /Modules /FvwmRearrange.

[rasatpc]

On the forum, there was a discussion, I thought it was finalized. https://fvwmforums.org/t/fvwmbutton-that-changes-the-value-after-pressing-it/4401/8

@ThomasAdam , Schedule This is undesirable -- and instead you should probably toggle outside of those PipeRead commands. How would you do it, a suggestion?

@ThomasAdam , Bonus points for using InfoStoreAdd here as well. I couldn’t get InfoStoreAdd to work but SetEnv does it.

[ThomasAdam]

I couldn’t get InfoStoreAdd to work but SetEnv does it.

What have you tried previously?

Please don't misunderstand me though, your examples are fine -- but when I see things which aren't correct, I'll raise them.

[rasatpc]

This InfoStoreAdd works fine. Schedule 0 to maintain the sequence.

DestroyFunc 3Tile
AddToFunc 3Tile
+ I FvwmRearrange -tile $0 -r -mn 3 -maximize 0 0 86 82 $[wa.width]p $[wa.height]p

InfoStoreAdd TileSwitch "ON"

DestroyFunc Tile
AddToFunc Tile
+ I Piperead 'if [ $[infostore.TileSwitch] = ON ]; then echo "3Tile"; \
    echo "Schedule 0 InfoStoreAdd TileSwitch OFF"; fi'
+ I Piperead 'if [ $[infostore.TileSwitch] = OFF ]; \
    then echo "All (CurrentPage, !Iconic, CirculateHit, !Sticky) Maximize Off"; \
    echo "WindowId $0 WarpToWindow 50 50"; echo "InfoStoreAdd TileSwitch ON"; fi'

Key t A M Tile

Why Schedule is undesirable, it is in many wiki examples.

[somiaj]

Note that Schedule 0 isn't needed, just remove that.

Once you update your PR, you can git commit --amend to add the new changes to the current commit, then force push, git push -f your branch so we get your updates. I haven't tested that, but it appears you have addressed @ThomasAdam concerns.

[somiaj]

Note you shouldn't need bash to do your testing for you, fvwm has logic to test things and can even have tests to see if the previous test failed (Giving you simple if...then...else logic). You can probably remove the PipeReads altogether.

DestroyFunc Tile
AddToFunc Tile
+ I Test (EnvMatch infostore.TileSwitch ON) TileOn
+ I TestRc (NoMatch) TileOff

DestroyFunc TileOn
AddToFunc TileOn
+ I 3Tile
+ I InfoStoreAdd TileSwitch OFF

DestroyFunc TileOff
AddToFunc TileOff
+ I All (CurrentPage, !Iconic, CirculateHit, !Sticky) Maximize Off
+ I WindowId $0 WarpToWindow 50 50
+ I InfoStoreAdd TileSwitch ON

[rasatpc]

@somiaj thanks, your functions work well. Updated and git push -f

[rasatpc]

I did cleaning of options that were not needed. The FvwmRearrange -tile -r -mn 3 -maximize 1 3 92 92 looks good on the default config. https://rasatpc.net/screenshot/tiled/tile-3column.png

[rasatpc]

Commit messages are repeated, I am using the same message title and description for all with GitHub Desktop client. I will change the description.

[rasatpc]

Did something go wrong? I pushed the FvwmRearrange text edit. The pr-module branch was 2 commits behind. Updated it and I did a second push. CookBook taga appeared.

[ThomasAdam]

Did something go wrong? I pushed the FvwmRearrange text edit. The pr-module branch was 2 commits behind. Updated it and I did a second push. CookBook taga appeared.

I don't know what command(s) you ran, so it's hard for me to say.

[rasatpc]

Please, give the exact terminal command on how to amend. I am not familiar with PR.

[ThomasAdam]

@rasatpc

What I suspect you're doing is squashing commits together -- the last squash's commit message is the first one at the top.

I can tell this because of your ever-growing commit message which you're not amending.

[rasatpc]

This is what I do each time after a new edit is pushed with GitHub Desktop

1. git rebase -i HEAD~2
2. With editor change pick to squash on the second commit
3. Save and exit the editor
4. git push -f

Where to do amend?

[ThomasAdam]

Closing this in favour of #23

[ThomasAdam]

This is what I do each time after a new edit is pushed with GitHub Desktop

1. git rebase -i HEAD~2

That's where you're going wrong. This assumes, each time, that you only care about the last two commits. What if you have more?

I don't want to sit here and turn this into a git tutorial. But in the general case:

# Assume you're on a topic branch:  pr-module
$ git rebase -i master

This puts you in to an interactive rebase.

This will show you all of the commits on pr-module which are not yet on master -- or put a different way, this list is the list of commits that will be in your PR.

If this list needs amending, you have options.

Choose whichever makes sense.

During the list of commits, you can modify the default action of pick for a specific commit to be something else, such as squash, fixup, of edit. I use all of these depending on what I'm trying to do.

Save the file.

Then push the branch. If it's the fist time I've ever tried to push this branch, I do:

$ git push -u origin HEAD

Then open your PR.

If I've already pushed it, but I've amended commits already -- or there's an open PR for it, then you will have to force-push:

$ git push -f

If you have an open PR already, that will be amended accordingly.