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.

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

Tk based apps are not getting allow with being swallowed by fvwm. Issue seen in both fvwmscript and fvwmbuttons #925

Open
hyegeek opened this issue Nov 17, 2023 · 1 comment
Assignees
Labels
type:bug Something's broken!

Comments

@hyegeek
Copy link

hyegeek commented Nov 17, 2023

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.0.8 (released)

  • Linux distribution or BSD name/version
    Gentoo

  • Platform (run: uname -sp)
    Linux AMD Ryzen 5 7600X 6-Core Processor
    (also happens on other systems)

Expected Behaviour

When a tk based app with a menu button is swallowed by fvwmscript or fvwmbuttons, clicking on the menu should display that menu by the button. When the swallowing app moves, the menu display should move with it.

Actual Behaviour

When a tk based app (tried with both perl and python) has a menu button, the menu appears where the app originally displays not where it is in the swallowing window. Moving the swallowing window does not move where the menu appears, so it seems tk is not recalculating menu positions so it is probably missing some sort of event.

Enabling logging

Let me know if I need to produce a log. Should the log be on a newly run fvwm3 or is it OK if it has been running for days/weeks?

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:

fvwm3 -v

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

I can provide one of my scripts and let you swallow it, display the menu and then move the swallowing window and display again.

  • 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.

  • Does the problem also happen with Fvwm2?

Don't know. It's been a while since I've run fvwm2

Include your configuration with this issue.

Does Fvwm3 crash?

No.

Extra Information

  • Anything else we should know?

  • 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.

@hyegeek hyegeek added the type:bug Something's broken! label Nov 17, 2023
@ThomasAdam ThomasAdam added this to the 1.0.9 milestone Nov 17, 2023
@ThomasAdam ThomasAdam self-assigned this Nov 17, 2023
@hyegeek
Copy link
Author

hyegeek commented Nov 20, 2023

In order to try to get to the bottom of what's going one, I added an event handler to my tk script to catch all configure events. When the script runs on it's own, it gets lots of config events as it moves around the screen. When the script is swallowed an the swallowing windows is moved, the script does not see any configure events.

@ThomasAdam ThomasAdam removed this from the 1.0.9 milestone Dec 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug Something's broken!
Projects
Status: To do
Development

No branches or pull requests

2 participants