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
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
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.
(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).
> 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.
(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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Created attachment 82699 [details] screenshot
A litle side effect on Unity, there is a new named like the application, is it ok Caolan or is it a bug ?
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