If we provide an AccelGroup when creating a menu item using a sock ID,
it installs the GTK default accelerator, accelerator we can't remove
since we don't know about it. So, don't give an AccelGroup so GTK
don't install it's own accelerator.
This fix also required to properly update the accelerator on some item
we used to ignore since the update didn't work anyway (since the GTK
accelerator was displayed instead).
Note that this doesn't fix the fact the editor popup menu accelerators
are never updated after startup so they don't get updated before
restart after changing a keybinding in the preferences. This is a
separate (and less problematic) issue due to a simple lack of update.
Closes#1912683 and #3599251.
Previously was hard coded with options to suit xterm. As this is
being replaced with different terminal programs some do not accept
the same options. The new setting stores the whole command with
%c to substitute the script name. Upgrades old settings if a new
one does not exist.
CTags defines __unused__ and __printf__, which not only are reserved
identifiers, but actually are used by GNUC as arguments of the
__attribute__() extension. This used to work because no code seeing
those definitions was trying to use them as __attribute__() argument,
but a recent change in GLib made it use it in atomic operation, which
are used by the tagmanager, which itself includes the CTags header
defining those, leading to a weird build failure -- since __unused__
expanded to an unexpected value.
To fix this, rename CTag's __ununsed__ to UNUSED and __printf__ to
PRINTF.
This allows for users to change the colors if needed (may be useful
with some themes or color blind persons).
On the sidebar, only the color is applied for now. This is because
it is not possible to style cell renderers through RC files, all having
to be done in the code; so currently only the color is applied.
This allows the user to override the custom styles we apply to some
widgets, like e.g. the unmatched search entry colors.
We use the :theme priority rather than the :application one because
it seems that the :application one cannot override theme settings, even
if it matches against a name the theme don't have rules for but have
rules for the class of that widget. This prevents a theme from
overriding our styles, but it's unlikely a theme actually provide some
specific stuff for us anyway.
On non-Windows, the icons are installed on the system's icon directory,
so installing our index.theme might override the system's one. Since
it's highly unlikely the theme index is missing on non-Windows, just
don't install it.
Install all icons on Windows, as well as a theme index because the
system doesn't have one and one is required.
Also install the theme index on non-Windows, although it shouldn't
be necessary because the system is likely to provide one.
