search

psifidotos / applet-window-buttons

Plasma 5 applet in order to show window buttons in your panels
GNU General Public License v2.0
403 stars 56 forks source link

Top-most maximized controls #100

Closed roracle closed 3 years ago

roracle commented 4 years ago

My setup works like this: if window is not maximized, the window controls are on the window itself, and slide out of the panel. When it is maximized, the controls go to the latte-dock top panel. But I had a suggestion, and didn't see the option for it in the settings:

So you have a web browser opened, then open Dolphin to get a file you just downloaded. The web browser is maximized, but Dolphin is not. Dolphin is on top of the web browser.

The suggestion: The top-most maximized window should be what the applet controls in this scenario. This way if I want to close the web browser while a non-maximized Dolphin is on top, I can click the applet close button and it closes the web browser, leaving Dolphin to its own controls.

I hope this has made sense. But I will clarify a few things for behavior as well: If no window is maximized, it should be able to hide. If any window is maximized, the applet should remain showing even if you're not in that window, but control that maximized window instead of anything not maximized in front.

I feel if this can be done, it would fully complete the window controls setup for my system, taking me one step closer to having a functioning user-friendly desktop Linux experience.

To see what my system looks like in action (sans the mentioned suggestion issue), here's a link to a video I did yesterday/this morning: https://www.youtube.com/watch?v=Q571XWR9vas

Please respond if you need more information!

All the best, ~roracle

roracle commented 4 years ago

EDIT: The purpose of this functionality was explained by the KDE VDG regarding the "muscle memory" of users. They'll WANT to close a window from the window itself if it isn't maximized, but the way it's set up, they'll always be closing it as though it is maximized.

In order to fix this problem, it would seem evident that showing the controls for a topmost maximized window (even if it isn't on top) would be the most beneficial option.

psifidotos commented 4 years ago

Funny... Where is the discussion of VDG is order to clarify my objectives?

roracle commented 4 years ago

It was while talking about my desktop setup, in the chat. I don't think what they said is the issue, and perhaps I didn't even need to bring them up at all. But I did for transparency on this situation.

Bottom line is this: if the topmost maximized window could show the window controls regardless of if it's in front and be active for that maximized window, it would solve a problem I'm having with this setup.

psifidotos commented 4 years ago

It would mess thing a lot. In order to to provide this window title, appmenu, active window behavior from Latte panels etc must be adjusted and behave all with the same way. This is not possible, so even though I had the same idea when I was adding window functionality at top panel and applets in the end the entire experience was broken.

Your solution in Latte panels and all applets including AutoColoring are tracking last active window per screen.

roracle commented 4 years ago

There is no way to find out which window was the last maximized and assign it to the controls? I mean it would have to be an option that can be toggled, as people might use your widget in a different way.

psifidotos commented 4 years ago

No I wouldn't, because adding such option will make users afterwards to request all other applets and parts to follow that paradigm, and when we would reach autoColoring then nothing can be done.

Feel free to contribute and test it out on your own.

roracle commented 4 years ago

I don't know how to code much at all, I'm more a designer type, an artist. Compile, edit code, etc? Sure. Actually coding it? That's out of my scope. :(