Windows rolled up into title bar don't float ontop (not "sticky")

Discuss problems, bugs or feature requests for WindowMizer version 5.x.
Post Reply
LeeBinder
Posts: 3
Joined: Sat Jan 26, 2019 11:50 am

Windows rolled up into title bar don't float ontop (not "sticky")

Post by LeeBinder » Sat Jan 26, 2019 12:06 pm

Hello RGB World. I just now started testing WindowMizer 5, but a core feature is completely missing: that Windows rolled up into title bar remain afloat, or "sticky" as some people say. I do not even see any such option in WindowMizer 5 Prefs. I'm sad :(

In addition, WindowMizer 5 is not compatible with the SIMBL Plugin Afloat, which enables that feature via a keyboard shortcut: Windows rolled up w/ WindowMizer 5 become oblivious to Afloat.

Double whammy :(

Can you please add this core feature in Prefs, please? Without it, WindowMizer is losing lots of its sense because one might as well minimize rolled up Windows, rather than having to search for their small title bar line afterwards.

Thank you and enjoy your weekend,
Lee

PS: I'll be offline now for about a week and can't reply to your reply until then

User avatar
rgbworld
Site Admin
Posts: 61
Joined: Sat Dec 05, 2015 5:42 pm

Re: Windows rolled up into title bar don't float ontop (not "sticky")

Post by rgbworld » Sat Jan 26, 2019 10:41 pm

Hi Lee,
Thanks for testing WindowMizer 5.

I'm not opposed to adding a "keep on top" or "floating window" option to WindowMizer. Please let's discuss exactly how that feature would work.

FYI, I'm really not a big fan of SIMBL, although in fairness, I only played with it for a short time several years ago. My concerns regarding installing SIMBL and/or AFloat are mainly future macOS compatibility issues. So, I don't care to install afloat, but hopefully we can discern exactly what a similar feature - built into WindowMizer, would do.

Currently, WindowMizer windows are implemented as normal (non-floating) windows and they are ordered and layered according to normal window layering. Also, WindowMizer windows (i.e collapsed or window-shaded) belong to WindowMizer and are stand-ins for the "real" window. Therefore, I am in complete control of the title-bar windows.

What I cannot do is make the "real", full-size, uncollapsed window become a floating window. I could create a full-size stand-in window, however the content would not be "live", instead it would only be an image of the real window's contents. I could make the stand-in window float, but without "live" content, it wouldn't be very useful as a floating window.

I have a few questions:
1) Are we talking about making the collapsed-window (i.e. title-bar only windows) stay on top, or the "real" window becoming a floating window?

2) When collapsing a window, would it automatically "float"? or does it have to be assigned to "float" by user?
If automatic, then I don't understand how every collapsed window would be a floating window. If user-assigned, I could "remember" a single (or possibly multiple) "floated" window(s), and anytime the "real" window is collapsed, I could automatically "float" the stand-in title-bar window. Just a thought.

3) Do the buttons on the floated window always remain active (i.e. colored red, yellow, green)? or do they become inactive (i.e. gray)?

Let me know your thoughts.

Chris

LeeBinder
Posts: 3
Joined: Sat Jan 26, 2019 11:50 am

Re: Windows rolled up into title bar don't float ontop (not "sticky")

Post by LeeBinder » Wed Jan 30, 2019 12:41 pm

Hello Chris,

thank you for your timely, thorough and exemplary reply. Great you're open for this feature.

SIMBL: I'm aware of its downsides, it's just that when migrating from Windows with WindowBlinds and comparing all the options for making Window frames stick to the foreground, Afloat clearly stuck out. Since I'll be sticking with High Sierra for now, and it's always performing as supposed for me, I'm 100% fine with it.

Answering your questions:

1) with Afloat already making the "real" window float (via keyboard shortcut), all that WindowMizer would need to accomplish is making the collapsed (title-bar only) window stay on top.

2) In WindowBlinds, when this is enabled in Options, any collapsed window automatically "floats". It seems unergonomic and confusing if the user had to decide for each single collapsed Window if it becomes afloat or not. Who appreciates or wants this feature can enable it in options.

Regarding floating order: I am not sure how Afloat (OS X) or WindowBlinds and Always-On-Top (Windows) handle the hierarchy code wise, but the effect is that that Window which is set afloat last has the highest foreground index. Analog to z-index in HTML, maybe if you start with i.e. 100 for the first Window's afloat value, the next one set float by the user would get index # 101, etc.

In regards to collaboration with Afloat, if installed and active, it sure would be optimal if WindowMizer indeed could detect if any Window to be collapsed has already been "floated" by Afloat and "remember" its state, and anytime the collapsed window is de-collapsed, automatically restore that state, regular or "float" (the exact afloat index in case of several afloat windows could be neglected, I would say).

3) With ergonomics being cross-platform and the wheel not needing to be re-invented over and over, glimpsing over to WindowBlinds again: the way Stardock handles it is that the buttons even on a floated window only remain active (i.e. colored red, yellow, green) until the user navigates into (mouse click, Windows switch etc.) a different window (then become inactive/ gray even in the floating window).

I hope I carried the picture along clearly enough. Hopefully this is not too hard of a feature to implement with Swift.

Thanks for your time and effort,
Lee

LeeBinder
Posts: 3
Joined: Sat Jan 26, 2019 11:50 am

Re: Windows rolled up into title bar don't float ontop (not "sticky")

Post by LeeBinder » Tue Apr 30, 2019 5:51 pm

Hello Chris. Just wondering: were you able to include any of the above into WindowMizer 5.0.2?

Post Reply