This has been proposed several times, and the conclusion was:
- If this is ever implemented, it should be an option (many people do
  like to reduce screen clutter by having a pop-up menu instead of a
  permanent menu bar - for the same reason it is possible to hide the
  rulers or the status bar to leave as much space as possible for the
  image)
- None of the current developers are interested in implementing it,
  but a patch would be appreciated.
It looks like you are proposing to do exactly that, so this is fine.
However, you should take into account the fact that the current
version in CVS is very different from the 1.2.x branch, so the patch
will only work for one of the branches.

Re-assigning all Gimp bugs to default component owner (Gimp bugs list)

Reassigned to current CVS because it's a wishlist item.

Just one question: What's the problem with the triangle in the
image window? Is there really a need to waste precious desktop
space for yet another way to access the menus? 

The problem is that a the menu is :

1/ a standard in most GNOME apps.
2/ a standard in most GUIs including MacOS, Win, BeOS, Gtk, Motif, etc.
3/ hierarchical menus have always been a pain to use, and having a
menu bar insure that we reduce the nesting levels by at least 1.
4/ right-click menu is in other GUIs a contextual menu, and the idea
is good enough to be followed.

BTW I talked about making this an option. I just haven't found some
time to dig into this like I did for Dia.

This has already been discussed every so often and the answer is that
the GIMP developers will most probably not accept such a change since 
we don't like the idea at all. The menu-bar you propose would have to
be very wide to give place for all the menus we have in the first
level of the image menu, so you won't be able to reduce the nesting 
level at all. Even worse, the menu bar will be too wide for a lot of
screens and you definitely don't want your image window to be larger
than necessary. Don't waste your time on this!

I must disagree with you.
First of all if there are two much top-level menu, perhaps could the
be reorganized. As for the window being larger that necessary, this is
up to the user to decide. Afterall he can size the window the way he want.

I needed to you use GIMP today and must say that I was pissed off by
this menu trickery. For me it is a *BAD DESIGN*. Sorry to be rude
about that.

<rant>
Many people think that the user interface of the Gimp could be
improved, but nobody has found a good solution yet.  Those who have
used the Gimp for a long time (and this includes all developers) are
familiar with its user interface and consider it to be easy to use.
But several users (especially the new users) think that the interface
is confusing or inconvenient.  Although it is impossible to make
everybody happy, it is important for us (who have a biased view of the
user interface) to listen to the criticism of the interface and to try
and improve it.  However, nobody has been able to propose a new design
that would be suitable for most users.  All proposals have one or more
problems that are hard to solve and could make them worse than the
current system for some users.  But let's keep an open spirit and
discuss these proposals anyway...
</rant>

Sven is right to some extent: if the current menu was placed at the
top of the image windows, it would be very large, and probably even
too large for some screens (laptops, for example).  In order to be
usable, the menu should not have more than 6 or 7 items at the top
level.  Maybe the menu could be re-organized in order to have less
top-level items, but this goes against the idea of reducing the
nesting levels by 1 (mentioned as problem number 3 above).

