Bug 48835 - Provide an application menu in GNOME 3
Summary: Provide an application menu in GNOME 3
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.4.5 release
Hardware: Other All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:4.2.0
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-17 11:04 UTC by Allan Day
Modified: 2018-09-20 02:40 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot (24.20 KB, image/png)
2013-07-19 15:26 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Allan Day 2012-04-17 11:04:19 UTC
GNOME 3 now lets you place items in an application menu. This provides a place for actions and options that are relevant to the application as a whole (as opposed to a single window).

Applications are already using app menus under GNOME 3; it would be good if LibreOffice were consistent with this.

Items I would suggest for inclusion in the app menu are:

New Window
----------------
Preferences
----------------
Help
About LibreOffice
Quit

Documentation on the app menus can be found here - http://developer.gnome.org/gtk3/stable/GtkApplication.html
Comment 1 Caolán McNamara 2012-04-20 03:20:36 UTC
caolanm->meeks: I suppose we could only do this in the gtk2 vclplug, or I guess via yet-another shared lib built when gtk3 is present and dlsym it
Comment 2 Michael Meeks 2012-04-23 03:00:58 UTC
It'd be good to get rid of our window decoration and shove some of the app functionality into there; I can't see us getting rid of our menu bar though.

If we enable gtk3 it builds separate gtk2 and gtk3 backends; I suspect the functionality we need for this is gtk3 specific (?).

