Blog

Resizable edges allows moving windows in Lion

In the old days of Mac OS 8 and 9, windows had a tick border and you could click and drag anywhere in that border to move the window around. This disappeared in Mac OS X when windows became borderless. Mac OS X Lion still has borderless windows, but if you know where to click you can move many windows around from the edges.

What changed in Lion is that resizable windows can now be resized from every edge. But windows still are borderless. So how does it work?

Each resizable window has an area around it that you can drag to resize the window. One part of this area is inside the window content, the rest is outside. You can observe this area by looking at how the mouse pointer changes to a resize pointer when you move it around the edge.

If you just click in the area inside the window near the edge (the orange overlay in the picture above) but do not drag, the click will do whatever normally happens when you click in that area of the window. If you click and drag, then the window will resize. Except that you must drag in the right direction: if you click on the left border and drag down you’ll exit the window resize mode and what happens is whatever normally happens when you click and drag in that area of the window (in TextEdit it would select some text for instance).

If you just click in the area just outside the edge (the green and blue overlay in the picture above), nothing happens. If you click and drag, the window will resize. But if you are dragging a border, and are dragging up or down on a vertical border or right or left on a horizontal border, your drag will move the window instead. Once the window has started to move, you can move it in any direction.

So the blue area in the picture above is where you can click to drag the window, but you have to start the drag parallel to that border. Note that this only works for resizable windows: windows which are not resizable don’t have those special invisible areas on the edges.

Getting to the dock in Lion's full screen mode

Mac OS X 10.7 Lion has streamlined full screen mode for many apps. Full screen mode get you in a distraction-free where the menu bar and the dock are hidden you only see one window covering the whole screen. Getting to the menu bar is easy: move your mouse pointer at the top and it’ll reveal itself. The dock is as easy: move your mouse pointer to the bottom and let it slide back… or is it?

Something funny is going on here. If you move the mouse pointer at the bottom, nothing happens. If after getting at the bottom you stop, then try to get further down, then you’ll see the dock slide into view.

That’s a clever fix for the problem of reaching a UI elements at the bottom of the screen without having the dock slide it to obstruct whatever we wanted to reach. But I can’t stop wondering whether it’s just too clever. How are normal people supposed to discover this trick? Won’t it just look like some odd erratic behaviour? Time will tell…

Magic Launch goes to Metakine

It’s been a year and a half since my first release of Magic Launch in January 2010. It is now used by hundreds of people who wants to regain the productivity of when creator codes were still honored by the system or by people who wanted to define by their own rules which app to use opening a document. Magic Launch will continue to live on, but it has now found a new home.

Today, I’m handing Magic Launch to Metakine who will be the one to handle future sales, development, and technical support for this product. Or if you already are a customer, Metakine will soon email you a new licence code so you can use the Metakine version of the software.

On my side it won’t change things much because I haven’t been devoting much time to Magic Launch since the beginning of this year. Given that the last release dates from December of last year, updates are without doubt going to be more frequent and interesting now that Metakine is in charge.

I wish good luck to Metakine going forward, and good luck to myself with my next application…

Objective-C reference counters

It’s interesting to look at the Objective-C runtime. I’ve been doing that a lot recently to bring D/Objective-C to life and found a couple of interesting things. For instance, do you know where the reference counts are stored?

They’re split between eight global hash tables in Core Foundation, each table protected by its own spin lock. The table is chosen according to a few bits in the object’s address… On iOS there’s only one global hash table. I guess all this is to avoid contention on multi-core machines. It’s still unexpected they don’t store the counter as a variable within the object itself.

I find it unexpected however that they’re not simply storing the reference counter directly as a variable inside the object. I guess there’s an advantage to gain by doing things like they do, but I don’t see it.

Reference: Runtime.c in Core Foundation’s internals