The final menu bar solution!

strobe

strobe

Puny Member
I'm not pleased with how menus work in OS X. I always enjoyed using global menus in MacOS. Not the ones provided by Apple but the 3rd party utilities which cut my time wasted at a computer dramatically (more than say doubling my CPU speed). Many of these utilities are difficult or impossible to implement in OS X, furthermore Apple is squandering their chance to revolutionize how menus are managed.

The way menus are currently managed is each application (Carbon or Cocoa) calls a shared library which then creates it's own menu bar. The Window Server sends each application mousing events which are interpreted by other library functions. When switching applications the menu bar is overwritten then hidden (often not well synchronized). I hate it, it leaves zero room for customization. If you don't like how one app manages menus you're screwed.

However if the menus were to reside in one address space there would be awesome potential for innovation. Literally everything about the menus could be altered. You could add/delete/change hotkeys. You could create custom global menus (instead of the unattached floating icon widgets which litter the nebulous void no-text-in-this-portion-of-the-menu area). You could rearrange menu items. You could create custom menus with those menu items you use most. You could tear off menus into utility windows or drawers or tabs or whatever. You could replace menu items with icons. You could get rid of the menu bar and use NeXT-like menus or put the menus under the title bars. You could make 3D menus. You could make a menu search. You could make a virtual screen which you scroll, yet the menus remain in the same place. Think up your own ideas, I'm sure there are an infinite quantity.

Keep in mind most 'commands' available in an application are hidden somewhere in the vast hierarchy if it's menus thus with complete control over how one accesses these commands you open the door to vast improvements in productivity! Do you use the menu bar in a typical graphics application? I sure don't, it's difficult finding what you need and once you do it's usually nested. With a custom menu with my commonly used items in a utility window this would change. Also being able to re-arrange the menu items would help immensely.

My scheme to implement menus in a single address space is blindingly obvious. Have the Window Server draw and manage it. Currently the application has to wait for the window server for mousing events, then the user has to wait for the application to respond and change the appearance of the menu bar. However having the Window Server interpret events and draw the menus would be more responsive and open the door to menu innovation. The code which draws the menus or interprets mousing already exists, the only major (if you can call it that) change would be the code which changes the menu state, like when pressing option in the Finder to restart. I don't consider this a big deal, the window server already can communicate both ways.

Current method:

interrupt->
kernel->
windowserver->
app(when it gets around to responding)->
event-interpreting-code->
menu-drawing-code->
CG

My scheme:

kernel->
windowserver->

1) event-interpreting-code->app

2) menu-drawing-code->GC

PS: The same argument can be used for managing title bars. Think about it, custom title bars with new buttons or sliders. A button to shade, a slider to vary the opacity of the window contents, etc.
 
To be really honest i hate all that stuff, but that's my opinion.

About your Menu-idea.
It wouldn't be in the new Spirit of the OS. You don't let apps share the same space (nor the same memory for that matter). That's what's always been possible in pre X and that's what made it so crashable. All those apps having the opportunity to f**k up the system.

Just my point of view, DJ
 
Originally posted by The DJ
About your Menu-idea.
It wouldn't be in the new Spirit of the OS. You don't let apps share the same space (nor the same memory for that matter). That's what's always been possible in pre X and that's what made it so crashable. All those apps having the opportunity to f**k up the system.

Just my point of view, DJ
Click to expand...

Uuuh no.

If you're saying my idea would make the system unstable that isn't just your opinion, it's your fallacy.

If Apple has a bug in the menu drawing code or the event handling code it will make all applications which use those libs unstable and crash. Furthermore if the window server has a bug it'll crash. Your point of view makes no sense in this reality. Apple's window server to libs are either fscked up or not, the app has no ability to fsck it up, period.

In my scheme the applications are not in a single memory space, but that is blatantly obvious. One app cannot drag the others down with it. I have no idea why you think it could. I'm amazed I'm replying to this.
 
Your idea of how menu bars currently work and how they might be improved shows a little vagary. What do you mean by "A single address space," and why would this matter in terms of performance or customization?

Currently, every application has its own menu structures which the system references when displaying the menubar for that application. This scheme is a necessary part of keeping resources tied to applications and in this instance you can see the structures that describe menus are all stored in separate address spaces.

On the other hand the code that interprets and draws menus resides in a single location, as part of the OS and GUI, and this resides in the address space of the OS or the GUI daemon. It has its own internal structures, which it refers to but which are not related to the structures each application contains.

