Tricks the Dock CAN'T do


Puny Member
The Dock is very inflexible. Here are a few examples of what the Dock cannot do:

• Switch between two apps easily using the keyboard

• Switch windows using the keyboard

• Split into categories

• Show item names without hovering the cursor over items

• Dock in non-primary monitor

• Minimize windows where the window used to be.

• Make minimized windows useful in any fashion. Even the preview is useless.

• NOT float

• Display custom contextual menu items.

• Store clippings

• Allow developers outside Apple who want to improve the Dock to do so
Originally posted by strobe
´æSwitch between two apps easily using the keyboard

Command-Tab and Command-Shift-Tab

Originally posted by strobe
´æSplit into categories

Not yet. I sent it in to Apple, and they're working on it, if those pictures at Think Secret were any good.

Originally posted by strobe
´æShow item names without hovering the cursor over items

Can the old application menu show the name of applications without both holding the mouse over it and clicking? And if you want to see the name of the program your running, just look next to the Apple menu. You can't even do that with the old application menu unless you have it expanded.

Originally posted by strobe
´æDock in non-primary monitor

Remember, we're running OS X 10.0.4 Public Beta 2? I bet this will be fixed in Puma.

Originally posted by strobe
´æMinimize windows where the window used to be.

Honestly, I'm glad they took this out, but for those of you who like it, that's your opinion. But that's not the Dock's problem, it just tries to make up for it. That's the window manager.

Originally posted by strobe
´æMake minimized windows useful in any fashion. Even the preview is useless.

If you want to make the windows in the Dock bigger, then open up the Dock preferences file and change the Magnify slider's maximum. It's not pretty, but it works.

Originally posted by strobe
´æNOT float

Why not turn hiding on? It's gone when you need it, but there when you don't

Originally posted by strobe
´ Display custom contextual menu items.

Apple's probably working on this, too.

Originally posted by strobe
´æAllow developers outside Apple who want to improve the Dock to do so

Nobody's stopping you from making your own dock, and changing it's type and creator codes and replacing the real dock with it. I made my own Finder and replaced it. It worked fine. (Hey, if you really wanted to, you could download Dragthing and replace the Dock with that.)
meanwhile back on earth...

I never mentioned the old application menu. I don't know why you bring it up.

If Apple wants to pretend the Dock is useful for storing documents and minimized windows they better provide an option to display the names of the documents and windows. Put two files with the same type in the Dock and you get identical icons. Same with URLs. Veeery useful.

If Apple wants to pretend that the Dock is useful for notifying the user like when you get mail, auto-hide is a joke.

Finally if you want to pretend the Dock is useful for notifying the user then how do you propose I replace the Dock? I use Drop Drawers which has an optional process drawer. I can switch apps using it, but it doesn't tell me when an app has changed it's Dock icon, when an app is receiving events, or allows me to select individual windows. Now if I had the Dock source I could replace it, or better yet improve it.

Let's stop fooling ourselves here. Without text it's useless for documents or minimized windows. Without source we can't replace or improve it. And let's face it, you don't need this gigantic waste of screen space to tell you the status of a particular app. Oh please, let me know that Stuffit is running by using up 48sq pixels of screen real estate! I could nit-pick for a whole week but I'd prefer to just edit the source. It's not like somebody can take this and port it to Windows, it links to exclusively OS X libs like CoreGraphics and Carbon.
hehe, I know what you mean, it is a silly wast of my processor and my ram. So, just re-name the dock (remane to something different), and then kill the dock and dockling server. Bam! no more dock.

Sure, its usefull, and sometimes I like it. But its a real drain when all you want to do is switch between windows and applications.

Don't get me started on FFM.....
Yea, kill the Dock, then what the heck is going to tell you which app wants you attention?

In Carbon there is a call which in MacOS will blink the process menu so you know not only that an app needs attention, but which app needs it. The Dock will eventually support this making it's removal all the more impractical.

