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

Running a full screen game doesn't open it for the whole screen #2524

Closed
rinnarii opened this issue Feb 3, 2024 · 6 comments
Closed

Running a full screen game doesn't open it for the whole screen #2524

rinnarii opened this issue Feb 3, 2024 · 6 comments

Comments

@rinnarii
Copy link

rinnarii commented Feb 3, 2024

Expected Behavior

Running a game from application menu that is set to full screen should do as such

Current Behavior

It opens the game on a partial part of the screen which is not showing the whole window and without the minimize/maximize/close

Possible Solution

Does the application launcher does things differently when launching wine?

Steps to Reproduce (for bugs)
  1. Create .desktop file with Exec=wine /home/user/BattleRealms/Battle_Realms_F.exe
  2. Run the newly created application entry.
Context

When I launch it from PCManFM-Qt it just full screened just fine. Same with going to the directory with the terminal and doing wine Battle_Realms_F.exe.
Or to make it work when launching from the application launcher, it should be wine start /max Battle_Realms_F.exe
Somehow when it's launched from the application menu its just on a small window and the graphics doesn't fit on it.

System Information
  • Distribution & Version: Arch Linux
  • Kernel: linux-lts-6.6.15-1
  • Qt Version: 5.15.12+kde+r150-1 or 6.6.1-3
  • liblxqt Version: 1.4.0-1
  • Package version:
@tsujan
Copy link
Member

tsujan commented Feb 3, 2024

This may be related to the window manager and how it opens a window when a menu is closed simultaneously. Have you tried another WM? You didn't say which WM you use.

@rinnarii
Copy link
Author

I didn't try changing the WM from the default one, which I assume is Openbox

@tsujan
Copy link
Member

tsujan commented Apr 26, 2024

There's no default WM, and Openbox is dead.

Closing because the WM is responsible for these things, not LXQt.

@tsujan tsujan closed this as completed Apr 26, 2024
@rinnarii
Copy link
Author

rinnarii commented May 4, 2024

So should I report the bug to Openbox instead?

Btw when I installed lxqt on arch, the package group contains openbox that it uses, thats what I meant default.

And what wm does lxqt usually used with these days?

@stefonarch
Copy link
Member

So should I report the bug to Openbox instead?

Its development has stopped...

And what wm does lxqt usually used with these days?

What users or distros choose. Debian ships it with xfwm4, me under x11 use mostly kwin, althought I'm 99% of the time on wayland using labwc, but this requires at least compiling the panel from a PR here and some other hacks.

@tsujan
Copy link
Member

tsujan commented May 4, 2024

but this requires at least compiling the panel from a PR here and some other hacks.

A Wayland session is really too soon for ordinary users, especially because they can't use git.

And what wm does lxqt usually used with these days?

As mentioned above, under X11, xfwm4 and kwin_x11 are very good WMs that come with their own compositors (you need to disable any other compositor you may have used with Openbox), but there are also other good WMs (which I haven't tried).

Openbox is dead, although it can still be used by many. However, it has bad issues that will never be fixed, especially with multi-screen settings but not limited to them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants