We should not tie the sensitivity of the select button
to the tweak action, since there may be fonts which are
selectable, but not tweakable.
Instead, enable the select button when a font is selected,
as it should be.
These can't be returned as part of the font description,
so we need new api for them. For now, this is just readonly
properties. Maybe these should be writable too, eventually.
Add a button the dialog's header bar that lets us
switch to a second page where we can customize
the selected font.
Make the font chooser widget export an action that the
dialog can use for the button. This has some advantages:
- we can export not just the toggle state, but also enabled
- we can reuse the same enabled state to make the select
button insensitive when no font is selected
To determine whether a font is selected, listen to changes
of the list selection. And ensure that the font chooser is
in an initial state when mapped, even if we close the dialog
from the tweak page.
Both GtkWidget and GtkContainer had similar docs regarding hfw/wfh
geometry management. Move these just to GtkWidget. Also make sure the
examples compile, port everything from gtk_preferred_* to measure and
replace some occurrences of "container" with "widget" where container
was just used to refer to a widget with child widgets.
This test was not updated to using a draw func instead
of the ::draw signal yet. At the same time, make it use
::size-allocate instead of ::configure-event.
Instead of creating a new one for every ident, name and string, just
create one GString and reuse it. This means the GString we keep around
will grow to the maximum size of any ident, name or string we parse,
which is still not terribly large.
Commit 4ee02725b4 made the :hover apply to
the title node, not the arrow node, but the selectors it added were not
caught by the recent commits fixing the specificity of title > arrow.
We don't want a pointer that is moved off a scrollbar
to trigger a row when it gets released. To avoid this,
require an explicit opt-in to handling unpaired-releases.
1) Add a --compare cmd line switch that lets people compare the normal
render path and the render_texture path.
2) Add a -o cmd line switch that lets people render the given .node
file to a texture and save that texture to the given png file name.
Putting a combobox in an expander was causing the combo arrow
to go sideways. Increase the specificity with which we address
the expander arrow to avoid that.
The documentation and annotations for some of the print API is defined
in platform-specific source files, so we need to ensure we're passing
those files to the introspection scanner in order to avoid warnings, and
to get the appropriate introspected API.
We already ceil() the given float texture sizes here, so if they are
valid, the result should definitely be > 0. Textures with size 0 can't
be properly used, especially not as render targets, where they will
trigger an assertion failure later in a glCheckFramebuffer call.
Text nodes will almost always end up using the exact same texture and
the same program. So, in that case we can simply add vertex data for all
the characters we need to draw and use just one draw call.
Render nodes can end up with bounds < 1 since they are floats, and the
implicit cast to int ends up creating a texture with 0 width or height.
Use ceil() instead in create_texture so we don't have to do that on the
caller side everywhere.
This way, we can also clip the created node bounds to the current clip
of the GtkSnapshot. This works as long as we don't modify the start and
end points, and happens all the time while rendering.
Clipping a color node is trivial so we do it here directly since that
might later save the entire clip node as well as freeing the fragment
shaders from coloring lots of pixels that will be clipped away.
The only time a style-updated indicates we need
to reload fonts is when it is synthesized by GtkSettings
in response to a fontconfig timestamp change, but
we are listening to those already, anyway.
Some emoji fonts (such as Emoji One), render Emoji sequences
such as some of the family variations using multiple individual
glyphs. This rendering is too wide and breaks our grid layout.
Therefore, we will just skip any sequence whose rendering is
more than twice as wide as a simple smiley.
Instead, pass the source window to gdk_drag_begin().
Also make Wayland use this window instead of the one under the pointer
(though those 2 Windows are most likely the same anyway).
The function was referencing itself in ways that bamboozled gcc:
static void
foo (void)
{
g_signal_handlers_disconnect_by_func (NULL, foo, NULL);
}
Well done, function, you get your own commit!
The code was asserting something that was not always holding
true. We can hit row == NULL here on page-up too. Handle that
case by moving to the first row.
https://bugzilla.gnome.org/show_bug.cgi?id=791549
Without selections, drags can't have them either.
Also included is removing the selection from GtkSelectionData.
Includes a bunch of crude cleanups to Wayland code that no longer has to
care about selection atoms.
VkImage contains a reference to the VkDeviceMemory and, because
the current code frees the VkDeviceMemory before destroying the
VkImage that references it, a warning is triggered by the validation
layers.
This is not critical, since we release both resources at the same
place. But the warning triggered by the validation layers sums up
adding 1 MB per second of extra debug logging, making the debugging
process much more painful.
This commit simply swaps the destruction order, and destroys the
VkImage first, then the now unused VkDeviceMemory.
There is a gtk_event_controller_scroll_set_flags() call that's meant
to be called after construction (eg. due to scrolledwindow relayouts
hiding/showing scrollbars). The property shouldn't be construct-only
for consistence.
In the motion compression phase the coalesced events will be saved
as a GdkTimeCoord on the motion event that shall be delivered.
For simplicity (and because history doesn't make much sense otherwise)
event history is only recorded while there are buttons pressed, this
also tidily ensures that those coalesced events would have the same
target widget on the gtk side than the delivered one, because of
implicit grabs.
Two warts remain. gdk_event_copy() should be unnecessary as
events should be considered static after delivery, so g_object_ref()
should be just as good. There's a few exceptional cases that the event
is copied and then modifier for later processing, those cases should be
reconsidered individually.
And gdk_event_free() could be likewise turned into g_object_unref(),
many callers remain though.
Now all events structs are private, it doesn't make as much sense
having GdkEventPrivate wrapping allocating events. This is a first
step towards removing it.
It won't stand true anymore that the GdkEventType argument is the
first field of the GdkEvent* structs. All callers have been updated
to use event->any.type instead.
Instead of just passing the GdkContentFormats, we are now passing the
GdkContentProvider to gdk_drag_begin().
This means that GDK itself can now query the data from the provider
directly instead of having to send selection events.
Use this to provide the private API gdk_drag_context_write() that allows
backends to pass an output stream that this data will be written to.
Implement this as the mechanism for providing drag data on Wayland.
And to make this all work, implement a content provider named
GtkDragContent that is implemented by reverting to the old DND
drag-data-get machinery inside GTK, so for widgets everything works just
like before.
Scrolling a path bar is of marginal usefulness - you need to
find a really deep place in your filesystem hierarchy in order
to scroll one or two places at best. And the code we had for
this was not working. And it was using legacy event handlers.
Instead of fixing it, remove it.
We now have a GdkX11Display::xevent signal that gets emitted for every
XEvent and allows you to interrupt processing via TRUE/FALSE return
values.
These return values to correspond to GDK_FILTER_REMOVE and
GDK_FILTER_CONTINUE respectively.
The GDK_FILTER_TRANSLATE case from gdk_window_add_filter() is now meant
to be handled via gdk_display_put_event().
This is in preparation for DND.
It moves a lot of code from gdkclipboard-x11.c to
gdkselectionoutputstream-x11.c to untangle it from GdkX11Clipboard
usage.
This code was doing horrible things, and the atk documentation
for the focus tracking feature says that this is deprecated and
not used anymore. So lets not do it.
Mark the following signals as deprecated:
event, event-after, button-press-event, button-release-event,
touch-event, scroll-event, motion-notify-event, enter-notify-event,
leave-notify-event, property-notify-event, selection-clear-event,
selection-request-event, selection-notify-event, selection-received,
selection-get, proximity-in-event, proximity-out-event. Most
of these have suitable replacements in event controllers and
gestures already. The selection-related signals will soon be
irrelevant when selection handling moves to GDK.
Set G_ENABLE_DIAGNOSTIC=1 to see deprecation
warnings for uses of these signals.
Instead, pass the actions as part of gdk_drag_begin() and insist DND is
always managed.
A new side effect is that gdk_drag_begin() can now return %NULL.
We were allocating the progress bar to the full size
of the entry. This made entry icons loose their cursors,
since they were 'covered' by the progress bar, even though
it doesn't draw anything there.
We need to notify ATK the description changed when the tooltip text associated
with the widget changes and gtk_widget_accessible_get_description() would use
it as the description.
https://bugzilla.gnome.org/show_bug.cgi?id=779009
This fixes stuttering in animations that rely on the regularity of
gdk_frame_clock_get_frame_time.
https://bugzilla.gnome.org/show_bug.cgi?id=787665
BEFORE
gdkgears:
58 FPS and visibly stuttering
gnome-maps on a 59.95Hz monitor:
"paint" g_get_monotonic_time +17278μs, gdk_frame_clock_get_frame_time +17278μs
"paint" g_get_monotonic_time +17449μs, gdk_frame_clock_get_frame_time +17426μs
"paint" g_get_monotonic_time +17620μs, gdk_frame_clock_get_frame_time +17600μs
AFTER
gdkgears:
60 FPS and smoother
gnome-maps on a 59.95Hz monitor:
"paint" g_get_monotonic_time +18228μs, gdk_frame_clock_get_frame_time +16680μs
"paint" g_get_monotonic_time +15010μs, gdk_frame_clock_get_frame_time +16680μs
"paint" g_get_monotonic_time +17134μs, gdk_frame_clock_get_frame_time +16680μs
This is the replacement for selection usage.
Backend implementations for X11 (missing support for backwards compat
formats like COMPOUND_TEXT) and Wayland are included.
GTK code should be adapted to use gdk_drop_read_*() functions instead
of gtk_drag_get_data().
The fix is twofold. First, when checking that a corner is resizable, we must
check the constraints on both edges. Second, when checking either edge we
must include both perpendicular sides in order to allow those to be
resizable when the constraint does not allow resizing the edge being
checked.
When looking for the cursor to apply, start from the innermost
widget and go up. This is the right behavior for cases like
entry icons. The top-down order we were using so far is the
right behavior for cases like global wait cursors. Since we
have entry icons in gtk, but not global wait cursors, lets
pick the other order for now.
Color matrix nodes as the child of other color matrix nodes can happen
quite frequently as a result of CSS. To ease the renderer
implementations, collapse chains of color matrix nodes into one.
In order to map a window with the correct initial parent-child
relationship when a modal dialog is set up to be a child of an imported
foreign window, the relationship must be set up before the window is
mapped.
In order to do this, if a window is not yet mapped, postpone the
relationship setup until when the window is eventually mapped.
https://bugzilla.gnome.org/show_bug.cgi?id=791062
The documentation about gtk_file_chooser_set_local_only() states
that "non-native files may still be available using the native
filesystem via a userspace filesystem (FUSE)."
The code that made this possible in GTK+2 was missing from GTK+3 and
that represented a regression for Linux users in numerous applications
(Firefox, Thunderbird, Chromium, ...)
https://bugzilla.gnome.org/show_bug.cgi?id=787128
Traditionally (and on most backends) there's a single master pointer driven
by all pointing devices. The notable exception is Wayland though, where
master pointing devices are created per capability in the case of
pointer/touch, and one for each drawing tablet.
This function call makes it easy to access all these.
https://bugzilla.gnome.org/show_bug.cgi?id=790920
Same reason as GtkViewport does it: We might allocate child widgets
outside of the paned's content allocation. For drawing, we add a clip
node.
This was causing the "Record" button in the inspector recorder to ignore
pointer events since the treeview column header label in the GtkPaned
was swallowing it.
As the summary says, this allows using g_autoptr(GtkTreePath). This is
useful for API that uses out parameters for GtkTreePath that need to be
freed.
https://bugzilla.gnome.org/show_bug.cgi?id=791234
We are using `path` unconditionally, but it can be conditionally filled.
To avoid inconsistent internal state, and a compiler warning, let's
assert that the variable is always set.
This API allows specifying a GType and va_args of a value of that type
to set the clipboard contents. This massively simplifies setting weird
object types into the clipboard.
2 example patches included in this patch are the GtkTextBuffer and the
file list in the file chooser.
Using gobject-introspection, this should work without specifying the
type, so that you can literlally say
clipboard.set ("Hello World")
or
clipboard.set (pixbuf)
which is why I've also marked all other setters as (skip). They just
exist in C as wrappers for type safety reasons.
This is in preparation of using input streams to show that these
coordinates aren't needed most of the time and can otherwise be saved
during GtkWidget::drag-drop.
I decided to put this in a custom subclass, because then I could keep
the whole gtk primary protocol self-contained.
The other option would have been reusing GdkWaylandClipboard, but that
didn't seem worth it, especially because that code needs to interact
with the DND machinery, while the primary doesn't.
When the reply to a TARGETS request comes in, the clipboard may already
be reclaimed by the local app. Deal with that case (in an ugly way,
strictly speaking we should use a cancellable here).
This happens for example at startup when the initial TARGETS requests
have not been answered until after the main widow popped up. And if such
a window immediately claims the primary clipboard (like when the initial
focus is inside an entry), this race will happen.
This object tracks the SelectionNotifyEvent that has to be sent in
response to a SelectionRequest.
Currently it just looks like code reshuffling, but it's a prerequisite
for handling MULTIPLE, which requires to only send the notify after
every stream has writtten at least once.
But anyway, code is cleaner now, so it's a win!
This is a GSList of GFile and we want it so we can operate with lists of
files and text/uri-list.
I chose GSList over GList because that's what the GtkFileChooser API
uses, too.
Instead of using GtkClipboard and handling everything ourselves, we now
put GtkTextBuffer into the GdkClipboard and register (de)serializers for
text/plain.
Also make clipboard_claim() a vfunc so backends can override it.
Because the whole operation a vfunc, backends have the option of adding
code before the actual claim is done and potentially even fail or do
something after the successful claim.
Instead of having just one function that has the gtype and mime type as
out arguments, have 3 functions: 1 that finds any match, 1 that finds a
GType match and one for a mime type match.
This makes the API way more convenient to use.
This requires implementing a "pipe" so we can have 2 streams running:
contentprovider => serializer => outputstream
inputstream => deserializer => reader
And the pipe shoves the data from the outputstream into the inputstream.
GdkContentProvider is the object that represents local data in the
clipboard.
This patch only introduces the object and adds the clipboard properties,
it does not yet provide a way for the actual implementations to access
it.
The only access that is implemented is the local shortcut GValue access.
(1) Try all passed in formats in order if one of them fails.
(2) Don't blindly accept all formats, make sure they are mime types
(3) Add a bunch of special non-mime types that plug converters to
get to mime types
This allows us not just to pass any mime type to the read function, but
it also makes it possible to pass multiple mime types and the clipboard
can then try them in order until it finds a supported one.
This is so far not implemented though.
Turns out, way too many async operations are implemented by running the
sync operation in a thread. The easiest solution is to support that is
to use a GAsyncQueue for the buffers and deadlock if called from the
main thread.
(1) Turn X11 clipboard event handling into a regular filter function
(2) Maintain a timestamp in the clipboard, so we can pass it when
querying selections.
No idea why it's here, the hash table can store any kind of data,
there's no reason why it wouldn't be able to store an old X string type.
Might be a holdout from the old days, when strings were handled in
a special way (stored directly in the clipboard?).
https://bugzilla.gnome.org/show_bug.cgi?id=786509
This prevents GTK from throwing a bunch of warnings when it tries
to get drag source window -> screen of that window -> ipc widget for that screen,
and then tries to attach a signal handler to that widget.
Specifically, this happens when we get a DnD move from another
application.
https://bugzilla.gnome.org/show_bug.cgi?id=786509
1) Ensure that any DELETE requests from the target are sent to GDK, even if
both the source and the target are in the same process and it
is therefore possible to use a shortcut and call the handler directly
in GTK layer
2) Ensure that target GDK doesn't do anything when GTK asks it to send
a DELETE request, just report back immediately (the code up the stack
does not check for successfullness when request is DELETE, so not giving
it any data is OK).
The source code already synthesizes a DELETE request, so that side is
also taken care of.
https://bugzilla.gnome.org/show_bug.cgi?id=786509
We need to know the target atom value to know when we need to
do something with side-effects (since side-effects are expressed via
special target values). Previously, the code side-stepped that by looking
at the data type (which was rather unique for the one side-effect
target that we supported, signalled by the TARGETS target),
but for the DELETE target that seems to be no longer an option, hence the new
field to carry this information past the convert_selection() routine.
This prevents GDK from throwing a warning when trying to convert
a DELETE target, which has no format or data objects set.
The side-effects for the DELETE target happen earlier, in GTK layer.
By the point it gets to change_property(), it's a no-op.
https://bugzilla.gnome.org/show_bug.cgi?id=786509
To do that, run the message loop for one second or until the side-effect
of running the selection request handler is achieved (as opposed to
running it until the event is no longer queued).
The disavantage of this method is that if the event handling is
somehow missed (due to a variety of reasons - after all, it's not
a straight path from an event being queued to property_change()
being called), this will loop for one second. Since we do process
events during that time, this will not hang the application, but
might still restrict some of the functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=786509
Handle WM_CANCELMODE and do nothing in response to it when DnD is
active. Otherwise pass it to DefWindowProc, which will call ReleaseCapture()
on our behalf.
This prevents us from losing mouse capture when alt-tabbing during DnD
(this includes the feature of Windows Explorer where dragging stuff over
a window button in the taskbar causes that window to receive focus, i.e.
keyboardless alt-tabbing).
https://bugzilla.gnome.org/show_bug.cgi?id=786509
Without this patch layered windows are only updated when they are moved
by the user or then their contents changes. This patch adds opacity
changes to the list of things that make GDK update a window. Without this
windows that don't redraw and are not moved by the used (DnD drag indicator
windows, for example) don't change their opacity.
(This commit is cherry-picked from the gtk-3-22 branch)
https://bugzilla.gnome.org/show_bug.cgi?id=786509
Massive changes to OLE2 DnD protocol, which was completely broken before:
* Keep GdkDragContext and OLE2 objects separate (don't ref/unref them
together, don't necessarily create them together).
* Keep IDataObject formats in the object itself, not in a global variable.
* Fix getdata() to look up the request target in its format list, not in the
global hash table
* Create target GdkDragContext on each drag_enter, destroy it on drag_leave,
whereas IDropTarget is created when a window becomes a drag destination
and is re-used indefinitely.
* Query the source IDataObject for its supported types, cache them in the
target (!) context. This is how GTK+ works, honestly.
* Remember current_src_object when we initiate a drag, to be able
to detect later on that the data object is ours and use a
shortcut when querying targets
* Make sure GDK_DRAG_MOTION is only sent when something changes
* Support GTK drag cursors
* Ensure that exotic GTK clipboard formats are registered
(but try to avoid registering formats that can't be used between applications).
* Don't enumerate internal formats
* Ensure that DnD indicator window can't accept drags or receive any kind of input
(use WS_EX_TRANSPARENT).
* Remove unneeded indentation in _gdk_win32_dnd_do_dragdrop()
* Fix indentation in gdk_win32_drag_context_drop_finish()
* Remove obsolete comments in _gdk_win32_window_register_dnd()
* Check for DnD in progress when processing WM_KILLFOCUS, don't emit a grab
break event in such cases (this allows alt-tabbing while DnD is in progress,
though there may be lingering issues with focus after dropping...)
* Support Shell ID List -> text/uri-list conversion, now it's possible
to drop files (dragged from Explorer) on GTK+ applications
* Explicitly use RegisterClipboardFormatA() when we know that the string
is not in unicode. Otherwise explicitly use RegisterClipboardFormatW()
with a UTF8->UTF16 converted string
* Fix _gdk_win32_display_get_selection_owner() to correctly bail
when selection owner HWND is NULL (looking up GdkWindow for NULL
HWND always succeeds and returns the root window - not the intended
effect)
* More logging
* Send DROP_FINISHED event after DnD loop ends
* Send STATUS event on feedback
* Move GetKeyboardState() and related code into _gdk_win32_window_drag_begin(),
so that it's closer to the point where last_pt and start_pt are set
* Use & 0x80 to check for the key being pressed. Windows will set low-order bit
to 1 for all mouse buttons to indicate that they are toggled, so simply
checking for the value not being 0 is not enough anymore.
This is probably a new thing in modern W32 that didn't exist before
(OLE2 DnD code is old).
* Fixed (hopefully) and simplified HiDPI parts of the code.
Also adds managed DnD implementation for W32 GDK backend (for both
OLE2 and LOCAL protocols). Mostly a copy of the X11 backend code, but
there are some minor differences:
* doesn't use drag_window field in GdkDragContext,
uses the one in GdkWin32DragContext exclusively
* subtracts hotspot offset from the window coordinates when showing
the dragback animation
* tries to consistently support scaling and caches the scale
in the context
* Some keynav code is removed (places where grabbing/ungrabbing should
happen is marked with TODOs), and the rest is probably inert.
Also significantly changes the way selection (and clipboard) is handled
(as MSDN rightly notes, the handling for DnD and Clipboard
formats is virtually the same, so it makes sense to handle
both with the same code):
* Don't spam GDK_OWNER_CHANGE, send them only when owner
actually changes
* Open clipboard when our process becomes the clipboard owner
(we are doing it anyway, to empty the clipboard and *become* the owner),
and then don't close it until a scheduled selection request event
(with TARGETS target) is received. Process that event by announcing
all of our supported formats (by that time add_targets() should have
been called up the stack, thus the formats are known; just in case,
add_targets() will also schedule a selection request, if one isn't
scheduled already, so that late-coming formats can still be announced).
* Allow clipboard opening for selection_convert() to be delayed if it
fails initially.
* The last two points above should fix all the bugs about GTK+ rising
too much ruckus over OpenClipboard() failures, as owner change
*is allowed* to fail (though not all callers currently handle
that case), and selection_convert() is asynchronous to begin with.
Still, this is somewhat risky, as there's a possibility that the
code will work in unexpected ways and the clipboard will remain open.
There's now logging to track the clipboard being opened and closed,
and a number of failsafes that try to ensure that it isn't kept open
for no reason.
* Added copious notes on the way clipboard works on X11, Windows and GDK-W32,
also removed old comments in DnD implementation, replaced some of them
with the new ones
* A lot of crufty module-global variables are stuffed into a singleton
object, GdkWin32Selection. It's technically possible to make it a
sub-object of the Display object (the way Wayland backend does),
but since Display object on W32 is a singleton anyway... why bother?
* Fixed the send_change_events() a bit (was slightly broken in one of the
previous iterations)
* Ensure that there's no confusion between selection conversion (an artifact
term from X11) and selection transmutation (changing the data to be W32-compatible)
* Put all the transmutation code and format-target-matching code into gdkselection-win32.c,
now this code isn't spread across multiple files.
* Consequently, moved some code away from gdkproperty-win32.c and gdkdnd-win32.c
* Extensive format transmutation checks for OLE2 DnD and clipboard.
We now keep track of which format mappings are for transmutations,
and which aren't (for example, when formats are passed as-is, or when
a registered name is just an alias)
* Put transmutation code into separate functions
* Ensure that drop target keeps a format->target map for supported formats,
this is useful when selection_convert() is called, as it only receives a
single target and no hints on the format from which the data should
be transmuted into this target.
* Add clear_targets() on W32, to de called by GTK
* Use g_set_object() instead of g_ref_object() where it is allowed.
* Fix indentation (and convert tabs to spaces), remove unused variables
(This commit is cherry-picked from the gtk-3-22 branch)
https://bugzilla.gnome.org/show_bug.cgi?id=786509
application/x-rootwindow-drop is not useful anywhere else,
so put it under #ifdef GDK_WINDOWING_X11
On W32 this prevents toplevels from automatically becoming valid
drop targets with a useless drop type.
(This commit is cherry-picked from the gtk-3-22 branch)
https://bugzilla.gnome.org/show_bug.cgi?id=786509
Instead of using a boolean to indicate a modal operation being in progress,
use a set of flags, and allow these to be set and unset independently.
Specifically, this allows WM_CAPTURECHANGED handler to only act when a drag-move or
drag-resize modal operation is in progress, and ignore DND (which can also cause
WM_CAPTURECHANGED to be posted). This avoids a crash due to assertion failure when
OLE2 DND code tries to end a modal operation that was already ended by the WM_CAPTURECHANGED
handler.
(This commit is cherry-picked from the gtk-3-22 branch)
https://bugzilla.gnome.org/show_bug.cgi?id=786121
Commit 1d0fad3 revealed that there were some assumptions made that were
actually to compensate for the bug fixed by that commit, so we need to
remove those assumptions as they would result in AerSnap to not work
properly on HiDPI screens.
Also re-do how we set the x and y positions of our GdkWindow, so that we
are more consistent across the board when we go between a GDK window
coordinate and a Windows API window cooredinate.
This would also simplify the code a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=785999
Some drivers don't do that (not sure whether that is the correct behaviour
or not). Remember each WT_PROXIMITY with LOWORD(lParam) != 0 that we get,
then look for a WT_CSRCHANGE. If WT_CSRCHANGE doesn't come, but a WT_PACKET
does, assume that this device is the one that sent WT_PROXIMITY.
Also include fallback code to ensure that WT_PACKETs for an enabled device
disable the system pointer, because WT_PROXIMITY handler might have
enabled it by mistake, since it's not possible to know which device left
the proximity (it might have been a disabled device).
https://bugzilla.gnome.org/show_bug.cgi?id=778328
Previously HiDPI scale was retrieved and applied too late in the initialization
process to affect monitor size and monitor workarea size, but the code that
initializes these sizes *did* try to use the scale, even though it was always
getting scale=1.
To fix this, move the too-late code into monitor enumeration routine.
This also fixes a probable semantic bug where width and height were divided
by scale, again.
Now monitor and workarea should be in application pixels (i.e. divided by scale),
as intended.
https://bugzilla.gnome.org/show_bug.cgi?id=778835
Previously GDK only made up monitors when it initially found none. Now it
also makes up monitors when it initially finds some, but later fails to get
their informatin in a normal way and finally prunes them out, being left with
zero monitors.
Having zero-length monitor array is unexpected and causes a number
of critical warnings and some critical functionality (such as displaying
drop-down menus) fails in such cases.
Ideally, there might be such a way to interrogate W32 API that produces the
information about non-real (but active) monitors out of it so that it isn't
necessary for us to make stuff up. However, this code is already complicated,
and i am not prepared to dig W32 API to find a way to do this.
This fixes the issues people had when they accessed a Windows desktop via RDP.
https://bugzilla.gnome.org/show_bug.cgi?id=777527
Windows WM handles AeroSnap for normal windows on keydown. We did this
on keyup only because we do not get a keydown message, even if Windows WM
does nothing with a combination. However, in some specific cases it DOES
do something - and we have no way to detect that. Specifically, winkey+downarrow
causes maximized window to be restored by WM, and GDK fails to detect that. Then
GDK gets a keyup message, figures that winkey+downarrow was pressed and released,
and handles the combination - by minimizing the window.
To overcome this, install a low-level keyboard hook (high-level ones have
the same problem as normal message loop - they don't get messages when
Windows WM handles combinations) and use it to detect interesting key combinations
before Windows WM has a chance to block them from being processed.
Once an interesting combination is detected, post a message to the window, which
will be handled in due order.
It should be noted that this code handles key repetitions in a very crude manner.
The downside is that AeroSnap will not work if hook installation function call fails.
Also, this is a global hook, and if the hook procedure does something wrong, bad things
can happen.
https://bugzilla.gnome.org/show_bug.cgi?id=776031
Instead of using some kind of flawed logic about modifying a keypress result
when CapsLock is toggled, just add a CapsLock shift level (and all derived
shift levels, i.e. Shift+CapsLock and CapsLock+AltGr and Shift+CapsLock+AltGr)
and query Windows keyboard layout API about the result of keypresses involving
CapsLock.
Keysym table is going to be (roughly) twice as large now, but CapsLock'ed
keypresses will give correct results for some keyboard layouts (such as
Czech keyboard layout, which without this change produces lowercase letters
for CapsLock->[0,2,3,4...] instead of uppercase ones).
Keymap update time also increases accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=165385
Instead of checking for window state and giving it extra styles that
fit, just give it all styles that it is missing. It turned out that
otherwise it is impossible to, for example, restore a maximized window
via sysmenu. Also, be more flexible towards GDK/WM window state mismatches
and consider the window minimized/maximized if *either* GDK or WM thinks so.
https://bugzilla.gnome.org/show_bug.cgi?id=776485
Just set check_for_dpi_awareness = TRUE and eventually it will be handled
correctly, even if setDpiAwareFunc() returns E_ACCESSDENIED or shcore functions
are NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=777031
When primary monitor is smaller than the actual monitor on which the
window is being maximized, the WM will do widnow size adjustments
that will completely screw the window size if we try to make it
smaller than 100% fullscreen (to account for taskbar size, for example).
Fix this by overriding maximized window size during WM_WINDOWPOSCHANGING.
https://bugzilla.gnome.org/show_bug.cgi?id=775808
Change the name of the property from stock-size to icon-size,
and make it an enum property instead of uint. This makes it
impossible to specify invalid numeric values in ui files, and
at the same time makes it possible to refer to the existing
values by their nick.
Fix up the callers.
If the rounded clip node is rectilinear, we can simplify it to a normal
clip node. If not, we really need to use a rounded clip node. In both
cases, we can do the same check we do when collecting normal clips and
avoid the clip node altogether if the child node does not get clipped
anyway.
This saves between 3 and 10 nodes in the widget factory, depending on
what page gets rendered.
Clip nodes have a clip rect and we only need to actually create a clip
node if any child node gets clipped at all. If the clip rect conains the
child node bounds entirely, we don't need a clip node.
Every added widget having a separate random widget type makes it useless
to use the widgetbowl demo for any sort of performance comparison.
Instead. use only one widget type for all the moving children but make
that changable.
I got a lot of "clip in clip" cases, for example a CellClip with a
CellTextClip inside. It is really trivial to merge these when we
pop and makes it easier for all backends, so lets do that.
This affects a few apis, such as gtk_text_iter_get_pixbuf,
gtk_text_buffer_insert_pixbuf and GtkTextBuffer::insert-pixbuf,
which have all been replaced by texture equivalents.
Update all callers.
It's unused. Plain text is not using that framework, neither is
in-process same-display transmission.
So it was only useful for sharing text with custom tags across
applications, and nobody is doing that.
That is some old code that still uses IOChannels, and the only
pseudouser is at-spi-atk's commented out code that is still using
CORBA types.
So get rid of it now before I need to start adapting it to the new
clipboard.
The wayland backend currently never emits GDK_SELECTION_CLEAR events.
GtkClipboard uses this signal in order to clear the clipboard owner when
the selection is set to something outside the application.
This commit ensures the wayland backend emits GDK_SELECTION_CLEAR before
setting the clipboard owner to NULL, as this means we lost the
selection.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790031
This function returns global session state that may
not be available to applications (e.g. in sandboxed
environments), and is not needed by applications,
so just drop it, instead of keeping a function around
that can't be guaranteed to work.
There are too many stack elements in the main stack. So add a substack
for the pages that display common global state. The appropriate name I
found for it was "Global".
It's used to house the General, Visual, Resources and Statistics pages
for now.
When I rewrote that function to not use GdkDeviceManager,
I overlooked that the window filtering needs to apply
to the master pointer as well, as other code assumes
that _gtk_widget_get_device_window will return non-NULL
on the devices in the list. Fix this.
This signal will be emitted whenever the gesture received a
button release or touch end event without a pairing button
press or touch begin. This usually happens when grabs transfer
input from one widget to another mid-press.
https://bugzilla.gnome.org/show_bug.cgi?id=789163
We can just as well use GdkSeat to enumerate (attached)
devices. Note that this change excludes floating devices
from consideration.
This keeps the copy-pasted code in sync with gtkwindow.c
This means we can directly upload these as textures, rather than
create a new surface and draw it into that. We still have to upload,
but there isn't a lot we can do about this as for these nodes
we generally redraw everything each time.
Similar to GtkEntry, add an "Insert Emoji" context
menu item, and add the same keybindings. We don't
add the icon here, since it is not clear where it
would go.
https://bugzilla.gnome.org/show_bug.cgi?id=790029
Ensure that things build again, and instead use the Windows API to
acquire the screen dimensions (note: this may need to be scaled for
HiDPI, but since I do not own a WinTab-based device, I will need to
keep the dimensions as-is for now).
Also update the gdkdnd-win32.c code to use formats rather than targets.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
This fixes the build of GTK+ master on Visual Studio 2013 (and possibly
others) as snprintf() may not be supported even if the required C99
features are supported by the compiler.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
The state argument was removed in commit 1518fe0 (API: stylecontext:
Remove state argument from getters), but we missed updating this file
until commit 5b94fe6 (stylecontext: Make first property name explicit),
as the compiler did not issue any warnings on the (now-defunct) usage.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
This is not used by anything yet, but add it now, so people looking at
this new code can make sense of it.
Plus, the documentation mentions it, so better have the docs make sense.
It will be used once we add support for conversions to GDK and allow
doing cipboard/dnd by GValue.
Make sure the API reflects the idea that GdkContentFormats is a set
containing mime types. In particular, treat the object itself as a
plural - it's named content format`S' after all - and therefor use
the correct verb form.
Also make GdkContentFormats keep an array instead of a list, now that
it's immutable.
Whereever we handle long-press for touch, it makes sense to handle
right-click as a faster alternative for mouse-based interaction.
This commit makes right-click work to bring up the variation
selector for Emojis.
The generated file clienthtml.h is #included by broadway-server.c, which
is one of the sources of the broadway library — so clienthtml.h needs to
be one of the sources of that library too.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790489
For a start, this makes gtk_main() work different from g_main_loop_run()
calls.
But most importantly, modern GDK does proper syncing itself and doesn't
need to rely on a catch-all to get it right.
Instead of allowing people to pass a uint user-data, insist on them
comparing mime types.
The user data was a uint instead of a pointer anyway, so uniqueness
could not be guaranteed and it caused more issues than it was worth.
And that's ignoring the fact that it basically wasn't used.
The HighContrast theme was not parsing anymore, due to
leftover widget style properties, and some missed cleanups,
like -gtk-icon-effect. Also update for the new focus handling,
and make checks and radios sharp again.
We no longer support registering custom icon sizes, so
we can make these properties just enums. This also lets
us specify them by nick in ui files. Nice!
Instead of looking at the icon size, look at the CSS value for
-gtk-icon-size. Set style classes depending on icon size instead.
Trivially change Adwaita and HighContrast to report the same values as
before.
Instead, add a function gtk_image_set_icon_size() for the cases where
overriding the icon size is necessary.
Treat icon sizes the same way as pixel sizes, too. So gtk_image_clear()
no longer unsets the icon size.
Instead of returning the icon size with them, make
gtk_image_get_icon_name() and gtk_image_get_gicon() only return the icon
itself.
As a benefit, we can turn them into regular getters that return values
instead of requiring out parameters.
Instead, provide gtk_image_get_icon_size() to query the icon size.
Instead, turn the functions into backend API:
gdk_broadway_display_add_selection_targets()
gdk_broadway_display_clear_selection_targets()
Remove the old per-backend functions, too.
This is a trivial commit that does a big change: We now ignore event masks.
Further commits will clean up code, but if bisection ends up here, you
know it's because code is getting delivered events that it weren't getting
before.
It wasn't taking into account whether the sidebar had support for them
or not, resulting in a file chooser with open in new tab/window menu
items when it's not supported.
To fix it, do as with the other menus and check for the availability of
new tab/window flags.
https://bugzilla.gnome.org/show_bug.cgi?id=786123
g_resources_enumerate_children expects the path to end
in a '/' (even though thats not stated in the docs), and
will copy it if that isn't the case. Avoid the copy
by putting a '/' there to begin with.
g_resources_enumerate_children expects the path to end
in a '/' (even though thats not stated in the docs), and
will copy it if that isn't the case. Avoid the copy
by putting a '/' there to begin with.
When the duration is set to 0, clamp it to 1us. This way we're almost
correct: We should really instantly finish, but we don't. But we do
respect the delay.
Doing this properly would require some refactoring of how the progress
tracker actually maintains progress, and this is just a quick fix.
Also, sanitize the RTL correction code that made sure resizing the width
of a treeview would keep the contents glued to the right border instead
of the left border.
GtkSourceView is not using it, so it's unneeded. And it's certainly
diving deep into event internals of GtkTextView which hinders a proper
gesturization.
The selection bubble is not part of the text windows, so hiding it
during scroll should not be done in the text window code.
Also remove an unused variable that was only set in that code but never
read.
Insist that a first non-NULL property is passed to
gtk_style_context_get().
This is in particular relevant because of dropping the state argument
since GTK3, and code like
gtk_style_context_get (context, state, "font", &font);
would keep compiling without warnings without this change.
Like the X11 and Wayland backends, re-work how the cursors are being
handled. So, we use a hash table to cache up the HCURSORS that we
create along the way.
We still need to cache up the icon/cursor themes since this is something
that is not part of Windows but was added on to support icon/cursor themes
such as Adwaita on Windows, but should be in-line with what is going on in
GdkCursor.
Also, remove the _gdk_grab_cursor global variable in gdkprivate-win32.h,
and replace it with another variable in the GdkWin32Display structure,
to make things cleaner in the process.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Use the same approach we take for recoloring in GtkIconHelper now.
As part of this change, GtkCsSImageRecolor is changed to not derive
from GtkCssImageUrl anymore.
commit 475d916eb9 added various paths that
use theme-name for this, but the existing path already used THEME, with
a subsequent description referring to the latter. So use that everywhere
With the shader approach to symbolic recoloring, we must
not recolor the svgs anymore as we're loading them. Instead,
load them the same way that gtk-encode-symbolic-svg does.
This fixes the rendering of large symbolic icons e.g. the
'no search results found' page in the file chooser.
We must reset the image delay when stopping the timeout,
otherwise the code setting it up thinks it is still running.
This fixes cursor animation only working for the very first
enter of a widget with an animated cursor, as seen in the
cursors example in gtk4-demo.
This is necessary because picking is no longer automatically constrained
to a widget's box. So all clipping widgets need to constrain their
clipping, too.
This patch does that for GtkViewport only.
We cannot fast-track picking by using gtk_widget_contains(). Child
widgets may extend their parent using ie negative margins.
This is not just a theoretical concern, this is what's happening right
now with GtkScale's sliders relative to the trough.
The problem is that we now iterate through all widgets, even when they
aren't anywhere near the mouse pointer. So essentially every pick
operation is now guaranteed O(N_WIDGETS) which used to be the worst case
that pretty much never happened.
The trough widgets have the slider on top of the fill level and the
hilight widget. Make sure the widget stacking respects that.
This is particularly relevant because picking event targets should pick
the slider and not the hilight widget.
In particular, allow specifying a filename for a GDK_TYPE_TEXTURE
property. This makes it easy to transition properties from Pixbuf type
to Texture type without having to touch resource files.
We cannot unrealize a renderer in the dispose function, because that
would cause this chain to happen:
gsk_gl_renderer_dispose
gsk_renderer_dispose
gsk_renderer_unrealize
gsk_gl_renderer_unrealize
So we would call into thje GL renderers unrealize when it has already
(partially) disposed itself and ause accesses to dead variables.
and gdk_texture_new_from_resource().
While doing set, turn all GDK_AVAILABLE_IN_3_90 into
GDK_AVAILABLE_IN_3_94 because that's now true after the renaming.
A sideeffect is that we don't set the correct parent window on child
widgets anymore, but that is hopefully going to be fixed once we get rid
of child windows completely.
Since on Windows we need to use a good amount of temporary GL contexts,
we need to switch back to the original GL contexts we were using when
we are done with the temporary GL contexts, otherwise multi-GL windows
will cause confusions causing display artifacts and crashes.
Also, use the GdkWin32GLContext::gl_hdc consistently throughout
the code and remove the GdkWin32Display::gl_hdc as Lukas K pointed out
that GdkWin32Display::gl_hdc becomes out-of-date and so the HDC that the
GL context is bound to becomes incorrect in sceanarios using multiple
windows with GtkGLArea/GdkGLArea items (which would cause the artifacts in
programs that use multiple windows with GtkGLArea/GdkGLArea items, and it
turns out that GdkWin32Display::gl_hdc is actually not necessary to help
keep track of the HDCs we use for our GL contexts.
This will also fix on Windows with GDK_GL=always, or when GSK's gl
renderer is used.
Partly based on patch from Lukas K <lu@0x83.eu>
https://bugzilla.gnome.org/show_bug.cgi?id=789213
Move the leftovers from the removals to use the current APIs, to fix the
build. Also for gdk_device_virtual_set_window_cursor(), only do
something when a valid GdkCursor is passed in here.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Widgets can now set their favorite cursor using public API.
This is very necessary because all cursor-setting APIs are still
setting it on their GdkWindow, which by now is the toplevel - oops.
Change constructors to reflect that.
While doing so, also add a fallback argument to the cursor constructors,
so it is now possible to create cursors with fallback.
Instead of creating a GdkX11Cursor, create GdkCursors. Cache the XCursor
in a hash table instead.
Also, make use of the new fallback mechanism for fallback code: Make
sure to provide cursors for the names that are guaranteed to exist, but
do not do bad attempts at displaying texture surfaces.
Black/White/transparent is not a replacement for those.
The check used to achieve discarding events not meant for the window
widget itself (because they are handled in the regular paths). Using
the target widget is the equivalent now.
Use g_value_set/get_boxed() in gtk_window_get/set_property(), case PROP_ICON.
icon_from_list() shall always add a reference to the returned icon.
gtk_window_set_icon() must accept icon != NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=789870
Stop wrapping the xsettings manager window in a foreign
window. This means that we cannot use the gdk window filter
APIs anymore, so just do the filtering in a non-generic
way.
The preferred api to create cursors is by name, and the
GdkCursorType enumeration can directly trace its ancestry
to the horrible X cursor font. So lets stop using it.
gdk_display_get_default_screen is gone, but we still
have x11-specific screen apis that GTK+ is using, so
we need an alterative way to get the screen object.
• Remove the box-shadow at the top when the entry is in the foreground
• Bump precedence so that :disabled entries do not have .flat overridden
• Also add :backdrop to stop HCInverse getting a lighter BG in :backdrop
https://bugzilla.gnome.org/show_bug.cgi?id=789733
Move the default pos of the Paned handle to 400px from the left, i.e.
50% of the default width of the window. The previous position at 300px
from left meant the node treeview was too narrow & could easily result
in the (useful) State column not being visible in the case of many
apps. The properties pane doesn't need to be as big as it was anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=788898
We disconnect from the GDK window, so the renderer can't keep any useful
state.
Plus, we might be using an entirely different window next time we
realize (after a call to gtk_window_set_display() for example) that should
use a completely different renderer anyway.
GTK+ now uses the gtk-xft-dpi setting directly.
Note: this commit only fixes the backends that
currently provide this setting. The win32 and
Quartz backends still need to be fixed.
This patch moves the "Copy to Clipboard" button into the same container
as the description label, to centre the button regardless of the number
of icons shown in the grid.
https://bugzilla.gnome.org/show_bug.cgi?id=789134
Drop the screen argument from gdk_dnd_find_window_for_screen
and rename the function to gdk_dnd_find_window. The screen
argument does not add anything here since the drag context
is already tied to the display. Update all backends, and
update all callers.
Consider the coordinates passed to gtk_widget_queue_draw_region to be
relative to @widget's origin, not its parent. That implies passing
priv->allocation or priv->clip to _queue_draw_region of a widget means
using its parent as @widget.
This fixes GtkScrolledWindow overshoot invalidation, which assumed the
coordinates to be widget-relative and not parent-relative.
And have a priv->display instead of a priv->screen.
Includes turning gtk_menu_set_screen() into gtk_menu_set_display(),
because that function just forwards to its window.
Implement GdkDisplay->get_setting() using the existing
_gdk_win32_screen_get_setting() and get rid of GdkScreen->get_setting()
as a result, to follow the changes in GDK.
Also, since we don't emit settings events in the Windows GDK backend,
but we acquire settings to print using GDK_SETTING, drop all references
related to GDK_SETTING since that is now removed. Update the debug
strings that are print out as a result
(gdk_screen_get_setting->gdk_display_get_setting).
https://bugzilla.gnome.org/show_bug.cgi?id=773299
This is just lots of renaming.
The interface remains private, so the public API does not change, apart
from removing the definition of the Interface object to avoid
subclassing.
We are not emitting these events anymore, so lets remove them
from the api. The GdkSettingAction enum is moved to xsettings-client.c
where its only use remains.
This commit adds gdk_display_get_setting and a ::setting-changed
signal, which will replace the settings event we use now. Note
that I've done away with the GdkSettingAction argument that the
event has, since we are not using it at all.
On Windows, when IME is used, each keystroke results in the
WM_IME_COMPOSITION event being sent first. This means that in our case
when one decides on to accept the input that is in the preedit buffer,
we first get from Windows the WM_IME_COMPOSITION event
(where we emit the commit signal), followed by the WM_IME_ENDCOMPOSITION
event (where we emit the pair of preedit-changed and preedit-end
signals).
Since commit f11f989 (GtkEntry: Remove recompute idle), we do the input
recomputation directly, this will cause a pair of "Pango-WARNING:
Assertion failed: (index >= 0 && index <= layout->length)" being shown,
as gtkentry.c's priv->preedit_length and priv->preedit_cursor was unable
to be reset to 0 in time as a result of the recomputation triggered by
the commit being done before the reset of priv->preedit_length and
priv->preedit_cursor (which are no longer valid as we essentially say
that we are done with the preedit buffer).
As we could only acquire the final string that was entered in this
preedit session when we handle the WM_IME_COMPOSITION event, fix this by
saving up the final string we acquire from Windows IME in UTF-8 when we
handle the WM_IME_COMPOSITION event from Windows, and emit the commit
signal with that string after we emit the preedit-changed and
preedit-end signals when we handle the WM_IME_ENDCOMPOSITION event from
Windows, which comes afterwards.
Also fix the formatting of the code around the parts of the files that
was changed.
https://bugzilla.gnome.org/show_bug.cgi?id=787142
When a widget unparents its child widget manually in finalize, this can
lead to the parent-set signal being emitted for those child widgets. The
parent already has a ref_count of 0 though, so it can't be used in a
meaningful way. Specifically, emitting the signal will already try to
ref the parent which prints a critical.
Since GtkWidget already has a "parent" property, one can use its notify
signal instead to get notified when the parent widget changes.
... instead of returning either itself with uncomputed images or a
copy of itself with only one computed image and lots of other
uncomputed images that we're never gonna look at again.
This fixes expressions like -gtk-scaled(-gtk-recolor(...),-gtk-recolor(...))
which Adwaita uses for checkmarks and bullets.
The Vulkan renderer creates a fallback surface for each shadow
node, even if we end up not rendering anything to it. Avoiding
this is a nice optimization.
This fixes blurry text and icons whenever we apply shadows
in a hidpi window. Shadow nodes are the last ones that we
still use fallback for, and this was causing us to render
the text blurry.
Pass a scale factor when caching glyphs or looking them
up in the cache. The glyphs in the cache are rendered
with subpixel precision determined by the scale. Update
all callers to pass a scale factor according to the window
scale. This lets us render crisp glyphs on hidpi systems.
The code that checks for the proper size of the our swapchain
was not taking window scale fully into account. With this change,
setting the window scale to 2 in the inspector causes the window
to grow and rendering to be scaled up as expected, with Vulkan,
in the same way it already is with cairo.
Epoxy 1.4 has new ad hoc API that we can use to check whether GLX is
available on the current system.
If we didn't use this API, we'd have to manually dlopen libGL (or its
equivalent on different OSes) and check if it had GLX symbols; since
Epoxy already does all of this internally, we can simply ask it instead.
https://bugzilla.gnome.org/show_bug.cgi?id=775279
The GtkWidgetClass::measure vfunc is not required to assign a value to
any of the (out) parameters, so we need to initialize the locals we pass
to it, otherwise we can end up with a garbage size request.
The path bar would crash if we disposed it before all pending I/O
operations had finished. Now we remember all the outstanding
operations directly in the GtkPathBarPrivate, and deal with them
consistently.
The copy of the PangoGlyphString we do here was showing up
in some profiles. To avoid it, allocate the PangoGlyphInfo array
as part of the node itself. Update all callers to deal with
the slight api change required for this.
According to the documentation, gdk_monitor_get_geometry() reports the
monitor geometry in ”application pixels”, not in ”device pixels”,
meaning that the actual device resolution needs to be scaled down by the
scale factor of the output.
x11 backend does that downscaling, whereas Wayland backend did not,
causing a discrepancy depending on the backend used.
https://bugzilla.gnome.org/show_bug.cgi?id=783995
If the compositor prefers server-side decorations and the client doesn't
customize the title bar, we disable client-side decorations and let the
compositor know. Otherwise, we continue to use client-side decorations.
Signed-off-by: Drew DeVault <sir@cmpwn.com>
https://bugzilla.gnome.org/show_bug.cgi?id=781909
Under Wayland, an xdg_surface.configure with size 0x0 means it's up to
the client to set its size.
When transitioning from maximized state to un-maximized, the Wayland
compositor will send such an 0x0 configure so that the client can
restore its original size.
However, the original size was already constrained, so re-applying
size constrains can lead to a smaller size when using size increments.
Avoid this caveat by not applying size constrains when we are restoring
the original size.
https://bugzilla.gnome.org/show_bug.cgi?id=777072
As documented, GtkAppChooser is "typically [used] for the purpose of
opening a file". However given that applications that support neither
opening files nor URLs are filtered out, the chooser is not actual
useful for any other (atypical) usage. Change that by only applying
the filtering if a content-type was set, and use the full unfiltered
list otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=789327
We were unnecessarily spewing warnings when blank cursors
were getting a new scale set. Standardize on "none" as the
name for blank cursors, and avoid the warning.
https://bugzilla.gnome.org/show_bug.cgi?id=775217
Since focus can now be represented by more than one state,
just looking at the focus_child is no longer sufficient - we
may fail to propagate :focus(visible) if we do so. For now,
just remove the shortcut and always do the work.
Some clients (e.g. gnome-online-accounts) quickly unmap and map
a window. With some backends the backend surface will be replaced
causing the application to crash because the GL context is still
using the old surface. Clearing the GL context when a window is
withdrawn fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=789141
__builtin_popcount is a GCCism that is used to count the number of bits
involved, which means any non GCC/CLang compilers won't like the code,
meaning that on MSVC builds we must implement it ourselves.
We first use __cpuid() to check whether the CPU supports the popcount
instruction, if it does, we use the __popcnt intrinsic, otherwise
(untested, since I don't have a system that does not have the
instruction), we use the suggested hacks at
http://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetParallelhttps://bugzilla.gnome.org/show_bug.cgi?id=773299
We still need to access the GdkEvent structure here directly, as using
the GdkEvent getters is likely not worth the trouble involved.
Please see Emmanuele's comment (#97) of the following bug URL.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
The list of surfaces passed into the function may be NULL, so don't try
to initialize the surfaces if it is so, to avoid a crash.
Also, remove the cast to GdkPixbuf* for getting surfaces->data, as we
are already using a cairo_surface_t*.
https://bugzilla.gnome.org/show_bug?id=773299
When building with G_DISABLE_ASSERT, the g_assert_not_reached()
statement won't do anything, and we're going to fall through, and the
compiler will emit a warning that we're not returning anything from a
function with a return value.
These are no longer used, instead we always covert to surface as
early as possible and drop the pixbuf.
This means we never store both the pixbuf and the surface at
for any longer time, which is wasteful. Also, its one step further
to drop GdkPixbufs from generic use in our APIs.
Rather than store the pixbufs as themselves we immediately convert
them to surfaces. In the uncommon case that a pixbuf is read back
from the renderer we generate a new one from the surface data.
This drops the pixbuf property and the pixbuf getters. We keep
gtk_image_new/set_from_pixbuf, but these are small helpers that
immediately convert to a surface, and there is no way to later get
back the pixbuf you passed in.
The from file/resource codepaths are also changed to load a surface
instead of a pixbuf.
Rename the surface getter to peek, following other render
node getters, and make the surface-based constructor private,
since it is not something we want to encourage.
Update all callers.
The gtk_tools variable is an array of arrays; adding a new element
requires to maintain the same type, or we'll get a build failure when
we try to extract the newly added element.
Add the necessary machinery into the Meson definition files so that we
can build for Windows.
Since we don't have Wayland or X support for our use case here, disable
them once we know that we are building for Windows, as they are
(otherwise) enabled by default, and enable the items that need to be
built for Windows builds.
Exclude gtk4-launch from Windows builds as that is something that
is not supported on Windows.
As we won't have gio-unix on Windows, and PangoFT2 is optional, don't use
fallbacks for them when we are on Windows (but do use fallbacks for
gio-win32, as it will be used).
Also, clean up meson.build a bit as we can just force-include
msvc_recommended_pragmas.h from GLib since we depend on GLib, and so we
can handle these warnings from msvc_recommended_pragmas.h instead.
https://bugzilla.gnome.org/show_bug.cgi?id=785210
The color-matrix shader was creating pixels with r,g,b > a in
some cases, which leads to unexpected test failures. In particular
this as visible the opacity render node test for opacity 0.
When making mockups for GNOME apps in Inkscape, looking for symbolic
icons is a common task. Searching for icons in the file system is clumsy,
and icon-browser provides a much better interface for finding them.
However, currently there is no way to insert the symbolic icons as SVG
directly from icon-browser, so right now it is only useful for finding
the name.
This patch adds a sixth column to the modal window that appears when
clicking a symbolic icon. The icon in this column is labeled "scalable",
and dragging it onto another window results in the vector icon URI being
inserted.
This enables a much simpler workflow when designing with symbolic icons.
https://bugzilla.gnome.org/show_bug.cgi?id=778930
What is missing is the "allocation" part of x/y coordinates. Since
gtk_entry_realize doesn't call gtk_widget_set_window(priv->text_area),
the coordinates returned by gdk_window_get_origin don't include it.
This patch fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=784509
Bug 737175 aimed to ensure that scrolling up on a horizontal range would
result in its value increasing, as that’s what users intuitively expect.
However, its commit 416c370da1 meant that,
if the event gives scroll deltas, we inverted our delta unconditionally.
So it broke horizontal scrolling: scrolling left moved the slider right…
We must only invert if using dy as delta. dx already has the right sign,
so inverting it was wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=788905
The gtk_widget_get_display call in this if statement is showing up in
profiles. It ends up walking up the hierarchy to the toplevel to get its
GdkScreen, etc. so it is relatively costly. Avoid that call in most
cases by first checking if the RESIZE debugging is enabled for any of
the displays and only then checking if it is enabled for the widget's
display.
If the call to set_parent() failed, we were still adding the child to
the internal list of children, despite that it was not really added.
That meant we could later try to do invalid stuff with that non-child.
Fix that by asserting and giving up if the child that the user is
attempting to add is already parented.
https://bugzilla.gnome.org/show_bug.cgi?id=701296
The language is useful for parsing tools, such as that of gtkmm, which
otherwise assumes these are C snippets and elides them from its
generated documentation.
The event coordinates are (so far) irrelevant to what we are testing here,
just make all events happen in the middle of the window in order to ensure
all widgets receive it. More importantly, avoid using fixed pixel distances,
since we don't get guarantees about window sizes.
Fixes the gestures testsuite on X11.
It was used to mark css properties that affect widgets with text, but it
caused unnecessary invalidations. E.g. 'color' was marked as
AFFECTS_TEXT but changing just the color of a label should not
automatically queue a resize, which is what the code in
gtk_widget_real_style_updated does.
Replace this flag with GTK_CSS_AFFECTS_TEXT_SIZE and
GTK_CSS_AFFECTS_TEXT_CLIP, which GtkWidget can use only if the widget
actually has text.
Now all widgets are mandated to handle the real thing, which means no
pointer events are emulated for the pointer emulating touch. The output
of these tests relied on this fact, so update to the tests handling real
touch events.
Legacy GtkWidget vmethods are now handled on an event controller, which
due to being the very first controller added to every widget, runs in
a different order than the previously hardcoded.
Probably testing legacy events is not really futurible, specially after
we stop installing this legacy controller by default. I'll leave the
choice to remove these specific tests for later though.
After a gesture first claims, and later rejects a touch sequence,
a press event will be propagated further along. However propagation
got messed up since we only emitted as far as the toplevel.
It does not hurt us to keep middle clicks doing the same
as shift-primary clicks. This makes the transition from gtk2
less painful in terms of muscle memory.
https://bugzilla.gnome.org/show_bug.cgi?id=787669
Clarifies the code and helps catch invalid enum values before they
propagate further. Also add a comment about why two seemingly legitimate
values are not handled there (they’re handled higher up in the file).
Coverity CID: 1457700
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788787
gtk_box_pack_end will put the label child at the right side of the label
(in LTR orientation), but we want it left, directly next to the icon.
Also remove the spacing from the box child as this is a theme thing.
~Company ╡ so TL;DR: we put the static style in the cache, but then
⤷ ╡ compute a child style from the animated style in the cache
⤷ ╡ and we put the child style also in the cache (because
⤷ ╡ it's not animated)
⤷ ╡ then we run the animation, but reuse the cache every time
⤷ ╡ for both child and parent
⤷ ╡ so after the animation is done, we end up with a cache that
⤷ ╡ has the correct static style for the parent but an
⤷ ╡ incorrect static style for the child
⤷ ╡ because that static style was computed from the
⤷ ╡ initial animated style
This fixes https://bugzilla.gnome.org/show_bug.cgi?id=763517
Check UUID for printers obtained via DNSSD whether
they are already installed on local CUPS server.
Don't show such printers.
Not all printers published via DNSSD have UUID entry though.
https://bugzilla.gnome.org/show_bug.cgi?id=786794
An empty container has the same effect as transparency
with the cairo renderer, but creates black with Vulkan.
To avoid this, explicitly use a transparent color node.
This fixes the css blendmode example in gtk4-demo with
the Vulkan renderer.
As Timm Baedert pointed out, the previous fix made the
menubar go on top of popovers, which is just wrong. Instead,
make gtk_window_snapshot handle all direct children of the
window, taking care to stack popovers correctly.
We were node handling coordinates correctly when dealing
with differently sized child nodes in a blendmode node.
This was showing up in the gtk4-demo css blendmode example,
for blendmodes other than normal.
GtkMenu’s own keynav code, which actually bothers to account for the
layout of items, only happens if columns > 1. So, adding items to 1
column using a reverse loop meant they were placed in the Menu’s list of
children in that order, and because we only have 1 column, Menu passes
keynav up to MenuShell, which doesn’t adjust for the items’ positions.
‘Fix’ that here by adding items in the same order they’ll have when laid
out in the Menu, so keynav does what you’d expect, not the opposite. For
that, it’s simpler just to use gtk_container_add().
Let’s presume users are using add(), attach() with a non-inverted loop,
or attach() with arguments that create 2+ columns and so GtkMenu keynav.
This is important since _push_state returns a pointer into a GArray
which could be invalidated and point to garbage after the subsequent
push_state call.
This is used for example in the source tab of gtk4-demo.
It broke because GtkScrollbar no longer is a GtkRange,
but rather has one. So we need to forward the signal.
It was selecting paned separator, which means any separator at any level
of descent within a paned, including the toplevel container in GEdit.
We need to be more specific and only select the relevant separator that
is the direct child of the paned. This is what Adwaita does.
https://bugzilla.gnome.org/show_bug.cgi?id=788573
Nulling priv->button in _unset_tree_view() is asymmetrical: we create
it via init(), not _set_tree_view(), so we shouldn’t null in the latter.
Worse, doing so manifests in criticals + a SEGV easily with basic use of
testtreecolumns, removing the TVC from a TV then trying to add it to one
Finally, the wrong null-out meant dispose() failed to unref the button,
so it leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=728452https://bugzilla.gnome.org/show_bug.cgi?id=788614
It was in both [general] with a description and [other] with none.
Leave it in [other] with the other folder- icons, + the description.
bonus: this makes all of [general] fit in our default window size!
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
-Wshadow these days does not overwarn anymore like it did in gcc 4.
There are no warnings inside gtk, so better enable it to keep it that
way.
-Wuninitialized also has no positives, so I'm gonna turn it on just
because.
GtkCellArea uses event coordinates (thus in treeview relative
coordinates), but calculations used to happen in bin window coords.
We can just offset the cell area by the bin window, fixes cell
renderer activation and edition.
If the column is not clickable, it may make some sense to stop
event propagation here for button events. However motion events
should be left alone.
Fixes treeview column resize pointer cursors, since that's
implemented up the bubbling phase in the treeview.
The operations rely there on bin window relative coordinates, but we
are receiving GtkTreeView relative coordinates there. Fixes clicking
on treeview expanders, which was offset by visible headers.
-Wint-conversion is important because it checks casts from ints to
pointers.
-Wdiscarded-qualifiers is important to catch cases where we don't
strings when we should.
The border and icon highlight are useful feedback that was defeated by
CSS precedence. It worked for .titlebuttons due to their implementation,
but the same was not true for custom .flat buttons. This makes it so.
https://bugzilla.gnome.org/show_bug.cgi?id=788580
When the window was backdropped, they suddenly regained their border.
This was clearly not intentional or of any practical use to anyone.
Shuffle around some selectors so that the backdrop ones do not override
the flat ones and make the borders magically reappear when backdropped.
Note that, whereas standard titlebuttons get the border on :hover, other
.flat buttons in the headerbar do not. That should probably be fixed too
https://bugzilla.gnome.org/show_bug.cgi?id=788580
They were hard-coded to a transparent black, but that is our bg colour
in HC Inverse, so windows stacked on top of each other or a dark
background blended together into a mush.
Fix this by making the $_wm_border* colours relative to the fg colour,
so that HighContrastInverse gets borders that are transparentised white.
https://bugzilla.gnome.org/show_bug.cgi?id=788575
A missing decoration selector meant that we got a solid black background
behind the rounded corners of the dialog.
Copy the equivalent code from Adwaita, including nicely rounding the
focus outline too (& sorry, but this needs more newlines to be readable)
There were various problems, like only selecting on .tooltip and not the
widget node tooltip, not being specific enough for tooltip.csd, etc. So,
specific theming was absent, and default popup window styles got applied
This commit copies in the better working tooltip CSS from Adwaita, but
applies a couple of changes to make it work better in the HC themes:
• Reduce the transparency of the tooltip, so we achieve higher contrast
• Drop the black text-shadow, as it is not useful on this more black bg
Note: we may then need to re-add some of this to the .tooltip class. But
it is unclear what needs done there. While Adwaita is not doing it, we
are better not to confuse by keeping it in HC only; we should try to be
as close as possible, to make it easier for HC to keep up with Adwaita.
https://bugzilla.gnome.org/show_bug.cgi?id=769879
We need
.window-classes decoration
but within the decoration parent selector, we were doing
&.window-classes, which gave us
decoration.window classes
We need to fix this by selecting on .window-classes &
https://bugzilla.gnome.org/show_bug.cgi?id=788496
n_attach_points is the result of g_strv_length(): the index at which the
string vector ends in NULL. So by definition, when i == n_attach_points,
string[i] == NULL, and there is no need to check for the latter. The
fact that we did appears to confuse static analysers, as the dereference
and index check were inverted from what would normally be safe. We could
reverse them, but we may as well just remove the unnecessary NULL check.
https://bugzilla.gnome.org/show_bug.cgi?id=788458
This gives consistent behavior with e.g. Qt, Mozilla's suites and
LibreOffice (with non-truly native backends like "gen" and "gtk",
but unlike "gtk2" and "gtk3" ones that probably use true GTK menus).
This behavior is expected by at least some accessibility users, and
it seems good to behave like other common applications and toolkits
in this area. There should be no issue in doing so either for current
users, as it only enters the submenu instead of not doing anything.
https://bugzilla.gnome.org/show_bug.cgi?id=778811
There is no guarantee that the gtk_surface won't be NULL,
and Wayland API does not safeguard against NULL, so we have
to do that ourselves here.
We were also mistakenly cheking for the surface version off
by one, fix that too by checking if the surface version is
equal or greater.
Ditch two items that were white and so weren’t visible on our standard
theme anyway, and use the new space to test extra grid-mode properties.
Note that if we do this then, as before, we set the ListStore on the
ComboBox before appending to it, that produced runtime warnings like:
Gtk-CRITICAL **: gtk_menu_attach: assertion 'left_attach < right_attach' failed
I didn’t look into that yet, but it may indicate that attaching items
vs. recognising their spans don’t occur in the correct order. For the
purposes of testing this, I just create the CB after filling its model.
ComboBox and TreeMenu warned in the doc for :row-span-column that the
value must not exceed :wrap-width, but :wrap-width does not interact
with the number of rows; it’s the :column-span-column that’s relevant.
Also: Warn that spans must be > 0 for rows too, and that column spans <=
:wrap-width are also not useful for items at menu column positions > 0.
Finally, refer to items having spans, not values, as we were already
talking about values in the model (and rows in the menu).
This reverts commit 6ee2bf6286.
There is a way to get different kinds of borders: it's CSS. It's better
to keep the 4 Frames and demo the different styles we can do using CSS.
Instead of creating one GPtrArray per GtkSnapshotState and saving nodes
in there, create one GPtrArray per snapshot and assign a
start_node_index to every GtkSnapshotState as well as a n_nodes variable
so every state knows which nodes belong to it.
In some cases, we were creating gigantic intermediate textures
only to clip out a small section afterwards (e.g. in the listbox
example in gtk4-demo). This is wasteful if we apply effects on
the texture, such as blur or color-matrix. So, clip the dimensions
of the intermediate texture with the current clip. To make this
feasible, we move the texture coordinate computation out of the
pipeline setup functions into the node_as_texture function where
this clipping happens.
One extra complication we encounter is that the node might get
clipped away completely. Since Vulkan does not allow to create
empty images, we bail out in this case and not draw anything.
With these changes, the listbox example in gtk4-demo goes from
32M pixels of intermediate texture to 320000.
It's not a GtkCssGadget anymore, it doesn't have any properties or
signals either and it's not public. Further, its lifetime is very clear
the way it's being used inside GTK+.
This showed up in profiles in certain scenarios, so export a
_get_n_shadows getter instead and let callers provide a sufficiently
large allocated array of GskShadows, which we can use with
g_alloc/g_newa.
Instead of having a function with lots of arguments in
GskVulkanRender that we call from GskVulkanRenderPass which
then just calls back into GskVulkanRenderPass, just create
the new render pass object locally, and an api to add it
to the list that GskVulkanRender keeps. This makes it
a lot easier to preserve all the relevant parameters from
the parent render pass.
Move away from the idea of intra-frame sampling, since we only
push samples once per frame, anyway. Instead, make the profiler
keep a rolling average of the last n frames.
Whenever we need a node as a texture, we now start a new render
pass that renders the node into a new intermediate texture, and
set up a semaphore to make the current render pass wait for it.
As part of this reorganization, much of the setup and drawing
code moved from gskvulkanrender.c to gskvulkanrenderpass.c.
Allow to pass in semaphores to wait for before executing
and to signal after executing the command buffer. This
just exposes the capabilities of the underlying Vulkan
api. Update all callers to pass no semaphores, for now.
We will use this in the future.
The GtkFlowBoxCreateWidgetFunc type lacked GObject Introspection
annotations for its arguments. This made gtk_flow_box_bind_model()
unusable from Python as the callback function would be passed useless
values.
The annotations that I've added match those of the similar callback
type GtkListBoxCreateWidgetFunc.
https://bugzilla.gnome.org/show_bug.cgi?id=780758
I've finally figured out the right combination of src and dest
stage and access flags to make all validation warnings go away.
This commit only fixes the direct upload code.
This is another example for a 2-texture shader.
So far, only separable blend modes are implemented.
The implementation is not optimized, with an
if-else cascade in the shader.
We were looking at uninitialized memory here, instead
of the type of the source clip, as we should.
This showed up as mispositioned clip in the first frame
of a crossfade stack transition, and also as overdraw in
sliding stack transitions.
We already move the descriptor set layout out of it,
so we can just as well keep the pipeline layouts in
the render object as well, and get rid of this extra
object. Update all callers.
Instead of doing multiple copy commands with a tiny buffer
for each glyph, we can just batch them all together. This
also avoids the issue of creating multiple barriers for the
same image.
By tracking the last transition we can build the appropriate barriers.
Also use the most appropriate initial layout/access at creation :
for linear image : predefined (we prepare the content ourself through memcpy)
for everything else : undefined (we don't care about the content, will most likely be erase)
Move the glyph caching api to something that can support using
multiple textures. We now split the text render ops into multiple
ops for different textures, and make each op render just a substring
of the text node's glyph string.
gdk_seat_default_grab() grabs POINTER_EVENTS if the capability is
GDK_SEAT_CAPABILITY_ALL_POINTING. But that enumerator is a union that
includes GDK_SEAT_CAPABILITY_TOUCH, but we never grabbed TOUCH_EVENTS,
an unused macro that was presumably created with this purpose in mind.
So, check which of the ALL_POINTING capabilities we have, and set the
right mask of POINTER_EVENTS and/or TOUCH_EVENTS as required.
As part of this, explicitly let TABLET_STYLUS take over pointer events,
as this is the intended behaviour and was the effective result before.
This should fix touch events being lost in migrating from Device.grab()
to Seat.grab(GDK_SEAT_CAPABILITY_ALL_POINTING), as found by Inkscape.
https://bugzilla.gnome.org/show_bug.cgi?id=781757
The behavior where a touchpoint takes over the pointer position is
really backend dependent. Since this went away from the generic code,
implement it here.
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.
It may result in a protocol error on older mutters, as GTK+ will
invariably request a higher version than what's available. Make
GTK+ also accept v1 if it's all the compositor has got.
As Benjamin says, ident should only be used if any value
is valid, which is not the case here. So use enums instead,
which should also be more efficient. To handle the more
complicated cases like font-variant-ligatures, we have to
introduce flags-like values.
Otherwise, we can't negotiate the latest version with the
compositor, making the compositor use v1 of the protocol and
pretty much ignoring all the edge constraints work.
Clarify that ::destroy, not ::hide*, removes a window from its app, by
replacing the mention of open windows with the blurb on destruction from
:application, completing commit 7db4bee4b6
Also link to the equivalent gtk_application_(add|remove)_window() calls,
since Application.add_window() already links back to Window:application.
* unless you use gtkmm…
https://bugzilla.gnome.org/show_bug.cgi?id=639931
It was never unref()d, either when replacing the existing GObject in
set_property(), cleaning up in finalize(), or becoming a placeholder.
Fix by using g_set_object() and g_clear_object() to unref as needed.
This also drops the check that the newly set object is a valid cloud
provider account, as we don’t do the equivalent for any of the other
object-typed properties, and Carlos didn’t think this was important.
https://bugzilla.gnome.org/show_bug.cgi?id=787600
Drop the current css2-style font-variant property and
replace it with a shorthand as specified in the css3 fonts
module. Currently, we fully support the font-variant-ligatures,
font-variant-position, font-variant-caps, font-variant-numeric
and font-variant-east-asian subproperties. font-variant-alternatives
is only partially supported.
Otherwise it fails to build with:
FAILED: gtk/im-ipa@sha/imipa.c.o
...
In file included from ../gtk/gtkintl.h:4:0,
from ../modules/input/imipa.c:28:
/opt/include/glib-2.0/glib/gi18n-lib.h:27:2: error: #error You must
define GETTEXT_PACKAGE before including gi18n-lib.h. Did you
forget to include config.h?
#error You must define GETTEXT_PACKAGE before
including gi18n-lib.h. Did you forget to include config.h?
^~~~~
../modules/input/imipa.c:144:3: error: ‘GETTEXT_PACKAGE’ undeclared
here (not in a function)
GETTEXT_PACKAGE, /* Translation domain */
^~~~~~~~~~~~~~~
../modules/input/imipa.c:145:4: error: ‘GTK_LOCALEDIR’ undeclared
here (not in a function)
GTK_LOCALEDIR, /* Dir for bindtextdomain (not strictly
needed for "gtk+") */
^~~~~~~~~~~~~
Instead of relying on special values of edge constraints, this
patch adds an internal-only gdk_window_supports_edge_constraints()
function that by default returns FALSE, and is implemented by
GdkWindowWayland and GdkWindowX11.
This way, we can properly detect server-side support for this
feature and adapt accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
The last touch on this patch series is making GtkWindow able to
selectively adjust various UI details based on the different
tiled edges. The main driver here is that we don't want to show
shadows on edges that are constrained.
This patch adds the necessary code to do that, while still
maintaining compatibility with the old ways.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
Following the previous patch, where edge constraints support
was added to the Wayland backend, this patch introduces the
necessary code to handle the _GTK_EDGE_CONSTRAINTS atom from
X11 backend.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
Now that GTK windows have the ability to properly handle
per-edge tiling constraints, this patch extends GTK's
internal Wayland protocol to have a proper enum with the
relevant edge data.
Once this approach is validated, we can think of upstreaming
this work as an official Wayland protocol extension.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
GTK windows don't have their tiling states really
hooked into the client-side decoration code, and
the only effect it has is disabling the resizing
edges.
With the introduction of per-edge tiling information,
we are backed by much more precise data on how the
window manager wants the app to behave.
This patch, then, fixes GtkWindow to take into account
per-edge tiling information. For compatibility purposes,
the previous tiled field was kept, and thing will just
continue working if no edge information is supplied.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
These states will be consumed by GtkWindow in order to
have better edge management on tiling situations. Their
values are supplied by the compositor, and will be send
through and X11 Atom or a Wayland protocol extension.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
The outline-{top,bottom}-{left,right}-radius names have been
deprecated for a while, so lets remove them. Everybody should
just use the -gtk-prefixed names for these properties.
The focus outline disappeared as the colour of the swatch got close to
the normal focus outline colour, which is alpha(currentColor, 0.3).
Fix by making the outline an alpha’d version of the tick colour, but
more opaque than normal outlines. 0.6 seems good enough; feel free to
improve it, but at least this ensures the outline can’t vanish anymore.
HighContrast achieves this already because it applies the color property
to the main node, not the overlay. Doing that means the outline is fully
opaque, which is fine for HC obviously but was excessive for Adwaita.
https://bugzilla.gnome.org/show_bug.cgi?id=787757
It used $text_color unconditionally, but in :dark, text is white, so we
overlaid a white tick on any light colours, all the way to white itself.
Using these named colours doesn’t make practical or semantic sense.
Instead, use white/black over dark/light swatches, as in HC, so all
variant–swatch combos work. Light looks the same, & :dark works now.
For backdrop, use alpha 0.5, unlike 0.7 in HC, as that seemed excessive
& different from the current effect. 0.5 is almost identical to how
$backdrop_fg_colour is a 50% mix of $fg_color, & matches backdrop text.
https://bugzilla.gnome.org/show_bug.cgi?id=787531
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
Make it slightly more obvious when things are about to slide sideways
because a NULL GtkSettings has been returned to a caller. This is a
valid return value, but is rarely handled correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=778382
As reported in https://github.com/ibus/ibus/issues/1944,
typing u201e while holding Ctrl+Shift used to give a „
when letting go of Ctrl+Shift. This broke when we introduced
Ctrl+Shift+e to start Emoji sequences. Fix this by only
looking for Ctrl+Shift+e if we are not already in a hex
sequence.
This is just a proof of concept - we use a single 1024x1024 surface,
and just give up when we run out of space. The cache is populated
incrementally, and items are never removed.
This commit takes several steps towards rendering text
like we want to.
The creation of the cairo surface and texture is moved
to the backend (in GskVulkanRenderer). We add a mask
shader that is used in the next text pipeline to use
the texture as a mask, like cairo_mask_surface does.
There is a separate color text pipeline that uses the
already existing blend shaders to use the texture as
a source, like cairo_paint does.
The text node api is simplified to have just a single
offset, which determines the left end of the text baseline,
like all our other text drawing APIs.
This is meant to cut down build time in flatpak and similar
situations. Since it produces technically incomplete builds,
we list these options in the status output at the end of
the meson run.
This fixes the proper dependencies getting set up for generating
the shaders and only the necessary things getting rebuilt on
resources changing in gsk.
We were only selecting a section’s button if the adjustment y coord was
within its heading, so scrolling slightly into it unchecked all buttons.
This also fixes how we could end up with the first 2 selected, somehow.
https://bugzilla.gnome.org/show_bug.cgi?id=787172
Add integration of the libcloudproviders DBus API to the
GtkPlacesSidebar by showing name and sync status of the cloud providers.
The exported menu is rendered as a GtkPopover.
The sidebar will be updated if the list of cloudproviders changes e.g.
by adding or removing an account. If any cloud provider changes detailed
information like sync status only the individual sidebar row gets
updated.
Co-authored-by: Carlos Soriano <csoriano@gnome.org>
Co-authored-by: Daniel Boles <dboles@src.gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=786123
Use opacity to differentiate unselected/hovered/selected buttons. It had
assumed bg < border < fg colours, which may be false, as in Adwaita:dark
This also means we do not need to special-case for the backdrop state.
https://bugzilla.gnome.org/show_bug.cgi?id=786956
I see 'out of memory' errors and crashes inside libvulkan when
creating nodes that have empty bounds and end up in the fallback
paths, like a shadow around an empty text node. Prevent this
by not creating text nodes in that case.
in a specific case, which was applying .slider as a class on the parent
switch, instead of correctly selecting on its child node named slider.
This makes the border on the outside of a switch in a selected listbox
row look better in the light variant. Since the code was never removed,
it was clearly meant to work, and making it work is a clear improvement.
Using this produced warnings about the Pango syntax of <Family> <size>
being deprecated, and the size being invalid due to no unit specified.
Also, that multi-word font family presumably wouldn’t work as expected.
This reverts commit 98e3018455.
As an English-speaker, I know nothing about complex grammar, and it’s
been brought to my attention that some languages might differ in the
translation of the same command depending on where it appears.
So, I’d better assume everyone else knows better than me. Apologies!
Currently, this information is not used since cairo_show_glyphs
deals with color glyphs for us. But when we get to uploading
glyphs to a texture atlas, we will need it to do the right thing.
We don't look at individual glyphs here, but just whether the
font has the has-color flag set. In practice, all glyphs in
such a font will be color glyphs, and we can avoid loading all
the glyphs this way.
The emoji chooser gets disposed already, because it is attached
to the toplevel as a popover. Doing it again when the object data
is cleared is leading to a crash.
https://bugzilla.gnome.org/show_bug.cgi?id=787103
Copy the PangoCairoRenderer into GTK+, rename it to GskPangoRenderer,
and strip it down far enough to build without private pango apis.
This means we currently don't support hexboxes or shapes.
Currently, this lives in gtk, but it might be nicer to put it
in gsk eventually.
• Use disconnect_by_data() to catch both _adjustment_changed() and now
_adjustment_value_changed(), as the latter had been missed until now.
• Also disconnect from indicator_value_changed(), which was not done in
destroy() due to indicator_reset() and remove_indicator() disagreeing.
https://bugzilla.gnome.org/show_bug.cgi?id=775074
Do not connect to get_settings_for_screen() if we have no screen…
Use g_signal_connect(), not connect_object(), to match how set_screen()
makes this same connection, and how finalize() already disconnects it.
https://bugzilla.gnome.org/show_bug.cgi?id=705640
Since the move from button-press to gesture events, Shift-clicking did
not work to start a selection (from none) or truncate an existing one.
This was due to the code being copy-pasted around and some logic being
broken in the process. This makes both of those work as they should, by
shuffling it again so the end result is the same as before. Highlights:
(1) ::button-press if extending due to a single press would call
set_positions(tmp_pos, tmp_pos), which is what made the Shift+click to
create a selection work. That was lost. Add it back to make that work.
(2) ::button-press in the “Truncate current selection” branch would not
execute all the stuff around “extend_to_left”, as that was the else
case. So, set extend_selection = FALSE so we skip over that later on.
(3) BUT! This Truncate case never fired because it was in the else
branch of if (in_selection())! Of course, it must be in the true branch.
(4) The IM context was not reset if the Shift-click occurred within an
existing selection, only if it did not. In ::button-press this was the
first thing done if extending a selection, regardless. Make it so again.
https://bugzilla.gnome.org/show_bug.cgi?id=780750
Themes should not enforce min sizes on blocks in continuous mode; in
this case, the filled block should be as large as it needs to be to
reflect the current value, and no larger or smaller than that. So, the
fact that the minimal size was selected on just levelbar block is wrong:
we should also require the levelbar.discrete class to apply min sizes.
The widget should enforce whatever correct minimum size results from the
above fix, by reapplying commit 78b4885fe8
Except: we should not allocate/draw the filled block if the value is 0,
as in this case, the LevelBar should be empty, not have a min-size fill.
This partially reverts commit 96062ffeae,
as it makes sense to set min sizes for discrete blocks, so keep that in.
https://bugzilla.gnome.org/show_bug.cgi?id=783649
This reverts commit 8c0e5adaab.
This is actually needed since GtkHeaderBar will allocate and snapshot
widget that coun_visible_children does not consider.
Under X, we were not setting the right drag cursor initially,
because at current_action == action == 0, initially. Fix this
by explicitly using the right cursor when grabbing.
Subsurfaces don't currently work with our new rendering,
and this makes popovers unusable. We can go back to using
subsurfaces for popovers when this is fixed.
.update_position() enforces that non-Wayland platforms must position a
Popover within its parent Window. We use the allocation of the Window
to translate the position and check for overshoot on each of its sides.
Calling Widget.get_allocation() of a CSD Window includes its shadows.
But shadows were not excluded from the area in which we can position.
Thus, Popovers could get positioned in the shadow of CSD windows, where,
at least on X11, no input is received. Therefore, positioning a Popover
over a shadow meant its child widgets within that area became unusable.
Fix by calling Window.get_shadow() and including it in the overshoot on
each side. This adjusts for how the allocation includes shadows, making
overshoots with and without shadows the same. Thus, we avoid considering
shadows as viable for positioning, favouring a side where input works.
https://bugzilla.gnome.org/show_bug.cgi?id=786209
This prevents the load_fonts() function from switching to the "no fonts"
page and back when the model is reloaded. Given
GtkSettings::gtk-fontconfig-timestamp is 0 on Wayland and style changes
happen often, the stack change messes up popovers and pointer focus
on the fonts treeview and test entry.
https://bugzilla.gnome.org/show_bug.cgi?id=784723 introduced support for
native file chooser dialogs on macOS, but due to the use of generics in
the patch, there will be compilation errors on pre-Xcode 7 platforms,
such as Mountain Lion and Mavericks.
I strongly recommend to revert this patch when the oldest supported
macOS release is bumped to Yosemite (10.10).
https://bugzilla.gnome.org/show_bug.cgi?id=785306
Instead of gtk_widget_draw'in the inspected widget inside the
magnifier's ::draw handler, just create a new GtkSnapshot and snapshot
in its snapshot handler, similar to what GtkStack is doing.
gtk_widget_draw_internal is now only used inside gtkwidget.c, so remove
the prototype from gtkwidgetprivate.h. And since all incovacations call
it with clip_to_size=TRUE, remove that parameter.
We cargo-culted this from Autotools, but GCC on Windows supports the
same __declspec syntax as MSVC. The only difference is the additional
flag needed for GCC-like compilers.
The linker on macOS does not support '=' in its command line; there's no
guarantee that we are using the correct compatibility versions compared
to the Autotools build, but for that we'll need to build GTK+ master on
macOS.
This property contains 5 integers, of which the last 2 respectively
contain the tool serial number and tool ID. We were only extracting the
first so far, but GdkDeviceTool also has API getters for the latter,
which remained 0.
https://bugzilla.gnome.org/show_bug.cgi?id=786400
They are not usually yellow anymore, the previous advice about how to
style them was for pre-3.20 versions, and the immediate replacement (CSS
class .tooltip) does not seem ready for primetime.
https://bugzilla.gnome.org/show_bug.cgi?id=784421
Spooky action at a distance is not really allowed in Meson, so the rules
to generate the SPV files should go in their own directory.
Tested by: Rico Tzschichholz <ricotz@ubuntu.com>
The ComboBoxes were initially empty, rather than reflecting the initial
values of the properties. The CheckButtons were only correct by chance.
Fix this by setting the initial values on the widgets and binding them
to the properties using SYNC_CREATE, so the two are always synced up.
https://bugzilla.gnome.org/show_bug.cgi?id=786209
No longer store variation sequences explicitly. Instead, put a 0
in the sequence where the modifiers will be inserted. This is more
compact, and it allows us to put variations directly into the
recent section.
Update the type of the recent-emoji setting to match these changes.
Add an "Insert Emoji" item to the context menu in entries.
We also add a show-emoji-icon property, which when set to
TRUE, will add an icon that can be clicked to bring up
the Emoji chooser.
When the popover is dismissed, we return the focus to
where it came from. However, by using gtk_widget_grab_focus,
we were messing up the selection if that widget happens to
be an entry. Special-case GtkEntry and use
gtk_entry_grab_focus_without_selecting to avoid this issue.
The json file is imported from the (MIT-licensed) emoji.json[0] node
module, which generates it from the emoji list published by the
Unicode Consortium.
This commit also adds a little tool to convert the data into
a compact GVariant, and the result of that conversion, which is
added to libgtk as a resource. The following commits will make use
of it.
[0] https://github.com/amio/emoji.json
We create various windows during the initial creation of display
objects, which causes some bootstrapping issues when we try to
find the default screen to get its root window. To work around this,
pass the display object into gdk_window_new.
This is not an API change, since gdk_window_new is no longer public API.
Interpret NULL as "root window" here - we only have one
screen nowadays, so there is no choice involved, and this
will let us avoid dealing with the root window in the
fontend code.
menu margins have been added has a hack to mitigate bug:
https://bugzilla.gnome.org/show_bug.cgi?id=591258 with gtk+4 this
doesn't work anymore on gtk+4, the margin should probably be moved
to the parent window node, but it's not selectable, commenting out
for now.
Since gtk+ draws more than the widget and allocates more size to it than
it knows about, this flag doesn't work anymore. Removing it (or setting
it to TRUE for widgets that used to set it to FALSE) fixes drawing
invalidation when these widgets get allocated a new size.
In gtk_container_real_set_focus_child(), we try to scroll to the
position of the new :focus-child if we have h or v adjustments.
gtk_widget_translate_coordinates() returns FALSE if neither widget is
realized or in other situations that cause output parameters x and y not
to be set. Thus, if the caller did not initialise x/y and uses them even
if the function returned FALSE, they are using uninitialised variables.
In gtk_container_real_set_focus_child(), we did not check the return
value but merrily went ahead and used x and y regardless. This is UB, as
revealed by Valgrind, as well as being pointless.
The trivial fix is to exit early if (!gtk_widget_translate_coordinates).
https://bugzilla.gnome.org/show_bug.cgi?id=776909
Commit 885bcd9fe4 trampled the bit here
that is meant to translate between the nominated focus child and the
actual innermost one that is used for updating the h/v adjustments.
So, we need to save the passed focus child before diving into its
children, then translate and get allocations between them both. This
makes GTK+ 4 behave like GTK+ 3 again: instead of priv->focus_child and
focus_child, we now have focus_child and child, serving the roles of the
nominated focus child and its innermost focus child respectively.
This also ditches the unnecessary call to Widget:get_focus_child(), as
Container::set_focus_child() gets that same new child as an argument.
process-stop-symbolic is unintuitive if represented as a stop sign as in
Adwaita, and completely ambiguous if represented as a cross like the
window close button in other icon themes.
Instead, use application-x-executable, which is already used elsewhere
as a fallback if no specific icon can be found for the application.
https://bugzilla.gnome.org/show_bug.cgi?id=784624
Don't beep when modifiers are released in entries.
This was an inadvertent change that snuck in with
the emoji support.
Also, don't beep while entering an emoji name.
There is entirely too much beeping here.
In GTK+ 2, the ch < 0x80 was ORd with klass->latin1_to_char, and that
was unconditionally set to TRUE in the class init function, so
effectively the ch < 0x80 never mattered before or served any purpose.
When klass->latin1_to_char was deleted from the class in commit
f760538f17, this check’s sense changed.
The resuls was that accel keyvals with gunichar value >= 0x80 stopped
being rendered as symbols, instead falling back to their keysym name.
Instead of recognisable symbols for these, we get raw, often obscure,
and untranslatable keysym names. This breaks accessibility as well as
client users who may be parsing such accels and migrating from GTK+ 2.
So, remove the < 0x80 to restore the behaviour from before said commit.
https://bugzilla.gnome.org/show_bug.cgi?id=783906
This commit adds some basic support for entering emoji by name
to GtkIMContextSimple. To begin an emoji sequence, use Ctrl-Shift-e
instead of Ctrl-Shift-u that is used for hex input. Otherwise, the
behavior is the same: you can can let go of the modifier keys and
end the sequence with space or enter, or hold on to the modifier
keys and end the sequence by releasing them.
Only a limited, fixed set of names is supported at this time, see
the GtkIMContextSimple docs for a full list.
• Add GtkLayout as a @See_also since it includes fixed-pos functionality
• Drop mention of the long-gone Linux framebuffer port
• Explain how to work around the problems with RTL text
Being addable to a ScrolledWindow is not interesting; now that SW
auto-adds a Viewport if needed, so can DrawingArea and any other widget.
Mention GtkFixed in case the reader just wants that bit of functionality
This adds support for the shortcut inhibitor protocol in gdk/wayland
backend.
A shortcut inhibitor request is issued from the gdk wayland backend for
both the older, deprecated API gdk_device_grab() and the new gdk seat
API gdk_seat_grab(), but only if the requested capability is for the
keyboard only.
https://bugzilla.gnome.org/show_bug.cgi?id=783343
We wait for a few 100ms for rendering to settle in various WMs. So far
we only did that for windows that were controlled by the WM (aka
toplevels).
With modern compositing gnome-shell however, this now also applies to
override-redirect windows, so we now wait there, too.
This makes the reftests a lot slower, but they now actually work when
running make check in gnome-shell.
If query.return_type is not one we want, binding_compose_params() is
not called, and so params remains a NULL pointer. However, the code was
then unconditionally iterating it regardless. Don't if it is still NULL.
CID 1452218 (#1 of 1): Explicit null dereferenced (FORWARD_NULL)
15. var_deref_op: Dereferencing null pointer params.
This would only happen if the last element was deprecated, but it should
be avoided anyway.
CID 1388852 (#1 of 1): Out-of-bounds read (OVERRUN)
12. overrun-local: Overrunning array pseudo_classes of 16 32-byte
elements at element index 16 (byte offset 512) using index i + 1U (which
evaluates to 16).
This function clearly assumes the parameter children cannot be NULL, and
the call sites seem to perform enough checks to confirm this.
CID 1388869 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking children suggests that it may be null,
but it has already been dereferenced on all paths leading to the check.
CID 1432024 (#1 of 1): Uninitialized scalar variable (UNINIT)
2. uninit_use_in_call: Using uninitialized value rect.x when calling
calendar_arrow_rectangle.
Add a default case to the switch which will bail out with
g_assert_not_reached(), which should reassure Coverity that the method
is always called with a valid value that is handled in the switch.
If value->values[i] is NULL, then values[i] was left uninitialised.
The code then reads each element of values[].
CID 1432029 (#1 of 1): Uninitialized pointer read (UNINIT)
11. uninit_use: Using uninitialized value values[i].
Our ::query-tooltip handler first checks whether the pointer is over any
of the icons, returning their tooltip if so, and if not chains up to
Widget::query-tooltip in order to show the text for the widget overall.
But ensure_has_tooltip(), which exists to update :has-tooltip based on
whether ::query-tooltip is needed, only set :has-tooltip to TRUE if any
icon had a tooltip, without caring whether the widget as a whole does.
That is asymmetrical and meant that if the Entry had a tooltip, but
subsequently all icons had their tooltips unset, :has-tooltip would be
set to FALSE, and hence the tooltip for the widget would become lost.
The fix is to set :has-tooltip to TRUE if the widget has a tooltip of
its own, and we only need to check the icons if that is not the case.
https://bugzilla.gnome.org/show_bug.cgi?id=785672
glib-mkenums is now done in Python, but since the Visual Studio build
environment (cmd.exe) does not support shebang lines, we need to call
the interpretor explicitly to run the script.
This means that we need to update on how we generate
gsk/gskenumtypes.[c|h] in our projects, as at this point GTK+-3.91.x
does not require a GLib installation that ships with the Python-fied
glib-mkenums. As a result, we adapt to this by first using Python
to call glib-mkenums. If this fails (where the output file becomes 0
in size), then we use PERL to call the glib-mkenums script. Note that
during the build this will cause a warning message to be displayed,
stating that '&' cannot be found, but due to the way Windows .bat script
are done, we need to live with that until a solution can be found on
this.
This is likely a problem that does not exist in the Meson builds, as
Meson will take care of calling the interpretor for us by looking at
the shebang lines for our case.
Also, clean up the .batin Windows batch script that is used to call
glib-mkenums by using a for loop in there.
Just to test tooltips in all cases; what was already here
should have been sufficient, but this doesn't hurt.
While here, also add some instructive placeholder text.
https://bugzilla.gnome.org/show_bug.cgi?id=780938
Use conditionals to select the Python installation, so that we can stick
closer to the default Visual Studio versions used to compile each official
Python releases.
This means by default:
-2013 builds use Python 3.4.x, which is built with 2010
-2015 and 2017 builds use Python 3.6.x, which is built with 2015.
Also rename PythonPath/PythonPathX64 in the property sheets to
PythonDir/PythonDirX64 repsectively, as PythonPath is the envvar name
where additional Python modules is searched for, so we don't want to get
confused with it.
Last but not least, distinguish between the Python interpretors that are
used on x64 and x86/32-bit builds for generating the libgtk4.manifest
file and the gdbus-generated sources, for consistency reasons.
Refactor the code updating the active link under the current coordinates
into a separate function, and call it on GtkGestureMultiPress::pressed
so the link is updated on GDK_TOUCH_BEGIN. Based on a patch by
Jan-Michael Brummer <jan.brummer@tabos.org>.
https://bugzilla.gnome.org/show_bug.cgi?id=776903
It is not necessary to (re)set the cursor on every crossing
event, and can probably yield the wrong results if there are
multiple master devices involved. Just set it on init(), and
let the inner machinery update the cursor whenever necessary.
This patch is an adaption of commit 0daf79676 in gtk-3-22, the
side effects are not as bad here because the cursor was already
being set on the widget specifically instead of the parent
widget's, but there's still some nonetheless (plus, it's simpler)
https://bugzilla.gnome.org/show_bug.cgi?id=785375
This check must be done explicitly on Wayland as the master device for
tablet tools differ from the Core Pointer. This ensures that whenever a
tablet tool is inside a window and the cursor is programmatically changed,
it will be visually updated too.
https://bugzilla.gnome.org/show_bug.cgi?id=785375
Replace uses of VLAs (variable-length arrays) using g_newa(), since
Visual Studio builds will unlikely ever support VLAs (which became optional
in C11).
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Adds support for creating scroll events from Wayland tablet wheel events.
Even though no Wacom tablet puck has a smooth-scrolling wheel, both event
types need to be generated to make the upper layers happy.
https://bugzilla.gnome.org/show_bug.cgi?id=783716
If a tablet device is used to perform actions like window moving or resizing,
GTK must provide the correct implicit grab serial number over Wayland to Mutter
in order for the action to succeed. This commit adds tablet support to the
implicit serial getters.
https://bugzilla.gnome.org/show_bug.cgi?id=777333
Since gtk_bin_add does a gtk_widget_set_parent call, we cannot use it in
a GtkBin implementation that has multiple child widgets and cares about
their order.
If a bad behaving application tries to make the window/display beep too
often, throttle the beep requests so that we don't end up filling the
Wayland socket queue.
The throttle is set to 50 beeps per second, which far more beeps than
will ever make any sense from a user experience point of view, but will
avoid terminating due to an excessive amount of requests.
https://bugzilla.gnome.org/show_bug.cgi?id=778188
So we can avoid creating a GtkCssPathNode in _init and then throwing it
away right after when using the _new_with_node constructor, which is the
one we use for all widgets.
Don't set the have_focused field of the window's toplevel to TRUE by
default and don't set the FOCUSED state in gdk_window_map. This a means
toplevel window's state is what the WM expects, and the FOCUSED state
will be set anyway when we map the window and receive a _NET_WM_STATE
message.
Since setting a clip is mandatory for almost all widgets, we can as well
change the size-allocate signature to include a out_clip parameter, just
like GtkCssGadget did. And since we now always propagate baselines, we
might as well pass that one on to size-allocate.
This way we can also make sure to transform the clip returned from
size-allocate to parent-coordinates, i.e. the same coordinate space
priv->allocation is in.
Remove the special case in gtkwidget.c where we didn't draw any css
background/border for popovers. Instead, rely on themes to not style the
popover node and add a contents gizmo that gets the actual css styling.
We then requeste enough space for the popover to draw both the contents
and the arrow on the side.
The reported minimum baseline is for the reported min height, but if the
css min-height is greater than that, we need to account for that fact
when saving the baseline.
Since the reported baseline is relative to the widget's origin, we also
need to add the top values for margin, border and padding to the
reported baseline.
We claimed the gesture previously to keep it from propagating to the
underlying entry, but now that the entry is in a box with the two
buttons, we can do this properly and restore the previous long-press
behavior.
It's getting harder and harder to find a dummy style property to use
here, so remove the test case since style properties should be going
away soon anyway.
Previously, we would request a size of 0×0 when the transition type was
NONE and the child un-revealed, making the revealer in this case a
gtk_widget_set_visible replacement. Instead, to the exact same thing we
do in the CROSSFADE case and request the child size instead. This also
keeps the revealer from under allocating the child when the transition
type is set to NONE.
Instead of hopping through 7 different functions to do that, just
remove all rows directly. This also mean we'll only remove rows and not
other children that've been added like placeholders.
Add :dir(ltr) where expected, i.e. everywhere we now have a widget but
had a gadget before.
Also, fix the expected output to expect mark subnodes in the order
specified in the GtkScale does, i.e.
├── mark
├── [label]
╰── indicator
for marks at the top of the scale and
├── mark
├── indicator
╰── [label]
For marks at the bottom of the scale.
Checking the given GtkAllocation against the current allocation insize
::size-allocate doesn't really work anymore. They are only different if
the content allocation (the one passed) and the widget allocation (the
current one) are different, so e.g. when the widget has padding >0
applied.
Since we get offset automatically to the widget allocation before
->snapshot is called, we still have to offset the difference to the
position of the content allocation.
We don't need to care in this case since the default values should
always be assumed to be 0, and setting a baseline of 0 is just wrong
when orientation == HORIZONTAL, it should be -1 (or unset).
This is optional for positive margins as they just increase the widget
allocation. However, with negative css margins, the allocation is
smaller than the clip.
This fixes scale sliders leaving a small trail behind.
This fixes the expansion not working. As a GtkBin, GtkExpander can only
have one child and if that's a GtkBox (and not the one added through
gtk_expander_add), things go wrong.
always initialize clips to the (content) allocation, don't walk up the
widget hierarchy in gtk_widget_set_clip, implement
gtk_widget_size_allocate in GtkSeparator. This way we don't end up using
uninitialized clip values.
The entire clip handling is up for major rework since we can't and don't
want to force every single widget to call _set_clip in size-allocate
implementations.
If widgets chain up in their size-allocate implementation, they pass the
content allocation and not the widget allocation which will cause the
wrong allocation to be set.
We need to adjust the passed for_size to fit into the content allocation
of the widget.
That also means that we can't call gtk_widget_measure(widget) inside
gtk_widget_measure(widget) since now the for_size will be adjusted
twice.
Events that get to gtk_main_do_event() have the toplevel GdkWindow
as event->any.window. Also, ensure that coordinates fall within
sensible places of the windows, since those might have shadows,
headerbars and whatnot on wayland.
That means the whole hierarchy is getting destroyed, leaving those
behind incurs not only in a leak, but also on weak refs (and unintended
repick) to happen in the wrong moment.
Showing all the different errors and warnings when renaming and creating
files/folders without potentially resizing popovers on every keystroke
requires us to know the size of the error messages beforehand, so pack
all of the possible error messages and warnings in labels and those into
a stack. This way we can also neatly crossfade transition between them.
https://bugzilla.gnome.org/show_bug.cgi?id=775636
GdkPixdata is deprecated. Warn when the application tries to load
pixdata embedded resources. The application developer will have to
remove the "to-pixdata" keyword from the GResource definition file.
https://bugzilla.gnome.org/show_bug.cgi?id=781583
The glib-genmarshal tool from GLib 2.54 added various command line
arguments that allow us to remove a bunch of as hoc manipulations of
the generated marshaller source files. The marshal generator tool can
now include an header in the source, and undef the G_ENABLE_DEBUG
pre-processor symbol for us. It can also generate the prototypes of the
marshallers in the C source, and avoid a 'missing-prototypes' compiler
warning.
Use the new predictable request object path and connect
to the Response signal before issuing the portal call.
This avoids a race that is pretty unlikely to hit in
the filechooser case.
Wacom tablets often have a "pad" device which houses multiple buttons. At
present, these devices are incorrectly marked as GDK_SOURCE_PEN which can
cause problems for some software.
https://bugzilla.gnome.org/show_bug.cgi?id=782040
Commit b52966a318 stopped the parser from
handling various deprecated pseudoclasses, which were aliases of others,
but it did not update the documentation to reflect that they were gone.
The label measuring code was only determining baselines
when the label was set to wrap, which does not seem right.
Non-wrapping labels have a meaningful baseline as well,
report it back.
When there is no externally allocated baseline, we should
do the same thing that GtkBox does, and determine one from
the children that want baseline alignment.
This commit adds a GtkCenterBox::baseline-position property
with setters and getters.
By relying on GtkSpinButton default activation behavior, the
collate icon doesn't get updated when a new number is typed
in the copies spin button.
https://bugzilla.gnome.org/show_bug.cgi?id=759308
Add beginning double asterisks and function names. Correct the parameter
names (next/previous_child -> next/previous_sibling). Make the documentation
of the two functions more similar.
https://bugzilla.gnome.org/show_bug.cgi?id=783445
The imcontext internals have been changed to use set_client_widget
instead of set_client_window in order to remove API dependency on
GdkWindow. Update the Windows IME support so that the code will
continue to build and work.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
The callback function that is used by VkDebugReportCallbackCreateInfoEXT
is decorated with VKAPI_CALL (which is __stdcall on Windows). This is
not detected on x64 Windows as __stdcall is not really meaningful on x64
Windows, and VKAPI_CALL expands to nothing on non-Windows.
As __stdcall functions are treated differently on 32-bit Windows, the
32-bit compiler does require that the function be declared as __stdcall
so that things will compile, link and run properly.
https://bugzilla.gnome.org/show_bug.cgi?id-773299
Under Wayland, when multiple keys are pressed and the user releases a
key, key repeat should continue unless the key released is the one
currently repeating.
In the case of:
- key1 press
- key1 repeat
- key2 press -> key1 repeat stopped
- key2 repeat
- key2 release
The behavior should be to cancel keyboard repeat, though key1 is still
held down. This is consistent with prior X11/XWayland behavior.
The following also must work:
- key1 press
- key2 press
- key2 release
- key2 press
- key1 release
- key2 should continue to repeat
The fix for bug #778019 should continue to work:
- key1 press
- key1 repeat
- key2 press -> key1 repeat stopped
- key1 release
- key2 should repeat
The choice to change the counter nkeys to the flag repeat_active
helps to solve the second test case.
https://bugzilla.gnome.org/show_bug.cgi?id=781285
begin_resize_drag() and begin_move_drag() check for xdg_surface being
not null, but those apply on xdg_toplevel so they should check for
xdg_toplevel being non-null instead.
https://bugzilla.gnome.org/show_bug.cgi?id=781945
When an event is received while a tooltip is showing, the GtkTooltip's
event handling code can end up calling gdk_window_set_transient_for()
from gtk_tooltip_set_last_window().
The Wayland GDK backend will try to automatically create a subsurface
in gdk_wayland_window_set_transient_for() but if the parent surface is
gone meanwhile, this will will cause a crash when trying to create a
subsurface from a parent with a null surface.
Checking for the parent is not sufficient, we ought to check for the
parent surface as well to avoid the crash.
https://bugzilla.gnome.org/show_bug.cgi?id=782283
Applications can specify the type hint as utility even on toplevel
windows.
When that toplevel is also marked as a transient for another window,
GDK Wayland backend would translate that as an xdg_popup which is not
appropriate.
While utility temp windows should remain mapped as subsurfaces (such as
the ones used by treeviews), regular windows should not translate as
neither a subsurface nor an xdg_popup.
https://bugzilla.gnome.org/show_bug.cgi?id=781945
The code used SIGDN_URL to get an URL for the selected item, but Windows URLs
are a mix of unicode and percent encoded characters in the locale encoding
and not something GFile can understand. The result is a garbage file
path.
Instead use SIGDN_FILESYSPATH to get a real file path if available.
Also checks the return value of g_utf16_to_utf8 because file paths on
Windows can contain lone surrogates which would make the conversion fail.
https://bugzilla.gnome.org/show_bug.cgi?id=783347
Another selector forces round corners for headerbars in a stack, and it
has higher priority than the selector covering the non-stack case from
commit 796f9b5bfb. Totem’s MainToolbar
happens to be in a stack, and we should maintain symmetry here anyway.
So, as window classes .maximized and .tiled are excluded from this other
selector, the newly handled .fullscreen case must be excluded here also.
https://bugzilla.gnome.org/show_bug.cgi?id=770513
Totem uses a fullscreen window with a headerbar at the top, and without
this change, that headerbar has rounded corners, which look different
from a maximised window and let video content show through beneath.
https://bugzilla.gnome.org/show_bug.cgi?id=770513
There is no need to have every application log a warning when the
Wayland display server goes away, and we are using _exit instead of
exit elsewhere.
This is also what the X11 backend does (see gdk_x_io_error).
https://bugzilla.gnome.org/show_bug.cgi?id=745289
As we now refrain from sending the crossing events if there's an
implicit grab, those events must be sent on button release when
the implicit grab is broken.
Check the grab widget (both explicit and implicit) and check for a cursor
from the target widget up to this grab widget. If the target widget is
outside the grab widget, only the grab wigdet's cursor will be checked.
This also means that we have to ensure the cursor is updated on button
releases, as an implicit grab being deactivated must trigger a cursor
lookup from the target widget.
In these situations we must perform the "is it claimed" check before removing
the (touch)point, as doing so when the gesture is empty will be too late if
the gesture actually claimed input.
This just applied to child windows, but now GDK should just take care of
toplevels, which shall get crossing events from the windowing when the right
conditions apply.
Removing this code fixes confused crossing state in widgets and messed up
window_under_pointer tracking (Which now is meant to be toplevels) when any
of the remaining child GdkWindows trigger these crossing events.
For some reason this wasn't done on windows with an impl, but it totally should.
Probably hidden by grabs in menus and somesuch being done on a child window.
We already issue the first _get_parent call before even entering that
loop, so make sure `parent` is not NULL. This happens when event_widget
is already a toplevel, and this change fixes row-dragging in treeviews.
Drop the in_widget flag since motion events the listbox receives are
always inside the listbox. Also drop the manual coordinate translation
code using GdkWindows.
We don't draw or size-allocate the titlebar when the window is
fullscreen or undecorated, so reflect this by setting it to
!child_visible. This can happen when changing the value of the decorated
property while the window is shown.
Instead of delegating on the parent shell of a menu item/shell on a variety
of situations, Simplify event handling so:
1) Menu item selection is handled entirely on GtkMenuItem through crossing
events.
2) The deepmost menu shell handles clicks inside and outside of it.
This avoids the rather hard to follow gtk_widget_event() calls going on all
throughout the handling of crossing and button events, and makes menus work
again.
As event->any.window is the toplevel, this is not useful anymore to
determine the window/widget that is the target for this event. Add
helper functions to attach user data to GdkEvents so the target
widget can be stored on the gtk/ side.
These calls should be made private with the rest of GdkEvent related
API.
It's not necessary anymore for clipping nor receiving events. So just
remove it. The event handling code was expecting events in bin_window
coordinates, and have been updated to relying on widget-relative coords.
We can just replace window comparisons with coordinate matching, the
cursor corresponding to edges is now set in a capture-phase motion
handler, as cursors aren't set on GdkWindows anymore.
It's not necessary anymore to receive input events. The pan gesture has
been set on the capture phase as the child widgets may capture during
bubbling.
There should be no circumstances where an implicit grab is requested but
no focus exists, there's however circumstances (like windowing grabs taking
input to a different window) where we might get implicit grabs being undone
when then new window didn't create a focus for the pointer itself.
Only if they fall outside the grab widget, in that case the widget holding
the implicit grab won't be receiving events anymore, so we can just undo
it.
We now rely on toplevels receiving and forwarding all the events
the windowing should be able to handle. Event masks are no longer a
way to determine whether an event is deliverable ot a widget.
Events will always be delivered in the three captured/target/bubbled
phases, widgets can now just attach GtkEventControllers and let those
handle the events.
Those are now needless and wrong, as we get guarantees that handled
events will contain widget-relative coordinates. A side effect is
that these events are very possibly not explicitly sent to the
GdkWindow that implementations expect, any extra checks performed
through gtk_gesture_set_window() will be wrong, so the function has
been dropped entirely.
And refurbish cursor management to be set on the GtkWidget. The
input window is not needed anymore to receive events either.
This is no longer set through the GdkWindow, so use the private
GtkWidget API.
The event shall no longer be "directed" to the event window, but the
widget. Getting a enter/leave event is enough now to know whether the
pointer is inside or outside the widget.
Unlike GTK+ grabs which are global to all/one device, the implicit grab
is per focus, which means each may have implicit grabs on different or
the same widget.
Now that gtk_main_do_event() is able to handle pointing events in toplevel
coordinates, forward all of these as is. Just minimal handling is still done
on the gdk side for GDK grab accounting, and toplevel tracking for each
pointer.
Implement target finding per-pointer/touchpoint through GtkPointerFocus and
_gtk_toplevel_pick(). Focus changes are handled through the emission of
crossing events between the old target and the new one.
Each toplevel will keep its own tracking of the current ongoing foci,
add the plumbing that will allow to create/update/remove those as they
come and go.
These objects (tied to a toplevel) track the focus of a pointer/touchpoint.
The info in these basically consists of current toplevel coordinates and the
current target widget.
This function will be useful in other places, such as determining the
widgets that must receive crossing events after pointer picking points
to another widget.
Aborting the application makes it look like an application bug, when
it is the expected thing to do when the Wayland display server goes
way. eg., when the user logs out. The log level is also demoted to
avoid a storm of warnings in the log from all applications whenever
this happens.
This is also what the X11 backend does (see gdk_x_io_error).
https://bugzilla.gnome.org/show_bug.cgi?id=783047
The :last-child selector supposed to reset the border was
overridden by the :hover selector. This is fixed by moving the
:last-child selector after the overriding one.
Thanks to Sebastian Keller for spotting.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=779078.
…erties clobbered by commit c92b7d4224.
That and its counterpart were for removing :expand and :fill child props
from GtkBox, but they ended up catching these for GtkToolItemGroup too.
While GtkToolItemGroup still has these, we may as well keep demoing them
Fix the sizing and spacing, blue tags for the bright variant,
similar to what gnome-documents was shipping, and inverted gray
tags for the dark variant, not vanishing on hover.
It was only testing the default configuration, where overlay scrolling
is on and both scrollbars use POLICY_AUTOMATIC. We should also test the
other 3 configurations that are available by including non-overlay
scrollbars and/or those that use POLICY_ALWAYS.
https://bugzilla.gnome.org/show_bug.cgi?id=778853
POLICY_AUTOMATIC means scrollbars are only shown when needed, i.e. when
the size of the window is not large enough to show the entire child. So
when measuring the preferred size, such scrollbars should be ignored.
But measure() added size for *any* non-overlay scrollbar of the opposite
orientation, e.g. for horizontal size, it added the width of vscrollbar.
So we requested for child + bar, & having enough for child meant that the
policy hid the bar, leaving extra space empty below/right of the child.
Fix this by only adding size for such bars if they use POLICY_ALWAYS.
https://bugzilla.gnome.org/show_bug.cgi?id=778853
• Only calculate the specified dimension – rather than measuring both &
discarding the other (which will often be recalculated right after)
• Only measure a given child scrollbar if it may be visible, not always
• Move variables into narrowest scopes & otherwise improve readability
https://bugzilla.gnome.org/show_bug.cgi?id=778853
Some files that this script will process might have UTF-8 items in
there, which can cause problems on Python 3.x as it is more strict and
careful on unicode issues. Fix this by:
-Doing what we did before on Python 2.x
-Opening the file with encoding='utf-8' on Python 3.x
The user data passed when exporting a Wayland window was supposed to be
freed using the destroy_func, as is commonly done. This was previously
broken, as the user data was just NULL:ed when exported, and only
actually destroyed when unexporting before having exported.
While e016d9a5db fixed this, it introduced
a regression, as GtkWindow was nice enough to free the memory anyway
after having received the exported handle, causing it now to double
free.
https://bugzilla.gnome.org/show_bug.cgi?id=782109
Otherwise in GC-ed environments the `g_source_remove` call during
disposal might be called on an already removed source, which results in
unnecessary console output.
https://bugzilla.gnome.org/show_bug.cgi?id=778301
Use the gravity enum values when converting to gravity. It doesn't fix
anything, since the enum values were identical, but it makes a coverity
warning go away.
https://bugzilla.gnome.org/show_bug.cgi?id=780301
5bb12474d9 removed the dnd window movement code to let
the gdk backends handle the window movement instead. While this
works for X11/wayland the win32 backend still uses the unmanaged
interface and expects the window movement to be handled on the gtk
side. This restores the functionality in case the dnd is unmanaged.
This fixes the drag window on Windows being stuck in the top left
corner instead of following the drag position.
https://bugzilla.gnome.org/show_bug.cgi?id=781737
Creating with `gtk_popover_new_from_model` should be exactly the same as
if via `gtk_popover_new` plus `gtk_popover_bind_model`.
Also remove the style if the model is unbound at any point.
Try text/plain;charset=utf-8 first, before falling back to
X11-isms like UTF8_TEXT. This makes things work on Wayland
compositors that don't carry a heavy X11 legacy around.
https://bugzilla.gnome.org/show_bug.cgi?id=781814
The `-export-dynamic` flag is a libtool-specific flag; since we're not
using libtool with Meson, we should instruct the C compiler to use the
appropriate linker flag instead.
Copy the location of the test data and binaries from the autotools
build, even though it's not really correct; currently we install the
test data under libexecdir, but it should live under datadir, and we
should use `G_TEST_DIST` to figure it out.
The `state` subdirectory is missing.
The common compiler and linker flags control, among other things, the
default visibility of symbols; without them, we leak symbols that ought
to be private.
GSK has various enumeration types that are currently not used; while
they may go away, currently they are built and introspected. If we want
the introspection machinery to work, and still use static libraries to
build GDK and GSK into the GTK shared library, then we need to reference
the get_type() function of these enumeration types somewhere, to avoid
the linker discarding it, and thus breaking the build.
As luck would have it, we have an autogenerated bit of C that refers to
all the get_type() functions in the library; if we add the GSK types to
it, then we get the reference we're looking for, and the build succeeds.
We need to reference the types file directly, because it won't be copied
into the builddir by Meson — except for GTK, which needs to generate its
own types file using configure_file().
We're mixing a lot of styles in the Meson build files. This is an
attempt at making everything slightly more consistent in terms of
whitespace and indentation.
If glslc is found, rebuild the shaders from GLSL to SPIR-V; otherwise,
we're just going to use the built files we have committed in the source
repository.
When building GTK+ straight from the repository without any assistance
from packaging tools, we need to trigger system-wide updates, like the
icon theme cache update, or the schema compilation.
We can build the name of the input and output files for the Wayland
protocols we use from the protocol name, stability, and version. This is
similar to how the autotools build does it, except much more clear and
without shelling out twice to sed just to resolve the Makefile rule.
We need to check if the linker flags we use are available, depending on
the platform, and we need to ensure that the shared library is
versioned appropriately.
GTK symbols are not visible by default, and only the ones annotated with
_GDK_EXTERN (and wrapper macros) are exported. We need to define
_GDK_EXTERN during the configuration, depending on the platform and
compiler we use.
The autotools build checks the version of GLib we are depending on in
order to generate the appropriate GLIB_VERSION values for the
min-required/max-allowed defines.
We have to work around some ordering problems here. We still
manage to keep most of the guts in modules/input/meson.build,
so it's not too ugly overall.
(The autotools build solves this with a 'make -C ../../input/modules'
inside gtk/Makefile, but that's not something we can or want to do.)
Remove workaround for gcc bug (Meson does that now), and
construct the right config.h defines for the headers on
the fly instead of listing them in the build file, which
is more error prone.
Add back dependencies on libgdk_dep and libsk_dep which are declared
dependencies. We removed this before because these declarations had
link_with: lines that dragged in the static libgdk.a and libgsk.a libs
which are linked into libgtk-4.so anyway and thus shouldn't be used
when linking internal exes/tools against libgtk-4. Remove the static
libs from the declared dependencies and have libgtk link those in
explicitly, so that the declared deps now just provide all the built
dependencies and include dirs and such for declared libgtk_dep users
such as the internal exes/tools, which want all the generated gsk/gdk/gtk
headers to exist before attempting to compile anything against the
gtk+ headers.
gdk and gsk are no longer separate libs but part of gtk now, so any
Gtk+ user should just link to gtk, there's no need to additionally
link against all those static helper libs that go into the gtk lib.
This means we need to specifically add confinc to include_directories
in more places to make sure the right config.h (i.e. ours) gets
included and not a subproject's like graphene's config.h.
Not dragging in static libs also fixes the issue of all executables
having to be relinked for any and all changes. With this change
it's super-fast now and can be skipped for most changes that don't
touch the external ABI.
gdkprivate-wayland.h includes generated wayland client protocol
headers and is included from gdkdisplaymanager.c, so we need to
generate those client protocol headers first also when building
main gdk itself.
This is how it's done in the autotools build. Also avoids problems
with multiple source files having the same name (gdkeventsource.c).
Also move broadway backend code into broadway subdir.
Almost all of these tests include gtk/gtk.h so we need
to dep on libgtk not just libgdk. Otherwise compilation
fails because graphene.h include can't be found.
Add libgdk_dep as dependency to the libgtk_dep declare_dependency(), so
that the generated gdk includes are generated before anything is built
that tries to include gtk headers (such as various tests that don't depend
on gdk directly).
This is needed for the Meson port, a file name .c that's included
and shouldn't be compiled into an object is difficult to manage
otherwise. And it's not actually a valid .c file anyway.
This was only every implemented under X11, and with CSD,
this is clearly in the application realm. We should not
pretend that we can support it on the toolkit level.
https://bugzilla.gnome.org/show_bug.cgi?id=775061
We used to inject the inclusion of the generated header file into the
generated body of the marshallers source code in order to avoid compiler
warnings about missing prototypes. The glib-genmarshal utility has been
fixed in GLib to include the prototype in the generated source, so now
we're going to trip -Werror=redundant-decls.
With Wayland, GDK_DEBUG=events would log key events but not explicitly
state whether the event is a key press or release, or if it's
originating from a key repeat.
Add some more verbosity to make sure these informations are logged on
key delivery when GDK_DEBUG is set.
https://bugzilla.gnome.org/show_bug.cgi?id=781767
The rect parameter in gtk_gesture_multi_press_set_area is annotated as
nullable and the code handles the rect==NULL case, but the
g_return_if_fail kept that case from ever happening.
Turns out that the destination is the last parameter, not the first one.
This fixes the flickering in the first page of the widget-factory when
using the expander on page 2.
It is generally a good idea to license individual files under the
same terms as the project license (in particular when the mismatch
boils down to having copied the wrong license header), so relicense
the code under the LGPL.
https://bugzilla.gnome.org/show_bug.cgi?id=781422
In the else branch of the if statement before this one, we're assigning
*smallest = *widest anyway, so this if statement is never true. Move it
to the if block before instead, where it can apply.
gtk_widget_set_parent (via gtk_widget_reposition_after) will queue a
resize on the parent widget automatically when adding a child widget, so
unparent should do the same
The center widget in GtkBox was only introduced to use it in
GtkActionBar. However, the implementation there is much more complex
than it needs to be, so move the center widget into GtkActionBar instead
and later remove it from GtkBox.
This replaces all internal gadgets with widgets.
Remaining problem: "block" nodes have a min-width of 32px in Adwaita,
but when allocated in continuous mode, the levelbar doesn't care and
underallocates them.
GtkGizmo is the easiest possible widget to implement. It does nothing
except give its creator a way to control measure/size-allocate/snapshot,
so it can be used in a variety of use cases.
Insert the css node before setting a parent widget on the column button,
so the gtk_widget_set_parent won't attempt to add the css node as child
of the parent widget css node.
Translating it seems pointless if we can use a non-translatable example
such as gnome.org instead of foo.example.com.
This will help to make changes in here without breaking string freeze.
https://bugzilla.gnome.org/show_bug.cgi?id=781622
We were send the "open-location" signal without mounting first the
location if necessary, making the open in tab/window context menu not
work for those.
This patch makes sure we mount the location before emitting the signal.
https://bugzilla.gnome.org/show_bug.cgi?id=771269
Because the network monitor can perfectly be NULL,
the tests were failing on that for GtkPlacesView
always tries to disconnect this handler.
Fix that by only disconnecting the handler when
the network monitor exists.
https://bugzilla.gnome.org/show_bug.cgi?id=781195
GtkPlacesView exposes local access points and network
shares transparently by using the 'network:///' URI,
which is handled by GIO.
Currently, however, it doesn't monitor the network
for new available points, such as computers that just
join the network. It may happen too that the backend
won't find all the networks before the network enumeration
finishes.
Fix that by keeping a file monitor inspecting the network
uri, and update the places list when that happens.
https://bugzilla.gnome.org/show_bug.cgi?id=781162
Instead of the deprecated g_object_newv().
This requires some internal surgery to create our own vector of names
and values, but it does not functionally change anything.
GLib 2.53 deprecated g_object_newv() and GParameter. If we want to stop
using those types without resorting to pretty convoluted pre-processor
dancing, we will need to bump up the dependency inside GTK+.
GLib has deprecated GParameter and g_object_newv(); until we switch to
the new g_object_new_with_properties() API, and bump GLib required
version, we should simply ignore the compiler warnings.
The addition of GdkMonitor broke the quartz backend. This patch restores
that support by adding a new class GdkQuartzMonitor, and by modifying
the existing classes GdkQuartzDisplay and GdkQuartzScreen where
necessary.
It should be noted that this patch is essentially a refactor as no new
functionality that will impact the user has been added or removed.
https://bugzilla.gnome.org/show_bug.cgi?id=779184
Instead of using Ruby/Sass to generate the CSS from SCSS files, we can
use the faster and more lightweight libsass/sassc binary.
We can keep the CSS files in Git to make it easier to dist GTK+, but we
can add rules to ensure they get rebuilt if the source SCSS changes.
https://bugzilla.gnome.org/show_bug.cgi?id=780041
Instead of creating a GtkWindow, connecting to ::draw and drawing the
surface in there, then adding that window to another GtkWindow... just
use a GtkImage. This also gets rid of a bunch of utility functions used
only in gtk_drag_set_icon_surface.
When the blend modes were ported to use gsk defines, some
dashes were accidentally turned into underscores. It also
turns out that we were expecting 'saturate' instead of
'saturation' as per the css spec. Fix that as well.
If the widget isn't drawable anyway, just return;
If the widget needs an allocate, print a warning, since it indicates a
problem in the widget workflow (e.g. forgot to size_allocate a child
widget).
This maches the previous checks in gtk_widget_draw (with the same
problems).
When the GtkWidget hierarchy does not match the GdkWindow hierarchy, the
GtkWidget code may find a common ancestor that cannot be found while
traversing the GdkWindow tree using gdk_window_get_parent().
This happens with for example on Wayland, a GtkPopover has another
GtkPopover as parent, in this case, the GdkWindow parent is the root
window, whereas the GtkWidget parent is the other GtkPopover.
That confuses the gtk_widget_translate_coordinates() logic which will
bail out in this case and won't return the translated coordinates.
Make gdk_window_get_effective_parent() aware of subsurfaces and use the
transient_for which represents the actual parent (whereas the parent
might be pointing to the root window).
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=774148
For some reason, we are seeing damage being NULL here.
While that should never be the case, crashing on it is
unkind and makes the Wayland experience unusable.
The TextIter is passed by pointer for efficiency. We neither need to
modify it, nor should we leave it possible to accidentally do so. So,
it should be passed as a pointer-to-const.
We do not need to go through the heavyweight process of constructing a
TextLineDisplay just to get the direction out of it, when we can simply
use TextIter API to get the text and then get its direction using Pango.
Adapted from a patch by Mehdi Sadeghi for GtkSourceView:
https://bugzilla.gnome.org/show_bug.cgi?id=779081#c20
Add a documentation annotation saying that set_page_ranges transfers
ownership of the GtkPageRange array.
Add a g_free() call to fix a memory leak when set_page_ranges is
used repeatedly.
https://bugzilla.gnome.org/show_bug.cgi?id=780234
Since the later gtk_style_context_add_class doesn't care about the order
of the style classes, we can as well just prepend style classes to the
list and avoid the squared behavior when appending to a linked list.
Explain where the adjustment comes from, clarify some of the wording
about how its fields influence the scrollbar, and also note that the
steppers may not be present, since they aren’t in our default themes.
If the child added is not a Scrollable, it gets wrapped in a ViewPort –
which is. So it is impossible to end up with a non-Scrollable child.
Just check we have /any/ child where needed, which is semantically nicer
https://bugzilla.gnome.org/show_bug.cgi?id=778853
• intro: Clarify that external policy and/or adjustments can be used.
• add(): Don’t waffle on about having to add a ViewPort since we handle
that transparently for the user, so they can add() any widget.
• Adjustment stuff: most of this was repeating the docs for Scrollbar,
so just refer the user to that. Also, mention how
policies NEVER and EXTERNAL interact with all this.
https://bugzilla.gnome.org/show_bug.cgi?id=778853
has_tooltip_widget was assigned twice in immediate succession.
return_value is not used anywhere else in this function since commit
14a864c8b5 and does not need a default
value anymore, so move it to the inner scope and don't init to NULL.
hide_tooltip gets overriden in any case 2 lines down, and return_value
isn't used later in that function. The second assignment was introduced
in ef1da5f6c2, directly below the first
assignment.
shade/alpha/mix() take colour(s) and a number that is the ratio by which
to transform them. It was written here that these shall be passed in the
order (number, colour). That was wrong: they must be passed in the order
(colour[s], number) to work, and for the Inspector not to flag an error.
gtk_shader_builder_add_define should check both define_name and
define_value for not-NULL and not-empty, but the second precondition
check checks define_name again for not-empty-ness.
If you set GTK_INSPECTOR_RENDERER to the same type of
values that GSK_RENDERER takes this can change the renderer
used for the inspector. This is useful if you're debugging
one renderer and don't want to affect the inspector.
We can e.g. get the entry dispose()d and a focus_out event after that
(because the toplevel unsets the focus which previously was the entry).
We then later use priv->current_pos in a call to pango API which makes
sure the given index is valid for the given layout. Since we lazily
create a GtkEntryBuffer in get_buffer() and a PangoLayout lazily in
gtk_entry_create_layout, these 2 are always valid but don't match
priv->current_pos in this situation.
Fix this by resetting priv->current-pos in dispose().
The :label-widget is drawn before the child, so put the controls that
set the alignment of the :label-widget before those that pad the child.
We set (horizontal|vertical) padding, not "[xy]thickness". Also change
to "label [xy]align" & use grid spacing, not spaces at end of Labels.
This was ruined, with only 1 of the 8 subwindows rendering any content.
This commit fixes the responsible errors in the embedded GtkBuilder UIs:
• Fix broken replace by commit fb3d9022ad
of HBox with a Box having a broken orientation <property>
• Replace VBox and [HV]Paned with GtkOrientable successors (properly!)
• Remove use of Button:use_action_appearance, as this no longer exists
This commit also adds error reporting, in case other errors creep into
the GtkBuilder UI definitions, plus cleanup for the Builders and Windows
Since margin-left and margin-right are gone, we don't have to care
about the difference between them and start/end anymore and we can just
save start as left and end as right.
Instead of mentioning the old _get_preferred_xxx functions, mention
measure() and print the for_size value as well. The orientation is given
by printing either "width" for GTK_ORIENTATION_HORIZONTAL or "height"
for GTK_ORIENTATION_VERTICAL.
There are GtkGestureSingle subclasses that can be made to handle multiple
fingers (GtkGestureSingle is a subclass of GtkGesture, and not the
opposite, after all). And GtkGestureSwipe already tries to handle
GDK_TOUCHPAD_SWIPE events, except this event handler silently ignores
those.
Falling back to the GtkGesture generic handler which already
handles touchpad gesture events fixes this.
Make sure to clear up the number of keys being pressed on enter/leave so
that we don't end up with leftovers if a new window is mapped by a
keyboard shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=779374
The key repeat is stopped as soon as a key is pressed, so if the user
quickly presses a key while another is already pressed and being
repeated, key repeat gets cancelled:
- key1 press
- key1 repeat
- key2 press -> key1 repeat stopped
- key1 release
- key 2 is not repeated even though it's kept depressed
This is a different behavior from X11, which confuses migrating users.
To mimic the X11 behavior, keep track of the number of keys pressed
simultaneously and cancel key repeat only when none is pressed.
This way, if a user pressed a key while another one is being repeated,
the new key press can possibly be repeated as well.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=778019
When resizing an xdg_popup immediately after the initial mapping, there
is a race condition between the client and the compositor which is
processing the initial size given by the xdg_positioner, leading to the
xdg_popup to be eventually of the wrong size.
Only way to make sure the size is correct in that case is to hide and
show the window again. Considering this occurs before the initial
configure is processed, it should not be noticeable.
https://bugzilla.gnome.org/show_bug.cgi?id=772505
This reverts commit 901e5ff3a3.
This causes criticals in e.g. the Text View: Multiple Buffers demo.
More work is required to get a fix for Bug 778853 that does not cause
anything else to regress.
https://bugzilla.gnome.org/show_bug.cgi?id=778853
The fact that it doesn’t reuse the existing GtkLabel if present is not
immediately obvious to users (or is it just me?), so clarify that the
pre-existing :label-widget, if any, is always removed and replaced.
It was only testing the default configuration where overlay-scrolling is
TRUE and the policy is POLICY_AUTOMATIC. We should also test FALSE and
POLICY_ALWAYS. This commit adds those tests and makes the !overlay &&
POLICY_ALWAYS case pass by excluding the size of the relevant scrollbar,
as we are only interested in whether the content size is as requested.
https://bugzilla.gnome.org/show_bug.cgi?id=778853
POLICY_AUTOMATIC means scrollbars are only shown when needed, i.e. when
the size of the window is not large enough to show the entire child. So
when measuring the preferred size, such scrollbars should be ignored.
But measure() was adding size for bars for which policy_may_be_visible()
was TRUE, which it returns for POLICY_ALWAYS (good) & _AUTOMATIC (bad).
So we reserved space for child plus scrollbars, & because we have enough
space for the child, POLICY_AUTOMATIC hides the scrollbar, leaving the
extra reserved space empty at the right/bottom sides of the child. This
is very noticeable/inconvenient for non-overlay, automatic scrollbars.
Fix this by only requesting size for scrollbars that use POLICY_ALWAYS,
rather than basing the decision on policy_may_be_visible().
https://bugzilla.gnome.org/show_bug.cgi?id=778853
Using Ctrl + left/right to skip between words, or left/right to cancel a
selection, were causing movement on the screen in the opposite direction
of the glyph on the key. This was surprising and awful UX for RTL users.
This is based on a patch covering the former case by:
Author: Mehdi Sadeghi <mehdi@mehdix.org>
Date: Sat Feb 18 02:16:00 2017 +0000
https://bugzilla.gnome.org/show_bug.cgi?id=136059
Using Ctrl + left/right to skip between words, or left/right to cancel a
selection, were causing movement on the screen in the opposite direction
of the glyph on the key. This was surprising and awful UX for RTL users.
This is based on a patch covering the former case by:
Author: Ori Avtalion <ori@avtalion.name>
Date: Tue Apr 20 08:06:23 2010 +0000
https://bugzilla.gnome.org/show_bug.cgi?id=136059
It was "Missing name of pseudo-class", but the real problem is exactly
the opposite: we /have/ been given a name, but it is not a valid one.
Change it to "Invalid name of pseudo-class" to minimise confusion.
gboolean ret for whether gtk_text_iter_backward_line() moved the iter
was declared but not used anywhere. I presume it was meant to be
checked, and it passes now, so let’s do it.
the scrollbar passed in better be either priv->hscrollbar or
priv->vscrollbar. Ensure that by using a simple else instead of an
else-if and a g_assert.
When a widget is created, its default scale is the scale of the
primary screen (for instance 2). But once parented to another widget
its scale factor should be the one of its parent (if parented to a
widget on a screen at scale factor 1, it should be 1).
The problem is that we don't emit the notify::scale-factor signal when
reparenting happens.
https://bugzilla.gnome.org/show_bug.cgi?id=776821
Otherwise we wait for the next gdk_drag_motion() call, which will
happen on the next motion event, making the drag window briefly visible
on the 0,0 root coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=778203
gtk_text_iter_backward_line() checks the value of
real->line_char_offset without previously calling
ensure_char_offsets (real) to make sure the former
is up-to-date.
As a consequence of this, when gtk_text_iter_backward_line()
is called after a gtk_text_buffer_insert_range() in the
first line of buffer, the iter is not moved to the start of
the line, and the return value is wrong.
Fixed by adding the ensure_char_offsets() call.
A test case for this bug is added to the textiter gtk testsuite.
priv->trigger_event is never set, so it is always NULL. This means the
gtk_menu_popup*() methods use the current event. The only way to get any
other event to combobox_menu_popup() was from the button-press-event
handler I just removed, which would end up being the current one anyway.
So, bin priv->trigger_event & explicitly pass NULL to gtk_menu_popup*().
gtk_show_uri_on_window() will pass enough information for Portal helpers
to allow dialogue parenting in Flatpak, gtk_show_uri() won't, so
deprecate it.
https://bugzilla.gnome.org/show_bug.cgi?id=778678
Update the autotools scripts to support Visual Studio 2017 builds by
copying the Visual Studio 2013 projects and updateing the items as
necessary to obtain the Visual Studio 2017 projects.
Note that the format of the toolset string changed, so allow one to
pass in and thus use a custom toolset string, otherwise the default
toolset string will be generated as it was before.
Note also the Visual Studio 2017 aims to be compatible with Visual
Studio 2015 on the CRT level, so binaries built with 2017 should
work without problems with the binaries built with 2015.
We can't pass the same string to two different snapshot states since
removing one of them will free the passed string, so just create another
one for the second state.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
