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).
Adding unsupported messages was overwriting the old message without
first freeing it. In addition, the first message was initialized
as a string constant.
We now start with duplicating the (empty) string, so that it can be
freed. We then add a define to reduce boilerplate to add the string
for each unsupported feature. The code in this define takes care of
adding the new message and freeing the old message.
Make sure we use gsize for intermediate results to not get integer
overflow on large image sizes.
This still is not ideal, but better than a crash, since we may (try to)
allocate a very large block of memory, which we should eventually fix
by looping over smaller size buffers.
Brushes can't be large enough to actually cause overflow here, but
since the result is gsize, it can't hurt to have the intermediate
results to gsize too.
Jordi Mas