Bug 266596 - Add support for appmenu-qt
Summary: Add support for appmenu-qt
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: kdecorations (show other bugs)
Version: git master
Platform: Arch Linux Linux
: NOR wishlist
Target Milestone: 4.10
Assignee: KWin default assignee
URL:
Keywords:
: 211978 (view as bug list)
Depends on:
Blocks: 102607
  Show dependency treegraph
 
Reported: 2011-02-18 12:31 UTC by Cédric Bellegarde
Modified: 2012-11-09 13:24 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.10
mgraesslin: ReviewRequest+


Attachments
firefox (36.62 KB, image/jpeg)
2011-02-18 12:31 UTC, Cédric Bellegarde
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cédric Bellegarde 2011-02-18 12:31:55 UTC
Created attachment 57348 [details]
firefox

Version:           SVN (using KDE 4.6.0) 
OS:                Linux

It should be cool to have appmenu (menu application over dbus) support in Kwin.

You should be able to add a button in titlebar configuration that will show application name with a single button menu for application, like firefox on Windows.

Reproducible: Didn't try
Comment 1 Dotan Cohen 2011-02-18 13:34:57 UTC
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.
Comment 2 Thomas Lübking 2011-02-18 16:54:18 UTC
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
Comment 3 Christian Jann 2011-02-18 17:30:00 UTC
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.
Comment 4 Cédric Bellegarde 2011-02-18 17:38:20 UTC
I know titlebar plugin but it's not the solution:
- It's a hack
- It doesn't works without effects
Comment 5 Martin Flöser 2011-02-18 17:52:58 UTC
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.
Comment 6 Martin Flöser 2011-03-20 14:36:57 UTC
*** Bug 211978 has been marked as a duplicate of this bug. ***
Comment 7 Dotan Cohen 2011-05-03 13:07:56 UTC
Martin, would it help if I open a ticket at Qt for this?
Comment 8 Cédric Bellegarde 2011-05-03 14:18:52 UTC
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.
Comment 9 Martin Flöser 2011-05-03 18:39:09 UTC
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
Comment 10 Cédric Bellegarde 2011-05-03 19:17:55 UTC
Are you sure appmenu patch will be accepted by Qt devs ?

It seems that gtk devs reject it...
Comment 11 Martin Flöser 2011-05-03 19:35:42 UTC
(In reply to comment #10)
> Are you sure appmenu patch will be accepted by Qt devs ?
In the merge request it looked quite positive.
Comment 12 Thomas Lübking 2011-05-03 19:44:25 UTC
@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 ;-)
Comment 13 Cédric Bellegarde 2011-05-04 08:42:29 UTC
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...
Comment 14 Cédric Bellegarde 2011-05-04 11:45:31 UTC
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 ?
Comment 15 Cédric Bellegarde 2011-05-04 14:01:32 UTC
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 :-/
Comment 16 Cédric Bellegarde 2011-05-04 15:54:34 UTC
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.
Comment 17 Thomas Lübking 2011-05-04 15:56:32 UTC
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."
Comment 18 Thomas Lübking 2011-05-04 15:57:12 UTC
sorry for restatements - mid-air incident ;-)
Comment 19 Cédric Bellegarde 2011-05-04 16:07:26 UTC
>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
Comment 20 Martin Flöser 2011-05-04 16:18:13 UTC
> 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 ;-)
Comment 21 Lionel Chauvin 2011-05-04 17:27:39 UTC
(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)
Comment 22 Martin Flöser 2012-03-11 15:02:28 UTC
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
Comment 23 Cédric Bellegarde 2012-03-14 07:32:43 UTC
It's ready, i hope sending a patch on reviewboard on monday
Comment 24 Cédric Bellegarde 2012-03-19 10:25:22 UTC
https://git.reviewboard.kde.org/r/104344/
Comment 25 Martin Flöser 2012-11-09 13:24:05 UTC
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