To make customized menus you could hack the GUI code for drawing and handling menus so that it interprets the same structures from each application but displays them differently... etc, blah blah...

As far as creating scrolling virtual desktops, that is another matter altogether, unrelated to the menu issue. Also you could come up with a thousand different ways to customize the GUI and none of them would necessitate doing anything in a "single address space."

To be frank, as a 22-year programming veteran I find your language very vague and in general it sounds like you have little or no idea what you're talking about with regard to "address spaces."

You sound inspired, and your ideas might be good ones. Clear up your thoughts, post some source code and we'll talk.

 
Originally posted by slur
Your idea of how menu bars currently work and how they might be improved shows a little vagary. What do you mean by "A single address space," and why would this matter in terms of performance or customization?

Currently, every application has its own menu structures which the system references when displaying the menubar for that application. This scheme is a necessary part of keeping resources tied to applications and in this instance you can see the structures that describe menus are all stored in separate address spaces.

On the other hand the code that interprets and draws menus resides in a single location, as part of the OS and GUI, and this resides in the address space of the OS or the GUI daemon. It has its own internal structures, which it refers to but which are not related to the structures each application contains.
Click to expand...

What on earth do you mean by the "GUI". Do you mean the krnel, the window server, core graphics, or what?! There are only so many adress spaces, does it hurt to say where it resides? There is no "GUI" address space. I don't know of any OS on the planet which has a GUI space, only a GUI specification.

Anyway it doesn't matter because the whole point is the structures have to be in one address space for this customization to be possible. The 'code' has no knowledge of the 'structures'. Furthermore the application uses the 'code', not the window server, thus making the proposed customizations impossible.

To make customized menus you could hack the GUI code for drawing and handling menus so that it interprets the same structures from each application but displays them differently... etc, blah blah...
Click to expand...

Not true. You could change the appearance but nothing else. You better read my original post again because you seem to be confused with another.

As a quick and painfully obvious example extracted from my original post, let's say I want to create a global menu with items from other applications. I have to know what menus other apps have registered, then create a menu which has to reside in the window server's memory space. Why? Because a menu in it's own memory space would have to make an IPC call and it would be too slow. There are only two ways to avoid latency when choosing a menu item:

Have every application manage it's own menu bar like it does now

Have the window server manage the menu bar.

There is no other process between the kernel and the application that I'm aware of. My points are clear:

a) Patching the menu drawing code would accomplish nothing but changing it's appearance (useless)

b) Any global menus have to reside in the window server to avoid latency problems.

As far as creating scrolling virtual desktops, that is another matter altogether, unrelated to the menu issue. Also you could come up with a thousand different ways to customize the GUI and none of them would necessitate doing anything in a "single address space."
Click to expand...

You can't make a scrolling screen without changing how the menu behaves. Currently every app will draw it's own menu at the top of the screen. A virtual screen without changing the behavior of the menu bar would move the bar off screen when you scrolled down. It is a menu bar issue.

To be frank, as a 22-year programming veteran I find your language very vague and in general it sounds like you have little or no idea what you're talking about with regard to "address spaces."

You sound inspired, and your ideas might be good ones. Clear up your thoughts, post some source code and we'll talk.
Click to expand...
To be frank I find YOUR language to be vague to say the least, starting with the illusory GUI address space.

The reason why the menu has to reside in one address space is painfully clear, you have to avoid IPC calls when choosing menu items. The only way to implement global menus is to have those structures reside between the kernel and the application, i.e. the window server.

So yes I know perfectly well what I mean by single address space, do you?
 
I really like the idea of each app not having to manage it's own menus, it seems that the Window Manger (or at least the OS) should be doing tasks like this.

It has always annoyed me that programs like IE do their own thing with menus and so forth - you set your colours in Mac OS and IE promptly ignores them! It would be far better if IE knew nothing except to ask the OS to put up *these* menus, and send me *this* message when *this* menu item is chosen.
 


Otherwise how do PTHClock and ClassicMenu work?

PTHClock is an app that draws itself in menu space at the top of the window. It's clickable because it is always on top of the menu and you can't move a window over it.

This is, therefore, a non-issue.

 
You can't make a scrolling screen without changing how the menu behaves. Currently every app will draw it's own menu at the top of the screen. A virtual screen without changing the behavior of the menu bar would move the bar off screen when you scrolled down. It is a menu bar issue.

Why wouldn't you just write the code so that it doesn't scroll the whole screen, but only the portion below the menu bar? There's no reason to scroll the whole viewport!