So - this is blocked by completing the gtk3 port - not something that's -that- far out, but it needs a man-month or two of concerted work.
Comment 3 Allan Day 2012-04-23 03:21:45 UTC
(In reply to comment #2)
> It'd be good to get rid of our window decoration and shove some of the app
> functionality into there; I can't see us getting rid of our menu bar though.

I wouldn't recommend removing the window decoration without removing the menu bar first (under GNOME 3, at least).
Comment 4 Michael Meeks 2012-04-23 04:19:35 UTC
> I wouldn't recommend removing the window decoration without removing
> the menu bar first (under GNOME 3, at least).

It is hard to see how we can collapse all our menus down into a single top-level entry, and the reviews of Epiphany hiding a number of menu items under some other button elsewhere were not so wonderful.

So - unless we can put all of our menus in the shell bar, it's unclear what benefit this brings really; doing that is a reasonably achievable goal I think, we have an abstraction for it - but the shell doesn't want that.

Anyhow - I'm most interested in people improving this area; cleaning up menus, and/or presenting / simplifying their functionality / putting it somewhere else is fine by me; but we'd need some reasonably coherent approach to that.

Thoughts on what works best here much appreciated etc.
Comment 5 Allan Day 2012-04-23 04:42:56 UTC
(In reply to comment #4)
> > I wouldn't recommend removing the window decoration without removing
> > the menu bar first (under GNOME 3, at least).
> 
> It is hard to see how we can collapse all our menus down into a single
> top-level entry, 

Right, that wouldn't work. All I'm suggesting is to move a small number of application specific items (as opposed to window specific menu items) to the app menu.

> and the reviews of Epiphany hiding a number of menu items
> under some other button elsewhere were not so wonderful.

Epiphany is in a transitional state. The plan is to dispense with the menu that is in the toolbar - see https://live.gnome.org/Design/Apps/Web#Tentative_Design

> So - unless we can put all of our menus in the shell bar, it's unclear what
> benefit this brings really; 

There are two main benefits that I can see:

 * Consistency with other apps in a GNOME 3 environment - we are aiming to ensure that all our apps present their app menu options here in the same way.
 * A more logical menu structure - splitting out options that affect all windows into their own place.

> doing that is a reasonably achievable goal I think,
> we have an abstraction for it - but the shell doesn't want that.

Yeah, I don't think that modifying the top bar is a good idea. The purpose of the top bar is to:

 * Be the presence of the system (as opposed to applications) eg, by providing access to the overview and indicating system status. It delineates the system from applications.
 * Provide a visual anchor that is always present - it's a consistently available way into the system and remains in position despite other changes in state and view (inside/outside the overview, screen rotation, etc)

More information can be found on the GNOME Shell design wiki page:

https://live.gnome.org/GnomeShell/Design/#Top_bar

> Anyhow - I'm most interested in people improving this area; cleaning up menus,
> and/or presenting / simplifying their functionality / putting it somewhere else
> is fine by me; but we'd need some reasonably coherent approach to that.
> 
> Thoughts on what works best here much appreciated etc.

To be clear - I'm not trying to solve the design of LibreOffice's menus. My chief motivation is better GNOME 3 integration.
Comment 6 Michael Meeks 2012-04-23 07:17:21 UTC
Sooo ... this is going to be fun :-) We need to somehow unwind the vcl/sfx2/framework mess to add some VCL APIs to nominate windows as top-levels (I guess), and to add some logic to allow the global 'set_app_menu' magic to get done inside the framework/ code (I suppose).

I suggest we decouple this from the set_menubar thing - which looks more intense (if that's to set the whole menubar for the unity-style merged-menu use-case) - since that's a tad more work.
Comment 7 Matthias Clasen 2012-09-12 00:10:08 UTC
https://gerrit.libreoffice.org/gitweb?p=core.git;a=log;h=refs/heads/feature/unitymenus 

is somewhat related work to convert the entire menubar to a gmenu for wholesale transplantation into the unity top panel.
Comment 8 Caolán McNamara 2013-07-18 16:25:12 UTC
For Mac we have something similar so we can reuse some of the work done there for its equivalent to put preferences, about, help and quit in there.
Comment 9 Commit Notification 2013-07-18 16:32:02 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c6d4c18c7ccf047bdb0ca1b65d8f63efa5d8422f

Related: fdo#48835 first cut at a GNOME3 appmenu



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2013-07-18 19:55:19 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=98ded3e42011b060368899018c07cbd32e7993f1

Related: fdo#48835 turn into unreadable goo to get correct options context



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 11 Commit Notification 2013-07-18 20:04:41 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c2fc6a5c46e1f3a825ba707cdd677eae7e1a688f

Related: fdo#48835 run everything through the uno dispatcher for clean quit



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 12 Commit Notification 2013-07-18 20:13:49 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4843d5e8865d2f63f408f464e28be9440cb1ecc2

Related: fdo#48835 reuse Mac appmenu translations



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 13 Stefan Knorr (astron) 2013-07-19 07:48:16 UTC
Caolan, as someone who would consider himself a Gnome 3 proponent – I'd say the GMenu is currently almost undiscoverable, especially when the application in question also has a menu bar. (It literally took me days to figure out Totem can still open videos via the menu.)

So, please, as long as LibreOffice still has the traditional menu bar, make sure the items in the GMenu are duplicated in there.
Comment 14 Caolán McNamara 2013-07-19 09:23:23 UTC
It also took me ages to realize that e.g. gnome-calculators preferences were in the appmenu after shouting loudly at it for a while :-)

I'm not strongly attached to what goes in it, and/or if they get removed from the "normal" menus. I might punt that bit and just stop after honouring the show appmenu settings.
Comment 15 Commit Notification 2013-07-19 15:20:08 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b163772e77e64261b62a9e8196799a499e4ef77d

Resolves: fdo#48835 complete application menu



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 16 Caolán McNamara 2013-07-19 15:26:25 UTC
Created attachment 82699 [details]
screenshot
Comment 17 Arnaud Versini 2013-09-08 17:19:48 UTC
A litle side effect on Unity, there is a new named like the application, is it ok Caolan or is it a bug ?
Comment 18 Jean-Baptiste Faure 2013-10-13 09:17:31 UTC
Hi Caolan,

As it now possible to build master in release mode, I saw that the name showed in the application menu is "LibreOffice 4.1" instead of LibreOffice 4.2. Perhaps it is a global problem because the master shows the name "LibreOffice 4.1" in the Unity Launcher.

When using French localization (not yet finished), I get the name "LibreOffice 4."; Perhaps the last digit is mangled by the French name of the File menu which is slightly longer ("Fichier").

Best regards. JBF