Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

InitialMapCommand ResizeMove: warp not moving pointer to new window location #1160

Closed
WhyIsFVWM3soBuggy opened this issue Jan 24, 2025 · 5 comments · Fixed by #1161
Closed

InitialMapCommand ResizeMove: warp not moving pointer to new window location #1160

WhyIsFVWM3soBuggy opened this issue Jan 24, 2025 · 5 comments · Fixed by #1161
Assignees
@ThomasAdam
Labels
type:bug Something's broken!
Milestone
1.1.2

Comments

@WhyIsFVWM3soBuggy
Copy link

Thanks for reporting your bug here! The following template will help with
giving as much information as possible so that it's easier to diagnose and
fix.

Upfront Information

Please provide the following information by running the command and providing
the output.

  • Fvwm3 version (run: fvwm3 --version)
    fvwm3 1.1.1 (released)
    with support for: XPM, PNG, SVG, Shape, XShm, SM, Bidi text, XRandR, XRender, XCursor, XFT, XFixes, NLS

fvwm3 comes with NO WARRANTY, to the extent permitted by law. You may
redistribute copies of fvwm under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

(Although the package was named fvwm3 1.1.1-2 in arch AUR)

  • Linux distribution or BSD name/version
    Arch

  • Platform (run: uname -sp)
    Linux unknown

Expected Behaviour

I'm trying to use a broken warp option for the InitialMapCommand ResizeMove command. Doesn't warp the mouse to the window at all. Does it's own thing, instead of warping the mouse pointer to the window.

Actual Behaviour

Does what it wants, not what you want. Doesn't warp to window.

Enabling logging

fvwm3 has a means of logging what it's doing. Enabling this when
reproducing the issue might help. To do this, either change the means fvwm3
is started by adding -v as in:

[1737756241.192131] FScreenInit: Using RandR 1.6
[1737756241.237415] scan_screens: Case 1: Add new monitors
[1737756241.237540] monitor_mark_new: Added new monitor: eDP-1 (0x56b458aa3380)
[1737756241.292554] main: Loading window states via (null)
loaded [0]: /home/test/.fvwm/config

or, once fvwm3 has loaded, send SIGUSR2 as in:

pkill -USR2 fvwm3

The resulting logfile can be found in $HOME/.fvwm/fvwm3-output.log

Steps to Reproduce

How can the problem be reproduced? For this, the following is helpful:

  • Reduce the problem to the smallest fvwm configuration example (where
    possible). Start with a blank config file (fvwm3 -f/dev/null) and go from
    there.
    Minimal config to reproduce:
    Key C A M Exec exec xterm
    Style xterm InitialMapCommand ResizeMove 100p 100p 100p 100p Warp

  • Does the problem also happen with Fvwm2?
    I don't know. Don't have fvwm2.

Include your configuration with this issue.

Does Fvwm3 crash?

No.

If fvwm3 crashes then check your system for a corefile. This is platform
dependant, however, check if:

  • corefiles are enabled (ulimit -c)
  • A corefile might be in $HOME or /tmp/.
  • If you're using Linux (with systemd), check coredumpctl list.
    coredumpctl may need installing separately.

If you find a corefile, install gdb and run:

gdb /path/to/fvwm3 /path/to/corefile

If you're using coredumpctl then use:

coredumpctl debug

Then from within the (gdb) prompt, issue:

bt full

... and include the output here.

Extra Information

  • Anything else we should know?
    Surprised nobody uses this option or that it was never tested. It isn't complex, just not functioning.

  • Feel free to take a screen capture or video and upload to this issue if you
    feel it would help.

  • Attach $HOME/.fvwm/fvwm3-output.log from the step above.
@WhyIsFVWM3soBuggy WhyIsFVWM3soBuggy added the type:bug Something's broken! label Jan 24, 2025
@ThomasAdam ThomasAdam self-assigned this Jan 24, 2025
@ThomasAdam ThomasAdam added this to FVWM3 Jan 24, 2025
@github-project-automation github-project-automation bot moved this to To do in FVWM3 Jan 24, 2025
ThomasAdam added a commit that referenced this issue Jan 24, 2025
@ThomasAdam
ResizeMove: Make Warp imply WarpToWindow
cbe3f36 
When asking for the pointer to be moved via the ResizeMove command, use
the WarpToWindow command to move the pointer centrally instead, rather
than the relative offset.

Fixes #1160
@ThomasAdam ThomasAdam mentioned this issue Jan 24, 2025
Merged
@ThomasAdam
Copy link
Member

@WhyIsFVWM3soBuggy

Aside from the antagonistic throwaway account you've created to keep reporting an issue you've already raised on the forums, by all means take a look at the ta/gh-1160 branch which ought to help resolve this issue.

Please let me know how you get on.

@WhyIsFVWM3soBuggy
Copy link
Author

Yes, this was raised on the forum, where you said you wouldn't be paying attention to it there and wanted me to open a new account to create this. Just following your orders.

As for you saying it's antagonistic, I have other bugs to report, so it seems pretty accurate from my end. As for the throwaway account, this is my only account here. Can you elaborate on why you think it's a throwaway account?

I got on all right, but not until I opened this and you linked to the solution, that isn't in the man pages. Seems the man pages don't get update as often as they should. But I am sure this isn't by design. :)

@ThomasAdam
Copy link
Member

I got on all right, but not until I opened this and you linked to the solution, that isn't in the man pages. Seems the man pages don't get update as often as they should. But I am sure this isn't by design. :)

Not sure what you're referring to here. We don't actually say in the man page either way, how/where the pointer is warped to, so I don't see a need to change any of the existing wording.

Anyway, may you let me know when you've been able to test this, and I'll merge it.

@WhyIsFVWM3soBuggy
Copy link
Author

You don't see how being specific is better than being ambiguous? Then that total explains your efforts regarding maintenance of the documentation. I'll try to keep that in mind when trying to decipher the rest of the man page.

Also you forgot to mention how this is a throwaway account. But I guess attention to detail is not in your purview.

@fvwmorg fvwmorg locked as too heated and limited conversation to collaborators Jan 24, 2025
@ThomasAdam
Copy link
Member

Unfortunately, I've blocked @WhyIsFVWM3soBuggy at the fvwmorg organisational level, as I think that's the right thing to do for the project.

This change however will go in for 1.1.2

@fvwmorg fvwmorg unlocked this conversation Jan 24, 2025
@ThomasAdam ThomasAdam added this to the 1.1.2 milestone Jan 24, 2025
@ThomasAdam ThomasAdam changed the title InitialMapCommand ResizeMove: warp option doing it's own thing, was this ever tested? InitialMapCommand ResizeMove: warp not moving pointer to new window location Jan 24, 2025
ThomasAdam added a commit that referenced this issue Jan 25, 2025
@ThomasAdam
ResizeMove: Make Warp imply WarpToWindow
9456479 
When asking for the pointer to be moved via the ResizeMove command, use
the WarpToWindow command to move the pointer centrally instead, rather
than the relative offset.

Fixes #1160
@github-project-automation github-project-automation bot moved this from To do to Done in FVWM3 Jan 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ThomasAdam ThomasAdam

Labels
type:bug Something's broken!
Projects
FVWM3
Status: Done
Milestone
1.1.2
Development

Successfully merging a pull request may close this issue.

ResizeMove: Make Warp imply WarpToWindow fvwmorg/fvwm3
2 participants
@ThomasAdam @WhyIsFVWM3soBuggy