Seriously, all this speculation is really pointless. Write the code, or find someone who can, and then you'll bloody well know for a fact whether a "single address space" is required to make something like Classic Menu. All this time spent defending your theory would be better spent proving it.

 
Originally posted by Pelorus


Otherwise how do PTHClock and ClassicMenu work?

PTHClock is an app that draws itself in menu space at the top of the window. It's clickable because it is always on top of the menu and you can't move a window over it.

This is, therefore, a non-issue.
Click to expand...

You obviously didn't read the post.

First of all PTHClock does indeed conflict with the menus since it's drawn in the vague area where menu items may or may not exist depending how large your screen is and how many menus you have. Secondly it assumes there are no other apps using the same space. Thirdly only a moron would equate PTHClock and Classic Menu with the customizations I have listed. Let's see...custom menus using items from other menus...changing menu hot keys...editing existing menus...etc.

Please do not post if you can't be bothered to read.
 
Originally posted by slur
You can't make a scrolling screen without changing how the menu behaves. Currently every app will draw it's own menu at the top of the screen. A virtual screen without changing the behavior of the menu bar would move the bar off screen when you scrolled down. It is a menu bar issue.

Why wouldn't you just write the code so that it doesn't scroll the whole screen, but only the portion below the menu bar? There's no reason to scroll the whole viewport!
Click to expand...

Because the applications assume the draw space exists in one desktop (even with multiple monitors it's one desktop) then draws the menu bar in a static location at the top. Before saying you can scroll the portion of the nebulous portion of screen under the menu bar, you should ask yourself what the hell you're scrolling! The menu bar is an RGBA image drawn like a window by the app at the top of the screen. If you're scrolling the screen you're going to scroll the menu bar as it's currently drawn. If you're not scrolling the screen, what on earth are you scrolling?!

What you propose is to scroll something which will never exist, a nebulous 'window drawing area' distinct from the nebulous 'menu drawing area'. I assure you they are NOT SEPARATE so you must either draw the menu in a different area when scrolling the screen or say goodbye to computing reality.

Seriously, all this speculation is really pointless. Write the code, or find someone who can, and then you'll bloody well know for a fact whether a "single address space" is required to make something like Classic Menu. All this time spent defending your theory would be better spent proving it.
Click to expand...
The whole POINT is that Classic Menu can't do diddly poop! Geez, you're worse than that other moron, Pelorus.

Classic Menu can NOT, I repeat NOT do **ANY** of the customizations I have listed. Not a one, similar to how I suspect you have not a one brain cell.

That has got to be the most stupid thing I have read all day..Custom Menus...geez. I have already explained that the code must exist in between the kernel and the application. But instead of dealing with this reality you banter about "Custom Menus" and source. Nobody can write such source without:

a) Interpreting the entire disassembled window server, replacing it, then patching the menu drawing and event handling code so applications no longer do it (only to have it break when Apple changes their code yet again)

b) If you have the original window server source which nobody outside Apple has.

Your incessant demands for source show how truly clueless you are about the issue at hand. It's OBVIOUS (to the point I can't believe I have to type this) that nobody outside Apple could implement this so long the code is closed source. BTW did I mention you're a moron for using Custom Menus as an example? Good.

In case you still don't get it, the issue is the customizations REQUIRE the menu bar management code exist between the kernel and application. The logical place would be the window server. This is not fscking speculation, deal with it!
 
Originally posted by strobe
You obviously didn't read the post.

I read what I (and plainly others) could make sense of.

First of all PTHClock does indeed conflict with the menus since it's drawn in the vague area where menu items may or may not exist depending how large your screen is and how many menus you have.

Yes, now tell me, how did this work in Classic Mac OS when we had four or five global menus? I think your mistake is being stuck in the menu-paradigm. Look at products like NeXbar, the Dock, etc.

Secondly it assumes there are no other apps using the same space.

Agreed. But your vague references to address space are frankly bollox. A case of you not knowing how it works so you just made it up!

Thirdly only a moron would equate PTHClock and Classic Menu with the customizations I have listed.

Thanks. Allows me to label you too.

Let's see...custom menus using items from other menus...changing menu hot keys...editing existing menus...etc.

This also already exists in Mac OS X.
P.A.Y. A.T.T.E.N.T.I.O.N

Please do not post if you can't be bothered to read.

You have described a lot of the "features" that were already present in NeXT as well as a lot that remained in OSX Server and are currently available in XWindows.

