This was by all lights broken, and is basically an implementation detail
of the X11 backend since the pointer emulating touch just steals the pointer
cursor, so should be reimplemented there.
One used to point to the toplevel and the other to the client-side window
that the pointer pointed to. The latter was made to be like the former in
most places, so put those together, and fix the remaining cases where the
variable might not end up with a toplevel/native window.
This is not necessary now that there's no client-side windows to track.
The only removed piece that could make sense is emission of grab broken
events, but it's already an stretch since the semantics of those with
multi-touchpoint is unclear.
Anyhow, This should be fixed at the GTK level, while we let GDK deal with
seat/device level grabs.
GDK just needs to care about toplevels nowadays, which means these events
are already delivered from the windowing. We don't need to generate
intra-window crossing events ourselves.
Those should be interpreted by widget-local gestures, not guessed at a
high level with no notions of the specific context. Users will want
GtkGestureMultiPress to replace these events.
Those worked similarly to those in GtkFlowBox, but would additionally
handle "active" state for child rows. Simplify this to just enabling/
disabling active state on gesture press/release, we don't get the
nice state updates when hovering around with a mouse button pressed,
but the rationale from flowbox applies here, and makes a nice cleanup.
They just maintain priv->in_button and widget state up-to-date, this
basically matters during user interaction, and is already maintained
in the gesture ::update handler. This seems to be sufficient.
Those basically controlled priv->active_child_active, which would
1) trigger a redraw when the pointer enters/leaves it, and 2) ensure
that press/release happen on the same child for it to be activated.
The former is not necessary, and the latter can be simplified by
just checking again the child on the coordinates given by the
::release gesture handler. This makes all enter/leave/motion_notify
event handlers unneeded.
All kinetic scrolling initial velocity calculations are now
taken from the scroll controller. The handling of timeouts
to snap back when overshooting has been also made to just
apply on devices that can't emit ::scroll-begin/end.
This is a GtkEventController implementation to handle mouse
scrolling. It handles both smooth and discrete events and
offers a way for callers to tell their preference too, so
smooth events shall be accumulated and coalesced on request.
On capable devices, it can also emit ::scroll-begin and
::scroll-end enclosing all ::scroll events for a scroll
operation.
It also has builtin kinetic scrolling capabilities, reporting
the initial velocity for both axes after ::scroll-end if
requested.
This change is made for consistency, it doesn't make sense to expose
one-way propagation, as it can only break expectations from GTK+. This
function might be made entirely private in the future, but it still
makes sense to do this in one go for our internal usecases.
This will allow further cleanups and optimizations in capture/target/bubble
event delivery. For simplicity, ATM every widget will receive its own
GtkEventControllerLegacy, it could be desirable to add finer control over
this in the future, so widgets that fully use event controllers for input
management can do away without this legacy piece.
For dependencies that do not generate pkg-config files for their Visual
Studio build systems, we need to look for them using cc.has_header() and
cc.find_library(), namely for Cairo and HarfBuzz, if one does not have
crafted pkg-config files for them (which, by themselves may be
error-prone).
As a result, we will still try to look for Cairo and HarfBuzz using
pkg-config, but will give another shot at them on Visual Studio using
cc.has_header() and cc.find_library() if they couldn't be found via
pkg-config.
https://bugzilla.gnome.org/show_bug.cgi?id=785210
The Vulkan .lib file that is supplied by the LunarG Vulkan SDK is
vulkan-1.lib, not vulkan.lib, so make sure we look for the right
libraries when building on Visual Studio (I am not sure whether the
LunarG SDK will work for MinGW/mingw-w64 builds, as only Visual Studio
.lib files are provided).
Note that this will require one to set LIB and INCLUDE appropriately to
find the Vulkan .lib and header files, and possibly PATH if one's video
drivers do not contain the Vulkan runtime DLL.
https://bugzilla.gnome.org/show_bug.cgi?id=785210
Visual Studio does not support things like -Wl,export-dynamic, so we
need to export those symbols by using __declspec(dllexport). So, we
decorate these with macros which we define accordingly for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=785210
On Python-3.x, we need to set the encoding when opening files, when this
script is run, as it might contain items that are not supported by the
system's locale (for example, non-English Windows). So, we use a
wrapper to set the encoding on Python 3.x, but open the file as we did
when using Python 2.x, since file encodings are not supported there.
https://bugzilla.gnome.org/show_bug.cgi?id=785210
This class is not added by any widgets nor themed by Adwaita/HC.
However, it is presented here as if it does something. It doesn’t.
But we changed the 2 buttons with the .raised class to use symbolic
icons, unlike their ‘unraised’ counterparts, which is unnecessarily
confusing and might make people think .raised affects icons somehow.
So, make them use the same icons in all cases; that way, if .raised is
ever made to do anything, 6 years later, what it does will be clear.
https://bugzilla.gnome.org/show_bug.cgi?id=644248
Instead of showing the 4 types except for GTK_SHADOW_NONE, which are all
treated identically and provide no way for themes to differentiate, just
keep 2 Frames, and make one of them GTK_SHADOW_NONE to demo a flat Frame
along the orthogonal orientation. It seems a FlowBox on its own can only
handle being shrunk along its main orientation. The orthogonal requests
a huge min size – reserving what it would need if the main orientation
got its min size, which would flow all children in 1 line orthogonally.
Adding it to a ScrolledWindow (any policy) enables free shrinking, so
size_allocate() can reflow how users in this situation probably expect.
https://bugzilla.gnome.org/show_bug.cgi?id=787021
Without specifically connecting ::delete-event to something, the dialog
will be destroyed when it is closed, for example by pressing Esc. This
meant that when dismissing it this way, unlike by pressing Cancel, any
custom palette would be lost when the dialog was next opened, and so on.
Resolve this by making ::delete-event just do GTK_RESPONSE_CANCEL, so
closing the dialog has the same effect as clicking its Cancel button.
https://bugzilla.gnome.org/show_bug.cgi?id=787444
