We use US English which uses behavior. So we replace all occurrences of
behaviour.
Most notable is File Open behavior in preferences. Besides that several
mentions in function documentation and a few in comments.
...the tab itself. Noted by @user062. This adds a right margin to the
close button on the image tabs so that the tab size is pushed out
to fit the button.
Use the dedicated function rather than comparing strings.
Because of this, menu items for the "windows-display-*" actions were not
destroyed, neither were the relevant images because the proxy menu item was
keeping a reference to the image (for the small in-menu preview in Windows
menu).
It's nearly the same list of placeholders which will make it easier to
third-party developers (though format still changed, devs will have to add
square brackets for section names).
Now some section names are missing because we would need to break some list into
smaller sections yet want to avoid having separators everywhere. This makes me
wonder if removing my first placeholder implementation was the right idea.
Anyway this new implementation is cleaner and we should find a way to add
sub-sections without creating separators in menus.
Also I didn't try to add new section names (though I did once or twice, e.g. a
"Close" section around quit/close actions which didn't exist) but eventually we
should. Being able to name logically parts of the menus will make them even more
organized (if we can't name a group of actions, it may mean we didn't think
properly the organization and order).
Per @ajonsson, gettext does not like < or > used as symbols
and throws a warning. They are replaced with HTML entities
< and > to prevent the problem.
These should be hidden on stable releases and shown on unstable branch. But
we'll also want to show these in the stable branch, outside of release
(typically when we'll be at 3.0.1).
The combo box button is contained within a box element.
The box was also having its background-color set,
so there were small square "corners" around each dropdown menu.
This patch separates the box color from the button color to prevent
this.
"Windows" and "Help" should always be last. New top-level menus (created by
plug-ins, scripts or GEGL ops) will be appended in the order of creation between
"Filters" and "Windows" menus.
There were some mixups between a few representations of menus:
* "_Some Menu" and "Some Menu" should both map to an existing submenu "Some
Menu" (in the GimpMenuModel, the stored path doesn't contain mnemonic).
* The menu item on the other hand should contain the mnemonic and not lose it.
* Not only this, but "Some _Menu" should still map to the same menu, even if it
was already created with a different mnemonic. It means that the first
registered menmonic "wins", as we don't want duplicate submenus with same
title (even if they have different mnemonics).
So this new code is better handling the canonical menu path (no mnemonic, no
section name, no double slashes, no trailing slashes, etc.) vs. the
canonical-with-mnemonic menu path to avoid weird duplicates.
Some additional bugs are fixed where we were creating weird empty submenus
containing the same items as the parent menu as well, or when a submenu title
was a perfect prefix of another submenu title at the same level.
Jehan