I work at a ~1200 person company, been using GWT since I think 2012, before I joined. It's a mixed bag - it's clunky as hell sometimes, and we have been iteratively replacing it with React in places. Buuuut at the same time I'm often marveling at how amazing it is what they accomplished getting Java->JS compilation working like that. It's a very productive framework if you know how to actually use it. And that's tough to do
I think you wrote the announced and effective dates twice. Effective date being 31 of January as far as I can tell. The whole point of Docker monetizing Docker Desktop is so that they can continue to be funded to maintain the base images themselves. That's the primary sell point of DockerHub.
How does "focus follows mouse" work? If I'm understanding; your desktop is a collection of various sizes windows, maybe overlapping and stacking. If your mouse goes off the side of the one you're focusing, it will auto focus the one you're now hovering over. Won't this lead to accidents where you'll have a larger window suddenly gain focus, with no way to see the old one and re-focus it? Seems easy to make a mistake.
This maybe would be solved by a window manager that enforces never allowing windows to stack depthwise? Which OSX doesn't have of course. Just size-and-position-hotkey workarounds
Nope, what you're describing is a mistake in focus-follows-mouse, one which has been made more than once.
In real, XWin-style focus-follows-mouse, the window you mouse over gets the focus, but, isn't pulled to the front. If you click, it gets the front and the focus.
I use Moom, a semi-tile snap-style window wrangler, and a widescreen with three panels. What I want to do is just slide the cursor over and start typing, but I have to remember to click, and often enough I just don't.
I remember setting some reasonable “raise timeout” and it worked well for me. For one use case, I had a workflow with two full-height overlapping windows (vim, xterm) and little mouse shifts toggled them up/focused.
Alt-tab didn’t work because its mru usually gets spoiled by other (browser) windows. If only there was a setting that fixed alt-tab mru into a stack. Alt-tab-tab to switch to app which started second may be much better than mru for some workflows, because you can always predict what it does with certainty of 1.
I actually have it set to not raise even on click; I often want to click just one thing in a window that is behind other windows. Moving a window brings it to front and I bind windows-click-drag to move a window. That lets me raise any window I like.
same. i don't raise on click. this is incredibly useful when a smaller window is
in the foreground--and perhaps a window underneath is maximized--and i just need to
select/copy something from the background real quick. the main task i am
working on is in the foreground, and i don't want its window to immediately vanish from my
sight because it's mentally and visually disruptive (in fact, i usually don't want to
blast every other window out of sight when the maximized window raises either). i will
easily raise the background window when i need to (in a variety of ways, depending
upon whether i am currently using keyboard or mouse); meanwhile, i can lazily
focus it and interact with it while all my windows stay put. it's very calming.
I was unable to cagro install it, had a bunch of build errors. Decided to brew install it instead, and although its a major version behind the github release, it works as advertised!