Even if the menu is reduced to 6 or 7 top-level items, this will
probably take too much space if there are many very small images open
on the screen.  Let's consider the example of someone who is editing
several icons or small images for the units in a game.  He will
probably edit small images (for example, 32x32) and maybe have many of
them (20 or 30) open on the screen in order to compare them.  Having a
menu bar in each image would waste a lot of space.  This may be solved
by using a single menu bar for all windows as in the MDI model (see
bug #7379) or by showing/hiding the menu bar in the images as they
become active/inactive.  But these solutions have their own problems
and I do not think that they would be better than the current system.

On the other hand, there is another problem if you are working with a
few large images instead of many small ones: a menu bar located near
the top of the window will force you to move the pointer to the top of
the window for every operation.  If you want to make several
selections and apply some filters to them, then you will have to move
the pointer back and forth.  Using a context menu such as the current
one saves a lot of movements.

I think that it will be very hard to find a good solution to the user
interface problems.  I am re-opening this bug but setting it to low
priority, as I did for bug #7379.  This means that it is unlikely that
any developer will work on it, but maybe a patch will be accepted if
if it solves the problem without introducing new ones and if it does
not make the code harder to maintain (combining both is very hard).

Hello everyone,

Since the current GUI of Gimp is very different from the typical GUI
logic (i.e. a window with menubar), I think it is not useful to try to
develop one GUI to combine both current and menubar-GUI as some have
suggested here.

I would really like to see a possibility to choose between (i.e.
selectable option) current GUI and one with menubars (or possibly even
fully MDI-style). That way both current active users and newcomers
would have something familiar to work with.

The reason I feel very strongly about this is that if we ever want
people using Photoshop, Paint shop pro or any other similar switch to
using open source, gimp (as the main alternative) must help these
people in the change. At least up to the halfway. Otherwise it will be
too much trouble to learn an entirely new concept of GUI. (i.e. too
much time spent on learning how to use versus actually using the
program productively).

What comes to the feasibility of menubars in Gimp is not a
blocker-issue. It's just matter of (re-)designing. Looking at existing
programs and how they have solved the issues and re-categorizing the
menus for the menubar -version does the trick. If Photoshop can do it,
so it can be done in Gimp as well.

Personally, I find current Gimp somewhat intimidating, because it's
minimalism offers very little guidance on how to start doing things
and what I can do and from where. However, I fully agree that current
GUI is very useful and good for the purpose it's made for. I would
just like to select the "newie"-GUI for myself.

Unfortunately I'm very little of an implementor and more adept at
doing more abstract things and designing. So, I won't be the one to
introduce this functionality to Gimp. However, I think I might
participate to the discussion, when time permits.

Best Regards,
   
         Mox (student of usability, in Finland)

Added this feature to current CVS. Will NOT be added to stable.
Closing this one as FIXED.

2002-12-10  Michael Natterer  <mitch@gimp.org>

  The unbelievable happened: a menu bar per display (optionally)

  * app/widgets/gimpitemfactory.[ch]: Added the possibility to have
  more than one item factory per <Prefix>. Added
  gimp_item_factories_set_foobar() variants of all functions which
  set menu item properties (label, sensitive, ...). Removed
  the #ifndef ENABLE_NLS code since that's no longer possible.

  * app/widgets/gimptoolbox.c: made it robust againt the <Image>
  factory not existing at the time of toolbox creation.

  * app/config/gimpconfig-blurbs.h
  * app/config/gimpdisplayconfig.[ch]: added boolean
  "menu_bar_per_display" property.

  * app/gui/preferences-dialog.c: added a toggle for the new option.

  * app/gui/menus.[ch]: added menus_get_new_image_factory() as
  temporary solution. Will add a GimpMenuFactory which creates the
  item factories soon.

  * app/display/gimpdisplayshell.c: add the menu bar if requested.
  Changed widget packing slightly for the menu bar case.

  * app/display/gimpdisplayshell-callbacks.c: changed accordingly.
  Currently there is no right-click popup menu when we have a menu
  bar. This will change soon.

  * app/gui/file-dialog-utils.c
  * app/gui/gui.c: use gimp_item_factories_set_foo().

  * app/gui/channels-commands.c
  * app/gui/dialogs-commands.c
  * app/gui/dialogs-constructors.c
  * app/gui/drawable-commands.c
  * app/gui/edit-commands.c
  * app/gui/file-commands.c
  * app/gui/image-commands.c
  * app/gui/layers-commands.c
  * app/gui/plug-in-commands.c
  * app/gui/select-commands.c
  * app/gui/tools-commands.c
  * app/gui/vectors-commands.c
  * app/gui/view-commands.c: per-display item factories pass the
  GimpDisplay as user_data to callbacks, not a Gimp. Changed all
  return_if_no_foo() macros to handle both cases.

  Cleaned up the plug-in menu stuff:

  * app/plug-in/plug-in-types.h: removed PlugInMenuEntry type.

  * app/plug-in/plug-ins.[ch]: added plug_ins_proc_def_add() as
  counterpart to plug_ins_proc_def_remove(). Added
  plug_ins_locale_domain() as counterpart to plug_ins_help_path().
  Remember the locale domains just as the help paths. Changed
  plug-in initialization so that their menus can be created multiple
  times.

  * app/plug-in/plug-in.[ch]: use plug_ins_proc_def_add() instead of
  doing it manually.

  * app/gui/plug-in-menus.[ch]: added plug_in_menus_init() which
  just registers the locale domains. Changed plug_in_make_menu() to
  take a list of proc_defs, not plug_ins_defs so it can be used
  after plug-in query.

<tongue-in-cheek>
Great!  Now, could you change the code a little bit so that there can
be only one menu bar on top of the screen and one status bar at the
bottom of the screen (shared by all windows), as well as a large
workspace window covering the desktop and in which all image windows
are included?  That would be nice because it would solve bug #7379.
</tongue-in-cheek>

it is in there. checked with gimp 1.3.16
thanks a lot.