The final menu bar solution!

Hey, is it just me, or does Strobe have issues?
Just kidding dude... Actually, I like some of your menu ideas. Regaurdless of who likes what, customization has always been one of the #1 perks of the Mac OS (at least for me, that and I frankly find the overall graphics far superior to anything I\'ve ever seen on a PC).
Users want that multitude of ability... Kaleidoscope, Window monkey, and other customization apps prove how much Mac users tinker with their computers... And I think that Strobe has some excellent ideas about the Mac interface.

I think we should have defaults, and a buttload of innovation opportunities from there. Now I\'m not quite sure what anyone means by Address Spaces; are we talking about something as high-level as a resource, or are we talking Darwin? Anyway, I\'d like to see some tear-off menus, some convertable ones (make it into a drawer-style palette on the right/left/bottom of your screen) and even the magnify effect seen in the dock applied to menus. It would help grandpa, and it would look damn cool.

The issue is not where the Menu code is located, I think; but whether someone can come up with a smart enough way around it. If Apple won\'t do it, it\'s users will--provided they want it bad enough :)

-agnt_M
 
And Strobe, old chap--

The reason Apple includes hack-inspired things in it\'s later versions of the OS is not because it\'s not creative, it\'s because it LISTENS TO IT\'S USERS :)

That\'s a good thing, not a point of suckage. The whole OS evolves with USER HELP, not by a panel of aged programmers like the schmucks at Micro-and-Soft.

If you want all those spiffy menu options (and believe me, I do to) PROGRAM them or hire someone to. With any luck it should turn up in os X.5.... :)

Your Daddy
 
Originally posted by boult
Strobe,

Please read this article at http://www.maccentral.com/news/0101/04.macosx.shtml

and don\'t bother to reply back to me.. A apology would be in order for all of this who posted in this topic.

(this isn't a reply back to you, I'll merely point out what a moron you are)

I read this a long time ago (which is evidenced by two posts I made which are clearly visible) and it has absolutely no relevance whatsoever. It has nothing to do with 'menu' or 'window server' or 'kernel', it's a simplistic article demonstrating the author's ability to read Apple's marketing blurb and re-arranging it. The only thing in common with this article and the posts on this thread have been the simplistic grasping explanations of technology which is best explained in the Apple documentation. Next you'll be reusing the ironic phrase from this article: "All techno-speak aside..."

What exactly does this article point out which we didn't know over a year ago?

I think you should apologize to me for making me laugh so hard.
 
Originally posted by Agnt_Mulder
Hey, is it just me, or does Strobe have issues?
Just kidding dude... Actually, I like some of your menu ideas. Regaurdless of who likes what, customization has always been one of the #1 perks of the Mac OS (at least for me, that and I frankly find the overall graphics far superior to anything I\'ve ever seen on a PC).
Users want that multitude of ability... Kaleidoscope, Window monkey, and other customization apps prove how much Mac users tinker with their computers... And I think that Strobe has some excellent ideas about the Mac interface.

The closest hack resembling what I'm getting at is Custom Menus, which has problems and only runs on System 8.1 and earlier. I could never get it to be responsive enough...which will be a problem in OS X unless the code resides in the window server.



I think we should have defaults, and a buttload of innovation opportunities from there. Now I\'m not quite sure what anyone means by Address Spaces; are we talking about something as high-level as a resource, or are we talking Darwin? Anyway, I\'d like to see some tear-off menus, some convertable ones (make it into a drawer-style palette on the right/left/bottom of your screen) and even the magnify effect seen in the dock applied to menus. It would help grandpa, and it would look damn cool.

I'll try to explain the crux of the problem in simple terms...

OS X has protected memory. This means data in one process cannot be read or altered by another and communication between processes requires an inter-process communication call which you want to avoid. An apple event for example requires an IPC.

In MacOS all menu data existed in a global structure therefore this hack would be possible (although subject to break whenever Apple changed the menu structure). In OS X every application creates it's OWN menu structure (using common menu-registering code) therefore you cannot change these structures or select them without an IPC call. Currently there is no delay when mousing around or selecting menu items because the application can access it's own memory. The code which uses the data structures is common however the structures themselves are not.

