I think GNOME is pretty set on eliminating menu bars....

Our goal is for ALL applications to provide app menus, not just GNOME applications, and not just in GNOME Shell.  I think Unity handles them very well already, adding them to the left of the traditional menu.

Not using an app menu would make Calculator inconsistent with other GNOME apps outside of GNOME Shell. Surely you don't expect every GNOME app to implement a fallback menu? gedit always shows a traditional menu bar and just makes a choice about whether to provide an app menu in addition to that, but this will change soon.  A better comparison would be to e.g. Nautilus, which uses only an app menu, or to Mines and Mahjongg, which are roughly as simple as Calculator: are you going to propose menu bars for them as well?

Furthermore the menu items you suggest (cut/copy/paste/undo/redo) are just clutter; mousing up to the menu bar to use Copy is not the workflow we're after.

Since you're looking for consistency, I would suggest proposing a GNOME goal to add fallback menus for all apps.  Otherwise, I predict more GNOME apps will be removing their menu bars.

> I think GNOME is pretty set on eliminating menu bars....

Right, no discussion there.

> Our goal is for ALL applications to provide app menus, not just GNOME
> applications, and not just in GNOME Shell.  I think Unity handles them very
> well already, adding them to the left of the traditional menu.

Well, Unity handle them, but they look weird, our menus are more traditionnal ones. Other desktop (XFCE, KDE, LXDE, etc) and other platforms (win32, masOC) don't have an "appmenu" though. 

GTK does fallback in those cases, but the fallback doesn't look as good in those environment that a standard menu would


> Not using an app menu would make Calculator inconsistent with other GNOME apps
> outside of GNOME Shell. Surely you don't expect every GNOME app to implement a
> fallback menu? 

Why not? Having a fallback menu is not that much code, see the patch there. It's basically a 3 lines function, a if test and a .ui for that menu

> A better comparison would be to e.g. Nautilus, which uses only an
> app menu, or to Mines and Mahjongg, which are roughly as simple as Calculator:
> are you going to propose menu bars for them as well?

Yes

> Furthermore the menu items you suggest (cut/copy/paste/undo/redo) are just
> clutter; mousing up to the menu bar to use Copy is not the workflow we're
> after.

Who is "we"? That's a standard workflow for most users. Sure keyboard or context menus are more efficient, but they are not discoverable.


> Since you're looking for consistency, I would suggest proposing a GNOME goal > to add fallback menus for all apps.  Otherwise, I predict more GNOME apps 
> will be removing their menu bars.

Well, I don't think that's a *GNOME* goal. GNOME doesn't need fallbacks. Those wishlist are mostly concerning apps that are used outside of GNOME/don't exist only to be a part of GNOME3 (gnome-calculator, gedit, eog, file-roller, evince, rhythmbox, ...).

@Michael: see https://wiki.gnome.org/HowDoI/AlternateMenubarLayout as well

I'm mostly concerned about consistency, so if all GNOME apps are going to do it, cool.

That looks like a fairly strong proposal, but as written, nothing there applies to Calculator: we don't have a gear menu at all, and that page notably does not call for removing the app menu.  I think we need some more discussion on how this fallback should work, and to propose it as a formal goal.  In the meantime, the vast majority of our apps provide no such fallback.

(In reply to comment #4)
> I'm mostly concerned about consistency, so if all GNOME apps are going to do
> it, cool.

All GNOME apps are not doing it. It doesn't make sense for most of them. You can't just retrofit a different design into an app like that, in general.

And I really don't see how it makes any sense for something that is that much a utility as a calculator - every desktop ships one, so why should the gnome-calculator need to grow a design bifurcation to accomodate traditional desktops ?

The scenarios under discussion are:

1) Providing a fallback menu as an alternative to the gear menu, as proposed by Ryan. This has nothing to do with Calculator, which does not have a gear menu.

2) Providing a fallback menu as an alternative to the application menu, which is what Sebastian is asking for.

Both are reasonable. Personally, I favor #1 and not #2. The proposed menu layout in this bug shows exactly why I think this is unnecessary. I do not think that application menus are incompatible with other desktops, and I'd rather we encourage non-GNOME apps to show the application menu in all environments than encourage GNOME apps to do the opposite.

