WindowMizer

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

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

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

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

Hi Lee,
Unfortunately not. The race-was-on to get WindowMizer notarized - which I just completed. So after of answering a few months worth of forum messages, I'll try a test build to see what happens if I just move the WindowMizer window to a "higher" layer.

In order to determine if a window is aleady floated, I would have ti discern that info from somewhere. I'll be lloking into how "scriptable" AFloat may be, and if there is a way for me to distinguish a loated window from a non floated one. Maybe AFloat simply puts the window on a higher layer - in which case I can obtain a window's layer number

It's still gonna be a while but I will give it a shot.

Chris

Thanks for getting back on this. It's all good, Chris. Congrats on getting WindowMizer notarized. I'm not in a hurry, but good to know this neat little feature is still in the pipe. Above all your WindowMizer project is about having fun along the way, isn't it ..

..on 2nd thought: I'd say that incorporating Afloat into the equation is rather 2nd stage because only few people are using it. 1st stage I think would be the option in WM prefs to always set rolled-up Windows on-top, regardless of Afloat or alike, assigning your own layer order (last rolled-up Window topmost as default most likely).

I think stage 1 first and only and see how it rolls with users, then stage 2 (Afloat etc.) later will keep your workload as small as possible

I've added Floating window options to WindowMizer version 5.0.5.

Please review when you can and advise if this implementation is helpful.
I suggest testing by "floating" a single application's windows. To float windows in Activity Monitor for example, you would follow these steps:

1) Go to WindowMizer Preferences > Applications
2) Add an app to the list.
3) Set the "Collapsed Window layer" to "Floating Window layer".

Alternately, you could choose to float windows in ALL applications by following these steps:

1) Go to WindowMizer Preferences > Advanced
2) Set "Default Collapsed Window layer" to "Floating Window layer".

That's great news, thanks Chris! Screenshots look very promising. Just got back from a trip - give me a few days to test thoroughly and feedback.

Hello Chris, here's my feedback:

When I drag an item over a collapsed Window (e.g. an image or webloc address I drag from any Browser window into a collapsed Finder window floating on-top), the title bar does not un- or de-collapse automatically but stays shut, keeping the item from getting placed into the file system.

When I un-collapse the window, it disappears in the background once I start dragging the image. In other words, back to square one.

Would it be hard to introduce a function "un-collapse on mouse-pointer hover"?
(and possibly in a 2nd step, collapse again once the mouse pointer leaves the Window again?)

I hope I could get the functionality across well enough