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.
File/Quit, Edit/Preferences|Input Devices|Keyboard Shortcuts should not be in
the main menu bar on macOS because they are already in the "app menu".
See #9322.
- Remove the wiki which is now dead.
- Update the roadmap link and title it in plural.
- Move the "Bug Reports and Feature Requests" inside "GIMP Online/" submenu.
I'm not sure what's the default for random string attribute, but better be
explicit anyway. I think this way, we make sure that gettext won't try and
translate these.
This removes a bunch of inconsistencies we had from the before-2.99.16 version
because new items from plug-ins were all added at the bottom of their respective
submenu.
This will replace the "placeholder" concept where I was using an invisible item
with a label and no action, making it invisible. Instead let's just name
(internally) our sections. This has the following advantages:
* Conceptually more correct: basically we just want to place items among the
same category of actions.
* Easier to search for plug-in developers who'll want to place their plug-in
procedures in menus, because it uses an actually searchable attribute
("section-name").
This is used by the core by allowing a special syntax in menu paths: if finished
by "/[Section]" then the item will be place in the specific section named
"Section". In case one actually wanted to create a submenu called "[Section]",
they can use a double bracket: "[[Section]" and "[[Section]]" will both map to a
normal submenu (not a section name) titled "[Section]".
All other usage of square brackets will not be processed in a particular way.
E.g. "Hello [World]" will end a submenu titled "Hello [World]" or "Bye]" will be
a submenu and so on.
Finally this system is currently limited to the position of the item itself,
i.e. must be placed as last element in the path. In particular, you currently
cannot use it to position a new submenu inside a section. E.g. say that I want
to create a submenu "From Platforms" under the "Open" section of the File/ menu.
This is currently impossible. With this syntax, we can create new items directly
in the "Open" section, or create a "From Platforms" submenu in the end of the
File/ menu, containing our new procedures.
This could be a good improvement to come.
Sphere-designer: Since some of the strings are translated versions, we
can't know in advance how long they are going to be.
Let's use string copy/cat functions that explicitly check the size and
are guaranteed to add a NULL.
- Add modern error handling using GError.
- Check return values of fseek and fgetc for errors.
- Remove most occurrences of g(u)long.
- Fixed overflow issue with maxred/green/blue found with coverity.
I noticed this in coverity. I couldn't find any actual script using
SF_DISPLAY, so the impact probably isn't very big.
Because the enums start at 0, the size of the array should be at least
one more than the value of the last enum, which was not the case here.
Increase the size of the array by 1, so that accessing SF_DISPLAY,
which is the enum with the highest value, is valid.
Resolves#5742.
The check is for a horizontal line (where the Y coordinate
would be the same for all three points), but the X axis was
checked instead due to a copy/paste error.
Resources are stored by the plug-in infrastructure and their memory should not
be managed by plug-in code.
My commit 4f69995b46 was crappy and modified a generated function. I was just
too tired with all the heat in here, I guess!
Similarly to how we handled image items, all resources are handled and stored by
the plug-in infrastructure and should not be destroyed. This wrong annotation
was triggering bindings to unref resources when going out of scope, hence
crashing plug-ins.
Note that in the future, we expect this to be possible to create other brushes
with a same name. Maybe we should have a special function allowing to request
core resources (the ones installed by GIMP itself).