Regardless, this is something we should figure out on a GNOME-wide basis, not in a Calculator bug.  (I'm actually pretty surprised Matthias found this.)  Part of the inconsistency problem is that different apps are handling this differently.  E.g. gedit is merging the app menu into the traditional menu bar Unity and OS X.

(In reply to comment #5)
> And I really don't see how it makes any sense for something that is that much a
> utility as a calculator - every desktop ships one, so why should the
> gnome-calculator need to grow a design bifurcation to accomodate traditional
> desktops ?

Ubuntu still ships GNOME Calculator (and several other GNOME utilities) by default. Considering recent contributions to Calculator, that's clearly been to GNOME's benefit.

@Matthias: gcalctool (which is now gnome-calculator) is an old project, it was not started with the goal to be "useful for the GNOME desktop only". 

GNOME sort of took over it and enforced its design changes, which is fine, but saying that others want to "bifurcate to accomadate traditional desktops" is quite a twist. 

But you are right, there are enough calculators out there than other desktops users can find one that fits in the environment they use.


@Michael: thanks for trying to be constructive. 

Imho the issue there is that the different desktops are building different visual identities, which is likely to lead to "applications need different versions/UIs for different desktops" (the same way mobile apps need different versions for e.g android and iOS). The differences are still low enough that it's easy to accomodate things easily with some patches at the moment though, so let's see if that remains to be true.

Review of attachment 260467 [details] [review]:

I guess instead of letting this sit unreviewed forever, I'll bite.

I'm willing to push something similar to this if Arth approves, recognizing that Calculator is a core app for Ubuntu as well as for GNOME, and that the maintenance burden of this patch is quite small.

::: gnome-calculator/data/classicmenu.ui
@@ +4,3 @@
+  <menu id="appmenu">
+    <submenu>
+    <attribute name='label' translatable='yes'>Edit</attribute>

I have misgivings letting Cut/Copy/Paste/Undo/Redo live in the menu bar, since they are not very useful in any menu bar, let alone a global menu, but if your designers really want them there I won't argue.

@@ +44,3 @@
+    </submenu>
+    <submenu>
+      <attribute name='label' translatable='yes'>Mode</attribute>

Since you created this patch, I moved Mode out of the app menu and into the window.  In 3.12 it's a gear menu packed into the start of the header bar; in 3.13 the header bar title is actually a dropdown menu that lets you change mode. So this is redundant now. I think you should take this menu out of this patch, and if you wind up patching out the header bar (which would be unfortunate) include it in that patch. Up to you.

::: gnome-calculator/src/gnome-calculator.vala
@@ +81,3 @@
         {
+            if (has_app_menu)
+                builder.add_from_resource ("/org/gnome/calculator/menu.ui");

Let's rename this to appmenu.ui if we're going to have multiple menus.

@@ +106,3 @@
+    }
+
+    protected bool calculator_has_app_menu ()

Should be private rather than protected

@@ +108,3 @@
+    protected bool calculator_has_app_menu ()
+    {
+        Gtk.Settings gtksettings = Gtk.Settings.get_default();

Missing a space before the parenthesis.

@@ +118,3 @@
+        bool show_menubar = gtksettings.gtk_shell_shows_menubar;
+
+        return show_app_menu && !show_menubar;

We definitely do not want to show a menu bar anywhere besides Unity. This probably made sense when you created this patch, since our app menu fallback used to be horrible, but nowadays we show the app menu with a menu button in the header bar, which I strongly prefer to a menu bar. So please just directly store Gtk.Settings.get_default ().gtk_shell_shows_menu_bar into a bool has_global_menu (instead of has_app_menu).

(In reply to comment #8)

> I'm willing to push something similar to this if Arth approves, recognizing
> that Calculator is a core app for Ubuntu as well as for GNOME, and that the
> maintenance burden of this patch is quite small.

Sure, as Calculator is one of the core app for many different DE and distros, it does make sense to push this patch forward.


> I have misgivings letting Cut/Copy/Paste/Undo/Redo live in the menu bar, since
> they are not very useful in any menu bar, let alone a global menu, but if your
> designers really want them there I won't argue.

Even I'm against cut/copy/paste in a menu. It's one counter intuitive habit that other closed source products have kind of regulated. Much better way to handle them in a tool like calculator would be by having dedicated buttons assigned to them.

For Undo/Redo, something like the back/forward buttons of Nautilus would be good, but it would be orthogonal to current discussion.

But if designers wants it as menu items, I'll be happy to accept it. :)

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

Created attachment 291693 [details] [review]
Don't use HeaderBars in Unity

This is the new style of patch we are going with in Ubuntu. Instead of relying on the X settings which are not necessarily set correctly we check XDG_CURRENT_DESKTOP and disable the HeaderBar when in Unity.

This method means that we special case Unity as opting out of the default GNOME experience with header bars. Other desktops would then have to be added to the blacklist to get the same behaviour.

In the case of Calculator we hide the header bar and add a menu instead. For other programs we just convert the header bar to a toolbar. This makes the patch very simple and is probably what should be done if the Calculator header bar gets more complex.

Arth, does this look good to you? The net effect is that there will be a Mode menu in the Unity menu bar immediately to the right of the app menu, and the header bar is completely dropped. This seems like the best approach to me. If in the future the header bar grows more functionality (which hopefully it will not), then it can be easily packed into the top of the window so that it appears immediately below the normal Unity window decoration.

Created attachment 292108 [details] [review]
Don't use HeaderBars in Unity

Updated for preferences dialog

Created attachment 304911 [details] [review]
Don't use HeaderBars in Unity

Updated to git master.

Not sure my opinion counts much here, but I can't see any way in which putting a menubar on a calculator is an improvement, regardless of which environment it runs in...

It counts for a lot with me, but not as much as Robert's, since he rewrote all of Calculator himself a few years back. Anyway, there is a failure of design downstream (especially since their global menu bar is going away; no need to use it if it's not baked into the desktop anymore), but users are going to get the patched version either way. This will help them keep their Calculator package up to date.

A couple more of these I handled with different results:

https://bugzilla.gnome.org/show_bug.cgi?id=739768
https://bugzilla.gnome.org/show_bug.cgi?id=750470

Let's just patch this downstream as desired. GNOME apps should not have menu bars anymore.