Whether or not they are currently available is one thing. Whether or not they will be implemented in an unseen final release is another completely.

English isn't your first language is it?



[Edited by Pelorus on 12-19-2000 at 06:41 AM]
 
Your rudeness is evident to everyone here. Regardless of how right or wrong you might be, being rude and insulting hurts your position and offends the people who are taking time out of their lives to answer you in the spirit of garnering clear information.

Have a merry little life, kid.
 
Originally posted by Pelorus
Originally posted by strobe
You obviously didn't read the post.

I read what I (and plainly others) could make sense of.

First of all PTHClock does indeed conflict with the menus since it's drawn in the vague area where menu items may or may not exist depending how large your screen is and how many menus you have.

Yes, now tell me, how did this work in Classic Mac OS when we had four or five global menus? I think your mistake is being stuck in the menu-paradigm. Look at products like NeXbar, the Dock, etc.
Click to expand...

Menus are a method to organize commands. Once you have complete control over these menu items you can REPLACE the menu bar with anything else you want!

Clearly if you want to move beyond the menu paradigm you're on my side.


Secondly it assumes there are no other apps using the same space.

Agreed. But your vague references to address space are frankly bollox. A case of you not knowing how it works so you just made it up!
Click to expand...

I didn't say address space in this sentence. I clearly meant menu bar space, meaning the screen location. How obtuse are you?


Thirdly only a moron would equate PTHClock and Classic Menu with the customizations I have listed.

Thanks. Allows me to label you too.
Click to expand...

OK, I'll label you as "a person who would equate PTHClock and Classic Menu with the customizations I have listed" and let others decide how to 'interpret' that.


Let's see...custom menus using items from other menus...changing menu hot keys...editing existing menus...etc.

This also already exists in Mac OS X.
P.A.Y. A.T.T.E.N.T.I.O.N
Click to expand...

These do NOT exist in OS X. You can do SOME of these modifications in OPENSTEP using categories, but not OS X because not all apps use AppKit to manage menus.

Again, none of the modifications I mentioned above are possible in OS X, not one.



Please do not post if you can't be bothered to read.

You have described a lot of the "features" that were already present in NeXT as well as a lot that remained in OSX Server and are currently available in XWindows.

Whether or not they are currently available is one thing. Whether or not they will be implemented in an unseen final release is another completely.
Click to expand...

OS X Server is OPENSTEP, OS X is not.

SOME of these modifications are possible in OPENSTEP, but NOT in OS X and necessarily so because not all apps use AppKit to manage menus. Furthermore this is not a feature which merely has to be re-implemented, it has never been implemented. Because of the nature of OS X as opposed to OPENSTEP this NEW mehtod has to be adopted.

I'll bet money this won't be possible in OS X GM 1.0. Apple has shown no interest in doing so. Please get a clue:

OS X IS NOT OPENSTEP!!!

MOST OS X APPS AREN'T USING APPKIT!!!

YOU CAN'T DO WHAT I'M PROPOSING WITHOUT HAVING THE MENU DRAWING AND EVENT HANDLING CODE BETWEEN THE KERNEL AND APP!!!

Nothing you have said has any relevance concerning the necessity that this code must reside between the kernel and application thus I have to assume you agree or don't have a clue.
 
Originally posted by slur
Your rudeness is evident to everyone here. Regardless of how right or wrong you might be, being rude and insulting hurts your position and offends the people who are taking time out of their lives to answer you in the spirit of garnering clear information.

Have a merry little life, kid.
Click to expand...

Sorry, I don't read any more posts from 'slur' without source code which replaces code from Apple which one didn't have the original source too so instead interpreted the entire disassembled operating system.

Also you have to be a 33yr programming veteran.

Also, could you please be a bit less vague?

I don't blame you for not replying to my posts, it would only bring to question your position on being a programming veteran--whatever that is.
 
<b>I don't blame you for not replying to my posts, it would only bring to question your position on being a programming veteran--whatever that is.</b>

Gee, do you really think so? That's quite an assertion. What do you base that assertion on? I think it's quite natural to stop talking to a rude individual. Don't you?

