I suppose that the OP is referring to the new Firefox 4. The latest Opera build use this as well, and it is terrific. It saves a ton of space in the UI, it looks great, and it is easy for the user to find what he is looking for.

If implemented in KDE, I might recommend to either use the application name as the name of the menu, or a generic KDE icon such as the Gear, or the Plasma Cashew.

no, he's referring to a patch for Qt4.7 which canonical is currently trying to push in:

http://gitorious.org/~agateau/qt/agateau-qt
https://launchpad.net/appmenu-qt

Have you seen that: 

http://kde-apps.org/content/show.php/Titlebar+menu?content=138804

I havn't compiled it yet due to lack of time but I am also interested in such a feature.

I know titlebar plugin but it's not the solution:
- It's a hack
- It doesn't works without effects

As long as the patch is not in Qt there is no way that we can add it. You 
could talk to Kubuntu whether they want to include it in their release and 
upstream it as soon as the code is in Qt.

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

Martin, would it help if I open a ticket at Qt for this?

I'm going to post on planet.kde.org about this:
- What we have.
- What we need.
- What to do.

For people looking at appmenu support for oxygen:
http://kde-look.org/content/show.php/Oxygen-appmenu?content=141254

Lionel Chauvin is working on kwin support (not in style) but need trunk :-/

I think menu layout need to be rethink but i heard that maybe appmenu2 will be the solution.

I don't understand why this wish was closed as wontfix given that we have a patch at reviewboard. It might not be ready for 4.7, but I'm sure that it hits 4.8

Are you sure appmenu patch will be accepted by Qt devs ?

It seems that gtk devs reject it...

(In reply to comment #10)
> Are you sure appmenu patch will be accepted by Qt devs ?
In the merge request it looked quite positive.

@Bellegarde
The Qt part of the patch is pretty harmless - it only defers the menu into a plugin.
The critical parts will be to provide an implementation for this in the kde platform plugin w/o breaking existing stuff & rethinking menu structure (ie. whether the current menus still fit this kind of setup)

Gtk+ allows preloading plugins anyway (and the gnome-global-menu already proved that deep changes are not required - it also proves that such changes "stuffed-on-top" (tm) can greatly crash some applications like eg. emacs ;-)

My question is:
- Do appmenu is the way to go ? If Gnome devs do not use it by default ?
- Isn't time to go think about a real freedesktop (Qt, Gtk, Mozilla compatible) dbus over menu SPEC ?
- I heard that current appmenu is already a dead project as Canonical wants to replace it with a new SPEC...

Ok, from what i get on #gtk channel, nobody propose them to include this patch :-/

Is communication between Gtk community and Canonical that hard ? :-(

Can you give me a link to bug report (about patch) for Qt ?

After talking with Gtk devs:
- appmenu/dbusmenu > /dev/null
- They are already working on their own "actions over dbus" spec:
https://gitorious.org/gnome-design/gnome-design/blobs/raw/master/mockups/menu-experiments/eog-menu-experiments.png
- They don't care about KDE

Really sad news...

So, Qt/KDE just need to wait for GNOME to finish their work, and just accept it as usual :-/

Ok, after some discussion with Gnome designer, there is no code for now...

What they want is a new kind of container which could contain richer interface elements than is possible with a menu.

I also think this is the way to go.

For now, appmenu can be included in KDE even if rejected by GNOME but i will try to keep in sync with GNOME devs to try to open a discussion with KDE devs as soon dev start.

Link to Qt patch request:
https://qt.gitorious.org/qt/qt/merge_requests/916
As mentioned, it's pretty generic and just puts the QMenu implementation into a plugin.

I've (expressed) personal concerns about the qdbusmenu approach and actually would much prefer the introduction of a new class which will
- prevent any kind of backward breaking
- allow explicit reorganization of the menu (like FF does) rather than verticalizing the horizontal menu (one justification for this is to preserve vertical screen estate...)
- not support some canonical move (sorry, i do not trust them at all)
but that's no spec but a mockup and afair Gtk+/Gnome is going for client-side-decorations anyway (so there needs to be no any kind of spec, because it'd be completely toolkit/application internal) - in this case we'd just waste time (on ppl. who don't care about others - who said that, btw?) and don't have to wait since there'll be two systems anyway and no uniform desktop in sight.

--- PS:
Next time anybody tells you "i don't care about [you, your family, your interests, etc.]" you just reply: "I don't care about anything but myself - that's why i'm seeking for some coordination here to not completely waste my time."

sorry for restatements - mid-air incident ;-)

>that's no spec but a mockup and afair Gtk+/Gnome is going for
>client-side-decorations anyway 

From what i understand, they plan to export action with dbus and a new spec, so it's not about client side decoration:

[13:50] <ebassi> gnumdk: it could be; it could be the Shell taking a list of GAction exposed by a GtkApplication and building a menu for them
[13:50] <ebassi> gnumdk: there are various ways of doing this, and they all require collaboration between the desktop and the toolkit. and a consistent design
[13:51] <gnumdk> and why not exposing this action with dbus? I do not understand
[13:51] <ebassi> gnumdk: the action would be exposed on the bus
[13:51] <ebassi> gnumdk: not the menu

> but that's no spec but a mockup and afair Gtk+/Gnome is going for
> client-side-decorations anyway (so there needs to be no any kind of spec,
> because it'd be completely toolkit/application internal)
to my knowledge they gave up on csd after realising that my concerns are valid and various apps just start to crash. Also defaulting to ARGB caused problems with various video players - as we all know ;-)

(In reply to comment #17)
> I've (expressed) personal concerns about the qdbusmenu approach and actually
> would much prefer the introduction of a new class which will
> - prevent any kind of backward breaking
> - allow explicit reorganization of the menu (like FF does) rather than
> verticalizing the horizontal menu (one justification for this is to preserve
> vertical screen estate...)


Ultimatly I would like it works in this way:

The user can switch between a button menu and a menu bar using Ctrl M. It should be a per-application setting (not possible with current qdbusmenu). 

The developper can specify in the rc file a (simpler) alternative menu: <MenuButton>

<gui name="GUI">
  <MenuBar>
    <Menu name="menu" >
      <Action name="an_action" />
      <Action name="an_action_already_displayed_in_the_UI" />
    </Menu>
  </MenuBar>
  <MenuButton  default="true">
    <Menu name="menu" >
      <Action name="an_action" />
    </Menu>
   </MenuButton>
</gui>

If <MenuButton> is available then 
    <MenuButton> is used by qdbusmenu for a button menu.
    if  <MenuButton> has the attribute default="true" then 
          the button menu is displayed by default.  (eg. dragonplayer, kget) 
    else
          the menubar is displayed by default but the user can switch to a button menu using cntrl M (eg. konqueror)
else 
    the menubar is displayed by default but <MenuBar> is used by qdbusmenu, so the user can switch to a button menu with a verticalized menubar. (eg. kdevelop)

Just wanted to ask what's the current state of this project? I would like to see it in 4.9 (and added therefore the target milestone). Soft feature freeze is on May 3rd. So I would like to see a merge request at begin of April

It's ready, i hope sending a patch on reviewboard on monday

https://git.reviewboard.kde.org/r/104344/

Application-menu support in window decoration has been merged into master and will be part of 4.10

commit 1bb5e4fb39613675eac4a29c7c11f3a54303a083
Author: Cedric Bellegarde <gnumdk@gmail.com>
Date:   Fri Nov 9 13:44:50 2012 +0100

    GUI: Kwin appmenu support:
    - Add support for application menu button in Kwin
    - Add kded appmenu configuration in kcm_style