Those used to work indirectly due to GtkEntry not setting GDK_TOUCH_MASK,
so pointer emulation would happen on those, but the event handlers on icons
and its icon-pressed/released signals have never been explicitly touch
aware, and this broke since the GDK_TOUCH_MASK can be set indirectly by
GtkGestures.
So make the icon event handler handle touch events, each icon can get hold
of one GdkEventSequence, reacting exclusively to it. This is still not
ported to GtkGesture due to GdkEvent exposure in these icon signals, as
users might expect GDK_2/3BUTTON_PRESS while GtkGesture ignores those.
Also, unset all icon pressed/sequence state on grab-notify, this used to
happen ad-hoc when initiating icon DnD, but that doesn't cut it for
user-defined reasons to initiate a grab (eg. popovers).
https://bugzilla.gnome.org/show_bug.cgi?id=736004
- cover missing statusses in selection-mode and the like
- button drawing functions cleanup and extension
- remove inline toolbar (ugly) special case not needed anymore
- button selector structure simplification and rationalization
- add back shadow to window control buttons
This is so signal handlers have an opportunity to undo its effect by
returning GDK_EVENT_STOP on ::button-press-event, just like they used
to do pre-gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=735965
This was forgotten when making DnD use a GtkGesture in the handlers
attached to the widget in gtk_drag_source_set(). The gesture must obey
the specified button mask, and switch to denied state if the pressed
button isn't part of the given mask.
https://bugzilla.gnome.org/show_bug.cgi?id=735965
Using the setting for this property conflicts with the documentation
for gtk_entry_completion_set_text_column() which explicitly states
that setting the property directly behaves differently. Concretely,
this caused the file chooser entry completion popup to have two
columns (with identical content).
This partially reverts 331c28b369.
When links are entirely hidden in an ellipsis, don't let
them be activated by clicking and skip them when moving
the focus around.
This commit depends on enhancements in pango 1.36.7 which
make it possible to find the ellipsed runs in a PangoLayout.
With older pango, things will work the same way as before.
https://bugzilla.gnome.org/show_bug.cgi?id=668258
The entry mixin now allows to specify the color of the widget bottom
edge hilight, istead then just enable/disable it, so `$noegde: true`
now is `$egde: none` or `$edge: $somecolor`, not setting it draws
the edge with the default theme color.
Calling this on an Xlib surface allows us to keep this in SHM memory,
giving it a potential speedup so we don't have to copy it to SHM memory
for the Composite when we mask later.
Tools like damn-lies rely on being able to generate .pot files
from pristine checkouts, so everything that goes into the .pot
file has to be in git. This is not ideal, but we already do
the same for other .ui.h files in GTK+.
Otherwise, git.mk will add them to .gitignore, and we want to
add them to source control for the benefit of tools like damn-lies
which rely on being able to generate a .pot file from a pristine
checkout.,
When a printer requires auth_info (e.g. a printer connected
over the samba protocol) it is now possible to save the
credentials necessary for printing if a secrets service
is available over dbus.
The auth_info is then stored / loaded from the default
collection of that secrets service.
If no such service is available the user is not shown
the option to remember the password and the behavior
remains the same as before.
https://bugzilla.gnome.org/show_bug.cgi?id=674264
This must be called while the window is not realized yet, and sets the
GdkWindow that will be used for the next GtkWindow's realize/unrealize
cycle. The GtkWindow takes ownership on the GdkWindow, and as such it
will be destroyed when the widget is unrealized.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
The wayland specific clipboard functions have been replaced by something
more similar to the hooking the win32 backend does, which allows for just
using the default GtkClipboard code in GTK+. As a consequence, the
wayland-specific GtkClipboard implementation is now gone.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
What was happening that the button press event that we use
to select a widget caused another clicked signal emission of
the inspect button, starting another pick action.
Both Owen Taylor and I, the originators of this code, allow the code
herein be relicensed to the LGPL, which is what GTK+ ships with. This
prevents GTK+ from being GPL-only.
Add yet another set of checks and radios assets used in selected
treeview cells and selected list-rows, the standard dark variant assets
work well in those cases so no need for special casing there.
Use the left border color for tree lines. This is similar to
our use of top border color for grid lines. As a side-effect,
tree lines now get recolored when they are in a selected row.
https://bugzilla.gnome.org/show_bug.cgi?id=415415
We need to be a little more forthcoming with showing and hiding
the separators - their visibility now depends on the the visibility
and pack type of the regular headerbar children. This was observed
in gnome-contacts, where headerbar buttons are shown and hidden.
We used to move help buttons to the secondary position regardless
how they were added to the action area. Keep doing that, to avoid
breaking existing dialogs that rely on this behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=735119
The previous way to invalidate was meant to work on the overshoot window
so it wouldn't be as taxing. Since the overshoot window is gone, this
would invalidate way more than intended. So constrain invalidated areas
to the sides where overshoot is happenning at that moment.
https://bugzilla.gnome.org/show_bug.cgi?id=735223
Using `font: Bold` will override the font with whatever the system
resolves a `Bold` font name to, including the font's own default size.
We want the font weight to be bold, but we want the default font name
and size to come from the GtkSettings:font-name property, like we do for
the rest of the system.
The pre-gestures code used to compare the current button press with the
previous one on !activate_on_single_click, and unset the previous event
data so ::row-activated would be emitted every 2 clicks.
So do the same with the multipress gesture and reset it after every 2nd
click to have ::row-activated emitted multiple times while manic clicking.
https://bugzilla.gnome.org/show_bug.cgi?id=735353
This makes the active state work invariably with both mouse/touch, and
regardless of X11 pointer emulation being friendly and sending crossing
events for the emulated pointer events in the latter.
This makes GtkButtons' active state look correct when pressing on
touchscreens on wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=731380
This is a rather hackish way to let GTK+ widgets declare popup windows
as subsurfaces, so they may work on wayland without the need of xdg_popup,
and without many changes yet on the GTK+ side.
https://bugzilla.gnome.org/show_bug.cgi?id=695504
Try to tidy up how the background is set on the textview:
*) the .view class should be applied only to the text window, not
to the margins
*) when setting the background on the margins we must use .left etc
*) use context_set_bg instead of manually setting the color
https://bugzilla.gnome.org/show_bug.cgi?id=735368
gtk_css_section_get_end_position() can return a position one byte beyond
the end of the last line.
gtk_text_buffer_get_iter_at_line_index() accepts only valid
line_number/byte_index pairs. Another solution is to make the
GtkTextBuffer function less strict, by returning a boolean if the exact
position was found.
The CSS parser should also be fixed to always return valid positions.
But it's better to have a safety net in the CSS editor, just in case (a
warning could be print).
https://bugzilla.gnome.org/show_bug.cgi?id=735337
The timeout ID used to be unset after we got the targets from the
clipboard, but there's still a moment between the clipboard request and
the GDK_SELECTION_NOTIFY event that the ID points to an already gone
timeout.
There is an insensitive label in widget-factory which was
not getting any different from the sensitive label next
to it. With this patch, it does, again.
Use U+00D7 MULTIPLICATION SIGN and U+200A HAIR SPACE instead of plain
old 'x' and ' ', following https://wiki.gnome.org/Design/OS/Typography.
Sadly, many fonts don't have space variations, so Pango/harfbuzz fall
back to using the regular space glyph anyway.
NULL was returned in case of an empty last line. Every users needed to
special-case this. Now it will return the expected result: char_len of 0
with one PangoLogAttr.
In compute_log_attrs(), 'paragraph' will be the empty string "" with
'char_len' == 0.
pango_get_log_attrs() works fine with an empty string, it will return
one correct PangoLogAttr (because there is one text position for the
empty string).
It fixes the unit tests for gtk_text_iter_is_cursor_position().
https://bugzilla.gnome.org/show_bug.cgi?id=156164
There was some confusion between unflipped and flipped positions.
Both final_position and current_position are meant to be unflipped,
and get_effective_position() needs to be applied to them to get
a flipped position. _gtk_window_set_popover_position() also expects
an unflipped position.
https://bugzilla.gnome.org/show_bug.cgi?id=735014
This was introduced as a hackish way in 3.6 to make font updates
propagate properly. But since then, font handling has been changed and
this flag is no longer necessary.
gtk_style_context_invalidate_internal() will respect only the current
saved state of the style context, which is wrong when updating the scale.
In that case, the whole style context needs updating.
- only one blank line is enough to separate code sections.
- the 'signals' variable was in the middle of function prototypes.
- compare pointers to NULL in some conditions ("if(blah) should be used
only if blah is a boolean variable). It makes the code clearer.
- various other things.
This is a hack to get around the optimizations done by the CSS engine.
The CSS engine will notice that no CSS properties changed on the
widget itself when going from one state to another and not queue
a redraw.
And the reason for no properties changing will be that only the
checkmark itself changes, but that is hidden behind a
gtk_style_context_save()/_restore() pair, so it won't be caught.
This is more for GTK developers to catch when they forgot to change
GTK_STATE_FLAGS_BITS after adding a new state flag than to prevent
widget developers from using the wrong flags.
This was a hack we added in early 3.x to allow themes to customize their
checkmarks.
Now that we want to properly support real backgrounds everywhere,
supporting this feature would cause double draws of backgrounds.
... in places where we draw a background. This was changed for GTK 3.0.0
to allow animations, but these days it doesn't make sense anymore to use
gtk_render_activity() for backgrounds.
All buttons should always be marked as :active when they are pressed.
That includes checkboxes (which are never activated in real code anyway,
so this change pretty much doesn't matter).
It doesn't make sense to support child displacement in a world where
pseudoclasses behave different from the actual displacement states.
Nobody would ever understand why a widget is displaced.
It is easily possible to simulate child displacement by using padding
CSS properties.
on:
- GtkToggleButton
- GtkCheckButton
- GtkRadioButton
- GtkModelButton
- GtkCellRendererToggle
- GtkCheckMenuItem
also update themes:
- Adwaita
- Raleigh
but not the win32 theme.
The new :checked state replaces :active for the actual checkedness of
the widgets and :active is now used exclusively while the button is being
pressed.
https://bugzilla.gnome.org/show_bug.cgi?id=733967
The font chooser constructs the display name for the font from
the family and face names. Do the same in the font button, so
we don't end up calling the same font by different names, which
would be confusing.
Instead of reconstructing a display name from the
PangoFontDescription, use the font family and face
objects, which have the original font. This lets us
get the names of fonts like Noto Sans CJK DemiLight
right, which would be shown as Noto Sans CJK SemiLight
when mangled via PangoFontDescription, since Pango
treats 'DemiLight' as an alias for the SemiLight weight.
https://bugzilla.gnome.org/show_bug.cgi?id=733832
GtkStatusIcon is using a problematic, XEmbed-based protocol under X,
and we want to get rid of it eventually. Document our intentions by
marking GtkStatusIcon as deprecated.
https://bugzilla.gnome.org/show_bug.cgi?id=734826
That gesture is meant to handle clicks on multiple buttons, so unset
the GDK_BUTTON_PRIMARY default. Also, remove unnecessary boilerplate
with the new GtkGestureSingle/GtkEventController defaults.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
That gesture is meant to handle clicks on multiple buttons, so unset
the GDK_BUTTON_PRIMARY default. Also, remove unnecessary boilerplate
with the new GtkGestureSingle/GtkEventController defaults.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
That gesture is meant to handle clicks from several buttons, so unset
the new GDK_BUTTON_PRIMARY default. Also, remove unnecessary boilerplate
with the new default values.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
GtkGestureSingle::button is set to 0 on the multipress gesture, as several
buttons are managed by that gesture. Also avoid some extra lines of code
setting what nowadays are default values.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
GtkGestureSingle::button is set to 0 on the drag/multipress gestures, as several
buttons are managed by these gestures. Also, avoid some extra lines of code
setting what nowadays are default values.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
GtkGestureSingle::button is set to 0 on the multipress gesture, as several
buttons are managed by that gesture. Also avoid some extra lines of code
setting what nowadays are default values.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
GtkGestureSingle::button is set to 0, as multiple buttons are managed by
the same gesture. Also avoid some extra lines of code setting what nowadays
are default values.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
gtk_statusbar_remove_all() was popping the top message if its
context_id matched before removing other matching messages from the
stack. This meant that if the context_id of the second top message
matched it was still displayed when the top message was popped and
then removed from the list of messages without updating the display.
Fix this by removing all the matching messages below the top one
before popping it if it matches.
https://bugzilla.gnome.org/show_bug.cgi?id=724281
Changing adjustment via the property setter would not emit
value-changed, however changing it via gtk_spin_button_configure would.
This inconsistency had the following side-effects:
- Setting an adjustment with a different value would not update the
value shown by the spin button.
- Creating a spin button like this (common in GtkBuilder XML) will
not show the initial value:
g_object_new (GTK_TYPE_SPIN_BUTTON, "adjustment", adj, NULL);
Let's use the same code path (ie. gtk_spin_button_configure) for all
public facing API for setting adjustment. The code that handled the
details of swapping out the old adjustment with the new has been split
into an unset_adjustment method and the rest has been folded into
gtk_spin_button_configure.
A spin button really needs an adjustment to work, so we don't need
most of the NULL checks. However we do need to check in
unset_adjustment because setting a new adjustment during object
creation might try to unset a non-existent one.
https://bugzilla.gnome.org/show_bug.cgi?id=734660
As a noinst_PROGRAMS, the libtool generated for cross-compiling will be
used, which will mess up the linking. Create a all-local target instead.
Also ensure that building uses always a native version of the tool by
specifying a GTK_UPDATE_ICON_CACHE automake variable.
Finally "config.h" has been created to work for the target platform and
causes problem when cross-compiling. So we temporarily generate a basic
config.h which contains only the strict minimum.
It is actually a bad idea to use noinst_PROGRAMS for build tools,
because it adds a $(EXEEXT). It is best to override the all target
with all-local to trigger the tool build.
If the foreground color has an alpha != 1 we used to just pass that into
the svg. This is useful to e.g. render an insensitive icon. However,
that is not an ideal model for symbolics. For instance, if the icon uses
overlapping areas when drawing, expecting these to be opaque then the
transparent color will result in a different alpha value for the overlapping
area. Also, non-foreground symbolic colors are still rendered opaque, and
the recoloring of pngs can't handle transparent colors.
So, instead we extract any alpha from the foreground, render using the
opaque colors and then apply the foreground alpha to the entire result.
This means we get an even transparency, even for other colors, and we
can apply alpha for the pngs too.
https://bugzilla.gnome.org/show_bug.cgi?id=734668
_gtk_icon_helper_get_size() is often used during size request and may
not necessary mean that the icon will be displayed immediately. In
many common cases we know the size without having to ensure a surface.
In many cases this means we can avoid loading an icon until needed, and
in the case of stateless IconHelpers such as GtkCellRendererPixbuf this
is very important as otherwise it will constantly be reloading icons
if the displayed set is larger than the in-memory icon cache.
https://bugzilla.gnome.org/show_bug.cgi?id=734651
If a child has set_has_window == FALSE, it purely relies on the events set on
the parent window, for which the bin window used to just ensure the exposure
mask, eating all input events.
https://bugzilla.gnome.org/show_bug.cgi?id=734357
gtk_widget_get_events() must indeed tell about events enabled purely through
a GtkEventController, those events will most surely trigger event handlers.
https://bugzilla.gnome.org/show_bug.cgi?id=734357
This check used to be present in the pre-gestures code, but was unintentionally
removed when splitting code into drag/multiclick gestures. The policy used to
be that if clicking happened on an already selected node, DnD would happen
instead of rubberband selection, so this behavior is resuscitated.
https://bugzilla.gnome.org/show_bug.cgi?id=734143
gtk_gesture_drag_get_start_point and gtk_gesture_drag_get_offset
have out args that need to be annotated.
This commit adds the (out) and (nullable) annotations as appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=734292
For that to happen the libgtk3 is embedded with a manifest that requests
common controls library 6.x, and GTK lazily calls InitCommonControlsEx()
to initialize those. Then this manifest is used to temporarily override
the process activation contest when loading comdlg32 (which contains the
code for the print dialog), ensuring that it too depends on common
controls 6.x, even if the application that uses GTK does not.
https://bugzilla.gnome.org/show_bug.cgi?id=733773
handle_x always corresponds to the visible position of the handle,
which is where we want to start the animation. Without this, repeated
keyboard activation will not always animate.
Since we are storing positions here that depend on the allocation,
we need to update them in size-allocate. This fixes incorrect
positioning of the handle if the switch is active initially.
https://bugzilla.gnome.org/show_bug.cgi?id=734213
