| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
gtksocket: Adjust X sizes by scale-factor
See merge request GNOME/gtk!164
|
| | |
| |
| |
| |
| |
| |
| |
| | |
X uses unscaled sizes, so they must be scaled properly. Otherwise
GtkSockets end up twice as big as they should be.
Closes: https://bugzilla.gnome.org/show_bug.cgi?id=765327
Signed-off-by: Jason Zaman <jason@perfinion.com>
|
| |/
|
|
|
|
|
|
|
|
|
| |
Gesture stuff
See merge request GNOME/gtk!169
(cherry picked from commit 8b24d59cde9410db28c7b61d323fa8b1f0180300)
334c7911 gesture: Fix get_last_event() docs
e9765c04 gesture: Fix code snippet
4d2b39d9 gesturemultipress: Don’t fire ::released after ::cancel
|
| |\
| |
| |
| |
| | |
wayland: check native window for crossing events
See merge request GNOME/gtk!147
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
gdk_wayland_*_grab()/ungrab() would emit crossing events which translate
as focus_in/focus_out events for keyboard.
However, the ungrab() functions compare the native toplevel as this is
what gets the Wayland pointer enter/leave events with the grab window,
so if the grab is issued on a child gdk window, those won't match and we
would emit more focus_out events than focus_in events.
This means that a widget such as spice-gtk which issues a keyboard grab
whenever the pointer enters the window and releases the grab when it
leaves the window would get uneven numbers of focus_in/focus_out events.
Also, gdk_wayland_seat_ungrab() would not emit crossing events for
keyboard devices, whereas gdk_wayland_device_ungrab() does, which adds
even more potential discrepancies between focus_in/focus_out events.
To solve this problem, introduce two new helper functions which check
the relevant native windows to emit crossing events when needed that get
called evenly from both gdk_wayland_seat_grab()/ungrab() and gdk_Wayland
_device_grab()/ungrab() APIs.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=780422
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/792
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The last round of patches to get the desired direction of value move in
response to scrolls/keypresses on scales had the inadvertent side effect
of giving the opposite direction on scrollbars. Seeing as gtkrange.c is
already a collection of hacks, add another so that fix only holds if the
instance is a GtkScale, since that is what those patches were aimed at.
Close https://gitlab.gnome.org/GNOME/gtk/issues/1065
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
'1053-scroll-cursor-gets-left-behind-if-a-child-widget-steals-the-scroll' into 'gtk-3-22'
Resolve "Scroll cursor gets left behind if a child widget steals the scroll"
See merge request GNOME/gtk!134
|
| | | |
| | |
| | |
| | | |
https://gitlab.gnome.org/GNOME/gtk/issues/1053
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
GtkTextView scrolls to the insertion point when the text
buffer signals a paste is done. This is wrong when there
are multiple views on the same buffer, and the paste
happened in another view.
To fix this, flip the handling of the scroll_after_paste
boolean to only be TRUE if we know that we want to scroll.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
'1069-thread-1-glade-received-signal-sigfpe-arithmetic-exception' into 'gtk-3-22'
Resolve "Thread 1 "glade" received signal SIGFPE, Arithmetic exception."
See merge request GNOME/gtk!151
|
| | | | |
| | | |
| | | |
| | | | |
https://gitlab.gnome.org/GNOME/gtk/issues/1069
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The gtk_app_chooser_dialog_set_heading() function do emit
notify::heading. Since the setter simply calls the function,
the setter itself shouldn't emit a notify signal by itself.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
"Select all" action is possible regardless of the text selection state
or if the text is editable or not.
|
| |/ / /
| | |
| | |
| | | |
Buttons can be created simply with gtk_button_new_from_icon_name().
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is the updates to the Visual Studio 2008 projects to generate
gtk/gtktypefuncs.c using the preprocessor and the gentypefuncs.py that
was adapted from master.
Unfortunately we could not clean up the projects as we did for the 201x
ones due to the differences in project file format.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Combine repetitive parts, and unify using $(PythonDir) for all builds,
which the paths set in the property sheets are now based on the Visual
Studio version and platform combination.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Not that it will make a difference, but to be consistent with the
autotools builds. Include gtkx.h instead of gtk.h when we generate the
source to feed to the preprocessor.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
We now need to generate gtktypefuncs.c by ourselves, so modify the
gentypefuncs.py script from master, and add a custom build step in the
projects to generate gtktypefuncs.c. The custom build step for the 2008
projects will be added later.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
wayland: Fix restarting cursor animation
See merge request GNOME/gtk!150
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When an animated cursor was set and the previous cursor animation delay
happened to be the same, we wouldn't restart the animation timeout and
just return G_SOURCE_CONTINUE assuming the timer would continue. This
assumption is however only valid if the function was called from the
timeout, which is not the case.
Instead also arm the timer also if there is no previous timer active.
|
| | | |
| | |
| | |
| | |
| | | |
We now need the generated sources to be included explicitly in the list
so that they get listed in the project files to be built.
|
| |/ /
| |
| |
| |
| |
| | |
It seems that CoreText is internally calibrated for this, see
https://bugzilla.gnome.org/show_bug.cgi?id=787867 for a detailed
discussion.
|
| | |
| |
| |
| |
| |
| | |
So gcc stops complaining about unnecessary parenthesis.
Closes #1059
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
In scroll_event(), there is no need to check whether we are realized
before emitting ::change-value, as we must be when receiving an event.
Git-formatted/rebased/cleaned up by Daniel Boles <dboles.src@gmail.com>
Close https://gitlab.gnome.org/GNOME/gtk/issues/292
|
| | |
| |
| |
| |
| |
| |
| | |
• #include <math.h> for the new uses of floor()
• Move the new ints and popdown_data into the scopes where they are used
• Don’t pointlessly init other ints to 0 as they always get reassigned
• Burninate gint
|
| |/
|
|
|
|
|
|
|
|
| |
This issue was caused when mouse coordinates were changed to floating
point values in commit e8b38fedbd8961df4aaaa75b122a06ddc68e75f2.
This patch floors the event->x_root and event->y_root values when
setting the navigation region, so the previous behaviour is restored.
https://gitlab.gnome.org/GNOME/gtk/issues/450
|
| |
|
|
| |
This avoids black flicker on compositing WMs when a window is first shown.
|
| |
|
|
|
|
|
|
| |
Use g_str_match_string for better results.
cherry-pick of be2853e5deb60274e43352352de74dc458908fe2
https://gitlab.gnome.org/GNOME/gtk/issues/898
|
| |\
| |
| |
| |
| | |
wayland: Use dev/evdev/input.h on FreeBSD (GTK3)
See merge request GNOME/gtk!132
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The header linux/input.h used by GDK is specific to Linux. It is
possible to get a few Linux headers on FreeBSD by installing v4l_compat,
but it is usually better to use the one shipped with FreeBSD.
We prefer dev/evdev/input.h to linux/input.h here, so it will always use
dev/evdev/input.h on FreeBSD regardless of v4l_compat.
https://svnweb.freebsd.org/changeset/ports/465644
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| | |
'gtk-3-22'
Resolve "GtkTextView accesses already disposed object" in 3.22
See merge request GNOME/gtk!110
|
| | |
| |
| |
| |
| |
| |
| | |
Instead of asking of TextMark for its buffer,
let's reference also the buffer in the SelectionData.
Closes #169
|
| |\ \
| | |
| | |
| | |
| | | |
gdk: do not deactivate window on keyboard grabs
See merge request GNOME/gtk!127
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When pressing e.g. a window manager shortcut, which acquires keyboard grab,
Xorg would send FocusOut NotifyGrab then FocusIn NotifyUngrab. Currently
gdk would then deactivate the current surface, which makes accessibility
screen readers think that we have switched to a non-accessible application
and came back again, and thus reannounce the application frame etc. which we
don't want when e.g. just raising volume.
And actually, receiving FocusOut NotifyGrab does not mean losing the
X focus, it only means an application aqcuired a grab, i.e. it is
temporarily stealing keyboard events. On Wayland, this isn't even
notified actually.
This commit makes gdk only deactivate surfaces when there was an actual
focus switch to another window, as determined by has_focus_window (instead
of just has_focus), which happens either normally through FocusOut with
NotifyNormal, or during grabs through FocusOut with NotifyWhileGrabbed.
Fixes #85
(cherry picked from commit 01455399e83a3dbafb0cdc6e12c7003b2f472a40)
|
| | |
| |
| |
| | |
Another instance of a check needed for gdk_win32_selection_add_targets().
|
| | |
| |
| |
| | |
gdk_win32_selection_add_targets() is for W32 displays only.
|
| | |
| |
| |
| |
| |
| | |
gdk_win32_keymap_check_compose() shouldn't be called for
non-W32 displays (i.e. when using broadway or other backends
that could be made to run on Windows).
|
| | |
| |
| |
| | |
This version also merges widgetbowl into fishbowl.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
to retreive paper size specific hard margins and use this
to set the hard margins in the print context.
(modified by Marek Kasik <mkasik@redhat.com>)
https://bugzilla.gnome.org/show_bug.cgi?id=686109
|
| | | |
|