The goal is to have the structures in one place thus allowing complete control over the menu items. Control over how they are drawn and selected. This is only possible if the code which registers menus, draws menus, and handles mousing events is between the kernel (source of the mousing events) and the application (which receives the menu selection events).

So to sum up:

Currently the application handles mousing events using it's private menu structures.

My proposal is the window server handle mousing events using a global menu structure.



The issue is not where the Menu code is located, I think; but whether someone can come up with a smart enough way around it. If Apple won\'t do it, it\'s users will--provided they want it bad enough :)

-agnt_M

I hope after reading my explanation you understand it does indeed matter WHERE the code is located, specifically between the kernel and application.
 
I don't understand what you mean by Mac OS X doesn't use the Appkit. I call on the Appkit classes all the time when I'm writing cocoa apps.

I must be misunderstanding what you're trying to say. Could you clarify, please?

- Non-abusive friendly question guy


 
And I suppose his point is that Avie Tevanian is an idiot. And with a simple thought, that is (apparently) blatently obvious, he understands the OS and has a better conceptual grasp of how things work than Avie.

I hope my sarcasm is coming through on this response. I'm trying to lay it on pretty thick.

I'm sure Apple has picked the aboslute worst way to implement all kinds of things in the OS.

My advice to you would be to send in your resume with your ideas. Apple should respond quickly.

And other bit of advice, keep your ideas and implementations vague as your posts are. That can only help your chances.

And drop the arrogance a bit. Maybe to a quiet confidence.
 
Hmmm. This is actually an interesting concept. Unfortunately, it's been abused by degrading arguments.

Strobe, I want to make sure I'm clear on a few things (please be gentle, I'm new at this ;-) )...

In order to have a shared memory space for the menus so as to avoid IPCs, would this mean a style of wrapper around the kernel (A protected space, like the kernel, but residing on top and shared by all apps)?

Perhaps there could be a type of plugable architecture (or use the existing plugin architecture) to add extra functionality and menu responses/redraws.

I have concern regarding how to prevent problematic plugins/apps from abusing the space, but I suppose that is always the case. I suppose, we could also add a "safe menu" boot option when problems do occur, to drop back to just defaults.

It would require some architectural buyoff from Apple, but I think it's definitely doable. ...and I think that it could be implemented in time without migration headaches.

I hope that I'm interpreting your requests correctly.
 
Originally posted by squishycat
Hmmm. This is actually an interesting concept. Unfortunately, it's been abused by degrading arguments.

Strobe, I want to make sure I'm clear on a few things (please be gentle, I'm new at this ;-) )...

In order to have a shared memory space for the menus so as to avoid IPCs, would this mean a style of wrapper around the kernel (A protected space, like the kernel, but residing on top and shared by all apps)?

The kernel wouldn't need a single change. Neither would the applications.

The WindowServer (aka "Window Manager" in the CoreGraphics framework) would execute the menu management code instead of each application. The primary change is a new protocol would have to be written so changes to the menu items instructed by the Application are handled properly by the WindowServer.

It really comes down to which process is managing menus.



Perhaps there could be a type of plugable architecture (or use the existing plugin architecture) to add extra functionality and menu responses/redraws.

I have concern regarding how to prevent problematic plugins/apps from abusing the space, but I suppose that is always the case. I suppose, we could also add a "safe menu" boot option when problems do occur, to drop back to just defaults.

It would require some architectural buyoff from Apple, but I think it's definitely doable. ...and I think that it could be implemented in time without migration headaches.

I hope that I'm interpreting your requests correctly.

Migration would be absolutely painless because there isn't a single change to the Carbon and Cocoa APIs. The current applications would just work without recompilation.

What happens now is each application calls a shared library to, for example, 'register menu item A'. The shared library code is executed by the application process to create a menu structure with the menu item 'A'.

What would happen under my system is the application would execute the shared library method for registering a menu item, however instead of creating a structure itself it tells the WindowServer to 'register menu item A'. The WindowServer then executes the same code to create the menu structure.