You could have said anything at all, like "So, when did you first learn BASIC?" I'd say, 1977, from a book I bought at Radio Shack. If you asked me, "What was the next language you learned?" I'd answer, 6502 Assembler on the Atari 800. Nice little architecture, with only three numerical registers, a program counter, and a status register for Zero, Overflow, and Negative.... blah blah. In those days we learned programming from awesome magazines like Compute!, SoftSide, Byte, and Antic. Then I'd tell you some anecdotes about writing games on the Atari and how I moved on to the Amiga using 680x0 Assembler, writing two published games, "DinoWars" and "Bill 'n' Ted's Excellent Adventure" (both of which sucked from a design standpoint, but that wasn't my job!). I'd tell you about the bizarre world of contract programming during the 80's, in which you were as likely to get paid as not, and through which I managed to get most of my Amiga equipment at that time.

I could tell you a lot of things about my experiences, and point you to my website http://www.fretpet.com which features my only Mac program so far, written from the ground up in C without recourse to any existing framework. This project was my introduction to the Mac, QuickTime, and the C programming language, which is why I wanted to write it from scratch, straight to the toolbox. A real change of pace, because all my prior work had been in Assembly language and straight to the hardware, even on the Amiga where I eschewed Intuition (the GUI) and programmed the Blitter, Copper, and sound chips directly.

I could sit by the campfire and tell a few war stories to you, kid. But you're only interested in preserving your eroding position, being insulting, trying to defend your fragile ego, and being a general pain in the ass.

So what now, are you going to pick me apart more? Are you going to take issue with every sentence I've written here, going further and further from your original intent? Hmm, probably. (Don't forget to point out how I couldn't be a real programmer since I only learned C 6 years ago, and make sure to drive home how those older architectures don't compare to MacOS X in terms of memory management, and therefore I couldn't understand that concept... Have a ball! I'll be giggling from the sidelines, rolling in my pile of old Dr. Dobbs Journals and Byte magazines.)
 
slur, your obsessive dick-slapping on the issue of experience is just what I was making fun of. Thanks for making that painfully evident.

When all is said and done the fact remains the menu drawing code and the menu mousing event handling code must reside between the kernel and application for this proposed feature to work. However it doesn't seem to matter how many times I say this because everybody keeps avoiding it.

* You can't do what I'm proposing by patching libs. All the menu structures have to exist in one location hence global or single address space.

* You can't do what I'm proposing if the code resides in a seperate process. This would necessitate an IPC call. If the menu bar were a seperate process instead of drawn by the application the lag would be intolerable.

The ONLY way to implement my proposed feature is for the code to reside between the kernel and the application like the window server is.
 
<b>slur, your obsessive dick-slapping on the issue of experience is just what I was making fun of. Thanks for making that painfully evident.</b>

I apologize. You're right. I am a fool.

 
Strobe - why don\'t you just go pop some zits, buy yourself a blow up doll and rid yourself of some of that teenage angst.

You are dull, boring, probably hideously ugly, without friends and your parents probably hate you too due to your obvious infinite capacity for rudeness.

Do us all a favour, lock yourself in an attic and never again darken this forum with your tantrums.

BTW - As far as I\'m concerned this topic is no longer worth reading so don\'t bother posting a reply.
 
Oh my god, what the kittylicking hell is going on in this forum?

Frankly, the reasons why people are not reading all the posts is they\'re
**TOO DAMN LONG**. What are you people, Lawyers? What seems to come across, though, is that OS X leaves much to be desired in the way of customization. What needs to be had is a whole new app for the System Preferences Panel--something that will enable all of us apple zealots to customize to our heart\'s content. For example, settings for menu, dock and alert placement, and more settings to customize the look, as well as the behavior, of finder windows and buttons.

Apple should get smart and realize that it does NOT want a bunch of amateur and even seasoned programmers tinkering in it\'s new system because they\'re not satisfied with not being able to change the goddamn font, and some of the quirks and wiggy functions in OS X. What we need is a toolkit... That, Apple to stop blocking the custom-nuts (see Apple freak out over custom schemes for OS X) and give us a goddamn hand.
 
I don\'t think Apple has a creative bone in it\'s collective body. Every single advancement in MacOS have been hacks. Everything from the multifinder to the hierarchical apple menu. However OS X can\'t be hacked in this fashion, the design prohibits anything beyond patching functions in libraries.

All I\'m asking from Apple is to provide a solid foundation on which modules can be written (or services wholly replaced) by creative people. When an idea becomes popular enough they have the option of bundling it like they did with window shade or drag+drop text (yes, all hacks!). Asking a large corporation like Apple to be creative is wishful thinking (if I want to be polite).

What I propose is something which is near impossible to write a hack to implement because it requires a methodological change in how menus are managed and drawn. However I think the potential would be awesome and would differentiate OS X from other systems.
 
You must log in or register to reply here.
Back
Top