Stateless Blog
Month
Window management and virtual desktops are, at least for me, a couple of the most important features an operating system provides in my day-to-day workflow. I do a lot of (re)arranging, resizing, and switching between windows. Being able to manage this via keyboard shortcuts is important because that’s where my hands are most of the time. I don’t want fancy gestures or GUI nonsense, I want something simple and efficient.
Unfortunately, OSX is lacking in this area out of the box - which I didn’t expect when I moved over from my linux setup 3 months ago. The good news is that I’ve found a couple of settings and (paid) apps that fill in the gaps and cover my basic requirements.
Virtual desktops on OSX are called ‘spaces’. Basically, you have a grid of spaces (I use 3x3 at the moment) in which you place groups of windows. Some of my spaces contain just one full-screen window e.g. I have one space exclusively for general web browsing, and others have multiple windows on them - my dev space has a text editor (MacVim), terminal(s), etc.
For me, the main benefit of arranging windows into separate desktops like this is that I can group them according to activities. This should (but doesn’t on OSX) mean that when I do something like cmd+tab, I’m only picking from the set of windows available on the current desktop. Instead, when you cmd+tab on OSX - you will get a list of every single application that’s running regardless of what space its on, and what’s more if you pick an application that’s in a different space (easily done) it will zoom you off to another space.
The zooming-you-off-to-another-space problem can be addressed by a spaces setting in your system preferences, by unticking the following checkbox:
Changing to show only the current space’s windows can’t be achieved by OSX alone. There’s an app that can help though called Witch. Witch has lots of settings but the two key ones for this purpose are:
Under 'Triggers’, rebind 'All applications’ to cmd+tab. It’ll give you a warning, just hit ok and ignore it.
Under 'Behavior’ untick 'List windows from all Spaces’.
–
There’s a couple of additional things that I got used to with my old linux setup that I didn’t get with OSX, keyboard shortcuts for:
Both of these features are provided by an app called SizeUp.
SizeUp allows you to quickly position a window to fill exactly half the screen (splitscreen), a quarter of the screen (quadrant), full screen, or centered via the menu bar or configurable system-wide shortcuts (hotkeys). Similar to “tiled windows” functionality available on other operating systems.
The necessary options can be bound under the 'Shortcuts’ tab when you open the SizeUp app.
–
So here’s a summary of my shortcuts (and where they’re set):
I’m interested to know if anyone else use a smiliar setup, and if there are better approaches..
Mike
@mikekelly85
I believe the current proposal for offline web applications is too complicated, fiddly, and brittle. There is a cleaner and more efficient approach which makes better use of existing mechanisms of the web to negotiate and manage “offline assets”. Here’s a brief summary:
The essence of this proposal is that a proper solution to the offline web app problem should not require drawing a distinction between “offline” and “online” assets. There is no need for ‘cache manifests’, or to create a separate 'application cache’ from the standard browser cache.
This solution should leverage existing web caching infrastructure (i.e. HTTP headers such as Cache-Control, Etags, etc) to control how browsers store and negotiate the assets required to run the application offline.
Key to this solution would be browser cache compliance with the HTTP Cache-Control Extensions for Stale Content. In a nutshell, essential assets (html, javascript, css, etc) of the application required for offline usage would be served with a 'stale-if-error’ directive in the Cache-Control header. When the browser is taken offline and the origin server cannot be reached, all of these assets will be served out of the cache (due to the stale-if-error directive) and the application will continue to function.
That’s pretty much it.
There is one significant hurdle here, and that is the limited capacity and reliability of local browser caches. However, a relatively simple solution would be to create a new HTTP header with which a server can indicate the cache storage requirements of its application (by domain). Something like
> GET / HTTP/1.1 > Host: myapp.com > ...
< 200 OK < Cache-Storage: 160M < .....
If this is the first time the browser has encountered this app then the user is prompted to grant access for the domain to reserve the disk space to 'install the offline app’. The user can then either accept, or reject (and optionally remember their choice).
Alternatively, the cache-storage value could be expressed as metadata in the <head> of the application’s main html document, however this would result in the pattern being unusable outside of html apps.
Either way, this would offer a familiar experience for users; where they are asked to 'install’ an offline web app in much the same way they would be by traditional desktop software.
When the reserved storage is full, any assets that were served with a stale-if-error directive must take priority in the reserved storage over those that weren’t.
Application developers can manage the way updates to individual assets are negotiated using HTTP’s standard caching mechanisms such as Cache-control max-age and ETag validations.
So that is the general gist of the proposal.. if anyone is interested let me know - perhaps we could try and flesh it out a bit more and push it forward.
Cheers,
Mike
@mikekelly85