The difference between the two methods is now all menu structures and selection of menu items (and thus an application's commands) exist and are executed in one global process.

So-called abuse can already happen now. You can replace methods in current libraries and introduce leaks thus crashing applications. There are methods to safeguard against such leaks but the ability for add-ons to leak and make stuff crash is already present as things are now.

Of course one doesn't want the WindowServer to crash, but it can be restarted just like the pasteboard. Leave it alone and it'll be just as stable.

Even if you don't use any plugins there are immediate benefits like a more responsive menu.
 
I like, I like it!

I think that ALL things should migrate in this direction as much as possible. And what I mean by that is, and Apple/NeXTSTEP has started this, that applications should be less 'applications', per se, and more like plug-in modules ("objects", if you will :) ), that fit themselves neatly into the system, and are drawn upon when needed (like little engines). I couldn't possibly explain how this would work or be implemented, but...

I also like a previous posters idea of Magnify Menus (tell Apple, tell APlle!), and am waiting patiently for them to introduce Tear-Off menus (it was in NeXTSTEP, so I'm sure we'll see it soon).

I sent a suggestion to Apple recently that I would like to see:
Implement the NeXTSTEP shelf for holding items for copy & moves between folders in single-window mode, but do it as a Cocoa drawer that can be disclosed and hidden. Certainly this won't be implemented until the Finder is Cocoa (if at all), but I would like a quick drop area for copy/move rather than desktop or launching a second window.

 
Oh. I think I'm getting it now. Thanks for the info. I don't think it would require as much work as I thought.

So, basically, the app doesn't have to process anything until a final selection is made, thus circumventing the round-trips to the app code each time.

The WindowServer could use the plugins for the global menu customization and tweak the menu accordingly, thus avoiding overlapping text, etc. on the menubar.

Further extensions could allow basically unlimited amounts of customization...AND this would allow really nice caching of certain standard menu structures used in multiple apps for some seriously quick response times.

Oh shit, I sound like a commercial. Sorry about that. ...and I think you already said all those things, huh?

I like this idea more and more.
 
OK, I think I get what you're saying strobe, and it sounds like a good idea. There seem to be many benefits to having all the menu code in one address space, and the Window Manager seems to be a good place for the code anyway - why is it not done like that now?

The only reason I can think of that Apple hasn't implemented menu code like this is that either 1) the way its done now is the quickest way (and given their tight schedule I'd say that's likely), 2) it's the most similar to Classic (which would make it quicker and easier in many ways).

So, the main question now is, short of writing an alternate Window Manger ( takers, anyone? ;), what can we do to flag this at Apple? Could you maybe (as the one with the idea and most knowledge) prepare a paragraph or two for others to submit to Apple's feedback page to make them aware that some users care about this?
 
Originally posted by miggins
OK, I think I get what you're saying strobe, and it sounds like a good idea. There seem to be many benefits to having all the menu code in one address space, and the Window Manager seems to be a good place for the code anyway - why is it not done like that now?

The only reason I can think of that Apple hasn't implemented menu code like this is that either 1) the way its done now is the quickest way (and given their tight schedule I'd say that's likely), 2) it's the most similar to Classic (which would make it quicker and easier in many ways).

So, the main question now is, short of writing an alternate Window Manger ( takers, anyone? ;), what can we do to flag this at Apple? Could you maybe (as the one with the idea and most knowledge) prepare a paragraph or two for others to submit to Apple's feedback page to make them aware that some users care about this?

Actually MacOS had everything in one global address. The new method was likely written from scratch.

The simple reasons why this hasn't been implemented are:

a) They didn't consider it. This is something useful from a HI perspective, something a software engineer trying to get menus to work probably would not consider.

b) The WindowServer is likely virtually the same as the OPENSTEP one and didn't have such a protocol in place.

c) Too many mac users were whining about specifics like the Apple Menu instead of a more general solution. In fact the Apple Menu as it is now is not actually a menu. What Apple did was shift the real menu right a few pixels and superimpose a fake Apple menu on the left. You can actually put the corner of a window under the Apple Menu (like the ICQ floating window). It was obviously a quick and dirty hack.

d) NeXT had a method for adding global menus (try xFiles for example) but they have many of the same shortcoming to the fake menus we see today. In other words what's the point?

I have written a piece on my WindowServer idea:

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!

I think I'll post a new topic with this so my case is more clear than this flamed-out thread.
 
Back
Top