Removing the Dock is not an option. It's an intergral part of OS X's HI and it'll only be more so in the future. If Apple doesn't open source the Dock it'll come down to disassembling it to see how to emulate the services it provides.

As for RAM and processor, I couldn't give a damn.
I don't really care what app wants my attention (yeah, developer's worst nightmare...).

On my computer, I do what I want to.

If I want to run afterstep and fu#$ aqua, I do it.

If wants me to know that it can't retrieve my mail, so be it. I'll find out eventually.

True, though, there are some notices that need to be addresses when they happen, so you certainly have a valid point.

On my linux box, I don't have an app-notification scheme. Things happen, and I get to them... not so smart sometimes... oh well.

Strobe, you know alot about the dock. Write your own.
Apple isn't going to open source the Dock. That would be like handing out porting OS X to x86 and and giving it away (not quite, but you get the point).
No, I don't get your point because it's too idiotic for comprehension.

The Dock links to libraries only found in OS X. Given the Dock source you could NOT port it to windows or any other OS!

As for replacing the Dock, I have already explained why that isn't possible without the source or without interpreting its disassembled code. If you would like to give it a crack type otool -tV /System/Library/CoreServices/
and have a ball

I always find these temperamental, world is ending, kind of threads amusing. I just simply like the dock and find it usable despite its "problems"

When all said and done we could find countless issues with 9.1, X, Windows, the telephone (want to talk about bad interface), the weather and etc.

kilowatt was right - life just goes on.

BTW strobe - don't be such a j@ck@ss. Flames like "No, I don't get your point because it's too idiotic for comprehension. " are totally unnecessary.

I don't care what application links to what libraries. Opening the source will give away some algorithms and ideas. I have ported plenty of code between platforms to tell you an application is a lot more than the libraries it links to and code can be easily adapted to multiple APIs.
The Dock doesn't have any algorithms. It uses CoreGraphics affine transform to do all those effects.

The Dock may be a very simple application that calls some sophisticated libraries but it exists and does *stuff*.

The mouse tracking with the scaled magnification is an algorithm.
{ for ( UInt32 i = 0; i < 10; i++ ) printf("You're missing the point"); }
is an algorithm. The Doc has freaken algorithms.

My point was not to argue the complexity of the toolbar type applications. My point was to say your previous response to mr_mac_x made you look like a condenscending j@ck@ass. If you had to look mac_x in the face eye-to-eye, would you have actually said his ideas were "too idiotic for comprehension." Think a little before you type.

Well designed applications, even simple ones, often have layers to abstract there *algorithms* from platform specific APIs. I am not saying the Doc has this approach but one could easily write adaptors to translate calls from the Doc application to, let's say, Window's GDI and process manager.
There is absolutely no way the Dock source could help in making a Dock-like utility for Windows. The APIs have absolutely NOTHING IN COMMON! Not the graphics, not the window manager (quartz services), not the notification manager, not the alias manager, not the apple events, not bloody anything!

I hate to break this news to you but at a previous position I wrote effective cross-platform adapters for

GDI vs Quickdraw
FSPec vs File Path
Alias vs Shortcuts (which have more similarities than most people realize)
QTML vs QTML (which was kind of easy - just some windowing and endian issues)
Mac Memory Manager vs ANSI C vs Wndows Memory Manager
many for PowerPlant vs MFC
just to name (remember) a few.

If two systems have the same basic behaviors, APIs can be molded to do whatever you choose. Often the behaviors can be made identicle with the appropriate layers.

There is a great book "Design Patterns" which discusses many of the techniques used.

Anyways Linux has the premise "you don't like it- you change it". Apple has no incentive to give its Aqua UI code away even to its customers.
I tend to use the Dock for the things it can do and for the things it can't do I use something else. This is a good approach to a lot of things, although I'm extremely peaved that I can't use a banana to open a can of tuna.

Uh Strobe, Aqua is Apple's marketing term for the user experience in MacOSX. The user experience is mostly comprised of the UI (user interface). This interface is made of the many complex, simple, and compound components. The Dock, Apple's new taskbar, is a UI component of Aqua.

