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

Hide scratchpad when switching window to full-screen #340

Open
wilhelmy opened this issue Apr 21, 2022 · 11 comments
Open

Hide scratchpad when switching window to full-screen #340

wilhelmy opened this issue Apr 21, 2022 · 11 comments

Comments

@wilhelmy
Copy link
Collaborator

When switching a window from the scratchpad to fullscreen-mode, the scratchpad stays in front of the freshly full-screened window. It should be hidden.

Furthermore when switching fullscreened scratchpad window back to its normal size, the scratchpad gets focused correctly but is put in front of the wrong desktop, rather than the last active one.

@wilhelmy
Copy link
Collaborator Author

wilhelmy commented Feb 2, 2023

About the first point:

lua> mod_sp.is_scratchpad(ioncore.current():manager():manager())
true

This seems to identify scratchpad windows. Now my approach would be to put a check like this into ioncore/fullscreen.c, but it shouldn't include code from mod_sp. So what's the alternative? Wrap the keybinding for Mod+f or whatever is the fullscreen keybinding in a lua wrapper? @raboof

@wilhelmy
Copy link
Collaborator Author

wilhelmy commented Feb 2, 2023

I've come up with the following code:

function toggle_fullscreen(arg)
	local parent = arg:parent()
	local r = WGroup.set_fullscreen(arg, 'toggle')
	if mod_sp and mod_sp.is_scratchpad(parent) then
		mod_sp.set_shown_on(arg:manager(), 'toggle')
	end
	return r
end

defbindings("WGroupCW", {
    bdoc("Toggle client window group full-screen mode"),
    kpress_wait(META.."F", "toggle_fullscreen(_)"),
})

Opinions?

Edit: It does however not solve the second half of my issue, namely that returning a scratchpad window from fullscreen returns it to the right scratchpad but in front of the wrong workspace.

@mjf
Copy link

mjf commented Feb 16, 2023

@wilhelmy This solves the case when you use specific key binding to toggle full-screen mode of a window but it does not solve the cases when the application toggles to full-screen itself such as Alt-Enter in XTerm of F in MPlayer etc.

@wilhelmy
Copy link
Collaborator Author

Thanks, I guess fixing it correctly is a bit more involved. The main problem I haven't solved is that I want to avoid adding a dependency to mod_sp to the core code handling fullscreen.

@raboof
Copy link
Owner

raboof commented Feb 25, 2023

Thanks, I guess fixing it correctly is a bit more involved. The main problem I haven't solved is that I want to avoid adding a dependency to mod_sp to the core code handling fullscreen.

Do you think it's still a net improvement to merge it?

@wilhelmy
Copy link
Collaborator Author

I wouldn't want to merge this snippet into the default config in this state, because everyone would need to edit their config in order to use it and the real fix would then make all those config changes obsolete again. I think it can live in this issue until we have a complete fix, and people who care about it can use it locally?

@mjf
Copy link

mjf commented Feb 27, 2023

I've come up with the following code:

Opinions?

Hello @wilhelmy,
have you tried it with multiple workspaces? I've just tried it on a screen with 2 workspaces, one tiled and the second one "empty". When I open a scratch pad and a terminal in it, then press META+F, the terminal gets fullscreen but when I pres META+F again to "unfullscreen" it I end up in the second workspace (the scratchpad shows OK with the terminal "swallowed" again in it, but it appears on a wrong workspace). I am not sure why this is... The issue occurs only if META+F toggled application is in scratchpad, otherwise it seems to work correctly.

@wilhelmy
Copy link
Collaborator Author

Furthermore when switching fullscreened scratchpad window back to its normal size, the scratchpad gets focused correctly but is put in front of the wrong desktop, rather than the last active one.

@mjf that's the second part of this issue for which I unfortunately haven't had the time to diagnose it yet.

@mjf
Copy link

mjf commented Sep 17, 2024

@wilhelmy Hi after some time passed. I guess you had no time to look into this more further, right?

@wilhelmy
Copy link
Collaborator Author

Thanks for reminding me. @raboof's efforts seem to have switched to volare (based on sway) and I didn't find much time or motivation for FOSS development recently outside of work. Gotta take some time off and take another look, I guess. Or wait until I'm unemployed with too much time on my hands :)

@raboof
Copy link
Owner

raboof commented Sep 20, 2024

Thanks for reminding me. @raboof's efforts seem to have switched to volare (based on sway) and I didn't find much time or motivation for FOSS development recently outside of work. Gotta take some time off and take another look, I guess. Or wait until I'm unemployed with too much time on my hands :)

TBH I'm currently neglecting both equally ;) - but indeed using Volare as my daily driver for now

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