This looks very promising! It's also brand new, just released this month. I've already downloaded it and will start putting it through its paces.
I understand fully. I just don't understand what benefit that gives you, especially in this case, because the large window is all white space on its right 40%. So you could reduce the window to 60% and both windows would fit on the screen without overlap and without any loss of information.
I seem to recall 30 years ago I was using a version of Unix, possibly Solaris, which allowed hidden windows to receive keyboard focus, but I didn't use that feature because it really wasn't helpful.
None at all. In this case.
I used two windows as examples that everyone here is familiar with: the KM Forum and the KM Editor.
As for the rest, I respectfully disagree ![]()
And I can probably solve that specific problem by creating a floating Custom HTML window above the browser, and I could display a macro inside that Custom HTML action. There's your floating window solution for that situation. You might reply, "but I can't edit the macro with your solution." That's true, but you can't edit the macro in your given example either, because as a floating window you can't focus it.
Which part of
didn't you understand?
You don't need floating windows. That's fine. Others need them. For completely different purposes. It's all good.
It's a floating window, and I could edit a macro, write text, or do whatever else you can do in a window in an app, floating or not.
Then you have to explain when a floating app becomes the focussed window and when it is not focussed. At no point in this thread has that process been explained. I even asked earlier if one could have two floating windows at the same time, and nobody answered. I asked how would overlap be handled? Nobody answered.
Once a "floating window" is focussed, it's up front, so there's nothing really "floating" about it any more. It's just a regular focussed window. Once it's floating, it cannot accept keys or mouse clicks. Right?
I like challenges. And now I think I might be able to solve this problem completely, but it would require two displays, and one of those displays would have to be reserved exclusively for my macro. Would that be an acceptable solution for you?
Not with ⌘Tab, but you can focus it by clicking on it.
Substantial benefits, particularly, if, like mine, your primary machine has a 13" screen and you need to see one thing while working in another. I would much rather have multiple monitors, but Apple only allows for two total screens, and monitors aren't as easily portable as the Macbook. In a pinch, I do occasionally use an iPad as a second screen, but not if I need to move focus back and forth between them because it gets very laggy.
Very few, in fact, so far only two of my use cases for floating windows could be solved with the custom HTML action. [...] I was in the process of typing out several of my use cases for which a custom HTML prompt wouldn't work, but as I was thinking about it...am I crazy, or is it actually possible to make a dynamic custom HTML prompt look like an app widget and have it be capable of updating the app after I've marked something completed? Hm. Would that require the macro to be running the whole time, though? That wouldn't really work. But OmniFocus has a lot of scripting support, so maybe a button to click when I'm done with the window can send the info from the floating 'widget' back to update OmniFocus. Hmmm...
(It still wouldn't work to keep a whole app on top, though, e.g. iPhone Mirroring as I have already lamented. And I still desperately want compact little floating dictionary widgets that I can sprinkle wherever I need them, but I don't think there's a solution to that beyond custom software.)
Yes, two or more at the same time. I would expect the overlap to be handled the same way KM handles its multiple floating windows, whichever was last active is the one on top of the others.
A floating window is focussed when it's clicked on and being interacted with. It is not in focus when you click on or ⌘Tab to any other app.
Nope. You can focus a floating window by clicking on it with the mouse.
[edit] I think I may have answered some questions twice, sorry about that.
Thanks a lot NaOH, I will mark your answer as a solution because :
-
KM seems limited because of Apple private API. The workaround is too “expensive” I would say.
-
Floaty clearly answers the need with a clean approach.
Thanks everybody for your help on this case!
Apparently there's another new app for this kind of goal: AlwaysOnTop. It's a one-time US $10 purchase.
Thanks for the tip, @NaOH. If I understand correctly, however, it's just an app that lets you float its own windows. That's probably not what most people are looking for.
I hadn't watched the demo video. Looks like you're correct. Thanks for catching that.