Created attachment 5511 [details]
Here's a quick gimp'ing of my idea

actually that looks really bad (just browsing through reviewing bugs)

The attachment i made was really terrible, i did it in like 30 seconds. I just wanted to show you what i meant.
Or do you think the idea was bad?

If you want, i'll make a better picture...

*** Bug 81375 has been marked as a duplicate of this bug. ***

Perhapse do not show the icon application (on top-left edge) because Location/File/Dovument menus are more usefull and should be reachable immediatly after moving the mouse to top-left edge of the screen.

Or, as I've said in my duplicate report, enable user to configure which buttons to show, like this :

[[ MAC OS BAR LIKE options ]]

Include window decorations into the top bar :
[ ] The left buttons
[x] The right buttons

As KWin allow to configure the order of buttons this would be powerful.
And some users could do not fully theire top bar with the [minimize][restore][close][...] buttons.
Instead, those ones can just enable "The left buttons" to just show the application icon andn reach easily all window features.

Marked as JJ (suitable for beginning developer). 

Let's see if this JJ thing will work. This can be solved as follows:
The standalone menubar needs embeded in the "Menu" kicker applet, possibly on a special Kicker child panel. That way other things can be "added" to the menubar, as applets to the panel. The buttons for this wishlist can be a new kicker applet.

The base class for kicker applets is KPanelApplet from kdeui, kdebase/kicker/applets has a couple of already existing applets as examples. The actual actions can be performed using the NETRootInfo and NETWinInfo classes from kdecore, note that the 3.2 and older HTML API documentation at developer.kde.org doesn't include them because of a mistake, http://developer.kde.org/documentation/library/cvs-api/kdecore/html/classes.html can be used. E.g. the following piece of code changes maximized state of the active window:
    NETRootInfo ir( qt_xdisplay(), NET::ActiveWindow );
    if( ir.activeWindow() != 0 )
        {
        NETWinInfo iw( qt_xdisplay(), ir.activeWindow(), qt_xrootwin(), NET::WMState );
        if( ( iw.state() & NET::Max ) != NET::Max )
            iw.setState( NET::Max, NET::Max );
        else
            iw.setState( 0, NET::Max );
        }

That should be roughly everything necessary. Finding some good icons for the applet and doing the painting is left as an exercise.

I use the MacOS menubar all the time, but I think including the window buttons in the menu is a bad idea.

First, it's confusing. Window Buttons belong to Window title bars to give the user the feel to close a specific window. I guess with an unconnectet close button, the propabilty to close accidental the wrong window and maybe loosing all your work is too high.

Second the upper right space is also on MacOS used for different things, like a list of applications, a clock, volume control, ... things which control the whole system, not a single application.

> I use the MacOS menubar all the time, but I think
> including the window buttons in the menu is a bad idea.

Yes, it could be confusing.
It's why it shouldn't be activated by default.

But I don't use the MacOS menubar for now and have close(...) buttons at the top-right screen edge is a great thing to speed up windows operations.
I personaly maximize the windows the most time, so it willn't disturb me : always one window at once.
MacOS menubar allow to actiavte the menus VERY quicly.
The current wish will mix old (close easy access) and new (menus easy access) powers into one !

Well, if we only allow maximized window to have its window buttons embeded into the menu bar, and keep the buttons in the title bar when they are not maximized (similar to the behavior of MDI applications), it will probably not be confusing at all.

Yes I probably should have stated that originally. Only maximised windows have window buttons in the menubar.
Btw wow... it looks like i've had a decent idea for once :) afaik no other operating system has this feature. hehe now microsoft is going to 'innovate' it into their next product.

This wish has nothing common with real Mac OS X style, which never includes window's buttons to the top application menu.
See Apple Human Interface Guidelines: The Menu Bar and Its Menus: http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGMenus/chapter_16_section_4.html

It wasn't supposed to duplicate os x. It was supposed to make it easy to close windows. I know that in osx there is spotlight and stuff up there, but there ISNT in kde.

If this feature were implemented as a regular kicker applet, I could see possibly using this feature on a regular basis. Since the user could place the application buttons anywhere in the kicker, I think this could be very convenient to control window actions and use the Mac OS-like menu simultaneously. 

Moreover, to avoid accidental window closure, the user can just set extra spacers in the Window Decoration *or wherever* section in KControl, and have the kicker applet use those configuration settings...or have a separate configuration dialog for the kicker applet.

This way a maximized window wouldn't need a titlebar at all.

You can easily close windows in plasma + appmenu-qt