Menu Management
All I have mentioned to this point are obvious problems with current technology, nothing revolutionary. I could mention countless other bugs, however I would rather end this article with at least one idea which could dramatically improve the way we use current applications. Something for Apple to consider for OS X 2.0.
There are several reasons why the evolution of MacOS was driven almost completely by 3rd party hacks. Primarily it's because Apple is a large corporation without a creative bone in it's body. They didn't invent the multi-finder, they didn't invent desktop publishing, they didn't invent floating windows or ubiquitous drag+drop text or hierarchical apple menu or 99% of the widgets we use daily. In fact they did invent a lot of stupid stuff which would have never succeeded as hacks like desktop mounted volumes. Anyway the second reason why hacks were so instrumental in evolving MacOS is because such hacks were possible to begin with.
MacOS doesn't have memory protection in the typical meaning of the term. This is to say each application doesn't have it's own 4 Gig memory space which no other process can access. Obviously it's a good thing that OS X has memory protection in that one application cannot directly cause another to crash, however it also has other consequences. In MacOS the structures created for system 'managers' existed in one global structure. This structure could be read and altered by anything else, including hacks. However in OS X each application maintains it's own structures (Apple had to overcome this discrepancy when designing CarbonLib by creating accessor functions). Now a 3rd party hack which requires access to these structures becomes near impossible.
I wanted to write such a hack for OS X but can't, so I'm forced to lobby for Apple to implement it instead. Every time I describe this functionality in the past I'm misunderstood so I'll try to get it right this time.
Mac HI convention properly states that all commands ought to at least be mirrored in the menu bar hierarchy. This means that virtually every command of every application is available to you via a menu item. What if you had absolute control over how you display and access all these commands? By that I mean implement any method your mind could imagine to organize, display, script, and engage all commands currently at your disposal. Out of the zillions of menu items available to you, how many do you use in a typical day? How drastically would your productivity increase if you were able to access those commands without using the menu bar hierarchy the programmer has selected for you?
If you would like to do any of the following:
¥ Set the hotkey of any menu item
¥ Drag menus off the bar
¥ Replace the bar with something else like NeXT-style menus
¥ Replace menus with something else entirely, like toolbars or whatever
¥ Reorganize the menu hierarchy
¥ Create custom menus with menu items from other menus
¥ Create global custom menus with menu items from other applications
¥ Have total scripting control
¥ Have more responsive menus
¥ Queue menu commands like you can currently queue mouse clicks
¥ Anything else imaginable
...then you're in favour of my proposal.
OS X currently has every application manage it's own menu. Each application calls a shared library (Carbon, AppKit, Swing, whatever) which registers menus and items in a local data structure. This is then accessed by other library calls which draw the menu and interpret mousing calls. The API doesn't specify how menus are managed, it only allows the application to create menus and items then interpret menu selection events. Two things ought to be immediately clear about this present situation:
1) When an application stalls when switching apps you either see no menu, or the menu of the inactive application which isn't clickable. Either way when you see a menu it's being managed in that application's process.
2) The hack I'm proposing is impossible.
There is a very good reason why the menu is managed each application's process. As you're using the menu the application is immediately aware of any selection you make because it's in the same process. If I were to write a hack whereby the menu was a separate process it would have unacceptable latency problems because for one process to notify another requires an IPC call (inter-process communication). However there is a way to have the menu structure in one location AND to avoid an IPC call, manage the menu between the application and kernel*. The obvious place to do this is the Window Server. Mousing and other events are sent from the kernel to the Window Server then to the applications. This is the current process:
Application registers the menus:
application->menu registering code
User clicks menu:
mouse->kernel->Window Server->application->event interpreting code->menu drawing code->display server
User selects item:
mouse->kernel->Window Server->application->event interpreting code->application responds
However if the Window Server managed menus the process would be:
Application registers the menus:
application->menu registering code->Window Server
User clicks menu:
mouse->kernel->event interpreting code->Window Server->menu drawing code->display server
User selects item:
mouse->kernel->Window Server->event interpreting code->application
Thus we have no delay and the Window Server has complete and utter control over how the menu behaves (interprets events) and is displayed. It should also be more responsive because the Window Server doesn't have to wait for the application to respond before the user can access his menus. This brings up a minor decision: how to handle cases where the Application isn't immediately responsive. This is important when the application's state can change after selections have been made. This is no different than problems you have when clicking an application with the cursor when it's not responsive. There are various ways to handle this situation:
¥ Menus are gray until application is responsive.
¥ Menus are red until application is responsive, yet selectable. Commands can be queued just like mouse clicks are currently queued. Queued commands which cannot be completed due to changing menu state are flushed and result in a beep or menu bar flash or something.
¥ Menus become invisible or lock up like they do currently.
Given the previous two choices why settle for the current behavior which is the third? To keep everything consistent if the first option is chosen the user shouldn't be able to queue mouse clicks as we can now. Perhaps gray the cursor instead of that weird spinning color disc.
As you can see there are many reasons to move the menu management code into the Window Server even before we introduce the massive productivity potential of allowing 3rd parties to make custom global menus and whatnot. The work involved for Apple to implement this is not massive, nearly all the code to register, draw, and interpret events is already written, the difference is where it's executed. The bulk of the work is patching specific calls like changing menu state which now involves telling the Window Server to change the menu state and flush the command queue for that item. However I consider the huge potential this project to be well worth it. Apple would have a truly unique interface users can globally customize to their maximum potential and retain a unified interface!