I know you are struggling with the fact the Dock "has algorithms" but it truly does have its own source code. So if the dock is part of the Aqua UI and it has souce code then it can be said that the Aqua UI has source code.

Back to my original statement and what mr_mac_x was flamed for trying to express. It is not in Apple's best interest to open source any of its UI, including the questionable useful dock.

I apologize for the somewhat childish tone.
"You can't use a banana to open a can of tuna? That is idiotic beyond comprehension. I do it every day, without breaking the skin!"

Buh-dum-dumm! Don't forget to tip your wait staff ; )

But seriously folks, for how I use my Cube, I have no problems with the Dock, in and of itself. I actually like the minimizing to the Dock to get windows out of the way, but wish I could still double-click the title bar to windowshade.

I like the idea of switching quickly between two (2) apps through the keyboard. My workaround for this is moving my Dock icons around so that the two apps I plan to switch between are next to each other.

I also like the idea of a window always minimizing to the same spot--in theory. But my hypothesis is that this would cause more confusion in practice.

The only way I can see them accomplishing so much with the Dock through the keyboard would be to add a 'Dock' key to the keyboard like the nasty 'Windows' key on M$ systems (since Ctrl, option, and Command are already used to the max).

Again, I like the idea of the Dock icon being used to notify you when you hear a system beep--in theory. Maybe it could pulse slowly (like the 'sleep' light), or jiggle quickly every so often, or take your pick from a list in the preferences. But in practice, I would hate the fact that this Dock icon was demanding my attention. Now that we actually have a stable OS foundation, I don't like the system commanding my attention and distracting me from my tasks--especially since just about anything that would cause a system beep in another application isn't going to distrupt what I'm working on now. Maybe the black triangle can turn into a circle or something, so its not so distracting. Changing colrs is kind of a problem becasue they can blend with the desktop pattern. Maybe a white box outline around the signalling application icon.

Oh well, I've gone on and on. Certainly some things can be improved upon--all in due time. But right now, I'd have to say I'm pretty happy with the Dock; even without text labels. I also think that the Dock is going to function quite nicely when speak recognition goes mainstream.

have fun!
All fatalism aside, I think some of these ideas are good....

Again, I like the idea of the Dock icon being used to notify you when you hear a system beep--in theory. Maybe it could pulse slowly (like the 'sleep' light), or jiggle quickly every so often, or take your pick from a list in the preferences.

All these methods are available if developers want to add them to their applications. The current APIs provide methods to change the appearance of the Dock icon, and some faceless applications actually use this exclusively. CPU Monitor is a perfect example. (Just change the preferences to display in the Dock.)

A standard notification method would be very welcome though. I wouldn't vote for jiggling, and pulsing is too close to the launching behavior (when "Animate opening applications" is turned off the little arrow pulses during launch). One method that would be consistent with The Apple Way would be to superimpose a blinking exclamation point over the icon. Or I suppose the icon could spin around every few seconds. That would get your attention!

Other cool ideas:
- The icon "pops out" of the Dock (gets larger and adds a drop-shadow)
- The icon blinks a shade of red/green/yellow depending on severity
- The icon sparkles (like a glistening drop of Retsyn...?)
- A little guy comes out and points at the icon while shouting "Hey! Yo!" etc.

If you wanted to limit the amount of attention the Dock is trying to get from you this could be one of those configurable options. Personally I find the insistent blinking of the Application Menu in MacOS 9 and Classic to be too obtrusive. A brief set of blinks, 3 or 4, followed by a 5 to 10 second pause is more than enough to let you know that something needs your attention.

Now if you want to find out what the application wants from you but you don't want to activate it there should be a simple method whereby an application can set a notification message. When you rolled over an icon in the Dock that wants your attention a "word bubble" would appear with the notification message. This is a far better alternative than having a little notification window appear, as happens in MacOS 9. When an application can use some other method for providing status information, as for example Mail does, then it should take advantage of that. The purpose of notifications should remain the same, to inform you when an action needs to be taken.