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.
Clamping the anchor values as introduced in commit 9a5ffcd to fix bug
777176 breaks menu positioning.
By keeping the anchors rectangle size greater than zero, we end up
deducting some positive value from the original position, so there is no
need to clamp() actually, keeping the values positive is enough and
avoids the issue with menu positioning on the menubar.
An additional benefit is to make the code a lot simpler.
https://bugzilla.gnome.org/show_bug.cgi?id=778009
Since GtkTreeMenu became a private class only used by GtkComboBox, all
this test actually did was to show a ComboBox constructed with a custom
CellArea. Now that the latter is no longer possible, the test just shows
a handful of settings that do nothing. Just test GtkComboBox directly.
Currently hiding destroys the wl_surface and all related interfaces,
(including the gtk_surface1) so the next time the GdkWindow is mapped,
we don't bother to set the DBus properties. Toggle the check off so
it's actually issued again after the GdkWindow gets a gtk_surface1.
https://bugzilla.gnome.org/show_bug.cgi?id=773686
The new CSS border-spacing does what Grid::(row|column)_spacing and
Box::spacing already did, i.e. controlling the space added between child
widgets, so it’s not a replacement for Container::border-width.
Now that priv->area is guaranteed to be constructed by us, and not
passed in by a user, we can move it to the .ui file and stop manually
managing its lifetime altogether. And once the area is there, we can
move the menu there too (and stop pointlessly destroying/rebuilding it).
We already have cell_layout_is_sensitive() to get whether at least one
cell in a Layout is sensitive, which we need because CellLayout/View
do not implement foreach(). So, since we wrote that, we can use it to
check our CellArea too, instead of doing foreach with a custom callback.
It was looping over all items, not breaking out when it found the first
selectable one, and then selecting the _last_ selectable one (if any)
found. So, it did exactly the opposite of its name. This made me quite
baffled when opening a submenu with right-arrow put me at its last item.
Originally, the loop set to_select and broke if the current item was
selectable and not tear-off, meaning that it would correctly select the
first suitable item. However, when tear-off functionality was removed
in commit 4ed9452e90, so was the break.
combo_box_popdown() currently skips popping down our menu if it is NULL.
But the required call to this at end-of-life was in destroy(), by which
point dispose() already NULLed the menu, so Menu::popdown() would never
run, even if it should. Fix this by trying popdown() earlier in unmap().
Also, add a converse assurance that we don’t popup() while not mapped.
Even once we remove all the now-pointless NULL checks, destroy() was the
wrong place to call combo_box_popdown(), and unmap() is the right place.
gtk_init() removed its support for supporting arguments, so we ought to do
likewise for Windows, which actually defines items that call gtk_init()
the old way (and also get rid of argument support in those functions,
since the direction is to not support them).
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Commit fdc0c6426b removed the appears-as-
list style property, & hence the ability to put the ComboBox into list
mode – but it left behind a pile of hijinks that were only used in said
mode & so were now doing absolutely nothing. This commit deletes those.
While doing that, I got carried away…so this also stops pointlessly type
checking popup_widget, as that can never be anything but a GtkTreeMenu.
It still checks for NULL everywhere, which shouldn’t be needed, but (A)
this commit is already too big, & (B) simply removing such checks where
they _seem_ unnecessary causes bad times. I’ll puzzle through that later
Commit fdc0c6426b for removing (partly!)
appears-as-list also deleted the code that propagated wrap-width to the
TreeMenu and thus put us into “grid mode”. This restores that code.
And as Benjamin noted, calling check_appearance() here is wrong, so bye.
We want to simplify our initialization code and remove all commandline
argument handling from it. The first stop for this is to reduce the
number of gtk_init variants we have.
This is how windows are meant to be hidden as per the wayland
protocol, there's no need to destroy the xdg_surface and other
interfaces.
Also, rename gdk_wayland_window_hide_surface() to clear_surface(),
as that's what it does.
https://bugzilla.gnome.org/show_bug.cgi?id=773686
i.e. when wrap-width > 0. This was only being done for non-grid cases.
So, ComboBoxes in grid mode did not indicate their selection when popped
up and required users to keynav from ‘nothing’ (at the top-left) to the
item they wanted to select. By selecting the active item in advance, now
it’s highlighted & acts as the starting point for keynav around the grid
This previously only mentioned its effect on the displayed value, and
even after the previous commit, its rounding of the actual value upon
change still reads like too much of an afterthought. Worse, it wasn’t
mentioned at all in the doc for the @digits parameter. Change this to
emphasise rounding always occurs and the displayed value is secondary.
Whether it should is an open question, but for now, the documentation
should clearly indicate that currently rounding is only applied upon
changes to the value, not to the existing value when ::digits changes.
This is already clear in the doc for the underlying Range::round-digits.
https://bugzilla.gnome.org/show_bug.cgi?id=358970
The documents state that gtk_scale_set_digits() “causes the value of the
adjustment to be rounded off to this number of digits, so the retrieved
value matches the value the user saw.” Note the lack of any condition.
But in fact, if draw-value was false, rounding was disabled on the base
Range, so values that weren’t displayed weren’t rounded. This made the
docs wrong and made an apparently cosmetic detail alter functionality.
Fix by ensuring the number of digits set on Scale is always propagated
along to gtk_range_set_round_digits(), thus rounding to it in all cases
when the value changes, regardless of whether the value is displayed.
This doesn’t address the other idea from Bugzilla: that changing the
number of digits should clamp the _existing_ value if it’s more precise.
This contradicts digits docs in the base Range, but the above from Scale
can be read as implying it’ll happen. For now, that’s an open question.
https://bugzilla.gnome.org/show_bug.cgi?id=358970
GtkFileChooserButton installs a handler for the popped-up signal, which
refilters the menu, in order to hide the “(None)” item from the popup
if it was previously selected in the ComboBox. This oddity means that:
• Until recently, this item would be selected in the menu shell, which
would then be popped up and change the selection away from that item.
This was therefore redundant (more on which below!) but benign.
• After the patch for https://bugzilla.gnome.org/show_bug.cgi?id=771242
however, this causes a critical assertion fail, as now we stash the
originally selected item in a pointer so that it can be selected only
after realisation/popup – but by that stage, the model has just been
refiltered and the previous pointer no longer refers to a valid item.
This commit works around this problem by, after popping up the menu,
getting the active item again, in case a popped-up handler has gone and
invalidated the pointer to the active item that we saved before popup.
If a handler does this, everything done to find/use the original item is
pointless. But this avoids the ugly critical in FileChooserButton, while
not harming every other ComboBox that doesn’t mess with its model while
popping up (hopefully the vast majority), and it’s very difficult to
imagine a way to check if the active item is /going to/ be hidden later)
Previously, for compatibility with GTK 3.0, we allowed specifying
numbers without units and interpreted them as pixels, even when the CSS
specification didn't.
Remove that now that we can break API.
This reverts commit 4875c689a0.
This was a thinko. Writable is not actually settable from the
application side, but only for the user, from the backend side.
Elsewhere we already go through the keymap to get modifiers so we
should do the same here. In fact, this was relying on xkb modifier
mask values being bitwise compatible with GdkModifierType which isn't
necessarily true.
https://bugzilla.gnome.org/show_bug.cgi?id=770112
Gtk+ treats MOD1 as a synonym for Alt, and does not expect it to be
mapped around, so we should avoid adding GDK_META_MASK if MOD1 is
already included to avoid confusing gtk+ and applications that rely on
that behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=770112
When a subsurface is used as a parent of a popup, GDK needs to traverse
up to the transient-for as the next parent, to properly find the parent
used by the popup positioner. This is because the parent of a popup
must always either be an xdg_popup or an xdg_surface, but traversing
the "parent" (in GDK terms) upwards from a subsurface will end up on
the fake root window before we hit the actual parent (in Wayland terms).
https://bugzilla.gnome.org/show_bug.cgi?id=776225
Instead of having 3 different shaders for the different clipping
versions, just have one shader and use a preprocessor define to use
different clip functions.
That preprocessor define is set in the Makefile.
Also use foo.frag and foo.vert as the file extensions instead of using
foo.frag.glsl and foo.vert.glsl, as that's what glslc suggests as
extension.
That way we don't need to move the clip rounded rect manually through
the vertex shader into the fragment shader but can just look at the push
constants.
Simplifies shaders a lot.
Passing a rectangle with zero width or height to xdg_shell-v6
set_anchor_rect() will cause a protocol error and terminate the client,
as with gedit when pressing the Win key.
Reason for this is because the rectangle used to set the anchor comes
from gtk_text_layout_get_iter_location() which uses the pango layout
width/height, which can be empty if there is not character at the given
location.
Make sure we don't use 0 as width or height as an anchor rectangle to
avoid the protocol error, and compensate the logical position of the
given rectangle if the size is changed, so that the actual position
remains as expected by the client.
https://bugzilla.gnome.org/show_bug.cgi?id=777176
Images with just an aspect ratio, but without a size, should be scaled
to be fully visible in the given area.
But we scaled them to completely cover the given area, which made them
partially invisible.
Reftest included.
gtk_snapshot_pop() => removed
gtk_snapshot_pop_and_append() => gtk_snapshot_pop()
So now there is no way to get a rendernode out of the snapshotting API
until you gtk_snapshot_finish().
... and use it.
The function is a bit awkward because it requires 2 calls to
gtk_snapshot_pop(), but once you accept that, it's very convenient to
use, as can be seen by the 2 implementations.
This is a free-form tab that can contain information about the
system environment. To see it, set GtkAboutDialog::system-information
to a non-NULL value.
https://bugzilla.gnome.org/show_bug.cgi?id=776604
The Mesa Vulkan drivers need XInitThreads() being called, because their
implementation has to use threads.
And I don't want to make the call depend on if Vulkan is compiled in
because that makes GTK's X11 behavior depend on compile-time flags, so
it's always called.
This way, we ensure that files that are built during make always get
properly listed. And we ensure that creating the resources actually
depends on them.
We already take ints when setting the translation, so it can't
currently take any other values. Additionally, I was seeing large
costs in int -> double -> int for the rects in
gtk_snapshot_clips_rect(), as all callers really are ints (widget
allocations) and the clip region is int-based.
This change completely cleared a 2% rectangle_init_from_graphene from
the profile and is likely to have nice performance effects elsewhere
too.
The width/height/aspect getters are called a lot, and almost all
callers already verify it from _gtk_css_image_get_concrete_size (),
so just skip these checks.
This means we allocate the collect data with the state, avoiding
an extra allocation. Also, a union means every state object
is the same size and we could reuse the state objects.
This was showing up quite high on the profiles, and there is
no real reason for copy to normalize, as the source is a
GskRoundedRect which should be normalized already unless
you did something very strange (and then you should have normalized
manually).
Simgle image cross-fade opacity was computed the wrong way, which caused
weird fade-in/out animations, for example in flat buttons.
I messed this up when porting cross-fades to snapshot().
Since the demise of theme engines, we can no longer hit
the case of id >= GTK_CSS_PROPERTY_N_PROPERTIES. So don't
check for this in a very frequently called function.
Using an image() fallback from svg to png doesn't make too
much sense, since the svg is always used (unless librsvg is
not present), while the png icon is faster and cheaper to
load and thus preferable.
Also, "ie" wasn't very clear, but fixing that to "i.e." would cause
truncation of the summary when processed by bindings using doxygen. So,
I replaced it with "in other words", which is no _less_ clear, at least.
It was suggested that the project files to be moved to win32/, so that we can
have one less layer of directories we need to go down into to reach the project files.
Tell people about what happens when generating projects when Visual
Studio 2013 or later is required, and mention that the .headers are
only needed when headers need to be copied.
So we can set the css name of a widget to something that's not related
to the class name. If the css-name property is set to NULL, we will
still fall back to the one set using gtk_widget_class_set_css_name which
is alwasys non-NULL since GtkWidget itself sets it to "widget".
Instead of relying on --generate-dependencies and the resource file,
actually list the resources in Make variables.
Fixes make not building new shaders because they're not inside the
resource file.
See the implementation of gtk_entry_create_layout():
pango_attr_list_splice() is used to add the PangoAttrList of the preedit
string. And that is done *after* applying the PangoAttrList of the
"attributes" property.
https://bugzilla.gnome.org/show_bug.cgi?id=776868
We now have GTK_CSS_AFFECTS_CONTENT for properties that have an effect
on content rendering.
Using GTK_CSS_AFFECTS_ICON is wrong for icon-transform and icon-filter
as they don't change the icon, just how the icon is rendered, so we use
GTK_CSS_AFFECTS_CONTENT for those.
We also introduce GTK_CSS_AFFECTS_POSTEFFECT for opacity and filter -
properties that affect the whole drawing of the widget by applying an
effect after everything is said and done.
...which treats the first '.' in doc comments as the end of the summary.
So, e.g., in gtkmm, get_kinetic_scrolling() is currently summarised as
"Changes the behaviour of @scrolled_window wrt." Not very informative!
No need for a period there & anyway, the phrase "wrt to" is superfluous,
and we have space to actually say "with regard to", so just do that now.
Instead of
-gtk-icon-effect: dim;
-gtk-icon-effect: hilight;
we now use
-gtk-icon-filter: opacity(0.5);
-gtk-icon-filter: brightness(1.2);
respectively.
This node essentially implements the feColorMatrix SVG filter. I got the
idea yesterday after looking at the opacity implementation.
It can be used for opacity (not sure if we want to) and to implement a
bunch of the CSS filters.
Since the status of the GDK broadway backend is more or less unsupported,
drop the projects that build gtk4-broadwayd and gdk-broadway, and update
the projects to not to refer to them.
However, keep the Broadway configs for now as we will later transform
them to become configs for Vulkan, so bascially besides "installation"
parts and output settings, they will do the same as their Release|Debug
counterparts with no support for Broadway.
...but disable them for now. Configs will be added for the projects to
support Vulkan-enabled builds which will then enable the builds of these
sources. Extra commands and items will be needed for the GSK resources
along with ensuring GSK_RENDERER_GSK being defined for the build of GDK,
GDK-Win32 and GSK so that the builds of Vulkan-enabled builds can be done
properly.
Filter out the Vulkan sources from the 'dist hook' rules in
gsk/Makefile.am as we don't want to in turn include them twice in the
projects when the 'make dist' is performed on a system with Vulkan
builds enabled.
If the signal handler ends up changing the label text,
the link is no longer around to update the css node.
Check for this possibility to avoid a crash here.
One cannot use #if...#endif within macro calls in Visual Studio and
possibly other compilers, and there are more uses of VLAs that need to be
replaced with g_newa().
There were also checks for the clip type in gskvulkanrenderpass.c which
were possibly not done right (using the address of the type value to check
for a type value), which triggered errors as one is attempting to compare
a pointer type to an enum/int type.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
This adds support to the GDK Win32 backend so that we can support Vulkan
context creation for use in the GSK Vulkan renderer, so that we can test
it on Windows platforms as well.
https://bugzilla.gnome.org/show_bug.cgi?id=776544
Use g_newa() instead of VLAs, as VLAs may never be supported by some
compilers as it became optional in C11 and there are concerns about their
implementations in compilers that do support it.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Forces a full redraw every frame.
This is done generically, so it's supported on every renderer.
For widget-factory first page (with the spinner spinning and progressbar
pulsing), I get these numbers per frame:
action clipped full redraw
snapshot 0ms 7-10ms
cairo rendering 0ms 10-15ms
Vulkan rendering 3-5ms 18-20ms
Vulkan expected * 0ms 1-2ms
GL rendering unsupported 55-62ms
* expected means disabling rendering of unsupported render nodes,
instead of doing fallback drawing. So it overestimates the performance,
because borders and box-shadows are disabled.
It's faster to render once for every rectangle in the clip region than
rendering the outline of the clip region.
Especially because this reduces the time necessary to build up the frame
data.
In widget-factory (where we have 3 rectangles), this leads to a 5x
speedup in the rendering time rendering alone.
Snapshotting time goes from 10ms to ~1ms, which is another huge
improvement.
Note: We interpolate premultiplied colors as per the CSS spec. This i
different from Cairo, which interpolates unpremultiplied.
So in testcases with translucent gradients, it's actually Cairo that is
wrong.
Homogeneous branches repeated the calculation/assignment of the initial
space available to children. This avoids that by shuffling some code.
Perhaps more importantly, in doing that, I ended up with some ambiguous
names, and Company and I realised how vague the pre-existing naming was.
"size" becomes "extra_space", as this is what it represents. Conversely,
"extra" becomes "size_given_to_child" (albeit still given out in two
different ways depending on whether the Box is homogeneous). My hope is
that these sections of code are now somewhat less baffling than before!
This is now tracking the clips added by the clip nodes.
If any particular node can't deal with a clip, it falls back to Cairo
rendering. But if it can, it will render it directly.
Now that every call to GtkCellArea is a snapshot call and no more cairo
calls are left, move the actual differentiation between Cairo and
Snapshot down to the cell renderer.
Little tool that creates a bunch of test files to throw add the
rendernode binary.
They should really be part of a testsuite, but we have none, so OI just
put them here.
Only keep the version that calls gsk_render_node_draw() if people
specify the --fallback option.
The actual renderer selection works just as for regular GTK. The easiest
way to influence it is setting the GSK_RENDERER environment variable.
... and implement it for the Cairo renderer.
It's an API that instructs a renderer to render to a texture.
So far this is mostly meant to be used for testing, but I could imagine
it being useful for rendering DND icons.
That code doesn't do anything.
And what the code should be doing (clearing the abckground) isn't
necessary as cairo drawing is guaranteed to clear the surface.
This does a conversion to/from GBytes and is intended for writing tests.
It's really crude but it works.
And that probably means Alex will (ab)use it for broadway.
I had originally thought I'd use GskShadow for box-shadow, but didn't in
the end.
So now it's only used for text-shadow and icon-shadow, and those don't
have a spread.
VLAs are not supported by Visual Studio and possibly other compilers that
are supported by GTK+-3.90+, and probably never will be, although it is a
C99 specification, and it became optional for C11. It is also not a part
of the newer compiler requirements that are listed out for GTK+-3.90.x.
There exist concerns about the implementation of VLAs in compilers that
support them as well, so change it to a g_newa() approach.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Instead of a separate allocation for any arrays in the render node
we allocate these as part of the render node itself, using C99
flexible arrays.
This leads to less allocations, which is nice, but the major reason
for this is that it allows us to change the allocation scheme further
in the future. For instance, we want to do stack-like allocation so
that all the render-nodes for an entire frame are allocated in one
(or a few) chunks.
Instead of constantly recalculating this (especially recursively for
parents!) we do it only on construction, because everything is
immutable anyway. Also, most nodes had a bounds already and can
use the new parent member instead.
We also do direct access to the node bounds rather than calling
gsk_render_node_get_bounds in various places, which means
we do less copying.
This causes the snapshotting algorithm to dump all widget nodes into
their own container node. We then name that group accordingly (ie
"GtkSwitch<0xdeadbeef>") so you can easily see which node belongs where.
The feature is toggleable in the inspector's visual tab.
There's a few problems with it, becuse GtkSnapshot optimized container
nodes away if they are not needed, so we are losing some widgets...
When the first/last color stop is not at 0%/100%, we need to start the
repeating at their offsets and not at 0%/100%.
Attached reftest demonstrates the problem.
Instead of making people intiialize a rectangle and then applying border
radius manually, provide a constructor that does it for them.
While doing that, also allow people to instead request the padding box
or the content box.
Refactor all relevant code to use this new constructor.
... and make the icon rendering code use it.
This requires moving even more shadow renering code into GSK, but so be
it. At least the "shadows not implemented" warning is now gone!
The node draws a solid CSS border, which can be used to cover everything
but dashed and dotted borders (double, groove, inset, ...).
For different border styles, we overlay multiple nodes and set their
colors to transparent for sides with non-matching styles.
This way we can pass the command pool around.
And that allows us to allocate and submitcustom buffers.
And that is necessary to make staging images work.
It turns out, some simple getters - such as
gdk_drawing_context_get_clip() - love copying things before returning
them.
I guess somebody has to burn cycles...
When the background-clip of the background is smaller than the
background-clip of blended images, not pushing a group is wrong.
Test testing exactly that included.
This uses the new push()/pop() mechanism to its fullest extent when
implementing transitions. It's fun to inspect the results in the
inspector.
Crossfades don't work yet, they continue using a Cairo fallback.
A side effect of the stack conversion is that widget-factory now uses
snapshots for a lot more things.
It is now possible to call push() subfunctions for simple container
nodes with just a single child. So you can for example
gtk_snapshot_push_clip() a clip region that all the nodes that get
appended later will then obey.
gtk_snapshot_pop() will then not return a container node, but a clip
node containing the container node (and similar for the transform
example).
This is implemented internally by providing a "collect function" when
pushing that is called when popping to collects all the accumulated
nodes and combine them into the single node that gets returned.
To simplify things even more, gtk_snapshot_pop_and_append() has been
added, which pops the currently pushed node and appends it to the
parent.
The icon rendering code has been converted to this approach.
This code makes renderers fall back to Cairo rendering if they don't
know how to handle a render node's type.
This allows adding new render nodes with impunity.
Instead of appending a container node and adding the nodes to it as they
come in, we now collect the nodes until gtk_snapshot_pop() is called and
then hand them out in a container node.
The caller of gtk_snapshot_push() is then responsible for doing whatever
he wants with the created node.
Another addigion is the keep_coordinates flag to gtk_snapshot_push()
which allows callers to keep the current offset and clip region or
discard it. Discarding is useful when doing transforms, keeping it is
useful when inserting effect nodes (like the ones I'm about to add).
Instead of having a setter for the transform, have a GskTransformNode.
Most of the oprations that GTK does do not require a transform, so it
doesn't make sense to have it as a primary attribute.
Also, changing the transform requires updating the uniforms of the GL
renderer, so we're happy if we can avoid that.
I'm about to move children handling to the container node, which means
the generic code can no longer assume children APIs existing.
So rewrite the treemodel to work without it.
gsk_render_node_get_bounds() still exists and is computed via vfunc
call:
- containers dynamically compute the bounds from their children
- surface and texture nodes get bounds passed on construction
In the brave new world of refactored render nodes, this function doesn't
really make any sense anymore. We could turn it into a vfunc, but I
don't think it's useful.
Especially because even in the brave old world, this function was
causing a vastl overallocation of nodes when the GL renderer needed render
targets.
If we ever feel, we need this function again, we can readd it later.
But nobody is using it other than for overriding opactiy. And you can
just override opacity directly if you care.
Creating render nodes is fire-and-forget, so all one should do is create
a container, append, append, append and then send it off to the
renderer. So there's no need to replace, insert between or anything
else.
We want to split nodes into containers and nodes that do actual drawing.
So pushing nodes that do drawing is exactly the wrong thing.
Also fix up GtkPopover. There's no need for it to push anything.
When we generate the Visual Studio 2013 projects, we need to remove the
*.vs12.sourcefiles and *.vs12.sourcefile.filters that are generated during
the process, so that 'make distcheck' won't complain about leftover files.
When running uninstalled tests with GtkApplication on an autobuilder with
a fake session bus, warnings will cause the tests to abort. The GNOME
session manager, the Xfce session manager, and the Inhibit portal are all
not needed for normal operation of GTK, so we should not log warnings if
they are not found.
As well as not being present on a fake session bus, it's also not
expected that they'll be present on all platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=774784
... with gtk_list_box_get_row_at_y. It would be nice to avoid the
'find' versus 'get' discrepancy since we are planning to expose it as
public API.
https://bugzilla.gnome.org/show_bug.cgi?id=776187
Fix the build after the branch wip/alexl/simplify-gdkwindow was merged, as
there are some changes that broke things in the Windows backend, namely:
-gdk_win32_input_shape_combine_region() should not be removed at this
point (though it is a stub--otherwise GDK/Win32 will crash)
-Some more code need to be removed due to the removal of items in the
above-mentioned merged branch
Also, like the X11 backend, do not allow the creation of native child
windows, and stop checking for subsequent child windows
(GDK_WINDOW_CHILD), so that we can clean things up a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
It does weird clipping that
(a) nobody likes
(b) is hard to support in the new rendering world.
So we take the easy way out.
The actual frame is now drawn by the frame node around the label.
GtkCellView has a gadget, so peopl can do all their shenanigans with
CSS.
And the original use case (overriding the background so that the
cellview's GdkWindow shares the background color of the combobox) is
outdated since we have transparent backgrounds.
We're not currently using this, and dropping it allows us to loose
a bunch of code which leads us towards the goal of having GdkWindow
only for toplevels (and reparenting makes not sense for toplevels).
We can't really support these on e.g. wayland anyway, and we're trying
to get rid of subwindow at totally in the long term, so lets drop this.
It allows us to drop a lot of complexity.
For subsurfaces, the new state which includes the input shape is not
applied by the compositor if the subsurface is in effective synchronous
mode.
So we need to apply the input shape once parent surface is in effective
desynchronized mode, which is when it's committed, otherwise the input
shape may never be applied if the widget is not using being_paint() /
end_paint() to draw on its subsurface, like clutter does.
We do that only for empty input shape as those won't need update when
the subsurface is resized, for all other non-empty input shape, the
client still has to use begin_paint()/end_paint() for the input shape to
be applied.
https://bugzilla.gnome.org/show_bug.cgi?id=774534
It's using a GtkCssPositionValue, even though that name is wrong. But
the functionality of managing 2 lengths is exactly what we want.
Nobody is using this yet.
- Recognize "gl" as well as "opengl" for the GL renderer
- GSK_RENDERER=help now works
- g_warning() for an unrecognized renderer (typo detection!)
- g_print() the actual renderer that is used (and error messages when
selecting) when a GSK_RENDERER is given, so you'll notice if your
renderer isn't taken.
Previously, code would work fine with --disable-vulkan if the Vulkan
headers were installed - code would happily just use them as they're
installed in /usr/include.
By creating unlimited render objects, we would never wait on the GPU.
This would mean that if the GPU was the bottleneck, we would fill its
queue with render commands faster than it could process them.
And because the nvidia binary driver and my code work surprisingly well
and bugfree, this lead to exhaustion of RAM. I had 50GB of swap
configured and my hard disk was quicker as swap storage than my GPU was
at processing the commands, so stuff still filled up.
At that point my computer became rather unresponsive and I decided to
reboot it, so I that could write this patch.
Add SURFACE and TEXTURE operations. This way, we actually render more
than one node every frame because not everything is a fallback node
anymore that gets composited with its children into a cairo surface.
Instead of pushing the root matrix, push the world matrix for the
current node. That way, the bounds we emit as vertices are actually
properly transformed.
First, we collect all the info about descriptor sets into a hash table,
then we use its size to determine the amount of sets and allocate those
before we finally go ahead and use the hash table's contents to
initialize the descriptor sets.
And then we're ready to render.
We can let the GPU do its stuff without waiting. The GPU knows what it's
doing.
Which means we now get a lot of time to spend on doing CPU things (read:
we're way better in benchmarks).
The old behavior is safer, so we want to keep it around for debugging.
It can be reenabled with GSK_RENDERING_MODE=sync.
And move the actual rendering code there.
A RenderPass is a collection of operations on the same target that
get executed one after another. It roughly targets VkRenderPass or
rather the subpasses of a VkRenderPass.
For now, only the infrastructure is there. No real stuff is happening.
This is refactoring work.
GskVulkanRender is supposed to be the global object for a render
operation, ie GskVulkanRenderer.render() will create this object for
what it does.
The object will be split into stages that perform the operations
necessary to create a drawing.
Instead of using a staging iamge, we require the final image to be
linearly allocated and have host-visible memory.
This improves performance quite a bit.
The old code is still there and can be enabled with a simple change
to a #define in gskvulkanimage.h
Instead, complain if somebody calls gdk_x11_window_get_xid() on a
non-native window.
We cannot make random windows native anymore because there's no GSK
renderer associated with them, so we cannot draw them.
We can now upload vertices.
And we use this to draw a yellow background. Which is clearly superior
to not drawing anything.
Also, we have shaders now. If you modify them, you need glslc installed
so they can be recompiled into Spir-V bytecode.
1. Output Vulkan status in summary
2. Add missing "test" call
3. Check for glslc
The glslc check will be necessary later for the code that automatically
compiles the Vulkan glsl source to Spir-V.
Nothing happens if glslc is not available - unless you modify the glsl.
gdk_window_create_vulkan_context() now exists and will return a Vulkan
context for the given window. It even initializes the surface. But it
doesn't do anything useful yet.
Adds the gdk_display_ref_vulkan() and gdk_display_unref_vulkan()
functions which setup/tear down VUlkan support for the display.
Nothing is using those functions yet.
These only exist for the window dragging which does not exist anymore
currently. It will be reintroduced later in a form that does not require
these handlers.
I read the code as if (use_gl) instead of if (!use_gl) and commented it
out in bddfd7bb41. That broke drawing on
Wayland without OpenGL completely.
Whoops.
Now it's back.
There were some parts that need some updates after the refactoring in
GDKGL, so that the code will continue to build and run.
For gdkwindow-win32.c, comment out the parts where we check for use_gl
(which was removed), since we are going to move all drawing to OpenGL,
but don't remove/disable the whole portion as that transition is not
complete at this point.
There a is new GDKGL function that checks for the damaged area of the back
buffer, but since the notion of "damage" is for *NIX (GLX/EGL for
Wayland/mir), meaning that there is no such extension for Windows in this
regard, so we can't support this on Windows as-is, at least for now.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
This is a way to query the damaged area of the backbuffer.
The GL renderer uses this to compute the extents of that damage region
(computed via buffer age) and use them to minimize the area to redraw.
This changes the semantics of GL rendering to "When calling
gdk_window_begin_frame() with a GL context, the area by
gdk_gl_context_get_damage() needs to be redrawn and every other pixel of
the backbuffer is guaranteed to be correct.
After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer
must be correct.
We can always glXBufferSwap() now because of this.
... instead of a gl context.
This requires some refactoring in the way we mark the shared context as
drawing: We now call begin_frame/end_frame() on it and ignore the call
on the main context.
Unfortunately we need to do this check in all vfuncs, which sucks. But I
haven't found a better way.
That way we can capture both the actual changes (clip region) and the
area that was redrawn (render region), which in OpenGL might not be
identical.
Nothing shows the render region yet though...
Reenable GL drawing, but do it without Cairo.
Now, the context passed to gdk_window_begin_draw_frame() decides how
drawing is going to happen. If it is NULL, Cairo is used like before.
If a context is passed, Cairo may not be used for drawing and
gdk_drawing_context_get_cairo_context() is going to return NULL.
Instead, the GL renderer must draw to the GL backbuffer and
end_draw_frame() is then swapping that to the front.
The GskGLRenderer has lost the texture it used to render to and adapted
to render directly to the backbuffer instead.
The only thing missing is for GtkGLArea to gain back a performant way to
render. But it didn't have one since the introduction of GSK, this
patchset doesn't change anything about it.
The new rendering avoids two indirections (the GSK renderer's texture
and the GDK double buffering surface).
It improves icon count in the fishbowl demo by 30%.
This way, we can query the GL context's state via
gdk_gl_context_is_drawing().
Use this function to make GL contexts as attached and grant them access
to the front/backbuffer for rendering.
All of this is still unused because GL drawing is still disabled.
No visible changes as GL rendering is disabled at the moment.
What was done:
1. Move window->invalidate_for_new_frame to glcontext->begin_frame
This moves the code to where it is used (the GLContext) and prepares it
for being called where it is used when actually beginning to draw the
frame.
2. Get rid of buffer-age usage
We want to let the application render directly to the backbuffer.
Because of that, we cannot make any assumptions about the contents the
application renders outside the clip area.
In particular GskGLRenderer renders random stuff there but not actual
contents.
3. Pass the actual GL context
Previously, we passed the shared context to end_frame, now we pass the
actual GL context that the application uses for rendering. This is so
that the vfuncs could prepare the actual contexts for rendering (they
don't currently).
4. Simplify the code
The previous code set up the final drawing method in begin_frame.
Instead, we now just ensure the clip area is something we can render
and decide on the actual method in end_frame.
This is both more robust (we can change the clip area in between if we
want to) and less code.
This is a temporary switch-off of the GL dawing code that will make
things keep running. All GL related code (like the GSK renderer or
GtkGLArea will now fall back to software.
Wayland subsurfaces can have other native window parents, but those need
to be destroyed along with the rest of the window hierarchy otherwise
an assert() is reached.
https://bugzilla.gnome.org/show_bug.cgi?id=774915
GtkListBox is not a windowed widget anymore so we can't use
gtk_widget_get_window. Just directly access priv->view_window instead to
get the right window.
For a menu mode CB with wrap_width == 0 and an active item, that item is
selected in gtk_combo_box_menu_popup. Selection causes the MenuShell to
activate and hence take a grab. This was done before the menu was popped
up. A patch distributed in Debian sid - after being proposed on our BZ -
revealed that on the 1st popup of any such ComboBox, within grab_add,
the MenuShell's toplevel's GdkWindow is NULL. This causes a Gdk-CRITICAL
assertion fail on the 1st time opening any such CB, on Debian and if
that patch were merged to GTK+. By selecting after popup, we ensure the
MenuShell is realised before its grab_add and so avoid the critical.
https://bugzilla.gnome.org/show_bug.cgi?id=771242
This way, we don't spam criticals when GL is not available. Instead, we
print a useful debug message to stderr and continue with the Cairo renderer.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
and remove gsk_renderer_get_for_display().
This new function returns a realized renderer. Because of that, GSK can
catch failures to realize, destroy the renderer and try another one.
Or in short: I can finally use GTK on Weston with the nvidia binary
drivers again.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Instead of having a gsk_renderer_set_window() call, pass the window to
realize(). This way, the realization can fail with the wrong window.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
gdk_window_get_toplevel() walks up the windows tree looking for the
corresponding toplevel window, but needs to account for subsurfaces as
well on Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=775319
We were producing org.symbolic.png from org.gnome.Recipes-symbolic.svg,
which is not useful. Look for the last dot in the original name, to
produce the expected org.gnome.Recipes-symbolic.symbolic.png instead.
gskrenderer.c includes gdk/wayland/gdkwayland.h and as a consequence
we need to be able to locate wayland's headers in case they are not
in standard location.
https://bugzilla.gnome.org/show_bug.cgi?id=775038
Now that subsurfaces can be created as child of another GdkWindow (and
not just the root window), they must be placed according to the location
of their parent, i.e. the abs_x/abs_y must be updated and taken int
account when placing and moving subsurfaces under Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=774917
Since at-spi-atk commit 96621a5e95 fixed PropertyChange notifications
for AccessibleParent, setting the parent will result in a call to
ref_state_set() which assumes that the object is fully initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=774939
While GtkEventController implementations today are all GtkGesture, it is
possible to create a GtkEventController manually. This is an extrac check
to ensure we only add gestures to the list.
https://bugzilla.gnome.org/show_bug.cgi?id=774760
We need to unrealize the children manually for that to happen, but so it
goes.
The order is necessary because we want the renderer to still be alive
while children are unrealizing.
Only attempt to initialize Wintab after the display manager announces
that the first default display has been set. Fixes a segfault during
initialization of specific tablet drivers' wintab32.dlls. Add assertions
and verbose comments explaining this nonsense because this stuff is a
pain to have to keep fixing.
https://bugzilla.gnome.org/show_bug.cgi?id=774379
Move the orientation sanity-checks into the packet decode func.
Rationale: the packet handling func may otherwise read beyond the end of
device->last_axis_data.
Also expand them to cope with my test Huion's weird reporting.
Also correct the azimuth angle to align with GDK's presentation.
Most importantly, fix annoying comment typo.
https://bugzilla.gnome.org/show_bug.cgi?id=774265
We no longer have GtkPlug nor GtkWin32EmbedManifest for GTK+-4.x, and it
is not entirely clear at this point what would be the "best" replacement
for them, but this issue here prevents GTK+-3.89.x building on Windows.
As a result, this is a fast port to avoid using APIs that have been
removed for 4.x, and things seem to work properly (the print.c page
printed).
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Fix a regression introduced in 4ce6d10601
which causes devices with an odd-numbered zero-based index in the list
to be passed over incorrectly. This might present as yet another "device
does not send pressure" bug for ~50% of devices out there.
This commit also closes off another potential segfault for wintab_devices
lists which have an odd length.
https://bugzilla.gnome.org/show_bug.cgi?id=774699
When checking if a rectangle is contained by the rounded box, the code
will refuse a rectangle which is the exact size as the one backing the
rounded box, since it checks for greater or equal width and height.
Check for greater only instead.
https://bugzilla.gnome.org/show_bug.cgi?id=774114
The functions gdk_pixbuf_get_from_window() and
gdk_cairo_set_source_window() are unreliable and depend on the windowing
system (they work great on X11 and Win32, less so on Quartz and Wayland).
With the switch to new drawing API and OpenGL, we can definitely no
longer support a generic way to snapshot windows.
People should either write windowsystem-specific code or draw their
widgets directly - like with gtk_widget_draw() - if they need to get a
rendering.
The tests read a nonexisting colorprofile, try to convert stuff read
from the window into it, do things that gdk-pixbuf should test and
then aren't even integrated into the testuite.
Sheesh.
- Make the rows larger
- Display the elapsed time between renderings
- Display if it was a full or a partial redraw
- Add a toggle button to display profiler info
Empty doc comments make gtk-doc complain about undocumented
functions, even though these functions are not supposed to
be documented in the first place.
Under Wayland, a subsurface can have another surface as parent, but
gdk would not allow native windows if the parent is not the root window.
Allow native subsurface for all parent under Wayland, not just for the
root window.
https://bugzilla.gnome.org/show_bug.cgi?id=774475
This can be triggered on workspace switches, and on hidpi results in
the scale factor being reset to 1 while the window is not in the
current workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=774476
Just to avoid having to do NULL checks when calling
widget_class->snapshot. We were crashing with drawing areas who don't
have a draw or a snapshot vfunc (woot!).
We need so subtract the allocation from the clip to get the clip offset,
not the other way around.
This was screwing in particular with marks on GtkScale, because GtkScale
mark clip computation is broken and always returns (0,0) which makes
scales have a waaaaay too large clip.
But that's another bug.
And use this to cull widgets and gadgets that are completely outside the
clip region.
A potential optimization is to apply this clip region to cairo contexts
created with gtk_snapshot_append_cairo_node(), but for that we'd need to
apply the inverse matrix to the clip region, and that causes rounding
errors.
Plus, I hope that cairo drawing becomes exceedingly rare so it won't be
used for the whole widget factory like today (which might also explain
why no culling happens in the widget factory outside the header bar.
The equivalent to cairo_matrix_multiply (a, b, c) is
graphene_matrix_multiply (c, b, a).
graphene_matrix_multiply (a, b, c) may not be called with b and c being
the same matrix.
Grips have long been unused in GTK, so remove all support for them.
This removes the GTK_STYLE_CLASS_GRIP and the special
gtk_render_handle() code for drawing those grips.
This allows renderers (or anyone really) to attach "render data" to
textures. Only the first render data sticks.
You can gsk_texture_set_render_data() with the key you will use to
look the data up again, and if no data has been set yet, yours will be
set.
You can retrieve this data via gsk_texture_get_render_data() later on.
If your data has been cleared, NULL will be returned.
When gsk_texture_clear_render_data() is called (which the texture will
call when it is finalized), your destory notify will be called and you
have to release your render data.
The GL driver uses this to attach texture ids to GskTextures.
We do no longer bind textures to a renderer, instead they are a way for
applications to provide texture data.
For now, that's it. We've reverted to uploading it from scratch every
frame.
The snapshot vfuncs must only append at most a single node,
otherwise things are going to break if the widget is the root node.
Unfortunately there is no code that can check this in a generic fashion,
so we'll have to debug this on a case-by-case basis.
This happens in regular code paths for example when trying to render the
empty text string. We don't want to store a surface on the render
node in such a case (so actual rendering isn't slowed down), but we do
want to return a working cairo context that is not in an error state
(so the cairo rendering can continue without error messages).
We want to unrealize the renderer only after all widgets have been
unrealized. Otherwise, the widgets cannot release rendering resources
like textures.
Note that this implementation does not respect GDK windows at all. If
your widget requires respecting them, you should write your own
snapshot implementation and not chain up.
We now look at which of get_render_mode, draw or snapshot vfuncs is the
latest to have been overwritten in the class tree and then use that one.
This allows GtkContainerClass and GtkBinClass to override all of them
for without screwing things up.
and gtk_snapshot_render_frame() to be direct replacements for the
old gtk_render_*() functions.
Use them to replace Cairo usage completely in gtk_window_snapshot().
We now try to emulate cairo_t:
We keep a stack of nodes via push/pop and a transform matrix.
So whenever a new node is added to the snapshot, we transform it
by the current transform matrix and append it to the current node.
Unlike other container widgets, GtkStack would allocate its children
prior to moving its windows, which might prevent further valid size
allocation signals to be emitted.
Re-order the size allocation of child widgets to be performed after
moving the GtkStack windows.
Thanks to Owen for spotting the real issue here.
https://bugzilla.gnome.org/show_bug.cgi?id=767713
As in the last commit on gdkdisplay-win32.c, we need to define that to be
0x0600 (Vista) or later so that the items needed in the Windows headers be
activated.
See: https://bugzilla.gnome.org/show_bug.cgi?id=768081#c62
... to be for Vista (0x0600) or later. This is so that the necessary
items in the Windows headers be activated so that the code will build
properly on mingw-w64, and we already require Vista or later for GTK+.
Thanks Ting-Wei Lan for pointing this out.
See: https://bugzilla.gnome.org/show_bug.cgi?id=768081#c62
This fixes a DOS where any app can cause all running gtk apps
to use arbitrary amounts of memory.
Originally reported against mate-panel, where running a big slideshow
in eye-of-mate caused increasing RAM usage in mate-panel.
v2: Hardcode the value
Signed-off-by: Lauri Kasanen <curaga@operamail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=773587
Making sure the surfaces are using the same scale factor makes it more
likely a fast path will be used when pixman gets involved, as pointed
out by Benjamin Otte.
https://bugzilla.gnome.org/show_bug.cgi?id=772075
We are currently truncating job names to 255 bytes, because that's the
maximum allowed length of job-name attribute in CUPS. This is a CUPS
limitation that GtkPrintOperation shouldn't need to know, and it
shouldn't affect other backends, that might have other limitations or
even no limitation at all. This has another side effect, that what you
set as GtkPrintOperation:job-name could be different to what you get if
the property is truncated, this is not documented in
gtk_print_operation_set_job_name(). So, I think the job name should be
truncated by the CUPS backend, right before setting the job-name
attribute.
https://bugzilla.gnome.org/show_bug.cgi?id=774097
The GApplication platform data may contain a startup ID that on X11
is used to set the startup notification ID when activated. Do the
same on the wayland backend to make startup notifications work for
DBus-activated applications where the DESKTOP_STARTUP_ID environment
variable is not set.
https://bugzilla.gnome.org/show_bug.cgi?id=768531
For wayland clients, the startup notification ID is currently only set
from the DESKTOP_STARTUP_ID environment variable. As that variable is
only set for clients launched via exec(), startup completion is not
indicated correctly for DBus-activated applications unless an explicit
ID is specified - usually that is not the case, as the default handling
uses gdk_notify_startup_complete().
To address this, we need API to set the startup notification ID from GTK
as we have on X11.
https://bugzilla.gnome.org/show_bug.cgi?id=768531
The spec says:
"If <shape> is omitted, the ending shape defaults to a circle if the <size>
is a single <length>, and to an ellipse otherwise."
Make it so.
It wasn’t clear that gtk_style_context_get[_valist]() behave like
g_object_get() — i.e. pointer-based types are returned newly-allocated.
Clarify that.
https://bugzilla.gnome.org/show_bug.cgi?id=773954
GtkLevelBar supports adding custom offsets as style classes, and they
are applied whenever the :value property matches. The current code,
however, only updates any CSS nodes when an offset is found, causing
it to not update when a discrete value changes but no custom offset
is added.
Fix that by always updating the CSS nodes.
https://bugzilla.gnome.org/show_bug.cgi?id=773799
This way we can recommend that applications use the
fullscreen_on_monitor() API on both X and Wayland otherwise they'd
have to keep a path for each backend to achieve this functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=773857
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
Now that GTK+ is built as a single DLL, and the .lib that is built is
gtk-4.lib, we need to update the autotools sections in generating the
NMake Makefile snippets so that we can have the correct commands and flags
for building the .gir files, which will all now link to gtk-4-vsXX.dll (or
so).
As with the autotools builds, use gtk-4 as the name of the .lib file that
is produced from the build.
Actually this is already done with GTK-3.x with the autotools builds,
but this update is not done there as gtk-3.0.lib/gdk-3.0.lib/gailutil-3.0.lib
was used for such a long time that changing it there might have caused
trouble for people there.
Update the project configs to build GDK/GSK as a static lib and include
them into the GTK+ DLL as a monolithic DLL, which is in line with what is
done in the autotools builds, since the code changes needed for Windows
builds for a monolithic build are now in place.
Now that the autotools build folded the GDK/GSK bits into the main GTK+
DLL, there are some updates that need to be done for this. We need to:
-Fold the DllMain() of GDK-Win32 into the main GTK+ DllMain(), as we need
the HINSTANCE to register the window. We can't have two DllMain()'s in a
single DLL.
-Remove the GDK rc(.in) files, as that is not used anymore. Make the GTK+
.rc(.in) file load the gtk.ico GTK+ logo file instead so that we still
get the GTK+ logo for the application icon by default. Update the
autotools build files as well.
-Revert commit b9f9980 as LRN pointed out in comment 25 in bug 773299, as
GTK+ is now a monolithic DLL, and we ought not to export this private
function.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
gdk_wayland_window_attach_image() is normally called from
gdk_window_end_paint() to notify the compositor of newly staged drawing.
If any of the drawing code inadvertently dispatches the wayland event
loop (for instance with a gdk_flush() call), then it's possible that by
the time gdk_window_end_paint() is called, the staged drawing is already
destroyed.
This commit bypasses the attach_image call in scenarios where the staged
drawing is prematurely dropped.
https://bugzilla.gnome.org/show_bug.cgi?id=773274
Commit d249e77 (API: screen: Remove gdk_screen_is_composited()) attempted
to update the GDK-Win32 for the removal of the API, but some parts were
missed. This updates the code so that things continue to build and run.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
gtk/inspector/rendernodeview.c calls this private function from GSK, so we
need to ensure that this function is exported so that GTK+ can link
properly on compilers that do not support automatic exporting.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
This is a problematic struct, and giving direct access to it
has kept us from making improvements to GtkTextView. Drop it
from the public API, together with the auxiliary APIs. If
it turns out that this functionality is needed, we should add
individual getters.
We now record all render operations and display them.
Warning: This is very brute force, you can't clear the recordings or
turn recording off. And this thing easily records 25MB per recorded
frame, so be careful to not run out of memory and get your browser
killed. ;)
This one introduces the Recording object which is essentially a single
instance of something that happened.
The RenderRecording is an instance of an actual rendering operation.
The GLSL versions are:
OpenGL 2.1: #version 110
OpenGL 3.0: #version 130
OpenGL 3.2: #version 150
OpenGLES 2.0: #version 100
OpenGLES 3.0: #version 300 es
So we need to check the version of the GdkGLContext if we want use the
appropriate version, especially for legacy OpenGL contexts, which can be
both 3.x and 2.x.
This ensures that the drawing does not extend the actually drawn area.
It also ensures that our math is sane, because the math assumes the clip
area cannot extend the window. After all, before GTK4 it always was like
that.
Fixes a bunch of drawing bugs when the clip area does indeed extend too
far.
We want to have the coordinate system of the created cairo surface to be
identical to the coordinate system of the node's bounds. For that, we
need to translate the cairo surface by the bounds' origin.
In that case, we can't just rely on the stack allocation being big
enough. Especially, the child can actually be bigger than the current
stack allocation, so take that into account when positioning it.
The typical UI file has a lot more <property> tags than it has
<requested> or <interface> tags, etc. so order the string comparisons
according to this expected case.
We need an overridable entry point for GskRenderer to create Cairo
surfaces.
Implementations of GskRenderer can override create_cairo_surface() to
create efficient surfaces, possibly with zero copies involved, depending
on the GDK backend.
Switch code to use gdk_display_is_composited() instead.
The new code also doesn't use a vfunc to query the property but rather
requires the backend to call set_composited()/set_rgba() to change the
value.
Also add properties for those two properties.
The first property is equivalent to checking if an RGBA visual exists,
the 2nd is equivalent to gdk_screen_is_composited().
This reverts commit 8e29222d95.
This needs more work - spin buttons need to be converted at
the same time, and we should make sure that text still appears.
Update the GDKGL implementation:
-Allow legacy contexts to be created.
-Use finer-grained attributes to ask for a pixel format when possible,
which also adds support for anti-aliasing
In fact the changes here are required for GTKGL to work properly on
Windows for 4.x.
Note that creation of gles contexts is not done here, as the system does
not support such contexts directly on Windows, but only through means such
as ANGLE, which is a totally different issue here.
https://bugzilla.gnome.org/show_bug.cgi?id=773528
Add the needed custom build steps to generate the GResource and
enumeration sources that is needed for the build, and make sure that the
build is able to find the Graphene headers and lib.
Also add the necessary CFLAGS needed for building GSK.
This follows what happens in the autotools builds.
Also fix some project namespaces and the install project where there is a typo
in a project dep, which may cause a problem during the build.
Includes the ability to turn on updates in the inspector. Animations are
now run via a tick function which allows us to neatly overlay a
semi-transparent red rectangle and fade it out over time.
It also probably enables way more, but somebody with more UI neatness
than me needs to figure out what it eanbles first...
Before, we would immediately invalidate the GdkWindow of the widget, now
we call the parent's GtkWidgetClass.queue_draw_child() function.
This allows the parent to track redraw queueing of children.
By default GtkWidgetClass.queue_draw_child() will again chain up to its
parent while respecting the GdkWindow hierarchy for clipping.
GtkWindow is then the only widget actually invalidating the GdkWindow.
This essentially moves redraw queueing from GDK to GTK.
For some reason we end up allocating the colorplane widget
before it is realized, and then never initialize the surface.
Fix this by explicitly doing it on realize.
https://bugzilla.gnome.org/show_bug.cgi?id=773474
This merged gtk, gdk and gsk into one library, making it possible to
have internal private APIs between gtk them, as well as producing more
efficient code.
https://bugzilla.gnome.org/show_bug.cgi?id=773100
This adds the initial MSVC build items needed to build GSK under Visual Studio,
this is part of it that is required, we need to add items to the property sheets
to generate the code that is generated via glib-mkenums and glib-compile-resources.
This set includes, with the autotools scripts for the complete:
-GSK project files, which is integrated into the gtk+-4.sln.
-The NMake snippets to build the introspection files for GSK.
-The .bat files to call glib-mkenums to generate the enumeration sources.
We now need C99 features from the compiler which are only supported by
Visual Studio 2013 and later, so drop the MSVC 2008~2012 projects, and make
the baseline supported Visual Studio version be 2013. Update the build files
as a result.
GTK+-3.89.0 and later will require C99 features that is only supported on
Visual Studio 2013 and later, so prepare build/Makefile.msvcproj for this.
We still keep the 2008~2010 stuff here as this strives to be a shared module,
and there are projects using this that still supports building on pre-2013
Visual Studio.
These complicate a lot of GdkWindow internals to implement features
that not a lot of apps use, and will be better achieved using gsk.
So, we just drop it all.
Add a new ::measure vfunc similar to GtkCssGadget's that widget
implementations have to override instead of the old get_preferred_width,
get_preferred_height, get_preferred_width_for_height,
get_preferred_height_for_width and
get_preferred_height_and_baseline_for_width.
Now that the use_es field is an int with a possible negative value, we
cannot use it its truth value directly; we need to check if it's a
positive value, instead.
GDK defaults to asking for an OpenGL 3.2 Core Profile, but if we get a
legacy profile from the underlying windowing system, the OpenGL version
will be fixed to 3.0. If that happens, we need to set the legacy bit on
the GdkGLContext, since that bit will be used to determine the version
and type of GLSL shaders that will be used by application and toolkit
code alike.
With best-effort, try to use gdk_window_move_to_rect() more often, when
all pieces fit together. For the non-legacy paths to be triggered for
when gtk_menu_popup_for_device() or gtk_menu_popup() were used, the
following conditions must be met:
1) There is no custom positioning function specified
2) The menu is attached to a widget (using gtk_menu_attach_to_widget())
3) There is a associated grab device
https://bugzilla.gnome.org/show_bug.cgi?id=772922
xdg_shell v6 allows grabless popups, whose behavior is not that
different from override redirect windows with no grab to take
keyboard input (and pointer events outside).
This means we can relax the requirement to have a grab before
creating an xdg_popup. The warning is still useful to have so
people stop relying on gdk_window_show();gdk_device_grab() being
an ok pattern to popup a window, it's been moved to wayland
implementation of gdk_device_grab() instead, so we warn if trying
to grab a GDK_WINDOW_TEMP window that's already visible.
https://bugzilla.gnome.org/show_bug.cgi?id=771694
Newer versions of Automake warn about forward compatibility when the
build uses sources in sub-directories without the subdir-objects option.
Both GTK+ and GDK have an almost-but-not-quite non-recursive Automake
layout, with sources in sub-directories contributing to the build of a
top-level object.
In theory, just adding subdir-objects to AM_INIT_AUTOMAKE would be
enough, but the test suite references sources in a different top-level
in order to build tests that verify the implementation of private data
structures. This is not really allowed when using subdir-objects and out
of srcdir builds. In order to fix this case, we require some ad hoc
rules to create symbolic links in the appropriate build directory.
the darker bottom border used on buttons looks bad on circular ones
so now a gradient clipped on the border-box and a transparent
border is used in that partcular case.
See https://bugzilla.gnome.org/show_bug.cgi?id=771205 for details.
$button_fill contains the background-image property value of
buttons, having it readable outside the drawing mixin allows, for
example, stacking background images in an easier way.
This updates all the projects files to be be named appropriately as we move from GTK-3.x to 4.x,
and updates the autotools files so that things are distributed and generated properly.
Also remove deprecated/gtkstatusicon-quartz.c from gtk/Makefile.am, as that was causing 'make dist'
to fail as that file has been removed.
This fixes 'make dist' with the updated existing project files in proper order.
Note that this does not include the new GSK, which will be added later, so the project files do
not yet build the whole stack on Visual Studio at this point.
Make the Makefile.am targets for generating the Visual Studio projects re-generate the
project files and the header listings whenever the Makefile.am's that include
build/Makefile.msvcproj changes, so that whenever a source/header is added, they will
be reflected in the projects and in the property sheets that are used to copy the
headers.
Also ensure that these are applied to the vs11, vs12 and vs14 projects when this
happens, as they are copied and processed from the Visual Studio 2010 projects.
While porting GTK to GskRenderer we noticed that the current fallback
code for widgets using Cairo to draw is not enough to cover all the
possible cases.
For instance, if a container widget still uses GtkWidget::draw to render
its children, and at least one of them has been ported to using render
nodes instead, the container won't know how to draw it.
For this reason we want to provide to layers above GSK the ability to
create a "fallback" renderer instance, created using a "parent"
GskRenderer instance, but using a Cairo context as the rendering target
instead of a GdkDrawingContext.
GTK will use this inside the gtk_widget_draw() implementation, if a
widget implements GtkWidgetClass.get_render_node().
We're going to need to allow rendering on a specific cairo_t in order to
implement fallback code paths inside GTK; this means that there will be
times when we have a transient GskRenderer instance that does not have a
GdkDrawingContext to draw on.
Instead of adding a new render() implementation for those cases and then
decide which one to use, we can remove the drawing context argument from
the virtual function itself, and allow using a NULL GdkDrawingContext
when calling gsk_renderer_render(). A later commit will add a generic
function to create a transient GskRenderer with a cairo_t attached to
it.
Renderers inside GSK will have to check whether we have access to a
GdkDrawingContext, in which case we're going to use it; or if we have
access to a cairo_t and a window.
GskRenderNode is, at its core, a write-only API; you're supposed to set
up the render nodes instead of querying them for state.
Querying render nodes is left to the GskRenderer implementation.
Add a should_propagate function for render nodes. Eventually,
this is meant to avoid creating render nodes for child widgets
that are outside the parents clip area. Since we don't have
that information available right now, just filter out nondrawable
children for now.
Change get_render_node to return nodes that are sized to the clip
area and expect to be placed at the clip position; change
gtk_container_propagate_render_node to place child render nodes
accordingly, and change gtk_css_gadget_get_render_node to return
nodes that are sized accordingly as well.
We store the vertices in (unscaled) window coords (but the item size
is still scaled to match the texture size). Also, the
projection/model-view multiplication order is switched so that the scale
is applied at the right place.
The renderer will always use nearest-neighbor filters because it renders
at 1:1 pixel to texel ratio.
On the other hand, render nodes may be scaled, so we need to offer a way
to control the minification and magnification filters.
If we already have a GL texture we definitely don't want to use
gdk_cairo_draw_from_gl() to draw on a Cairo context if we're going
to take the Cairo surface to which we draw and put it into an OpenGL
texture.
The details of the modelview and projection matrices are only useful for
the GL renderer; there's really no point in having those details
available in the generic API — especially as the Cairo fallback renderer
cannot really set up a complex modelview or a projection matrix.
Instead of using the background as the gadget's node, we add a
non-drawing node that can be used to apply offsets; all other nodes are
children of the "box" node.
Just like we reuse texture ids with the same size we can, at the expense
of a little memory, reuse vertex buffers if they reference the same
attributes and contain the same data.
Each VAO is marked as free at the end of the frame, and if it's not
reused in the following frame, it gets dropped.
The child-transform is useful only if we also provide clipping to the
parent nodes, otherwise children will just be drawn outside of the
parent's bounds.
We'll introduce child transforms either at a higher layer, or once we
add clipping support to GskRenderNode.
This is the first example of indirect rendering involving
a box gadget. For now, we iterate the child gadgets manually,
and rely on gtk_container_propagate_render_node for the
child widgets. Eventually, we may want a better solution
here.
...and implement it for GtkCssGadget and GtkCssCustomGadget.
This allows us to decide on a per-object basis if a custom
gadget needs a render node for content or not.
The custom gadget draw function has the side effect of informing
the gadget machinery wether to draw focus or not. Bring the
draw function back, just for its boolean return value. We may
want to find a better solution for this.
I don't think this should stay in the code long-term, but it
is useful for debugging. It helped me track down some suspicious
placements of render nodes.
Give all nodes the same detail about the owner widget.
This reveals that every GtkCssCustomGadget gets a
DrawGadgetContents node, even if their draw_func is NULL.
We may want to come up with a better solution for that.
When creating the GskRenderNodes for the gadgets we should not translate
the coordinates inside the Cairo context, but we should tweak the
coordinates of the anchor point.
This is still not enough to get an appropriate rendering, as the result
is still slightly offset to the left.
Instead of passing the size of the buffer, we should pass the number of
quads; we know what the size of a single quad structure is, so we can do
the multiplication internally when creating the VAO.
This allows us to print the quads for debugging purposes.
GtkWidget.create_render_node() sets up a GskRenderNode appropriate for
rendering the contents of a widget, including its bounds,
transformation, and anchor point.
The naming is consistent with other scene graph libraries, as it
represents an additional translation transformation applied on top of
the provided transformation matrices.
We can also simplify the implementation by applying the translation when
we compute the world matrix.
We keep the textures used inside a frame around until the end of the
following frame; whenever we need a texture with the same size, and
it's not marked in use, then we just reuse the existing texture.
We were allocating a surface thats big enough for the clip, and
we were setting the transform for that, but then GtkContainer
was overriding the transform with the one for the allocation.
Also, we were drawing at the clip position, not the allocation
position.
This was overwhelming other useful debug output, so make it
opt-in. We print the render items for both opengl and transforms,
since the matrices bleed into each other, otherwise.
Since we use an FBO to render the contents of the render node tree, the
coordinate space is going to be flipped in GL. We can undo the flip by
using an appropriate projection matrix, instead of changing the sampling
coordinates in the shaders and updating all our coordinates at render
time.
We need to apply a scaling factor whenever we deal with user-supplied
coordinates, like:
- when creating textures
- when setting up the viewport
- when submitting the scene
Render nodes need access to rendering information like scaling factors.
If we keep render nodes separate from renderers until we submit a nodes
tree for rendering we're going to have to duplicate all that information
in a way that makes the API more complicated and fuzzier on its
semantics.
By having GskRenderer create GskRenderNode instances we can tie nodes
and renderers together; since higher layers will also have access to
the renderer instance, this does not add any burden to callers.
Additionally, if memory measurements indicate that we are spending too
much time in the allocation of new render nodes, we can now easily
implement a free-list or a renderer-specific allocator without breaking
the API.
We cannot implement GtkWidgetClass.get_render_node() in GtkContainer
without breaking the fallback path that renders a widget to a single
render node rasterization. For GtkContainer subclasses we should provide
a simple API, similar to gtk_container_propagate_draw(), that gathers
all the render nodes for each child.
If a node is non-opaque and has a non-zero opacity we need to paint its
contents and children first to an off screen buffer, and then render the
resulting texture at the desired opacity — otherwise the opacities will
combine and result in the wrong rendering.
We're not going to use separate rendering lists soon, and the way we
render items is less similar to a gaming engine and more similar to a
simpler compositor. This means we don't need to perform a two pass
rendering — opaque items first, transparent items later.
Use appropriate names, and annotate the names with the types — 'u' for
uniforms, 'a' for attributes. The common preambles for shaders are split
from the bodies, so we need some way to distinguish the uniforms and the
attributes just from their name.
We want the GL driver to cache as many resources as possible, so we can
always ensure that we're in a consistent state, and we can handle state
transitions more appropriately.
Drop the texture parameters handling from the texture creation, and
associate them with the contents upload. Also, rename the function to
something more in line with what it does.
We want to add the list of FBOs tied to a texture; this means we cannot
trivally copy the Texture structure when adding it to a GArray. We're
also going to have more textures than VAOs, so it makes more sense to
use a O(1) access data structure for them.
We can use the GL_ARB_timer_query extension (available since OpenGL
3.2, and part of the OpenGL specification since version 3.3) to query
the time elapsed when drawing each frame. This allows us to gather
timing information on our use of the GPU.
The clip rectangle may have non-zero offsets, so we need to ensure that
the GskRenderNode associated to the rendered area is translated by those
same offsets.
For the root node we do not need to use blending, as it does not have
any backdrop to blend into. We can use a simpler 'blit' program that
only takes the content of the source and fills the texture quad with
it.
We should use ShaderBuilder to create and store programs for the GL
renderer. This allows us to simplify the creation of programs (by moving
the compilation phase into the ShaderBuilder::create_program() method),
and move towards the ability to create multiple programs and just keep a
reference to the program id.
We should keep the ShaderBuilder around and use it to query the various
uniform and attribute locations when needed, instead of storing those
offsets into the Renderer instance, and copying them. This allows a bit
more flexibility, once we have more than one program built into the
renderer.
The GL renderer should build the GLSL shaders using GskShaderBuilder.
This allows us to separate the common parts into separate files, and
assemble them as necessary, instead of shipping one big shader per type
of GL API (GL3, GL legacy, and GLES).
GskShaderBuilder is an ancillary, private type that deals with the
internals of taking GLSL shaders from resources and building them,
with the additional feature of being able to compose shaders from a
common preamble, as well as adding conditional defines (useful for
enabling debugging code in the shaders themselves).
Using GObject as the base type for a transient tree may prove to be too
intensive, especially when creating a lot of node instances. Since we
don't need properties or signals, and we don't need complex destruction
semantics, we can use GTypeInstance directly as the base type for
GskRenderNode.
We need a virtual function to retrieve the GskRenderNode for each
widget, which is supposed to attach its own children's GskRenderNodes.
Additionally, we want to maintain the existing GtkWidget::draw mechanism
for widgets that do not implement get_render_node() — as well as widgets
that have handlers connected to the ::draw signal.
This commit changes the way GskRenderer and GskRenderNode interact and
are meant to be used.
GskRenderNode should represent a transient tree of rendering nodes,
which are submitted to the GskRenderer at render time; this allows the
renderer to take ownership of the render tree. Once the toolkit and
application code have finished assembling it, the render tree ownership
is transferred to the renderer.
Whenever the render tree changes we want to drop the RenderItem arrays,
as each item contains a pointer to the GskRenderNode which becomes
dangling once the root node changed.
The surface-to-GL upload logic has become more complicated with the
addition of the GLES code paths; it's more logical to have a public
utility function that can be called from GDK users, instead of copy
pasting the whole thing multiple times.
GSK is conceptually split into two scene graphs:
* a simple rendering tree of operations
* a complex set of logical layers
The latter is built on the former, and adds convenience and high level
API for application developers.
The lower layer, though, is what gets transformed into the rendering
pipeline, as it's simple and thus can be transformed into appropriate
rendering commands with minimal state changes.
The lower layer is also suitable for reuse from more complex higher
layers, like the CSS machinery in GTK, without necessarily port those
layers to the GSK high level API.
This lower layer is based on GskRenderNode instances, which represent
the tree of rendering operations; and a GskRenderer instance, which
takes the render nodes and submits them (after potentially reordering
and transforming them to a more appropriate representation) to the
underlying graphic system.
This is an attempt to get rid of gdk_window_new() for more specific use
cases. These 2 are for client-side windows - regular ones and input-only
ones resepectively.
So far all those functions just call into gdk_window_new().
On windows you might not have a theme installed by default which
means that when trying to create the context quark it will fail.
If then we try to replace a NULL key in the hash table it will crash.
https://bugzilla.gnome.org/show_bug.cgi?id=769859
Just like GLib, GTK+ would benefit from getting warnings and errors from
the compilers.
We check various, common warnings, especially for a future use of C99;
additionally, we promote some warnings to errors, in order to ensure
that simple mistakes are caught during the development phase, before
they are submitted to the code repository.
Use a static array for the known icon sizes, now that we don't allow
registering custom icon sizes any more. This allows us to cut a one-off
allocation that makes Valgrind sad.
The update tracking code was ugly and using deprecated drawing APIs. It
was also in the wrong place.
So instead of trying to keep it working, I'll remove it. We need to find
a better way to put it and make it work there.
This API was only used in GtkModifierStyle and GtkStyleProperties and
they are both on their way out.
CSS properties must now be set using strings via the regular parser API.
And replaces its usages in GtkTextView/GtkStyleContext with a hard-coded
0.04 which was the default value for cursor-aspect-ratio. Also remove
the public gtk_draw_insertion_cursor which used draw_insertion_cursor
which in turn looked up cursor-aspect-ratio
And with it, gtk_widget_get_visual() and gtk_widget_set_visual() are
gone.
We now always use the RGBA visual (if available) and otherwise fall back
to the system visual.
The cursor was set using gdk_window_set_cursor() even in
gdk_window_new().
So instead of having yet another flag, just make the users of that flag
call gdk_window_set_cursor() directly after the window was created.
X11 was the only backend to support it and people can just override it
using XSetClassHint() directly.
The docs already advertised the function as "Do not use".
Keep the existing call to XSetClassHint() in place, so that we keep
setting the same values as in GTK3.
... and gdk_screen_get_window_stack().
Those functions were originally added in
5afb4f0f11 but do not seem to be used as
they are not implemented anywhere but in X.
As GDK is not meant to fulfill window management functionality I'm going
to remove these functions without replacements.
... and gdk_screen_get_width_mm() and gdk_screen_get_height_mm() and
the shortcut counterparts that call these functions on the default
screen.
Modern display servers don't provide an ability to query the size of a
screen or display so we shouldn't allow that either.
Nobody ever does a NULL check there so all that causes is crashes. So
we better return a non-primary monitor than NULL.
Fixes gdk-wayland always returning NULL.
gtk_widget_destroy() removes widgets from their container. However
_internal_ widgets must be unref'ed using gtk_widget_unparent() instead.
This is symmetric with the fact that these widgets were ref'ed by direct
call to gtk_widget_set_parent(). It's also the method that was used in
gtk_headerbar_destroy().
https://bugzilla.gnome.org/show_bug.cgi?id=772859
> Due to Gtk+ keeping a reference to the window internally,
> gtk_window_new() does not return a reference to the caller.
> To delete a GtkWindow, call gtk_widget_destroy().
Caller(s) aren't expecting a need to delete help_overlay themselves
once they've installed it. (E.g. see gtk_application_window_added()).
I didn't notice any direct precedents, but there's a parallel in the
current implementation of gtk_container_destroy() which uses
gtk_widget_destroy() on any added widget.
This avoids leaking 100s of kB per window, when I tested nautilus.
https://bugzilla.gnome.org/show_bug.cgi?id=772859
This allows the use of a "text-direction" hint set to one of "none", "rtl",
or "ltr" to enforce the text direction of a "horizontal-buttons"
display-hint.
This is useful when a menu has buttons that map to physical space in the
UI and therefore must match the application widgetry.
https://bugzilla.gnome.org/show_bug.cgi?id=772775
ClutterEmbed on Wayland uses a subsurface and relocates it on configure
events, but when placed within a scrolled window, no configure event is
emitted and the ClutterEmbed subsurface remains static.
Emit a configure event for native windows in GdkWindow's internal
move_native_children() so that custom widgets relying on configure
events such as ClutterEmbed can relocate their stuff.
Similarly, when switching to/from normal/maximized/fullscreen states
which change the shadows' size and possibly shows/hides a header bar,
we need to emit a configure event even if the abs_x/abs_y haven't
changed to make sure the subsurface is size appropriately.
https://bugzilla.gnome.org/show_bug.cgi?id=771320https://bugzilla.gnome.org/show_bug.cgi?id=767713
to hilight drop target there is a wildcard selector which turns
the border and shadow to green, this clearly shouldn't happen when
the whole window is a drop target.
...by putting it in a stack. The busy_spinner and eject_button are
mutually exclusive, but only the latter was coded to ensure that its
visibility did not cause the rest of the row to reflow. By putting both
widgets in a stack and setting child_visible on that, the row allocates
enough space to show one - or none - at once, avoiding any misalignment.
https://bugzilla.gnome.org/show_bug.cgi?id=772345https://bugzilla.gnome.org/show_bug.cgi?id=772348
Calling eglGetDisplay forces libEGL to guess what kind of pointer you
passed it. Different EGL libraries will do different things here, and in
particular glvnd will do something different than Mesa. Since we do have
an API that allows us to explicitly type the display, use it.
The explicit call to eglGetProcAddress is working around a bug in
libepoxy 1.3, which does not understand the EGL concept of client
extensions. Since it does not, the normal epoxy resolver for
eglGetPlatformDisplayEXT would not find any provider for that entry
point, and crash when you attempted to call it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772415
We currently beep when a character is appended at the end in
overwrite mode. That is obviously not right. Patch based on
a patch by Ian MacDonald.
https://bugzilla.gnome.org/show_bug.cgi?id=772389
13 bytes in 1 blocks are definitely lost in loss record 766 of 16,875
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0xA9D0247: vasprintf (in /usr/lib64/libc-2.24.so)
by 0xA2453FC: g_vasprintf (gprintf.c:316)
by 0xA2152F7: g_strdup_vprintf (gstrfuncs.c:514)
by 0xA21539C: g_strdup_printf (gstrfuncs.c:540)
by 0x678F25C: gdk_rgba_to_string (gdkrgba.c:360)
by 0x5FAE00D: rgba_to_string_noalpha (gtkicontheme.c:4322)
by 0x5FAE6F2: gtk_icon_info_load_symbolic_svg (gtkicontheme.c:4492)
by 0x5FAED4F: gtk_icon_info_load_symbolic_internal (gtkicontheme.c:4622)
by 0x5FAEEE8: gtk_icon_info_load_symbolic (gtkicontheme.c:4711)
by 0x5F00246: gtk_css_image_recolor_load (gtkcssimagerecolor.c:118)
by 0x5F003E4: gtk_css_image_recolor_compute (gtkcssimagerecolor.c:170)
14 bytes in 1 blocks are definitely lost in loss record 801 of 16,875
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0xA9D0247: vasprintf (in /usr/lib64/libc-2.24.so)
by 0xA2453FC: g_vasprintf (gprintf.c:316)
by 0xA2152F7: g_strdup_vprintf (gstrfuncs.c:514)
by 0xA21539C: g_strdup_printf (gstrfuncs.c:540)
by 0x678F25C: gdk_rgba_to_string (gdkrgba.c:360)
by 0x5FAE00D: rgba_to_string_noalpha (gtkicontheme.c:4322)
by 0x5FAE68E: gtk_icon_info_load_symbolic_svg (gtkicontheme.c:4482)
by 0x5FAED4F: gtk_icon_info_load_symbolic_internal (gtkicontheme.c:4622)
by 0x5FAEEE8: gtk_icon_info_load_symbolic (gtkicontheme.c:4711)
by 0x5F00246: gtk_css_image_recolor_load (gtkcssimagerecolor.c:118)
by 0x5F003E4: gtk_css_image_recolor_compute (gtkcssimagerecolor.c:170)
15 bytes in 1 blocks are definitely lost in loss record 838 of 16,875
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0xA9D0247: vasprintf (in /usr/lib64/libc-2.24.so)
by 0xA2453FC: g_vasprintf (gprintf.c:316)
by 0xA2152F7: g_strdup_vprintf (gstrfuncs.c:514)
by 0xA21539C: g_strdup_printf (gstrfuncs.c:540)
by 0x678F25C: gdk_rgba_to_string (gdkrgba.c:360)
by 0x5FAE00D: rgba_to_string_noalpha (gtkicontheme.c:4322)
by 0x5FAE6C3: gtk_icon_info_load_symbolic_svg (gtkicontheme.c:4487)
by 0x5FAED4F: gtk_icon_info_load_symbolic_internal (gtkicontheme.c:4622)
by 0x5FAEEE8: gtk_icon_info_load_symbolic (gtkicontheme.c:4711)
by 0x5F00246: gtk_css_image_recolor_load (gtkcssimagerecolor.c:118)
by 0x5F003E4: gtk_css_image_recolor_compute (gtkcssimagerecolor.c:170)
16,384 bytes in 1 blocks are definitely lost in loss record 16,847 of 16,875
at 0x4C2DADE: malloc (vg_replace_malloc.c:298)
by 0x4C2FC91: realloc (vg_replace_malloc.c:785)
by 0xA1F89FA: g_realloc (gmem.c:159)
by 0xA1BAD2E: g_array_maybe_expand (garray.c:779)
by 0xA1BA566: g_array_set_size (garray.c:555)
by 0xA1BBCB8: g_byte_array_set_size (garray.c:1752)
by 0x8D1CC48: g_file_load_contents (gfile.c:6766)
by 0x5FAE767: gtk_icon_info_load_symbolic_svg (gtkicontheme.c:4501)
by 0x5FAED4F: gtk_icon_info_load_symbolic_internal (gtkicontheme.c:4622)
by 0x5FAEEE8: gtk_icon_info_load_symbolic (gtkicontheme.c:4711)
by 0x5F00246: gtk_css_image_recolor_load (gtkcssimagerecolor.c:118)
by 0x5F003E4: gtk_css_image_recolor_compute (gtkcssimagerecolor.c:170)
https://bugzilla.gnome.org/show_bug.cgi?id=772215
The relative-to widget may be reparented itself into/out of a
scrollable. In this cases make the hierachy-changed handler to
unset the parent scrollable when unparented, and look up again
the parent scrollable after it's reparented.
https://bugzilla.gnome.org/show_bug.cgi?id=771812
gtk_popover_set_scrollable_full() takes care of the signal connected
on the scrollable itself, in addition to the adjustment signals the
popover listens to.
gtk_popover_update_scrollable() looks up the current relative-to
widget hierarchy and updates the current scrollable.
The places where the scrollable is being maintained have been updated
to use these functions.
https://bugzilla.gnome.org/show_bug.cgi?id=771812
Opaque region, margin and input region were only being synced when a cairo
paint happened. That caused GL paints to sometimes end up with bad state.
Move calls to sync state to gdk_window_impl_wayland_end_paint.
https://bugzilla.gnome.org/show_bug.cgi?id=771553
Setting the shadow width earlier as done with commit 4cb1b96 to address
bug 771561 proved to cause unexpected side effects on size_allocate
signal propagation.
As the window is sized correctly earlier, the size_allocate signal is
not emitted again in gtk_widget_size_allocate_with_baseline() which
prevents clutter-gtk from relocating its child widget correctly.
To avoid this issue, revert commit 4cb1b96 but make sure the values
passed as min and max size is never negative in Wayland as this is a
protocol error.
With this, the min/max size will be wrong for a short amount of time,
during the state transition, until the shadow width is updated from
gdk_window_set_shadow_width().
This approach is much safer and less intrusive than changing the
size_allocate logic in gtk.
This reverts commit 4cb1b9645e.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=771915
After checking for rendered_surface, the call to gtk_css_node_get_style
can invalidate the style and result in rendered_surface being set to
NULL. This was result in some icon views appearing blank on
Endless OS on armv7hl, and this error:
Gtk-CRITICAL **: gtk_css_style_render_icon_surface: assertion 'surface != NULL' failed
Call gtk_css_node_get_style earlier to ensure we always pass a valid
surface to gtk_css_style_render_icon_surface.
https://bugzilla.gnome.org/show_bug.cgi?id=765649https://phabricator.endlessm.com/T13524
This was meant to be silenced unless expicitly requested but
G_ENABLE_DEBUG is defined by default unless --disable-debug is passed to
configure, so use G_ENABLE_CONSISTENCY_CHECKS instead which is only
defined if --enable-debug is explicitly passed.
add circle objects to the injected style for recoloring.
Should avoid randomly colored symbolic icon bits when circles are
in the mix as in network-vpn-acquiring-symbolic for example.
Otherwise, with CSD, we could have a discrepancy where gtk uses the
right values for the shadows whereas the gdk backend still uses the old
values, leading in some cases to invalid or negative min size being
computed (which, in Wayland, leads a protocol error).
https://bugzilla.gnome.org/show_bug.cgi?id=771561
The GLib main loop blocks on MsgWaitForMultipleObjectsEx to
determine if there are any incoming messages while also allowing
for background tasks to run. If all available messages are not
processed after MsgWaitForMultipleObjectsEx has signaled that
there are available, CPU usage will skyrocket.
From my limited understanding (by inspection of profiling
under Visual Studio):
Key is pressed - MsgWaitForMultipleObjectsEx unblocks, and
sends message to GDK's event handler. Some event is now queued.
g_poll unblocks, calls the g_event_dispatch which finally
resolves to gdk_event_dispatch. This then calls
_gdk_win32_display_queue_events, but since a message is already
queued, it fails to call PeekMessage and returns immediately.
At the next iteration, g_poll again calls MsgWaitForMultipleObjectsEx
which queues yet another event and returns almost immediately, since
there are events available which haven't been processed by PeekMessage.
The dispatch function is then called and the process repeats.
https://bugzilla.gnome.org/show_bug.cgi?id=771568
The main corpus of the documentation for gtk_window_get_size() is still
full of X11-isms, so we should port it to something that is more
backend-agnostic. Additionally, having some examples would be nice for
application authors looking at a way to appropriately use this function.
If somebody decides to use gtk_widget_set_double_buffered() in the
middle of a draw() then there's the risk of calling end_draw_frame()
with an invalid pointer.
Some overeager compilers may warn about the double_buffered bit field
changing values and leading to a potentially uninitialized variable.
In order to avoid compiler warnings or crashes, we can simply store the
value of the double_buffered bit field at the beginning of the rendering
and use that instead of the actual bit field.
https://bugzilla.gnome.org/show_bug.cgi?id=771463
Not all occurrences of this warning can be fixed today, so put it behind
a G_ENABLE_DEBUG flag since it still shows legitimate problems even if
some of them are false positives.
A popup may have moved and resized when configured. Make sure every
layer knows about this and call gdk_window_move_resize() with the
configured dimension and position. This won't actually move the
window, but might resize it.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
The result of move_to_rect, received from the xdg_popup.configure
event, needs to be translated to the correct coordinate space; that is
from real parent window geometry to coordinates relative to the gdk
window set as transient-for.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
Use a helper to translate a coordinate from non-real GdkWindow parent
to window geometry coordinate space of the real GdkWindow parent,
meaning the coordinate space of the GdkWindow of the parent used as a
xdg_popup parent where (0, 0) is inside of the shadow margin.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
When using the dynamic positioner (i.e. positioning from move_to_rect)
we can always rely on having a proper transient-for to position
relative to, so lets drop the ignored parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
Move the code used for calculating the result of move_to_rect
(final_rect, flipped_rect etc) closer to the other move_to_rect
functions (i.e. next to create_dynamic_positioner), and let the
xdg_popup configure handler just call the calculation function.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
If an application umaps the toplevel from its popup callback, this can
lead to a protocol error.
Make sure we mark popup parent and use that to check if their parent is
the toplevel being unmapped in which case we shall unmap the popup first
to avoid the protocol error.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=770906
The fix for bug 767468 had some unintended side-effects. This is
an attempt at doing the same fix (don't grab focus when we are
grab-shadowed), while avoiding the breakage, by using GTK+'s
internal tracking for grab-shadowed-ness.
https://bugzilla.gnome.org/show_bug.cgi?id=770508
Analogous to (un)mount operation, we now keep a reference around
during the ongoing operation and make use of the destroyed flag
to check if we are still alive or if we have been cancelled as
a result of the widget being destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=764979
Since we hold on to a reference during (un)mount operations, we
don't trigger the cancellation of operations in finalize anymore.
Instead we now override the GtkWidget's destroy() and cancel any
ongoing operations there.
https://bugzilla.gnome.org/show_bug.cgi?id=764979
The current code wrongly assumes that cancellation can only happen
as a result widget finalization, and consequentially does not
properly recover from it. Therefore if the operation is cancelled
as a result of user interaction, the entry is will stay disabled
and the spinner will keep spinning. This is fixed by removal of
the early bail out in case of cancellation.
https://bugzilla.gnome.org/show_bug.cgi?id=764979
During mount and unmount opertions we keep a reference to the
GtkPlacesView around, so we have a valid view for the callback
code, even in the case that othe external references have been
dropped (i.e. the containing window gets destroyed).
https://bugzilla.gnome.org/show_bug.cgi?id=764979
RandR 1.5 is enabled on VirtualBox guest of Fedora 25 but
XRROutputInfo->name is "default". If init_randr15() does not
return TRUE, the monitor size sets 0 because gdk_screen_get_width()
returns 0.
This problem causes GtkStatusIcon not to show the activate menu.
https://bugzilla.gnome.org/show_bug.cgi?id=771033
This reverts commit 6af5033386.
Scrolled window behavior of propagating child natural sizes
has now been made optional, so there is no need to work around
this by setting a hard coded maximum content height anymore.
This reverts commit 76af907676.
The behavioral change described in the migration guide
has now been made optional with new scrolled window API,
so no need to mention this in the migration guide.
This reverts commit 37e913d76b.
This is no longer needed since the natural size propagation of
scrolled window children is now an optional behavior. Reverting
this also makes the widget factory scrolled window sizes behave
the same as with the gtk+ 3.20 branch.
In gtkscrolledwindow.c, the return type of _get_propagate_natural_width()
and _get_propagate_natural_height() were accidentally gint instead of
gboolean, fixed to match the type correctly declared in the header file.
The code always assumed that getting a row at a certain 'y' was
possible but if the list box has more empty space than rows then a
valid row may not be retrieved.
https://bugzilla.gnome.org/show_bug.cgi?id=770703
- while we don't use steppers anymore, for some reason they are still
defined in the theme and if you sacrifice a chicken and jump on one
leg at full moon, you can enable them.
https://bugzilla.gnome.org/show_bug.cgi?id=769498
When a popup is mapped but will not be the top most popup (for example
the parent is not the current top most popup, or if there already is a
popup mapped but the parent is a toplevel), warn and ignore it instead
of continuing, as continuing would be a protocol violation.
https://bugzilla.gnome.org/show_bug.cgi?id=770745
Since we're using _get_rect_coords in size-allocate when allocating the
size of the child widget, use the newly introduced _get_rect_for_size to
calculate the difference between the passed size_for and the one we're
supposed to pass on to the child widget.
When calculating the requested size of a popover, we need to do the
exact same same thing _get_rect_coords did, but not for the
current popopver allocation. Add _get_rect_for_size that can be used for
this purpose
Making propagation of child natural sizes mandatory (or default, even) was
evidently a mistake as this causes dynamic content in a scrolled window
to resize it's parent when the scrolled window is competing for space
with an adjacent widget.
This patch instead adds API to control whether natural width and
height of the child should be propagated through the scrolled windows
size requests.
There was a return between a push/pop of an error trap, and
this managed to trigger the 'unpopped trap' warning in the
displayclose test now. Fix this.
Add an API that enables an application to, given an exported window
handle, set its own window as a transient of the window associated with
the exported window handle.
https://bugzilla.gnome.org/show_bug.cgi?id=769788
We were using __VOID for the SHOW_OTHER_LOCATION signal that
uses flags named SHOR_OTHER_LOCATION_WITH_FLAGS.
However, if a signal uses flags the marshal needs to use __FLAGS.
This patch addresses this using VOID__FLAGS as the marshaler parameter.
Thanks to Jan Steffens for pointing this out.
https://bugzilla.gnome.org/show_bug.cgi?id=770550
Only set input, opaque and window geometry regions once per commit.
They are double buffered anyway, so the last one would only take effect
either way; this way reading protocol logs are much more pleasent.
https://bugzilla.gnome.org/show_bug.cgi?id=769937
There is annoying interference between formatting the value
(for which we set the number of digits to show) and the small
frame-to-frame value changes that we do for autoscrolling.
To work around this, turn off the digits-based rounding entirely
and format the value ourselves with ::format-value.
And rename it to "Touch and Drawing Tablets", since it's no longer about
"axes" really.
As for pad support in the demo, just keep it "simple", make the
controller handle all pad devices, and make all the actions have the
same callback.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
The wayland tablet protocol allows notifying the compositor with
descriptions of the actions performed by each tablet element. This
API call allows to hook up in to this wayland-specific feature.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
These devices are kind of an strange case. Their "master" device is
the keyboard, because they share toplevel focus with it, regardless
of stylus focus. Nonetheless, they are only expected to send the
GdkEventPad* set of events.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
This is a subclass of GdkWaylandDevice that implements GdkDevicePad,
all pad features are looked up from the info obtained through the
tablet v2 interface.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
This GdkEventController is a helper object to handle pad events,
it allows setting a mapping to action names, to be triggered in
the given action group.
In order to help on places where advanced mapping/configurability
of pad features is not desirable, this controller also allows
passing a NULL pad device, meaning it will listen on all pads,
and/or passing -1 on mode/index, so an action applies to all
modes/features (eg. strips/rings).
https://bugzilla.gnome.org/show_bug.cgi?id=770026
This is an interface meant to be implemented by the "pad" devices.
This device-specific interface exposes the mapping of all pad features,
it allows retrieving:
- The number of buttons/rings/strips
- The number of groups
- The number of modes a group has
- Whether a given button/ring/strip belongs to a given group
https://bugzilla.gnome.org/show_bug.cgi?id=770026
We want the same treatment for those, the event will be emitted on the
toplevel, which will then decide what to do with the event.
It just doesn't make much sense to propagate those up/down the hierarchy,
when we want specifically one action being triggered from those.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
GDK_PAD_BUTTON*,RING and STRIP will be emitted respectively when
pad buttons, rings or strips are interacted with. Each of those
pad components belong to a group (a pad can contain several of
those), which may be in a given mode. All this information is
contained in the event.
GDK_PAD_GROUP_MODE is emitted when a group in the pad switches
mode, which will generally result in a different set of actions
being triggered from the same buttons/rings/strips in the group.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
An xdg-popup requires a serial that the compositor will compare against
its own serial and will dismiss the popup if it doesn't match.
gtk+ uses either a pointer or touch serial for its helper function
_gdk_wayland_seat_get_last_implicit_grab_serial() but if the menu is
triggered before the user has had any pointer or touch interaction with
the client, using a keyboard shortcut, there is neither pointer nor
touch serial available, and gtk+ will use 0 as the default.
As a result, the compositor will instantly dismiss the xdg-popup. In
this case, gtk+ should use the keyboard serial instead.
Track keyboard serial as well and use the keyboard serial as the value
if there is no newer pointer or touch serial available.
https://bugzilla.gnome.org/show_bug.cgi?id=768017
At the time of move_to_rect() is called, not all state may have been set
up on the impl gdk window, causing the position to sometimes be
slightly offset due to drap shadow margins. For now, work around this
by postponing the processing of the move_to_rect() parameters until
showing, when its more likely that all state (such as shadow margin)
has been set correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
The Wayland backend manages a set of fake root coordinate spaces, where
each non-relative positioned toplevel (i.e. not popups, popovers,
tooltips etc) make up the basis of separate fake root coordinate spaces.
This means that the Wayland backend doesn't have the abilitiy get a
proper root coordinate when querying on a non-toplevel GdkWindow. To
avoid this issue, first find the toplevel, while translating the anchor
rect coordinates so that they are in the toplevel window coordinate
space. Then use this toplevel to translate the coordinates to root
window coordinate space.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
The position of each transient-of will be in fake-root coordinate
space; thus we should not accumulate all the positions making it an
offset; each window is already in fake root coordinate space.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
When using the set transient-for as a popup parent, fetch the effective
toplevel instead, otherwise we will position against the wrong
coordinate.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
The effect of transitions-enabled=true can now be
achieved using gtk_popover_popup/popdown and the effect
of transitions-enabled=false can be achieved using
gtk_widget_show/hide.
https://bugzilla.gnome.org/show_bug.cgi?id=769706
Since not chaining up in gtk_widget_show/gtk_widget_hide is not allowed,
we can't just implicitly delay the hiding in GtkPopover's hide
implementation. Fix this by introducing gtk_popover_popup() and
gtk_popover_popdown() to show or hide a popover with transition and
revert GtkPopover's show/hide implementation to apply their effect
without the transition.
https://bugzilla.gnome.org/show_bug.cgi?id=769706
The order in which tooltips are created, drawn, shown and then positioned,
always requires repositioning the surface. The tooltip window type only has
limited capability to do so. An alternative could be to use bufferstreams.
https://bugzilla.gnome.org/show_bug.cgi?id=768138
When a dialog is created, the mir event source is already executed on the
call stack. So without the recurse flag it will not be run in the main loop
used for the dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=768138
The event will be sent when the surface becomes visible on an output. With this change the GdkMirWindowImpl keeps track of the scale value and sends a configure event on change.
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com>
The config.rpath script was added by running gettextize, but it's not
really needed, as config.rpath is generated by autotools and it's
included in the dist tarball automatically.
Upstream gettextize has been fixed so it does not happen any more:
http://savannah.gnu.org/bugs/index.php?48729
The GtkHeaderBar gadget implementation was subtly broken: it called
gtk_widget_set_allocation both in gtk_header_bar_size_allocate (with
the actual allocation) and in gtk_header_bar_allocate_contents (with
the content allocation of the main gadget). Dropping the second call
fixes the render node conversion for GtkHeaderBar.
The event code could potentially dereference pointer_info if the
invariant that ENTER_NOTIFY and LEAVE_NOTIFY events are only emitted on
devices which have pointers is violated elsewhere.
Found with scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
In order to eliminate g_test_expect_message() (which doesn’t work with
G_LOG_USE_STRUCTURED), make the warning about the fallback theme not
existing be conditional on the icon theme search path containing a
system path. Any application code which modifies the search path does so
through appends and prepends, so this should not affect whether the
warning is emitted in production.
https://bugzilla.gnome.org/show_bug.cgi?id=769485
:toggled is triggered on :clicked, so using :toggled lead to the menu
to be popped up at the same time, while allowing to use the toggle state
and avoiding any need to a hack to prevent recursion, which somehow
wasn't enough for double emission of GtkMenuToolButton:show-popup.
https://bugzilla.gnome.org/show_bug.cgi?id=769287
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
This changes the group/level semantic.
Previously W32 backend used "group 0/1" to denote "AltGr OFF/ON"
and "level 0/1" to denote "Shift is OFF/ON".
Now "group" means "keyboard layout" and there can be up to 255 groups,
while AltGr and Shift are combined into a single level enum that
takes values between 0 and 4.
Unlike X, W32 doesn't do effective group overriding, meaning that
it will never tell the caller that a different group was actually
used (even for universal keys, such as Enter), because key symbol
table is completely fabricated and there's no point in trying to
save a few of kilobytes of RAM by not duplicating universal key
records for all groups.
Also contains many whitespace changes (tab elimination, fixed
indentation) and cleanup (axed a few global variables, these are
now accessed via the default keymap).
https://bugzilla.gnome.org/show_bug.cgi?id=768722
GTK+ has two directories for translations: the default 'po' and the
additional 'po-properties' for the GObject properties translation
domain.
Since the content of the translations directories are filled by
autoreconf and gettext, and are duplicated between the two gettext
domains we use, we should handle this ad hoc inside git.mk, instead of
trying to catch up by adding po-properties files in GITIGNOREFILES.
The contents of the macro directory are too complicated for git.mk to
handle: the contents are filled by autotools and may change between
systems or autotools releases; and we additionally ship our own m4
macros.
To avoid unnecessary noise on the `git status` output we should simply
add an ignore file specifically for the macro directory.
The new positioning-related properties had some quality of
implementation issues, such as incorrect initial values and
excessive change notification. This broke the notify test.
It tried to set the expand state if either xexpand/yexpand where true.
Due to a missing queue_compute_expand when adding a child it actually
only computed the expand state in case a child queued after being added
or in case a child had the expand property set (see optimization in
gtk_widget_set_parent)
In my case this broke layouts as a child of GtkCombBox started setting
an exand flag with 3.20 which queued a compute_expand, which in turn
propagated an expand child props set for a cell in the same table up
and overrode the expand child prop of a parent GtkBox.
This removes the custom compute_expand implementation to match the
behaviour of GtkBox (don't propagate child prop expand flags
but let child expand flags override the child props) and not get random
expand behaviour depending on whether and when child widgets set their
expand state.
https://bugzilla.gnome.org/show_bug.cgi?id=769162
gtk+/demos/gtk-demo/css_blendmodes.c: In function ‘update_css_for_blend_mode’:
gtk+/demos/gtk-demo/css_blendmodes.c:49:26: error: format not a string literal, argument types not checked [-Werror=format-nonliteral]
blend_mode);
^~~~~~~~~~
https://bugzilla.gnome.org/show_bug.cgi?id=769236
The error was:
gtk3-scan.c:193: undefined reference to `gtk_shortcuts_label_get_type'
collect2: error: ld returned 1 exit status
It's since commit 7543cd8ce4, which made
the GtkShortcutLabel class public.
Introduce a private API meant for abstracting how to get a handle
of a window that can be shared with other processes. The API is
async, since some implementations will require that. Currently,
only X11 is supported, which doesn't.
Based on a patch by Jonas Adahl.
When there's no useful shortcut accelerator set,
GtkShortcutLabel doesn't show any useful information.
To work around that, add a new property to set the
text to be displayed when there's no accelerator
available.
https://bugzilla.gnome.org/show_bug.cgi?id=769205
GtkShortcutLabel is a widget that displays a single
shortcut accelerator or gesture in the user interface,
and is currently used by the shortcuts window.
This widget, however, has public value as other applications
also may want to expose their own shortcuts. For instance,
it'll be useful for the Keyboard panel on Control Center and
the new shortcut editor in Pitivi, among others.
This patch exposes GtkShortcutLabel as a public widget,
and adds the necessary documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=769205
Scroll history must refer to a timespan for the values to be valid, otherwise
we return FALSE, in this case the stored event(s) should be discarded anyway.
It could be the case that the last scroll event is received long after any
previous scroll event, in this case the last scroll event discards all "old"
scroll events, and scroll_history_finish() returns FALSE because there's no
time/offset deltas in the scroll history.
This is desired so we don't trigger the deceleration effect if there was no
effective velocity, we still must reset the installed scroll cursor, so take
it out of this if() condition.
I thought I needed ot rearrange the ordering of the animation-direction
values for the parser, overlooking the fact that we already parse them
backwards to address this very problem.
It is important to know whether the returned object can or cannot
change, for a certain widget. For example to connect to the
GtkStyleContext::changed signal.
https://bugzilla.gnome.org/show_bug.cgi?id=769047
Always return an error if we fail to get a dbus proxy; the callers
are only looking whether error is set, not whether the return value
is NULL.
Use the same function for the inhibit proxy as well, and clean up
the sm_proxy in finalize.
Only update to using v2 headers/structs. The incompatible changes
to tool events are dealt with in the next commit. Pads aren't handled
in this commit either.
In the "Other Locations" view, locations can be opened from the context menu
based on their mount or volume. However, some locations, like "Computer", do not
have either of those so they cannot be opened from the context menu. In order to
fix this, the file associated with the location can be used as well.
https://bugzilla.gnome.org/show_bug.cgi?id=768657
The sizes passed are in device pixels and do not take into account the
scaling factor of the window itself. We cannot change the semantics of
the function, so let's at least add a warning for this trap door.
xdg-desktop-portal now has a portal for inhibiting session status
changes. We don't need to use it if we can talk to the session
manager, but if can't, try org.freedesktop.portal.Inhibit.
https://bugzilla.gnome.org/show_bug.cgi?id=768499
This commit adds API for adding combo boxes and check buttons to
GtkFileChooser, and getting the selected value back in ::response.
In contrast to gtk_file_chooser_set_extra_widget, these APIs are
abstract and suitable for implementation in GtkFileChooserNative.
https://bugzilla.gnome.org/show_bug.cgi?id=768499
Implement GtkFileChooserNative for sandboxed applications
by talking to org.freedesktop.portal.FileChooser. Currently,
this supports OPEN and SAVE mode.
https://bugzilla.gnome.org/show_bug.cgi?id=768499
The gtk_show_uri API doesn't let us specify a parent window. With
portals, there may be an intermediate dialog, for which it is nice
to have parent window information, to place it properly.
https://bugzilla.gnome.org/show_bug.cgi?id=768499
If we have an application that never goes idle (or takes a long time to
go idle), the close buttons in CSD decoration don't work properly.
While it's not clear why the usage of an idle was added in the first
place, keep on using it to avoid unexpected reentrancy problems, but
change the priority to G_PRIORITY_DEFAULT.
https://bugzilla.gnome.org/show_bug.cgi?id=768485
On X11, device_query_state() uses XIQueryPointer() which will return a
child window only if the pointer is within an actual child of the given
window.
Wayland backend would return the pointer->focus window independently of
the given window, but that breaks the logic in get_device_state() and
later in gdk_window_get_device_position_double() because the window is
searched based on coordinates from another window without sibling
relationship, breaking gtkmenu sub-menus further down the line.
Fix the Wayland backend to mimic X11's XIQueryPointer() to return a
child only if really a child of the given window.
That's the most sensible thing to do to fix the issue, but the API here
seems to be modeled after the X11 implementation and the description of
gdk_window_get_device_position_double() is not entirely accurate.
https://bugzilla.gnome.org/show_bug.cgi?id=768016
Our property parser stops at the first match when looking for
enums, so we need to order our values so that we don't end up
with prefixes of longer names being found first.
I noticed this when the parser tried to interpret
background-blend-mode: color-burn; as "color, with junk at the end".
It also affects animation-direction, which is also fixed here.
After introducing the CSS blend mode enum values and including
the background-blend-mode CSS property, it is very important to
actually provide an example of the new feature.
This patch adds a new demo to gtk3-demo which shows how the
background-blend-mode CSS property works.
https://bugzilla.gnome.org/show_bug.cgi?id=768305
CSS supports blend modes, in which a series of layers are
merged together according to the given operation or set of
operations.
Support for blend modes landed on Cairo, which exposes all
the commons and also the exquisites blend modes available.
Adding support for blend modes, then, is just a matter of
using the available Cairo operations.
This patch adds the background-blend-mode CSS enum property,
and adapts the background rendering code to blend the backgrounds
using the available blend modes when they're set.
https://bugzilla.gnome.org/show_bug.cgi?id=768305
Xfce4-session-manager added support for managing dbus based clients.
This patch adds support for checking if Xfce session manager is
around after trying the gnome one.
https://bugzilla.gnome.org/show_bug.cgi?id=693203
I was struggling to understand why calling
gtk_print_unix_dialog_set_manual_capabilities (...,0)
was not having the expected effect of hiding the preview
button. The initial capabilities were not applied at all.
This has most notably impact in selection buffers, because those were
shared across all selection atoms. This turned out wrong on 2 situations:
- Because the selection atom was set at SelectionBuffer creation time, the
GDK_SELECTION_NOTIFY events generated will have unexpected info if the
buffer is attempted to be reused for another selection.
- Anytime different selections imply different stored content for the same
target.
This is better separated into per-selection buffers, so it's not possible
to get collisions if a same target is used across different selections.
https://bugzilla.gnome.org/show_bug.cgi?id=768177
The sanitize_utf8() function has been copied from X11 so both
backends behave the same. This allows interaction with older clients
(mainly through Xwayland, and the STRING selection target) that
request non-utf8 text.
https://bugzilla.gnome.org/show_bug.cgi?id=768082
commit 0015ebc4a8 reworked
some of the titlebar size allocation code. Those changes
inadvertently introduced a warning when the application sets
the headerbar title widget to be hidden.
This commit fixes that warning.
https://bugzilla.gnome.org/show_bug.cgi?id=768184
This partly reverts 9f5b9c0e07, which
removed the check for GtkWidget-window-dragging in the multipress
gesture. This check is still needed for widgets which have this style
property set (e.g. menubars and toolbars) can maximize the window on
double click -- but those widgets which have it set to FALSE shouldn't
maximize the window.
Use G_FILE_ATTRIBUTE_FILESYSTEM_REMOTE to detect remote filesystems
instead of hardcoded list of filesystem types.
Bump required GLib version accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=767965
...or warning style class applied.
This particular style bit wasn't converted to the saner 3.20 way
so `entry:selected` used in place of `entry selection`.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=768025
we used to style infobars by using the .info, .question, .warning
and .error selectors directly, which used to be ok when we had just
styleclasses all over the place, now it needs to be more specific
or it interferes with everything with those styleclasses applied
like entries.
The header bar currently ignores the expand property on its
children. This commit changes the code to honor that property.
It divvies up any free space and distributes it equally to packed
children (with any left over space given out a pixel at a time
on a first come, first serve basis).
This commit also adds support for the title widget to be made
expandable.
It accomplishes this by using up the padding the title widget
is centered with.
https://bugzilla.gnome.org/show_bug.cgi?id=724332
In order to support the expand property on children, we're
going to need to look at the size of the packed children
on each side of the title widget, up front, before allocating
them (to compute how much extra allocation each expanded child
gets).
This commit lays the groundwork for that analysis by splitting
the size calculation of each side of the header bar outside
of the loop that allocates each child of the header bar.
https://bugzilla.gnome.org/show_bug.cgi?id=724332
With a headerbar, the widget in the center may be a label, constructed
internally, or a custom widget, constructed externally. The size
allocation code needs to handle either case the same way for the most
part. There's more than one place in the code that checks which of
the two widgets to use and does some operation on the selected one.
This commit simplifies the code by checking up front which one is the
center (title) widget and storing that in a temporary variable,
This allows reducing duplicated logic later on in the function.
https://bugzilla.gnome.org/show_bug.cgi?id=724332
There's some extraneous MIN() calls that have predetermined answers.
This commit drops them and then simplifies a few redudant checks into
one MIN call.
https://bugzilla.gnome.org/show_bug.cgi?id=724332
The size allocation code maintains an array of two elements,
to track the allocation of children packed into the two sides
of a header bar. Sometimes this array is indexed with 0 and 1,
and sometimes its indexed with GTK_PACK_START and GTK_PACK_END.
The latter happen to have the values 0 and 1, respectively, but
that's not really obvious.
For clarity, this commit changes the code to index those arrays
consistently, sticking to 0 and 1 across the board.
It's only possible to have a label or a custom title, not both.
The size allocate code confusingly treats them as independent.
That is confusing, because, as the code is written, it makes it
look like the space for the custom title isn't getting accounted
for.
This commit else-ifies some parts of the size allocate code for
clarity.
Firefox does a bunch of interesting things with GTK.
If the top-level GtkWindow does not have a "csd" style class associated,
Firefox will happily draw the contents of the container used to render
HTML and XUL directly on the top level's GdkWindow; on the other hand,
if a "csd" style class is found, the MozContainer will create a new
child window, and draw on it.
Then, Firefox will proceed to disable double buffering on both the
top-level window and the MozContainer (unless they are backed by the
same GdkWindow, in which case only the top-level will be
single-buffered) *and* it will add a GDK_EXPOSURE_MASK flag to the
MozContainer events for good measure (even if this is only needed for
GTK+ 2.x).
After landing the GdkDrawingContext API in GdkWindow, GTK enabled
automatic double buffering on all top-level windows backed by a native
surface, ad most users of single buffering rely on child widgets instead
of top-levels, and we'd still like to have the same double buffering
behaviour for all top-levels on all backends. Obviously, with Firefox
disabling double buffering on the top-level window, the change broke
their drawing mechanism.
Ideally, Firefox could be fixed to not disable double buffering on the
top-level window when MozContainer has a separate GdkWindow — i.e. the
CSD case — but since we did introduce a slight change of behaviour in
fringe users of the GTK+ API, let's keep backwards compatibility with
the old code for a little while longer, and create an intermediate Cairo
context unbound from the GdkDrawingContext, like we used to do until
GTK+ 3.20.
And ensure it's still visible before returning the keyboard focus to it.
Because of the extra ref, add a dispose handler that will ensure the
ref is lost (by popping down), although this should be already ensured
through other paths (eg. when the popup widget loses visibility).
This fixes a possible crash in dispose paths, where we might be restoring
focus on an already destroyed widget, and at a time where, if the toplevel
is being itself disposed, no new focus should be set.
https://bugzilla.gnome.org/show_bug.cgi?id=767849
If there are widget margins set, the whole popover will be displaced.
However the calculation of the tail position doesn't have this into
account, ending up with the tail being detached from the popover if
the margin grew too big.
We should not render the arrows invariably next to the GdkWindow edge,
but optionally displaced inside it depending on the widget margins.
Fixes the gtk3-demo "Popovers" demo case, whose GtkEntry popovers set
widget margins for some reason.
https://bugzilla.gnome.org/show_bug.cgi?id=767851
do_sort will crash if sort_func is not defined. Instead of adding a check
there in the hot path, just check for sort_func before invalidating the
sort of the underlying GSequence.
I noticed that some of the gestures did not show up in the
search results in the builder example in gtk3-demo, because
they share the same title and don't have an accelerator to
disambiguate. Include the shortcut type to handle this case.
Set a max-content-width on some of the scrolled windows to
keep things looking mostly the same, now that GtkScrolledWindow
passes along the natural size of its child.
The cellrenderer signals might be taking the grab somewhere else, at which
point it's dubious we should attempt to take the keyboard focus into the
treeview.
This concretely breaks popovers triggered from cellrenderer signals on
button press, because the treeview will attempt to grab focus
inconditionally then.
https://bugzilla.gnome.org/show_bug.cgi?id=767468
It's almost certainly a programmer error if an action isn't
activatable because its target and parameter type don't match.
This commit changes the existing g_message to a g_warning.
https://bugzilla.gnome.org/show_bug.cgi?id=767705
Previously a style cascade's parent could not have a parent itself. That
represented the two levels at which you could add a style provider: at
the screen level, with gtk_style_context_add_provider_for_screen(), and
at the style context level, with gtk_style_context_add_provider().
This commit changes no functionality, but this change will be necessary
for adding style providers in the future that apply to a subtree of the
widget tree. It relaxes the requirement that a style cascade's parent
must not have a parent, since in the future a style context may be
affected by any number of parent widgets' style contexts.
https://bugzilla.gnome.org/show_bug.cgi?id=751409
Debian stable currently ships with a 3.16 kernel, so
it doesn't have memfd available.
This commit adds shm_open fall back code for that case
(for now).
https://bugzilla.gnome.org/show_bug.cgi?id=766341
We currently use syscall() directly to invoke memfd_create,
since the function isn't available in libc headers yet.
The code, though, mishandles how errors are passed from syscall().
It assumes syscall returns the error code directly (but negative),
when in fact, syscall() uses errno.
Also, the code fails to retry on EINTR.
This commit moves the handling of memfd create to a helper function,
and changes the code to use errno and handle EINTR.
https://bugzilla.gnome.org/show_bug.cgi?id=766341
When disposing a GdkDrawingContext we should unset the association
between the instance and the Cairo context; this avoids stale pointers
in case a reference that has acquired on the Cairo context survives the
lifetime of the GdkDrawingContext.
This is a bit of fallout from 34feba1, now that we resolve
the has_indicators value earlier than realize, it becomes
possible to call gdk_window_move_resize() before realization.
Just added the appropriate checks.
Instead of associating the GdkWindow that created the GdkDrawingContext
we can directly bind the Cairo context to the GDK drawing context.
Cairo contexts created via gdk_cairo_create() go back to not having a
GdkWindow associated to them, like they did before we introduced the
gdk_window_begin_draw_frame() API.
https://bugzilla.gnome.org/show_bug.cgi?id=766675
Instead of giving out Cairo contexts, GdkWindow should provide a
"drawing context", which can then create Cairo contexts on demand; this
allows us to future proof the API for when we're going to use a
different rendering pipeline, like OpenGL.
https://bugzilla.gnome.org/show_bug.cgi?id=766675
Existing code drawing on a GDK window has to handle the direct drawing
and the buffered drawing by itself, by checking the window type and
whether or not the window is backed by a native windowing surface. After
that, the calling code has to create a Cairo context from the window and
keep an association between the context and the window itself.
This is completely unnecessary: GDK can determine whether or not it
should use a backing store to draw on a GdkWindow as well as create a
Cairo context, and keep track of it.
This allows to simplify the calling code, and enforce some of the
drawing behavior we want to guarantee to users.
https://bugzilla.gnome.org/show_bug.cgi?id=766675
The maximum content size does not increase the minimum request
but only ensures that both minimum and natural requests do not
exceed the maximum setting.
Widgets should support size requests before being realized in general,
otherwise this can cause flicker/resize at initial display time as
the toplevel window can make a request before realize/allocate.
This also makes the added testsuite/gtk/scrolledwindow.c test work again,
this was broken because we only ever calculate whether we are going
to use overlay scrollbars once the scrolled window is realized (and
the test case does not realize any window).
This patch does a couple of things:
o Removes the obscure 'extra_width' and 'extra_height' variables
making the request code exceedingly difficult to read
o Fixes the max-content-size properties introduced in bug 742281
so that they do not grow the minimum request.
o Cleanup of request code in general:
- min/max content sizes are clamped around the child request as needed
- scrollbar requests are only added in one place, after child request
sizes are calculated and without the extra_width/height thing.
Commit 023f406c96 has a typo that results
in this error:
../../../testsuite/gtk/notify.c: In function 'test_type':
../../../testsuite/gtk/notify.c:679:54: error: expected expression
before ')' token
(g_str_equal (pspec->name, "max-content-width") ||)
^
A wl_buffer has a max size of 4096 bytes, of which 8 are needed for the
header and another 4 for the string argument length (in this case), so
make sure the we only save the first 4083 bytes that are still valid
UTF8.
https://bugzilla.gnome.org/show_bug.cgi?id=767241
The allowed values for the max-content- properties depend
on the value of the min-content- properties, in a way that
our simple test is not prepared to deal with. Just skip
them for now.
xdg-shell allows desktop environments to extend the list of states
within a given range.
Use this possibility to add a new state for tiled so that gtk+ can
benefit from this.
https://bugzilla.gnome.org/show_bug.cgi?id=766860
If gtk_scrolled_window_add() has added a GtkViewport,
gtk_container_remove (GTK_CONTAINER (scrolled_window), child_widget);
or
gtk_container_remove(GTK_CONTAINER(scrolled_window),
gtk_bin_get_child(GTK_BIN(scrolled_window)));
removes both the added child widget and the viewport.
https://bugzilla.gnome.org/show_bug.cgi?id=710471
This removes leftover code from when classes where added to the style
context.
Now that they get added directly to css nodes, the classes can exist
without a style context.
https://bugzilla.gnome.org/show_bug.cgi?id=767312
With the FTS5 query syntax, when using quotes to delimit the search phrase
the '*' token must happen after the quote, or will otherwise be considered
a character to match, go through the tokenizer, and end up ignored in
result.
This reverts commit 0943c9f6b2.
The commit caused unexpected breakage in gtk3-widget-factory,
and also broke the just-added max-content-size properties.
Needed to adjust this again after applying commit 4e5ecb7
for bug 742281. Now that we also have max content size properties,
pushed the addition of possible scrollbar sizes to after the
clause which clamps the child request size into min/max content
sizes.
Commit a01fe14 changed the behaviour of popovers when the focus leaves
them to stop child popovers being hidden when the focus leaves their
parent. However they are now a bit too reluctant to hide - if the
focus passes to an unrelated popover the first popover is not
hidden. Also if the focus passes to another widget that does not
perform a gtk grab then the popover isn't hidden until the user
presses a non-movement key or clicks outside the popover.
The solution is to go back to checking if the focused widget is a
descendant of the popover, but to include popovers and their related
widgets in the ancestry chain.
https://bugzilla.gnome.org/show_bug.cgi?id=765595
This patch causes the scrolled window default behavior to change in
such a way that the natural size request of the child is unconditionally
reported, which probably should have been the case since day 1.
This should not cause significant fallout since a scrolled window is
normally used to expand/fill, eating up remaining space for scrollable
content - it will however cause the scrolled window to compete for
additional space with siblings, proportionally to the size of the
scrolled window's content.
gtk_tree_view_get_path_at_pos() mistakenly identifies the first
pixel of all but the first column in a tree view as belonging to
the previous column.
https://bugzilla.gnome.org/show_bug.cgi?id=708148
The GtkScrolledWindow has support to set the minimum content size (both
width and height) which controls the minimum space allocated, but does
not exposes any way to control the maximum size the content can grow.
After the introduction of GtkPopover, which always uses the minimum
size of it's children widgets, the lack of max-content-width and -height
properties became a concrete use case.
This patch introduces the GtkScrolledWindow::max-content-width and
-height properties. The properties will alter the minimum size of
the scrolled window, making it grow up to the set value. They also
respect the previously set ::min-content-width and -height.
https://bugzilla.gnome.org/show_bug.cgi?id=742281
Similar in spirit to
gtk_style_context_get (ctx, state, "font", ...)
but avoids the need for a style context.
This will be used to for css-styled text rendering
from css subnodes.
This is _gtk_style_context_get_pango_attributes, decoupled
from the GtkStyleContext. This will be used to drive css-styled
text rendering from css subnodes of widgets, e.g. for the value
in GtkScale.
The Wayland protocol does not share XI2's wealth of information
about individual devices, but it does provide discriminating
information about the source for scroll events. Pass this on to
the application by creating separate slave devices for these,
and setting them as source device on the scroll events.
These devices can be discriminated by their input-source property:
wheel - GDK_SOURCE_MOUSE
finger - GDK_SOURCE_TOUCHPAD
continuous - GDK_SOURCE_TRACKPOINT
https://bugzilla.gnome.org/show_bug.cgi?id=767093
fix up
GtkHeadeBar checks the window type hint to determine if the regular
buttons such as menu, maximize or iconify should be visible in the
header bar.
However, an application may very well use a "normal" toplevel window and
set it transient and modal afterwards. In such a case, the iconify
button would remain visible, and the user can hide the window, but being
a modal, the parent window would remain insensitive.
Check for the window type, modality and transient relationship to decide
whether or not the regular toplevel buttons should be visible in the
header bar.
https://bugzilla.gnome.org/show_bug.cgi?id=767052
When we emit ::draw, the widget should not have alloc_needed set
anymore. If this happens, it indicates a broken situation. Add a
warning to help tracking down why this might occur.
See https://bugzilla.gnome.org/show_bug.cgi?id=765410
When filechooer is re-used (instead of being created and destroyed
every time it's needed), it might happen that the directory the
application wishes to initially show is the same directory that
was shown last time the filechooser was used. In that case, make sure
filechooser knows that it does not need to do its default "select $pwd
or $home" routine.
https://bugzilla.gnome.org/show_bug.cgi?id=766122
adds a paragraph to gtk_text_view_get_pixels_below_lines(),
describing how it can be used together with
gtk_text_view_get_pixels_above_lines() to get the total
amount of line spacing between two paragraphs.
https://bugzilla.gnome.org/show_bug.cgi?id=747206
Calling gdk_gl_context_realize() should always result in a valid result,
so we need to provide a default implementation, to avoid a call to a
NULL function pointer.
If the popover's relative-to widget is unparented/reparented, we end
up unparenting/reparenting the popover as well. In that case, at the
moment of reparenting, the widget might have been visible (and is
thus mapped again), but priv->window hasn't been set yet.
We must first set priv->window, and then call gtk_window_add_popover(),
that way gtk_popover_map() has its prerequisites straight.
https://bugzilla.gnome.org/show_bug.cgi?id=766323
gtk_widget_set_parent() will map the widget if the parent is mapped
and the widget is both visible and child-visible. As we currently
only set the child visibility after adding the child, we immediately
map all children that are added to a mapped stack, even when they
are not actually shown. Avoid this by setting the child visibility
before adding the child, so widgets are only mapped when shown.
https://bugzilla.gnome.org/show_bug.cgi?id=766737
Use g_drive_is_removable for external drives detection. Current heuristic
fails in some cases (e.g. when removable drive is attached before login),
see Bug 765457.
Bump GLib version accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=765924
When starting a rubberband selection from an empty area, we could run
into crashes if the selection moves over the rows and then back out
to unpopulated area. Handle this case without crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=766336
Use .marks-before/after to indicate the presence of marks.
As Lapo points out, compatibility with the previous names
is not really that important, since everything else changed
around it.
https://bugzilla.gnome.org/show_bug.cgi?id=766440
Warn about the situation when we've found a resource or file path,
but gdk-pixbuf fails to give us a pixbuf. This generally means that
either pixbuf loaders are not found or the shared-mime database
is missing.
Given that Wayland has no global coordinate, the only way for gdk to
retrieve the monitor a window last entered is to retrieve it from the
GdkWaylandWindow itself.
Implement the backend specific get_monitor_at_window() to return the
monitor that was last entered by the window.
https://bugzilla.gnome.org/show_bug.cgi?id=766566
In Wayland, surfaces get an enter/leave notification each time they
enter or leave an output.
Add an API to GdkWaylandWindow to retrieve the output the window has
last entered.
https://bugzilla.gnome.org/show_bug.cgi?id=766566
Some backends (namely Wayland) do not support global coordinates so
using the window position to determine the monitor will always fail on
such backends.
In such cases, the backend itself might be better suited to identify
the monitor a given window resides on.
Add a vfunc get_monitor_at_window() to the display class so that we can
use the backend to retrieve the monitor, if the backend implements it.
https://bugzilla.gnome.org/show_bug.cgi?id=766566
It turns out that it is too hard (and in some cases, impossible)
to get this information from node positioning, so bring back the
.scale-has-marks-above/below style classes on the main node.
This should allow us to fix the 'pointy sliders'.
https://bugzilla.gnome.org/show_bug.cgi?id=766440
The GdkDragContext should only listen to GDK_GRAB_BROKEN events sent to
its own pointer device. It turns out that the passive key grabs mistake
GDK into sending a GdkEventGrabBroken on the master keyboard, which the
DnD machinery mistakes as a signal to cancel the operation.
https://bugzilla.gnome.org/show_bug.cgi?id=766442
Only generate crossing events on wl_touch.down for the virtual master
device used for touch events, and only whenever this virtual device
actually moves across surfaces. This behavior resembles better what is
expected in X11, where the pointer is warped to the touch position
on XITouchBegin.
This avoids the double emission of leave events when the pointer
emulating touch is lifted, that crossing event will be instead
generated when/if the focus surface changes.
https://bugzilla.gnome.org/show_bug.cgi?id=766314
This is required for proper integration with any other library/application that
may perform wayland API calls and poll() the wayland fd from multiple threads.
Using wl_display_dispatch{_queue}() is thread-safe if not mixed with custom
poll() usage, which GSource/GMainContext does.
Essentially, the problem is that multiple threads polling and reading
the same fd is extremely racy. Use the wayland provided API for allowing
concurrent access to the wayland display fd.
See the wayland man pages for wl_display_prepare_read(),
wl_display_cancel_read() and wl_display_read_events() for more details.
https://bugzilla.gnome.org/show_bug.cgi?id=763852
GtkScrolledWindow leans towards using the minimum size of its child
widget, unless the scrollbar policy is GTK_POLICY_NEVER. This is
probably fine for most GtkScrollable implementations out there.
Especially when using GTK_SCROLL_MINIMUM, which is the default for all
implementations inside gtk+.
However, this is not good for GTK_SCROLL_NATURAL children. eg.,
VteTerminal's minimum size is 1x1 and natural size is the number of
visible rows and columns requested by the user. We really want to use
the natural size unless the user has resized the window to change that.
https://bugzilla.gnome.org/show_bug.cgi?id=766569
This code tries to add the minimum content size, if one is set, to the
GtkScrolledWindow's size requisition. This is obvious from the check
for non-negative values of min-content-height and min-content-width.
Using MAX needlessly makes the code harder to read by implying that
there is more to it when there actually isn't.
Fall out from 0d9ebb501dhttps://bugzilla.gnome.org/show_bug.cgi?id=766569
When we are beginning to calculate the height, if the vscrollbar_policy
is not GTK_POLICY_NEVER, and there is no min-content-height, then we
need some small non-zero value to get started. The idea is to always
ask for at least enough to fit the horizontal scrollbar.
Simply put, this should be the mirror image of the corresponding width
calculation code.
Those who got used to the buggy behaviour might notice that their
GtkScrolledWindows are not as tall as they used to be.
Fall out from 55196a705fhttps://bugzilla.gnome.org/show_bug.cgi?id=766530
Sometimes on wayland we're seeing a frame draw before the first tick
callback, where the window position has not yet been updated.
With this change, the window is properly positioned as soon as
gtk_stack_start_transition returns.
https://bugzilla.gnome.org/show_bug.cgi?id=766405
Fix testsuite/a11y/about.ui GtkAboutDialog :
"CRITICAL **: atk_hyperlink_get_start_index: assertion 'ATK_IS_HYPERLINK (link)' failed"
That is set widget->priv->accessible as soon as accessible object is generated.
When accessible object is created accessible->priv->widget is set,
if widget->priv->accessible is not , then _gtk_label_accessible_update_links
exits early, thus without creating the links on the accessible side.
(This as it checks for the widget to have the accessible set before proceeding).
https://bugzilla.gnome.org/show_bug.cgi?id=766458
GTK used to not emit GtkWidget::style-updated on widgets that weren't
realized. This sped up construction of complex widgetry in the early
days of GTK3 where we instantly invalidated on every change.
We don't do that anymore, so in theory (and in my limited testing with
widget-factory) this shouldn't be a prolem anymore.
What is a problem though is that postponing style-updated leads to 2
problems:
(1) Unrealized widgets will not emit style-updated which may cause them
to not properly update their state and return wrong values from
get_preferred_width/height() etc
(2) Emitting style-updated during realize can happen too late.
When a widget is not made child-visible by its parent (common
examples: notebook, paned) it will also not be realized when the
parent is initially shown. However, when they get realized later
(after a resize of the parent), they will emit style-updated (and
potentially queue a resize) during size-allocate.
https://bugzilla.gnome.org/show_bug.cgi?id=765700
Cancelling the gesture causes the last_event pointer to become
invalid. Make a copy of the event so we can keep using it
regardless of the gesture state.
At one point, the sidebar was using gtk_treeview_set_tooltip_column,
which expects tooltips to be markup. With the listbox-based sidebar,
we don't do that anymore. So don't escape the tooltip text.
https://bugzilla.gnome.org/show_bug.cgi?id=766175
We're measuring both the width of the minimal and the maximal value for
the value gadget, but only give the value the minimal width for its
current value, resultnig in an always left-aligned value.
Fix this by assigning the width of the value gadget to the value layout
and letting pango align the text inside the layout.
https://bugzilla.gnome.org/show_bug.cgi?id=766120
Menus are placed vertically by definition, it does not make much sense
to support horizontal axis for scrolling.
Use GDK_EVENT_STOP/GDK_EVENT_PROPAGATE instead of TRUE/FALSE and add a
default case to return GDK_EVENT_PROPAGATE for unhandled events.
https://bugzilla.gnome.org/show_bug.cgi?id=765939
On X11, we get both smooth and emulated scroll events, whereas other
backends such as wayland will give smooth events only with touchpad
scrolling.
Discard emulated scroll events so that we get consistent behaviours
between backends.
Allow for both horizontal and vertical smooth events for scrolling so
that horizontal scrolling still works without emulated scroll events as
well, again for consistency between gdk backends.
https://bugzilla.gnome.org/show_bug.cgi?id=765939
Some compilers we support, such as pre-2013 Visual Studio, does not support
for INIFINITY, log2() and exp2(), so check for exp2() and log2() during
configure, and use fallbacks for them and INIFINTY if they are not found.
https://bugzilla.gnome.org/show_bug.cgi?id=766207
Split out the part where we generate/update the caches for the GSchemas
and the icons, so that it is easier to ensure that things continue to
function correctly when we have GlibEtcInstallRoot != CopyDir.
Children tend to call back into the scrolled window while being removed
and that doesn't work too well if the scrolled window is destroyed
already as Christian Hergert found out.
Consolidate the .lib's that we need to link to for GDK and GTK+ into the
property sheets, and also link to setupapi.lib as that is needed by
the port to the new GdkMonitor API.
WINBOOL is MinGW-specific, so change it to BOOL, which is universally
available.
Also, Visua Studio is more picky on where __stdcall (WINAPI) is placed, so
fix that to be in-sync with what is done in the other sources.
This only used by luck before. We are changing a property from the
::notify handler for that property. Now that GtkRevealer is notifying
the property when it stops animations on unmap, we end up in a life
lock situation where we never make it out of the notify queue.
Fix this by not restarting the animation if the widget is unmapped.
Depending of float rounding during target calculation, the size of the
GtkRevealer can be set to zero will the animation is not finished.
If the GtkRevealer is in a GtkPaned, it will be hidden and so the animation
will be stopped before it is finished.
In this case, force the emission of the child-revealed signal to let
client code know the animation is finished.
https://bugzilla.gnome.org/show_bug.cgi?id=765973
This was another very frequent use of qdata. Since we typically
have only one or two display objects, storing the display-settings
association in a simple array is faster than using object data
or a hash table.
Use of g_signal_handlers_disconnect_by_func() needs to do more work than
necessary to find all the matching handlers. Instead, just hold on to the
signal identifier and remove it directly so we hit the fast path.
Not terribly ground breaking in terms of performance gains, but its done
enough to be worthwhile.
https://bugzilla.gnome.org/show_bug.cgi?id=766049
Christian Hergert reported seeing webkit crashes with recent
GTK+. The stacktrace points at the CSS machinery calling into
GtkSettings to get the font name, and then getting surprised
by a property notification that triggers style validation.
To avoid this, query the font name xsetting right away when
we get set a screen.
The active keyboard grab can be spared then. This way the passive
key grabs allow other key combinations (eg. alt-tab) that are not
mandatory to grab here.
This will almost certainly overwritten before the widget gets
to the screen, but while we are doing this, we might as well
use the same state that we initialize the widgets state to.
Instead of creating 2 pango layouts in every draw() and on in
_get_content_size (and calling into gettext twice in both cases), just
keep the layouts around and create them in only one place.
I was somehow under the misconception that we'd get GdkEventSettings
events for all the xsettings at startup. That is not in general true,
so we need to make sure that we check for the xsettings value before
we use them, or derived fields. Update all the private getters to
do so; and fix settings_update_font_values() to cope with font
descriptions that might miss the family or size.
I mistakenly assumed that gtk_settings_init was already doing
something to trigger a notify for all properties. It doesn't,
so we have to ensure that settings_update_font_values() is
called at least once.
https://bugzilla.gnome.org/show_bug.cgi?id=765966
The wayland specification for discrete step information for scroll and
other axes reads:
| The discrete value carries the directional information. e.g. a
| value of -2 is two steps towards the negative direction of this axis.
mutter sets a value of 1 for SCROLL_DOWN events and -1 for SCROLL_UP
events.
gdkdevice Wayland backend does the opposite, it translates a positive
discrete value as SCROLL_UP and a negative value as SCROLL_DOWN, which
ends up inverting the scrolling direction.
Fix the logic in gdkdevice Wayland to use a positive value as
SCROLL_DOWN and a negative value as SCROLL_UP so that it matches mutter
and weston logic.
https://bugzilla.gnome.org/show_bug.cgi?id=765907
The fallback code for rendering builtin checks, radios
and expanders was using border parameters. With the generic
gadget borders using the same parameters, this was giving
double borders.
Before commit 6c1bee2377 we were setting an attribute of GtkNotebook
to track the pressed button if the pressed button happened on the
tab itself.
Later in the motion handling code we were checking whether the private
pressed button attribute was set or not in order to handle a tab dnd
or not.
In commit 6c1bee2377 the code changed and set the pressed button
variable unconditionally, which means, a motion event from within the
tab content triggered a tab reordering.
This happened only if the children hierarchy have a widget that bubbles
up both button press event, which sets the private pressed button
attribute; and motion events, which started the tab dnd checking the
private pressed button attribute.
A widget that experienced the regression was GtkListBox.
In order to fix it, set the button pressed variable only when it press
the tab itself, not the content.
https://bugzilla.gnome.org/show_bug.cgi?id=764395
Specifically, this URI is not supported on Windows, but GFile will
do its "best" and turn it into GLocalFile("$pwd/network"), with
spectacularly bad results.
https://bugzilla.gnome.org/show_bug.cgi?id=765858
When checking for cairo_win32_surface_create_with_format in -lcairo,
temporarily put CAIRO_LIBS into LIBS so that AC_CHECK_LIB() can
find it in weird places like /usr/local/lib, where gcc would not look
on its own.
https://bugzilla.gnome.org/show_bug.cgi?id=765793
We only keep one align flag per child, so it seems odd to
keep separate h/v expand flags. Just keep one expand flag
and interpret it according to orientation. Allow setting
the expand flag for child widgets too, though, so we can
make widget expand without interfering with the recursive
widget expand flag.
Update all callers.
Use the new possibility of expanding child widgets to make
the label of check and radio buttons expand. This fixes
unexpected behavior of these widgets in RTL in some places.
https://bugzilla.gnome.org/show_bug.cgi?id=765742
In RTL, we want to interpret GTK_ALIGN_START and _END
in the opposite way. Since we don't give gadgets a text
direction, just allow setting an align_reverse flag
to the box gadget.
If the monitor vfuncs are not implemented in a display class,
fall back to providing a single monitor object representing
the entire screen. This is not meant to be 'good enough', it
is just to provide some implementation until all backends
implement the monitor vfuncs. When that is the case, the
fallback should be removed.
If there was a piece of text in the cell, then when the edit
entry is shown for that cell, it should have a piece of text
in it roughly at the same location.
Therefore, when child widget is enlarged (child preferred
size exceeds cell size), extra width should be added by
extending either left or right edge depending on text direction.
If after that the child sticks outside of the treeivew visible region,
try to push it back inside (breaking its alignment with the
cell), again, giving preference (i.e. adjusting it last)
to either left or right edge depending on text direction.
https://bugzilla.gnome.org/show_bug.cgi?id=765471
NoSymbol is not a valid GDK symbol (it only has the concept of
VoidSymbol, for some reason, which is neither the same thing nor
produced by any sane keymap). Passing NoSymbol events through to GTK+
apps is unlikely to produce anything useful.
In particular, this meant VTE would scroll to the end of the buffer when
pressing Fn (required for Page Up/Down on Macs), as it was receiving a
keypress that wasn't a modifeir. This does not happen on X11, as the
KEY_FN keycode is above 255, so does not get sent to clients.
https://bugzilla.gnome.org/show_bug.cgi?id=764825
We don't care about the specific (possibly client-side) window that
requested the focus here, only the toplevel. Fixes mistakenly sent
focus events when the grab happens inside the current focus window.
https://bugzilla.gnome.org/show_bug.cgi?id=762756
This avoids the g_source_remove(), g_source_destroy(),
g_timer_source_new(), and g_source_set_name_by_id() in the common case.
Instead, we reuse our previous source and update the ready time to our
new deadline. We lose the coalescing with g_timeout_add_seconds(), but
that is not going to help in the common case anyway (unless you have
three hands and can scroll multiple pixelcached backed widgets at once).
https://bugzilla.gnome.org/show_bug.cgi?id=765640
In non-composited environments, we were ending up with all-black
drag icons, because nothing was drawing the background of our new
toplevel. Fix this by drawing background when we are not composited.
We don't do this when composited, since we want to allow transparent
icons.
GtkPlacesView currently provides no example of
server addresses, which may confuse users.
To fix that, add a helper popover with some
guidance on server addresses.
https://bugzilla.gnome.org/show_bug.cgi?id=756570
The documentation clearly says that the widget is not destroyed,
but we were in fact failing to keep it alive, since it was still
a child or the icon_window when we destroy that. Fix this by
reparenting the icon_widget out before. Also, deal with the
possibility that the application might destroy the widget
halfway through, for whatever reason.
I added a new test function, but didn't actually use it.
No wonder I couldn't reproduce the lifecycle issues with
drag widgets that firefox is experiencing.
Always associate a drag context with a GdkDisplay and use that when
getting a cursor for a given action.
If we don't do this, dragging on a window that doesn't use the default
display will make us use cursors from the wrong display.
https://bugzilla.gnome.org/show_bug.cgi?id=765565
Typically, there won't be any references on old frame timings except for
the most recent timing. So instead of discarding these and re-entering
gslice twice, just steal the old frame timing and reuse it.
https://bugzilla.gnome.org/show_bug.cgi?id=765592
Don't track all orphaned dialogs globally, as mixing them up with each
other would in most cases trigger errors when we try to pass bogus
values to Wayland requests.
https://bugzilla.gnome.org/show_bug.cgi?id=765474
The naming of pointers to GdkWaylandDisplay's were inconsistent.
Running the following commands in gtk+/gdk/wayland illustrate the
inconsistency:
$ grep -r '\<display_wayland\>' *.[ch] | wc -l
195
$ grep -r '\<wayland_display\>' *.[ch] | wc -l
81
This patch renames all occurrences of "wayland_display" to
"display_wayland". This is also consistent with naming in the X11
backend. A couple of whitespace changes were done as well in places
where the rename was already done, that added line breaks to long lines
that stood out.
https://bugzilla.gnome.org/show_bug.cgi?id=765474
Generate .pc files for the package, so that it would be easier for
building introspection for packages that depend on GTK+. Also split
PythonPath into PythonPath and PythonPathX64 to facilitate the build of
introspection files, which need to have Python that is built with the
same ac=rchitecture where GTK+ is built.
Clean up the formatting and spacing a bit.
When synthesizing keyboard repeat, we can potentially drift further from
the mark depending on the timing of the frame callback and how long it
took to deliver the event.
This patch attempts to reduce this by tracking from a stable epoch the
time of our next keyboard repeat.
https://bugzilla.gnome.org/show_bug.cgi?id=765567
There are various functions to access links based on their index for
a11y. We can spare quite a few lines of code by just using
g_list_nth_data instead of iterating over the list ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=765496
We perform lots of gadget allocations that require allocating a
GtkBuiltinIcon. One notable example is the scrollbar for a scrolled
window.
In the process of doing this, we often calculate baseline information that
isn't necessary. With how much this code path gets exercised, its worth
catching the result for the common case, which is that the font-description
has not changed and we are using the default language the application
was started with.
This simply caches the previous result and verifies that we can reuse it
with pango_font_description_hash() and a simple language check.
Numbers below are scrolling through a textview with GDK_KEY_Down.
Before:
SELF CUMULATIVE FUNCTION
[ 0.08%] [ 9.26%] gtk_builtin_icon_get_preferred_size
[ 0.01%] [ 8.82%] pango_context_get_metrics
[ 0.02%] [ 0.16%] gtk_widget_get_pango_context
[ 0.06%] [ 0.06%] pango_context_get_language
[ 0.01%] [ 0.02%] g_type_check_instance_cast
[ 0.02%] [ 0.02%] strlen
[ 0.02%] [ 0.02%] pango_context_get_font_description
[ 0.02%] [ 0.02%] g_list_foreach
[ 0.01%] [ 0.01%] gtk_css_style_get_value
[ 0.01%] [ 0.01%] itemize_with_font
[ 0.01%] [ 0.01%] pango_context_get_type
[ 0.01%] [ 0.01%] get_base_metrics
[ 0.00%] [ 0.01%] pango_font_metrics_unref
[ 0.01%] [ 0.01%] g_list_free
[ 0.01%] [ 0.01%] gtk_builtin_icon_get_type
After:
SELF CUMULATIVE FUNCTION
[ 0.08%] [ 0.18%] gtk_builtin_icon_get_preferred_size
[ 0.02%] [ 0.02%] pango_font_description_hash
[ 0.00%] [ 0.02%] gtk_widget_get_pango_context
[ 0.00%] [ 0.02%] g_object_get_qdata
[ 0.00%] [ 0.02%] g_datalist_id_get_data
[ 0.02%] [ 0.02%] gtk_builtin_icon_get_type
[ 0.01%] [ 0.01%] pango_context_get_font_description
[ 0.00%] [ 0.01%] - - kernel - -
[ 0.01%] [ 0.01%] pango_context_get_language
[ 0.00%] [ 0.01%] gtk_css_style_get_value
[ 0.00%] [ 0.01%] gtk_css_gadget_get_style
https://bugzilla.gnome.org/show_bug.cgi?id=765486
This allows us to decide when the R and B color channels should be
flipped with a much better granularity.
For instance, when using GLX_EXT_texture_from_pixmap to create a GL
texture from a surface we don't need to swap the R and B channels, as
the internal representation of the texture data will already have the
appropriate colors.
We also don't need to flip color channels when blitting from a texture.
Cairo surfaces are in BGRA format, but we upload them as RGBA buffers on
GLES; this means that the R and B channels are flipped in the texture
data.
Instead of doing a costly channel flip before putting them on the GPU,
we can flip the values inside the GLSL shader we use specifically for
GLES.
We cannot use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV when reading back
from the frame buffer in the software fallback path, as they do not
exist on OpenGL ES.
This will make the slow path a bit slower, because of the implicit
format conversion.
When uploading a Cairo image surface to a GL texture we cannot use
GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV on OpenGL ES, as they do not
exist in the core spec.
On some platforms we can ask the GL context machinery to create a GLES
context, instead of a GL one.
In order to ask for a GLES context at GdkGLContext realization time, we
use a bit field like we do for forward compatible, or debug contexts.
The 'use-es' bit also changes the way we select a default version,
because OpenGL and OpenGLES versions differ.
https://bugzilla.gnome.org/show_bug.cgi?id=743746
When decelerating the kinetic scroll, we can get into a position where it
looks like we are stuttering. This happens because the amount we move is
so little that it takes multiple frames to make forward progress by one
pixel.
This prevents that by detecting when we have reached the slow stutter of
the deceleration and simply stops the deceleration phase immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=765493
This has several benefits:
- Less code in GtkApplication. The accels handling is something
self-contained, and GtkApplication now delegates the work.
- For the accels functions, there is now a distinction between static
functions and functions in the gtkapplicationaccelsprivate.h header,
which makes the code easier to understand, because we have a good
overview just by reading the header.
- The struct _GtkApplicationPrivate is now easier to find instead of
being in the middle of the file.
https://bugzilla.gnome.org/show_bug.cgi?id=764879
These will become the functions present in the
gtkapplicationaccelsprivate.h header.
The gtk_application_accels functions deal with detailed_action_name's
instead of action_and_target's. action_and_target is an implementation
detail of Accels.
The added function prototype is temporary, it'll be removed in a later
commit.
https://bugzilla.gnome.org/show_bug.cgi?id=764879
When the current cursor_row is taller than the page_size we get from the
GtkAdjustment, the previous code would not actually cause any scrolling,
so make sure we just take the row after or before the cursor_row in that
case.
https://bugzilla.gnome.org/show_bug.cgi?id=765261
Windows save in hardware_keycode an information which is not so low
level and some application require the hardware scancode.
As Windows provides this information save it in GdkEventPrivate
and provide a function to get this information.
For no Windows system the function return the hardware_keycode instead.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=765259
These runtime checks were being performed whether or not we were in a
debug build. Using GTK_DEBUG_CHECK() will compile out of production
builds, as it will result in something like:
if (G_UNLIKELY(0))
which the optimizer can prune.
https://bugzilla.gnome.org/show_bug.cgi?id=765284
This first adds a common autotools module that can be included by
the Makefile.am's to generate the file lists and the g-ir-scanner/
g-ir-compiler command lines to build the introspection files.
The autotools files for gdk/ and gtk/ are then updated to generate
the full file lists needed to build the introspection files, with
the full command lines for g-ir-scanner and g-ir-compiler as NMake
Makefile modules that can be used to build the introspection files
for Visual Studio builds.
https://bugzilla.gnome.org/show_bug.cgi?id=765195
These were showing up higher in Sysprof profiles.
The simple fix is to avoid the emit_by_name() and let the interface emit
the signals directly. No function preconditions are provided since these
are internal API.
Setting the font: shorthand to something like smaller is not
in line with the css spec. Just set the font-size: property
for this.
Also fix the other font: shorthand to specify size and family
according to the css spec.
If we get gdk_wayland_seat_flush_frame_event() with no previous event to be
flushed, we fallback into the scroll event checks. However, there's no check
performed there as to whether it really scrolled, so it'd always send a smooth
scroll event with 0/0 deltas in this case.
This should be mostly harmless, but still, we should only end up emitting scroll
events if those really happened.
The frame event is also meant to compress wl_pointer.leave events, at this
point the focus surface will be definitely NULL. In the end, wl_pointer.frame
should flush the last composed event despite the pointer focus.
https://bugzilla.gnome.org/show_bug.cgi?id=765065
We must emit the cancel event with the same semantics, and towards the GdkWindow
that is currently under the touchpoint, so make proxy_button_event() deal with
GDK_TOUCH_CANCEL.
Fixes the GDK_TOUCH_CANCEL event being emitted only on the toplevel, which is
usually non-sufficient.
Add a way to associate a detailed action name with a shortcut.
If the action name is set, update the accelerator whenever
accels change on the window that the shortcuts window is
associated with.
https://bugzilla.gnome.org/show_bug.cgi?id=764975
https://bugzilla.gnome.org/show_bug.cgi?id=765134 shows
a stacktrace where we end up with arrow_gadget being NULL
despite the conditions for its presence being satisfied.
This commit makes sure we call update_arrow_gadget() whenever
any of the conditions changes. This should fix the reported
crash.
The previous patches didn't mark some strings as to be translated, and
tried to translate strings with a variable part already inside the
string, which isn't going to work.
Mark the strings as translatable with context, and also make sure to
translate static strings when getting them out of their structure.
https://bugzilla.gnome.org/show_bug.cgi?id=764585
broken from my previous commit about rounded corners, dialogs
doesn't use the "window" node, but the "dialog" node, so use the
.background styleclass in the selectors which is more generic.
Since Wayland is using libxkbcommon, it inherits X unfortunate
real/virtual modifier distinction, so we have to do the same
gymnastics we do for X to map between the two.
This should fix matching of accelerators using virtual modifiers
(modulo gnome-shell bugs regarding the handling of Super).
https://bugzilla.gnome.org/show_bug.cgi?id=764424
1) g_print() can be redirected
2) g_print() does some extra processing, such as character set conversion.
Specifically, on W32 it will detect system codepage via GetACP(),
and will convert UTF-8 output into that codepage, even though
the output should stay unchanged (whether gtk-builder-tool interprets
strings from ui files as UTF-8 is a separate matter).
https://bugzilla.gnome.org/show_bug.cgi?id=765118
MoveWindow should not be used over the pre-existing move/resize
functions, which already correctly position a window with respect
to its parent, while also taking into account the size of window
decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=765100
When clearing the icon helper, we need to invalidate it. Otherwise the
previous icon keeps lingering along.
This is not relevant inside gtkiconhelper.c where other code causes the
invalidation, but happens when external code calls
_gtk_icon_helper_clear().
https://bugzilla.gnome.org/show_bug.cgi?id=765066
Fixes a couple bugs...
- Pixel font sizes in css would render as point sizes.
- For em font sizes, where the parent size was set and not default, we would
incorrectly convert a pixel value from points to pixels.
We'll always grab the default font size in pixels so we don't keep confusing
things.
Worth noting that gtk css font-size will still behave differently than the
web. Pango interprets font-size differently.
gdk_window_reparent() already changes children list for old and new parent.
Doing so twice results in a circular reference in the list, which can hang
the application later, for example in gtk_window_show().
https://bugzilla.gnome.org/show_bug.cgi?id=764845
This makes usage of _gdk_display again when creating a window.
This is needed because there is a window created when the display
is being initialized, so it becomes a chicken and egg problem.
For now we roll back this to fix the wintab crash but we might
want to fix this again in the future by improving the wintab
initialization.
https://bugzilla.gnome.org/show_bug.cgi?id=764664
The zoom/rotate change for quartz does not build on 10.7. This change
adds zoom/rotate support in quartz only for 10.8 and following. The
problems is described here:
https://bugzilla.gnome.org/show_bug.cgi?id=760276 and here
https://trac.macports.org/ticket/51052
NSEventPhaseMayBegin was only introduced in 10.8 although documentation
says it is introduced in 10.7. Tests on 10.7 indicate that the phase
property for the Magnify event is not supported at all on 10.7
Because of our port of css animation and css transition to
progress tracker, we should not think of animated styles as
immutable objects that can map any timestamp to css values.
Rather, timestamps can correspond to different values depending
on the value of GTK_SLOWDOWN over the course of the animation.
To keep animated styles and style animations totally immutable,
we will not share styleanimations between animatedstyles, and
make a new copy of a styleanimation for each timestamp.
Not the ideal solution for this problem, but in practice leads to
much better performance on lower end hardware.
Stack does a double draw on the first frame of its animation, of
both the old contents (into a cairo surface) and the new contents.
Homogeneous stacks only need to reallocate contents on the first
frame.
On lower powered hardware where our frames will be a good deal
slower than the refresh rate anyway, we can assure a smother
experience by waiting a frame to start tweening where frame duration
will be more consistent.
glade-previewer places a gtkwindow inside another toplevel gtkwindow,
updating the shadow width for the client induces a busy loop where the
parent will grow continuously until it crashes gnome-shell/mutter.
To avoid the loop, do not update the shadow width if not dealing with a
toplevel window.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=761651
On wayland, such axes are per-tool, we must update device capabilities
on the fly as new tools enter proximity, first the slave device so
it matches the current tool, and then the master device so it looks
the same than the current slave device.
Only the management of tablets and tools is added so far. No tablet events
are yet interpreted.
As it's been the tradition in GTK+, erasers are split into their own device,
whereas the rest of the tools are meant to be routed through the
GDK_SOURCE_PEN device. Both pen/eraser devices are slaves to a master
pointer device, separate to wl_pointer's. This is so each tablet can
maintain its own cursor/positioning accounting.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
This will enable multiple "pointers" to have separate data here.
Will come out useful when adding support for tablets, as they
will have a separate cursor for all purposes.
On wayland we get separate master/slaves for each tablet, we will
need to receive crossing events for each master pointer if there's
more than one around.
Axis labels are very X specific, and are not really possible to port to other
backends such as Wayland. As such, it makes more sense to use GdkAxisUse and
GdkAxisUseFlag in order to determine the axis capabilities of a device and draw
their axes.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Because there are multiple different types of styluses that can be used with
tablets, we have to have some sort of identifier for them attached to the
GdkDeviceTool, especially since knowing the actual tool type for a GdkDeviceTool
is necessary for matching up a GdkDeviceTool with it's appropriate
GdkInputSource in Wayland (eg. matching up a GdkDeviceTool eraser with the
GDK_SOURCE_ERASER GdkInputSource of a wayland tablet).
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
On the devices and backends that support it, this signal will be emitted
on slave/floating devices whenever the tool they are interacting with
changes. These notifications may also work as a sort of proximity events,
as the tool will be unset when the pen moves too far.
For backends, gdk_device_update_tool() has been included, all that should
be done on their side is just calling this whenever any tool might have
changed.
GdkDeviceTool is an opaque object that can be used to identify a given
tool (eg. pens on tablets) during the app/device lifetime. Tools are only
set on non-master devices, and are owned by these.
The accounting functions are made private, the only public call on
GdkDeviceTool so far is gdk_device_tool_get_serial(), useful to identify
the tool across runs.
This fixes a bug that was introduced by db1b24233e.
The reason why 0:0 coordinates were passed was that SWP_NOREPOSITION was
misinterpreted as SWP_NOMOVE. That is not the case - SWP_NOREPOSITION
prevents owner Z-order change, not the window position change.
gnome-control-center is calling gtk_window_resize() on configure-event
signals which leads to a busy loop.
Avoids such a busy loop by not re-configuring a window with the same
size, unless this is coming from and xdg-shell configure.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764374
A naive way to perform an action on all parent nodes of a given node
could be to do:
while(gtk_tree_model_iter_parent(model, &iter, &iter)) {
/* perform some action on iter here */
}
However, since gtk_tree_model_iter_parent() will initialize the iterator
pointed to by the second parameter before performing the lookup, this
will not work.
Explicitly document this behaviour.
Signed-off-by: Wouter Verhelst <w@uter.be>
https://bugzilla.gnome.org/show_bug.cgi?id=573380
We use a label_sizing_box to make sure the headerbar can always contain
both a title and a subtitle without resizing when showing/hiding either
of them, but we should only do that for the height; the min width of the
label_box can be larger than that of the label_sizing_box.
Commit cdc580463e made it so that
unresizable windows can't be smaller than a set default size but it
lost the logic to ensure these windows remain at least big enough to
comply with their requisition.
https://bugzilla.gnome.org/show_bug.cgi?id=764174
When we invalidate a window we need to also invalidate all child windows
that are native (non-native are automatically invalidated as we track
invalidation once per native window only). This was done in a pretty
inefficient way, recursing over the entire tree.
This makes the invalidation much faster by only looking at the native
children of the native window we're in, filtering out those that
are not a descendant of the client side window we're interested in.
Given that there are very few native subwindows this is much faster.
We were missing all of the status directories, and a few sizes.
This was causing us to not find image-missing on systems without
hicolor icon theme (this basically only happens on Windows).
https://bugzilla.gnome.org/show_bug.cgi?id=764378
e8aa9b0440 introduced a new debug mode
that highlights resizes. Unfortunately it has the side effect of
always queueing redraws even when the debug mode is not enabled.
Make the redraw conditional.
Currently only one kind of decorative window is in use - the shape
indicator that is shown when snapping windows to the edge of the screen.
When normal toplevel class is used, its window procedure expects certain
motions from GDK (passing user data to CreateWindowEx(), registering
handle in a hash map etc), and might crash if that is not done.
Dumb window doesn't require anything, it can just be.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
Now halfleft/halfright/fullup snaps do hug screen edges as intended.
Documents AeroSnap behaviour when snapped windows are drag-resized
(currently this implementation handles this in a very simplistic way).
Don't believe GTK when it tells us that window shadow is 0, preserve
previous values (but do remember that GTK wants no shadow, in case
we need that).
Fixes a couple of bugs in unsnapping (check offset against the half
of the window; don't put pointer in the middle of the window vertically
if it still fits in the top half).
https://bugzilla.gnome.org/show_bug.cgi?id=763013
Implements gdk_win32_window_set_shadow_width().
Uses shadow width/height to adjust max tracking size, allowing
windows to be drag-resized to cover the whole desktop.
Also uses SM_C*VIRTUALSCREEN instead of SM_C*MAXTRACK.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
Indicator is a bare layered click-through native window,
painted completely by GDK, including animation.
This commit also isolates some of the more spam-ish debug logging
under ifdef.
This commit also changes the system metric used for maximal window
height for the snapping purposes. Turns out, SM_CYMAXTRACK is way
too large, use SM_CYVIRTUALSCREEN instead.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
This implements the part of AeroSnap that snaps windows when you
drag them (while moving or resizing) to the edge of the screen.
It also fixes drag behaviour for snapped and maximized windows
(if such windows are dragged, first they must be unmaximized/unsnapped).
Note that this code does not take into account the shadow width, and
because of that the under-pointer-position-preserving window moves
might not look as such for maximized windows, which lack the shadow
when maximized, but do have the shadow when unmaximized.
This commit also doesn't cover some corner-cases the same way AeroSnap does.
Also, the snapping indicator (which is supposed to be a window shape that
shows where the window will be if the drag op is stopped at its current
point) is not being drawn, all routines responsible for its creation,
moving and drawing are stubs.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
This is what AeroSnap does. If a window is being unsnapped on
a new monitor, check if the work area is large enough for the
window to fit in its normal size. If the window fits, just
reposition it so that the ratio of
left-window-edge-to-screen-edge / right-window-edge-to-screen-edge
remains the same, without scaling the window.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
It works exactly like AeroSnap.
Except for shift+win+left/right, which is left for AeroSnap
to handle (AeroSnap takes action before we get the message,
so there's no way for us to override it).
The only thing that doesn't work is shift+win+left/right on
a maximized window, for reasons unknown at the moment.
This only implements winkey+stuff behaviour of AeroSnap,
not the drag-to-the-edge-and-something-funny-happens one.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
If a layered window was hidden and is made visible, erase its
contents before showing it. GDK will schedule a redraw, but until
then we generally don't want to show old contents.
https://bugzilla.gnome.org/show_bug.cgi?id=763783
This is achieved by sending undocumented message WM_SYSMENU
to the window.
Before doing that, the window is given WS_SYSMENU style
(to enable window menu) and some combination of
WS_MAXIMIZEBOX (for "Mazimize" item)
WS_MINIMIZEBOX (for "Minimize" item)
WS_SIZEBOX (for "Size" item)
depending on which operations are currently permissible.
WM_SYSMENU is processed by DefWindowProc(), which results
in showing the window menu. We remove extra styles
at the first opportunity (WM_INITMENU message), as they
alter the way our window is rendered.
https://bugzilla.gnome.org/show_bug.cgi?id=763851
While this commit was found to make emacs windows shrink (and it was
reverted in the gtk-3-20 branch for that reason), that was the only
observed breakage, while the reversal broke several of our unit tests.
Closer study of the emacs sources revealed that it does some really
unsupportable things like doing its own X event handling behind GTK+'s
back and freely mixing sizes of GtkWindows and GdkWindows obtained in
various ways. I've filed a bug against emacs with suggestions for how
to avoid the shrinking window, regardless of this commit.
Original commit message:
It seems this branch is not needed anymore. It was originally added in
1999 to support gtk_widget_realize(), but all those reasons seem
obsolete today.
Instead just call gtk_widget_realize().
If you end up at this commit when bisecting:
There is no bug that made me remove this code, it was purely meant to be
cleanup / dead code removal. I seem to have introduced a new bug or
bisecting wouldn't have let you here. So it seems we should just revert
this commit.
Since we are really only interested in the center point of the
slider allocation, the pre-computed slider geometry is perfectly
fine, just use it always. This avoids the complication with
gadget visibility.
The slider gadget may be turned invisible as side-effect of
gtk_range_calc_slider(). If that happens,
gtk_css_gadget_get_content_allocation() returns { 0, 0, 0, 0},
which leads us to calculate a negative allocation for the highlight
node. Avoid this, by just reusing our already calculated slider
allocation in this case (it is not technically the same as the
content, allocation, but the difference hardly matter here.
https://bugzilla.gnome.org/show_bug.cgi?id=764022
These functions are supposed to return the numbers of consecutive
1 bits in each components mask as precision. However, due to a
copy-paste mistake when this code was moved around in
commit 70d689cddd, the precision
was always reported as zero. This affects only a few applications
that directly set window background on X11 windows, such as emacs.
https://bugzilla.gnome.org/show_bug.cgi?id=764210
Delay as long as possible before calling OpenClipboard(),
call CloseClipboard() as quickly as possible after that.
Don't call OpenClipboard() when we don't need to (for example,
we don't need to open clipboard to call GetClipboardOwner()).
Also, print out actual W32 error code in some cases where it
was not printed before.
https://bugzilla.gnome.org/show_bug.cgi?id=763907
Error codes can be easily looked up in an error code list
and/or googled up. Error messages, while descriptive, often
describe the wrong thing, and the messages themselves are not
part of the documentation of a function, unlike error codes.
It would be preferable to have the code, or both.
https://bugzilla.gnome.org/show_bug.cgi?id=763913
As the elements in the enum are not explicitly numbered, inserting an
element between some other elements shall change the values of elements
after the insertion. So append the new element at the end.
Anyway, no code should rely on the position of an element in an enum.
https://bugzilla.gnome.org/show_bug.cgi?id=763850
Some other widget might have mapped and raised another child window of
the toplevel in the meantime, causing the popover window to be covered.
Raise the popover window to avoid the issue.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=763627
The trash is monitored for state changes - going from empty to non-empty and the
other way round. Monitoring is done by handling change signals from a regular
file monitor. On each signal, an enumeration of the trash contents is started in
order to see if it is empty or not. This causes issues when many files are
trashed, because the gvfs trash backend is flooded with enumeration requests,
resulting in CPU usage spikes. In order to fix this, the "item-count" attribute
of the trash should be queried instead.
Replace asynchronous enumeration with asynchronous information query and update
the trash state based on the "item-count" attribute. Emit state change signal
only when the state actually changes.
https://bugzilla.gnome.org/show_bug.cgi?id=763600
gtk+ currently depends on the scaling factor and the cairo device scale
of both the backend surfaces and image surfaces to be equal.
Until now we didn't apply a cairo device scale at all and depended on the
automatic scaling of CGContexts. This works when drawing with cairo but
fails in case of image surfaces, which get requested at a too small size.
To make the quartz backend behave more like the X11 one, set the cairo device
scale on the surface in gdk_quartz_ref_cairo_surface(). As this conflicts
with the default scaling done by CGContext (we would get double scaling)
undo the CGContext scaling using CGContextScaleCTM().
This patch is based on the following patches by Brion Vibber:
https://bugzilla.gnome.org/show_bug.cgi?id=740199#c4https://bugs.freedesktop.org/show_bug.cgi?id=69796#c4https://bugzilla.gnome.org/show_bug.cgi?id=763779
When loading a per-theme settings.ini file, look for it in
the same directory where we found the gtk.css file for the
theme. Previously, we were always looking in
$prefix/share/themes/THEME/gtk-3.0/, even if the css was
loaded from somewhere else.
https://bugzilla.gnome.org/show_bug.cgi?id=641354
With this change, we now look in
$XDG_DATA_HOME/themes/THEME/gtk-3.x
$HOME/.themes/THEME/gtk-3.x
$XDG_DATA_DIRS/themes/THEME/gtk-3.x
GTK_DATA_PREFIX/themes/THEME/gtk-3.x
https://bugzilla.gnome.org/show_bug.cgi?id=641354
If the configure-event gives us the same size as we had before,
which is common for animation resizes, then try to keep the
existing buffer around. This saves us a memfd_create() syscall
on every frame.
https://bugzilla.gnome.org/show_bug.cgi?id=763350
Now that GdkWaylandDeviceData is gone, the functions prefixed
"gdk_wayland_device_" and taking a GdkWaylandSeat as first
parameter feel out of place. Renaming those makes it more obvious
that it's seat functions.
https://bugzilla.gnome.org/show_bug.cgi?id=763859
It's the same than gdk_device_get_seat() nowadays. Also, rename the
usages of GdkWaylandDeviceData to GdkWaylandSeat in the functions
affected by the removal.
https://bugzilla.gnome.org/show_bug.cgi?id=763859
When animating, we might be changing the size allocation of the previous
stack child. However, we were not querying the size in the process
meaning you would often see warnings about allocating the size without
knowing what it should be.
This simply adds an innocuous size request, since responding to last_child
sizing requests is not all that critical in the transition.
https://bugzilla.gnome.org/show_bug.cgi?id=763900
We were just relying on the drag context finalize() to destroy
the window. But with garbage-collected bindings, that might
not happen as soon as we like, so explicitly hide the window
when the drag ends successfully.
https://bugzilla.gnome.org/show_bug.cgi?id=763659
This isn't an issue at the moment. Only exporting to a file can fail
by setting by setting an error and it happens to correctly return
GTK_PRINT_OPERATION_RESULT_ERROR regardless of this code.
Still, let's make this block of code more correct to prevent future
changes from introducing broken behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=763731
We've changed our API here; what these applications are doing
used to be fine. Don't make users suffer for this by spamming their
logs in a stable release. We'll keep the warning in master.
https://bugzilla.gnome.org/show_bug.cgi?id=763796
backdrop wasn't in the mix, added and adjusted other widgets
styling not to be overridden by it when not needed.
Spotted a typo making the backdrop base color white in the process.
Using UpdateLayeredWindow() on iconic windows brings them *back* from
their iconic (minimized) state. That is bad.
As a precaution, also don't use SetWindowPos() on iconic windows.
This means that iconic windows can't be moved. That is fixable
by using SetWindowPlacement(), but there is no pressing need to do so,
as there are very few cases when windows need to be moved while minimized.
https://bugzilla.gnome.org/show_bug.cgi?id=763835
Some applications set both a default size on their gtk window and a size
request on the corresponding gtk widget.
Until now, the default size was ignored for fixed size windows, so this
had no effect and remained unnoticed, but with the recent change for
client-side decorations, the default size is now used even for fixed size
windows, which can cause the resulting fixed size window to be much
smaller than expected with the size request.
For fixed size windows, if we have both a size request and a default
size set, prefer the size request as before.
https://bugzilla.gnome.org/show_bug.cgi?id=763749
if (orientation) doesn't make a lot of sense but C doesn't complain and
instead evaluates orientation to TRUE for GTK_ORIENTATION_VERTICAL
(since that's 1), thus inverting the value sizes.
commit c3dc0d80f1 fixed the behavior of
GtkContainer widgets requesting an IMMEDIATE resize-mode.
However, GtkWindow has been stomping on resize-mode during realize()
since commit addcc64b9c. The combination
of factors that led to this not being a visible problem during all this
while is uncertain, but this now causes the Shell to continuously try to
relayout its ShellEmbeddedWindow (a GtkWindow subclass).
This commit separates the resize-mode as set internally by GtkWindow
from the one set with the external API, so that GtkWindow only changes
it when it had not been set before by the subclass.
https://bugzilla.gnome.org/show_bug.cgi?id=763650
The implicit grab may be finished so the pointer lies on top of the other
scrollbar, in this case one scrollbar should lose the hovering state, and
the other should gain it. So we must check for proximity in both indicators.
Two errors here:
1) A typo in splashscreen rectangle calculation - sets right twice
instead of setting top
2) Centering for dialogs is off because it doesn't convert
GDK virtual desktop coordinates to Windows WM virtual desktop
coordinates by adding _gdk_offset_*
https://bugzilla.gnome.org/show_bug.cgi?id=763628
The way gdk_drag_status() may be called multiple times during the
processing of drag and drop events throughout the widget hierarchy
brings some superfluous messaging going in, esp. when it's the last
request the one we want to honor, yet we emit messaging requests on
all.
This is barely appreciable in the X11 backend, but due to the design
of the wayland protocol, quick series of changes like this it have
some self-amplificating consequences which may end up flooding the
connection.
We can delegate this to a late "commit" call, performed within GDK
event management. This way gdk_drag_status() calls may be cached
and only result in windowing messaging once per ::drag-motion or
::drag-data-received event. Emitting the final status will also
avoid spurious action changes on the compositor and the other peer.
https://bugzilla.gnome.org/show_bug.cgi?id=763298
Besides the ::drag-failed handling in order to trigger the window creation
hook, add some handling of the application/x-rootwindow-drop mimetype, so
the same effect is achieved if the tab could be dropped in a destination
accepting this mimetype.
https://bugzilla.gnome.org/show_bug.cgi?id=763387
This makes toplevels pseudo-transparent wrt this mimetype, so if
the drag source offers this mimetype and not another that was
managed by the destination-side widget hierarchy, the window will
be an acceptable target for this mimetype, allowing it to trigger
whatever is meant to in the source side.
https://bugzilla.gnome.org/show_bug.cgi?id=763387
This code:
> gdk_window_get_root_origin (window, &x, &y);
> x -= root_x;
> y -= root_y;
> pointer_window = gdk_device_get_window_at_position (device, &x, &y);
was meant to find the child gdk window at coordinates root_x and root_y.
These 4 lines had 2 bugs:
1) x = x - root_x (same for y) is wrong, it should be x = root_x - x
2) gdk_device_get_window_at_position() does not give you the window
at position x and y. It gives you the window under the device
(mouse pointer) and the returns the device coordinates in x and y.
https://bugzilla.gnome.org/show_bug.cgi?id=763533
Don't make the popup follow the slider while it is open; that
makes interaction with it unnecessarily hard. Also move all the
popups inwards a little bit, so they are not flush with the
scales, which looks untidy.
https://bugzilla.gnome.org/show_bug.cgi?id=763380
We were not taking the scrollable borders into account when
requesting size for the scrolled window, which could lead
to underallocating the scrollbars at size allocation time
when we *did* take the borders into account.
This is most notable with treeviews, where we have the
headers as borders, and was causing the treeview-crash-too-wide
reftest to fail.
This test has a word that wouldn't fit in the room we have with
a window width of 100, and then we get clipped in the one case
but not the other. Make the window a little wider, so it fits.
The tree walk holds a tree iter, which will become invalid
when we either remove the row that it points to or remove
all rows.
Reset the tree walk in those cases to avoid a crash that
was pointed out by Bastien Nocera.
MacOS provides the NSEventTypeMagnify which is very similar to the
Gtk ZOOM gesture and NSEventTypeRotate which is very similar to the
Gtk Rotate gesture. Those two event sequences are translated to a
sequence of GDK_TOUCHPAD_PINCH events. This sequence is then detected
in the upper gtk layers as Gtk Zoom/Rotate Gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=760276
This widget is a bit unusual in that it is a box that acts as
the drop target, while the visible content is a child of the box.
Propagate :drop(active) to the child to make the highlight visible.
When compressing window state events, we didn't free the discarded
event after removing it from the queue, causing us to leak it. This
commit makes sure to free the discarded event after unqueuing it.
https://bugzilla.gnome.org/show_bug.cgi?id=762468
We previously considered any click inside the trough if it
hit an area that the slider might cover. Bring this behavior
back; the trough of scales is otherwise just too narrow to
hit easily with a click.
Consider this bug:
1. Open a file chooser; switch it to $HOME
2. Start typing "~/Dow" with some file that *does* exist in your $HOME
3. Delete the inline-completion selection (e.g. the "nloads" after "~/Down").
4. While you are at "~/Dow_" hit Tab. No completion will occur.
This happens because of the following.
Say the GtkFileChooserEntry is in the process of loading $HOME,
because _set_base_folder() was called. If the entry contains no text,
then the FULL_PATH_COLUMN of the file system model will be set to
unprefixed filenames from $HOME, like
.ssh/
Documents/
Downloads/
somefile.txt
Later we avoid reloading the folder if g_file_equal(old_folder, new_folder).
However, the FULL_PATH_COLUMN gets populated in completion_store_set()
out of the actual filenames that GIO returned, plus the chooser_entry->dir_part.
If the user starts typing "~/Dow" then dir_part changes to "~/", *but*
the folder won't be reloaded since it is also $HOME. However, the completion
machinery assumes that FULL_PATH_COLUMN will contain prefixed entries like
~/.ssh/
~/Documents/
~/Downloads/
~/somefile.txt
So, we add an invariant that chooser_entry->dir_part and
chooser_entry->current_folder_file must change at the same time, and
must not get out of sync: If any of them changes, then the
completions are regenerated.
A gtk_surface.present request was added to gtk_surface which takes
timestamp from some input event, and uses that timestamp to figure out
whether the window can be presented or not. If we don't have a
timestamp, we should just give up instead of making up our own,
otherwise we might steal someones focus.
https://bugzilla.gnome.org/show_bug.cgi?id=763037
The gtk_shell protocol used some half baked unstable protocol semantics
that worked by only allowing binding the exact version of the
interface. This hack is a bit too confusing and it makes it impossible
to do any compatible changes without breaking things.
So, instead rename it to include a number in the interface names. This
way we can add requests and events without causing compatibility issues,
and we can later remove requests and events by bumping the number in
the interface names.
https://bugzilla.gnome.org/show_bug.cgi?id=763001
The adjustment double properties allow values from -G_MAXDOUBLE
to G_MAXDOUBLE, which leads to overflow when calculating
max - min / 10. To avoid that, simply use a fixed page_size of 1.0.
The contents node was not getting state updates at all, and the
trough node was missing some state updates as well, because we
were not calling update_trough_state() in all the places where
it is needed.
This request actually means nothing to the upper GDK layers,
we used to preempt a GDK_SELECTION_REQUEST event, but this is too
eager, and not like things work in X11.
Originally in wayland, this event may be used for feedback purposes.
We however don't perform any mimetype-based feedback, so we can
safely ignored.
This makes data_source_send() the only place where we actually
trigger GDK_SELECTION_REQUEST, this one is conceptually the same
than the X11 selection request event.
...hopefully when needed.
By default I assume a left hand side placement on ltr languages
and the opposite in rtl, for other placements left/right style
classes can be used.
Under Wayland, popovers use subsurfaces, and we end up getting
configure events for these delivered to the toplevel they're in.
To avoid triggering resize loops, ignore configure events that
are not for the toplevel window itself.
https://bugzilla.gnome.org/show_bug.cgi?id=763351
The virtual host assigns the name of the mouse device to
"VirtualBox USB Tablet" in VirtualBox and we'd use that device as mouse.
If not, GtkTooltip is not enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=763017
Other portions of the GDK-Win32 backend make use of this function as
layered windows need to be disabled for GL windows and possibly other
parts, so make this function a private function that is available within
the backend.
https://bugzilla.gnome.org/show_bug.cgi?id=763285
Layered windows and GL do not work well together, so disable layered
windows when initiating a GdkGLContext, so that GtkGLArea programs can run
properly.
Also based on patch by LRN to address the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=763080
The default value for the double-click key in the
org.gnome.settings-daemon.peripherals.mouse schema is 400.
Use the same value as the declared default for the
gtk-double-click-time GTK+ setting, to avoid pointless
differences in corner cases.
https://bugzilla.gnome.org/show_bug.cgi?id=720950
The sidebar in the object page was using up more space than it deserves.
Replace it with a combo box in the subheader. Now that we have more space,
put the CSS node tree and the style properties in the same page again.
And add a default color like it was before.
This also fixes other issues with scale values interacting with scale
mark labels, which were buggy at least since 3.18.
When opening the value editor for any GtkAdjustment properties
in the inspector, the popover stretches out for miles, since
it reserves enough space to draw MAXDOUBLE. This is not useful.
Limit the space we reserve to 8 digits.
This removes the event_poll_fd global variable and the (ab)use of
get_default_display. It is also more consistent with other backends.
Also store display
This is not much of a test, tbh. But it will give us a convenient
dump of all GTK+ settings in continuous, which helps with tracking
down test failures that might depend on settings.
We're seeing loops where the size of some status icons constantly
dithers between 24 and 25. Since I couldn't track down exactly
where the one extra pixel comes from, just stop reacting
to single-pixel size changes.
https://bugzilla.gnome.org/show_bug.cgi?id=758893
We used to always make the labels in message dialogs selectable,
which is a bit problematic wrt. to keynav - the label can
unexpectedly 'turn blue', which irritates some people.
With the new gtk-keynav-use-caret setting, we can now only
make the labels selectable when it is required for accessibilty
reasons.
When changing tool button contents according to the toolbar-style
property, we need to update the style classes to ensure that the
visual style matches.
https://bugzilla.gnome.org/show_bug.cgi?id=760560
gnome-session takes an "app id" for client and inhibitor registration,
This app id is supposed to be a desktop file id (complete with the
.desktop extension), but gtk+ currently uses g_get_prgname ().
This commit changes gtkapplication to use the application id instead,
which is a much more natural fit. gnome-session is going to be updated
to stop using the .desktop extension, too, so everything is consistent.
https://bugzilla.gnome.org/show_bug.cgi?id=763106
We weren't using the open flags on the other locations signal, which
makes impossible for applications like nautilus to act in the same
way that for any other location where the user can choose between
opening in the current view, in a new window or in a new tab.
Add a new signal with an open flags parameter and deprecate
the other-location signal.
https://bugzilla.gnome.org/show_bug.cgi?id=754743
Use gdk_window_get_effective_toplevel when looking for
a suitable transient parent, to skip over offscreen windows
that we might encounter in the window tree. This fixes
a crash in glade.
https://bugzilla.gnome.org/show_bug.cgi?id=763110
One important aspect of non-resizable windows that we need to preserve
is that they shrink when their content requires less size.
Previous changes to allow the default size to be applied to fixed size
windows would have prevented all fixed size windows from shrinking when
their content requires less size.
Allow shrinking for fixed-size windows unless a default size was
specified.
https://bugzilla.gnome.org/show_bug.cgi?id=762974
It does not make sense to pass a for_size into the size allocation
machinery that is smaller than the min-size in that direction.
Warn if it happens, so we can track it down when it occurs.
added a min-height/width compensation too when in fine-tune mode,
so scale with marks and no labels doesn't make the scale node grow
when in fine-tune.
added a scale node padding compensation for the trough growth in
fine-tune mode, so now the scale node doesn't grow anymore when
mark labels are present.
We were failing to do that, leading to progress not disappearing
anymore after it was initially shown, in the gtk3-widget-factory
entry progress example.
Fixes bug 763023: in certain circumstances, XRRGetOutputInfo will return
a null pointer. This commit adds a check to detect and handle this
return value.
If animations are disabled, the only difference we need to make is that
we don't have to start the transition. Size requests should remain the
same.
https://bugzilla.gnome.org/show_bug.cgi?id=762996
Previous commit to address the default size introduced a regression
with fixed size windows if no default size was given, the resulting
window would end up much smaller than its actual content.
kind of a workaround, this approach is pretty unmaintainable, I
hope we'll get a CSS property for spacing directly on the parent
container (a toolbar in this particular case).
See https://bugzilla.gnome.org/show_bug.cgi?id=762397
If a window is not resizable (with gtk_window_set_resizable ()),
the size given with gtk_window_set_default_size() is ignored.
The solution to this would be to use gtk_widget_set_size_request() but
that's a GtkWidget API and therefore does not take into account the
client side decorations when in use with GtkWindow.
Refactor the code so that gtk_window_set_default_size() (which is a
GtkWindow API) gives the expected result on non-resizable windows as
well.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762974
Will make GTK+ more willing to use CSD for all normal windows without
being asked to. Lack of desktop composition will, of course, prevent
it from using CSD (in theory).
GTK_CSD=0 will force CSD to NOT to be used whenever
possible (i.e. in cases where CSD is not specifically requested
by a window, by design).
https://bugzilla.gnome.org/show_bug.cgi?id=759899
Otherwise WM-dependent default cursor is used, which does not
match our theme. Worse, later GDK will realize that we have
our own left_ptr cursor and will apply it after all, making
the discrepancy even more noticeable.
https://bugzilla.gnome.org/show_bug.cgi?id=762902
* Explicitly grab the device, setting appropriate cursor on it.
* Fix gdk_device_virtual_set_window_cursor() to just set the
cursor, without trying to check that mouse is over the given
window. Also prevent it from immediately resetting cursor.
* Alse take into account things that happen in other parts of
GDK - don't look for replacement cursor, GDK already did that,
and don't create a default arrow cursor instead of NULL,
GDK-W32 already did that up the stack as well.
Warn about inappropriate cursor == NULL argument instead.
https://bugzilla.gnome.org/show_bug.cgi?id=762711
When a gtk_widget_queue_allocate() on some widget increases the clip,
widget->parent's clip was not updated. This appraoch naively just
unions widget's new clip with widget->parent's clip.
This of course only works if widget and parent share the same GDK
window. In the cases where they don't we can't do anything and need a
better fix.
Fixes label-text-shadow-changes-modify-clip.ui reftest.
Toplevels are now true layered windows that are moved,
resized and repainted via UpdateLayeredWindow() API call.
This achieves transparency without any extra effort,
and prevents window size and window contents desychronization
(bug 761629).
This also changes the way CSD windows are detected. We now
use window decorations to detect CSDiness of a window,
and to decide whether a window should be layered (CSD windows should
be) or not.
Decorations are now stored in the window implementation,
not as a quark-based property of the window-as-gobject.
https://bugzilla.gnome.org/show_bug.cgi?id=748872
Normally works only on CSD windows, non-CSD windows continue
to use WM modal loop for drag-resizing and drag-moving. However,
if it is activated on non-CSD windows, it does work.
Has the advantage of being completely immune to AeroSnap.
AeroSnap only worked partially on CSD windows, with the only part
that worked being "don't let users drag window titlebar outside of
the desktop". Now AeroSnap doesn't work on windows moved by
this code at all, which is good, since they currently don't work
well with it due to the way shadows are drawn.
It's possible to also re-implement AeroSnap (or something similar),
but that is a story for another commit.
This code was originally intended to fix the problem of window
size and window contents desynchronization, but failed to achieve
that result in the end. Nevertheless, it serves as a foundation for
other changes to the way window resizing works.
https://bugzilla.gnome.org/show_bug.cgi?id=761629
key repeat is handled client side, which means stalls in the compositor
dispatching key release events can lead to fictious repeat events.
This commit ties key repeat to a server roundtrip to ensure the client
and server are in sync.
https://bugzilla.gnome.org/show_bug.cgi?id=757942
We don't need the key repeat rate or anything like that when
handling key up events, so do key up events first before querying
for that information.
https://bugzilla.gnome.org/show_bug.cgi?id=757942
deliver_key_event is sometimes called from a timeout handler and
sometimes called directly. We currently erroneously return TRUE
(G_SOURCE_CONTINUE) in the case where it's called directly, but to
no ill effect, since we ignore that return value. In the future,
we're going to need to call it directly in other parts of the code
where the return value would be relevant and handling TRUE, would
require adding redundant code.
Instead, this commit just changes the code to always reset the timer
manually, and never rely on glib's ability to automatically reset
the timer by returning TRUE. This makes the code smaller, too, since
there's less special casing required.
https://bugzilla.gnome.org/show_bug.cgi?id=757942
The check is not working for many containers anymore as they are not the
direct parents of their children. We want to allow this behavior in more
places.
We are actually not using the crypt() in GDK-Broadway for quite a while,
so the code implementation for MSVC is actually not used. So, it's time
to get rid of this.
Search also for the headers in include/gio-win32-2.0, as gio.h will
include those headers at some point, and arrange the include paths in a
dependency hierarchy style, top-to-down.
If the parent of a transient is not a native Wayland window (e.g.
offscreen window), the transient loop check will crash.
Check for the actual type in the transient loop check and do not assume
the parent is necessarily Wayland native.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=761156
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
If there are already a window state event for a given window queued
when the window state is changed, drop that event and queue a new event
with a changed_mask based on the state before last event that was queue
without compression.
https://bugzilla.gnome.org/show_bug.cgi?id=762468
We create and destroy gadgets inside the levelbar hierarchy here,
and if we don't explicitly remove their CSS nodes from the parent,
they stick around.
According to xdg_shell, an xdg_surface.configure with size 0x0 should
be interpreted as that it is up to the client to set a size.
When transitioning from maximize or fullscreen state, this means the
client should configure its size back to what it was before being
maximize or fullscreen.
This problem currently only occurs on weston because weston sends a
configure with size 0x0 when transitioning back from maximize or
fullscreen.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762713
gdk_display_list_devices is deprecated and all the backends
implement the same fallback by delegating to the device manager
and caching the list (caching it is needed since the method does
not transfer ownership of the container).
The compat code can be shared among all backends and we can
initialize the list lazily only in the case someone calls the
deprecated method.
https://bugzilla.gnome.org/show_bug.cgi?id=762891
The way this method is used from the GtkRange subclasses doesn't really
work well when the slider properties change as a consequence of e.g. a
style class being applied (e.g. the fine-tune style class).
In fact, there's no need to read the minimum slider size out of band,
and we can obtain the same result in a way that always work by setting a
private property on GtkRange.
Since we can use negative margins, we should not use the margin box
for the slider area. Use the border box instead, since that's what is
typically mapped to the visible area.
This commit introduces another node, called "contents", that holds the
main contents of the range. This allows for the main gadget itself to
span across the whole surface of the widget now.
The staging buffer gets allocated any time begin_paint is called
on the window. This can happen even with an empty paint region,
so we should cope with that situation. At the moment we crash
trying to post a runtime warning.
https://bugzilla.gnome.org/show_bug.cgi?id=762755
We were adding the border gadget size and the label widget size in any
case, but when calculating the width, we want the maximum of those two,
not the sum.
https://bugzilla.gnome.org/show_bug.cgi?id=760482
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
GtkWidget uses gtk_container_foreach() to iterate over children and
check whether they need their allocation reset.
However, that leaves out internal children, such as scrollbars of a
GtkScrolledWindow. Use gtk_container_forall() instead.
gdk_display_add_seat was prepending new seats to the list, which
was effectively making the added seat the new default. Since that
is probably not intended, append to the list.
Setting label-yalign should affect the border gadget, but we need to
compensate for its position by moving the child down or up, depending on
the border gadget's position, so the child never moves.
https://bugzilla.gnome.org/show_bug.cgi?id=762123
The gdkprivate-wayland.h header file is included from the top-level gdk
directory; this means that all included files referenced in the header
must be relative to the `gdk` directory, otherwise the build will fail
when the build directory is not equal to the source directory.
This commit fixes a build failure under continuous:
In file included from ../../gdk/gdkdisplaymanager.c:60:0:
../../gdk/wayland/gdkprivate-wayland.h:40:51: fatal error:
gtk-primary-selection-client-protocol.h: No such file or directory
#include "gtk-primary-selection-client-protocol.h"
^
compilation terminated.
Makefile:1155: recipe for target 'libgdk_3_la-gdkdisplaymanager.lo' failed
make[4]: *** [libgdk_3_la-gdkdisplaymanager.lo] Error 1
Except for the init function, all the visual related code is made
of gdkscreen vfuncs, so let's move it to gdkscreen-win32. This way
we avoid keeping other static variables and instead store the info
inside the screen struct.
It just looks wrong if the file chooser comes up with
"Other Locations" ellipsized. Treat it like the other
fixed entries. We only want to ellipsize bookmarks, because
their length is unpredictable.
We now draw real Windows 95 buttons.
Also split out a draw_edge() function that is supposed to emulate
Windows' DrawEdge() function. I guess we'll need it in other places,
too.
So far, this only reworks the tabs at top implementation.
Windows doesn't have support for theming tabs at left/right/bottom
so we need to figure out what to do there. Wine falls back to
unthemed code.
This is necessary for GtkNotebook so that the stack is always drawn
before the header.
And that is necessary so that the active tab can use negative
margins to overdraw the border of the stack to create a gap and
simulate old GTK2-style visuals for notebooks.
:active is reserved for "mouse button down on node", so we have to use
something else. And stack switcher and radio buttons use :checked for
the active widget, so it makes sense to use :checked for the active tab,
too.
Themes have been adapted.
TODO: Implement :active for tabs.
I am testing GTK+ master against mutter 3.19.90, so I'd
like GTK+ to survive even when the compositor does not
support the primary selection interface.
Implement it using the internal copy of the protocol. Otherwise,
we just deal with it the same than clipboard selection, just mapping
it to the PRIMARY atom instead of the CLIPBOARD one.
https://bugzilla.gnome.org/show_bug.cgi?id=762561
This protocol is an internal mirror of the primary selection drafts
being proposed for wayland-protocols. No changes besides prefix/suffix
changes.
https://bugzilla.gnome.org/show_bug.cgi?id=762561
1f74f12d9 rendered entry of keypad decimal mark unuseable for
several national keyboard layouts, this commit amends that, at
least for W32, and makes GTK+ behave more or less the same way
W32 behaves.
The patch works like this:
- When typing the first character at the keyboard or when switching
keyboard layouts, the decimal mark character will be cached in the
static variable "decimal_mark" within gdkkeys-win32.c
- in case of WIN32, gdk_keyval_to_unicode() asks gdkkeys-win32.c for the
current decimal_mark when converting GDK_KEY_KP_Decimal.
https://bugzilla.gnome.org/show_bug.cgi?id=756751
1) MSDN says that the coordinates of the maximized window
must be specified as if the window was on the primary display,
even if nearest display where it ends up is not the primary display.
So instead of using nearest display work area verbatim,
use it only to account for taskbar size, while using
primary display top-left corner (0:0) as the reference point.
2) MSDN says that max tracking size is a system property, we
should just call GetSystemMetrics() and use that.
https://bugzilla.gnome.org/show_bug.cgi?id=762629
This is a hack because we can't really rtesize the buttons.
Instead, we draw the background only over the area that they would
be drawn if they were drawn by Windows. The button is still selectable
outside of this area, but what can you do...
The way we were adjusting baselines if min-height forces
a size increase was not quite working as intended. Redo
it in a simpler way: just split up the excess and count
half of it for above the baseline and half below.
This fixes button labels in dialogs appearing too low.
It is clearly not the intention that the baseline of icons is at
the very top. The visible effect of this was that spin buttons were
higher than expeted, because the box gadget was trying to line up
the baseline of the text with the top of the buttons, forcing extra
height to be requested.
Just don't set a baseline at all for now.
That would imply the pixelcache monitors the style context for changes
and it doesn't do that.
Its only use case was opacity checks, so add
gtk_pixel_cache_se_is_opaque() instead.
We were updating the whole places sidebar when the trash changed.
This effectively removes all rows and create new ones for every trash
state change.
Although when using GtkTreeView it was somehow ok, with the new
implementation with GtkListBox this effectively locks the UI while the
trash operations are being performed.
When performing operations for i.e. 100 files, the UI can be locked
for more than 1 minute since gvfs-trash usually takes time.
To fix this just update the icon of the trash when the state of the
trash change instead of the whole sidebar.
https://bugzilla.gnome.org/show_bug.cgi?id=762677
This adds vendor and product id and axes. This reveals that
the GDK backends have quite different quality when it comes
to returning meaningful information here.
When size_allocate is overridden in widgets, but draw is not,
we can end up drawing a gadget that has not been given a size.
Warn about this, and limp along by drawing the gadget over the
full allocation of its owner widget.
https://bugzilla.gnome.org/show_bug.cgi?id=762614
Sigh.
Now that we've neutered the QEMU USB tablet, I'm finding that
spice is doing just the same nonsense. It has a fake "spice vdagent
tablet". Blacklist that as well.
Text handles use to connect to the first GtkScrollable up the hierarchy
so they can be repositioned when scrolling. It makes more sense to look
up the first child of a GtkScrolledWindow, it must be an scrollable too,
and will be the scrollable that can actually change the position of the
text handles.
https://bugzilla.gnome.org/show_bug.cgi?id=761676
... if the child is concealed and the transition type is set to NONE.
In this case, both preferred width and preferred height should be 0, but
we still can't use that to allocate a size for the child, so care about
the minimum size of the child in gtk_revealer_get_child_allocation.
https://bugzilla.gnome.org/show_bug.cgi?id=761760
We were using the enclosing location when connecting to a server, so
for instance if we were connecting to ftp://test/test it would actually
open ftp://test/ instead of the full path.
To fix it, use the full location when emitting the open location signal.
https://bugzilla.gnome.org/show_bug.cgi?id=756659
Remember the last source device we're generating multiple clicks for,
just so we can bail out if the device changed. That will just reset
the counting.
https://bugzilla.gnome.org/show_bug.cgi?id=723659
This prevents multipress sequences to possibly come from different mice.
Now the accumulated number of presses will be reset if the device changes
in the mean time.
https://bugzilla.gnome.org/show_bug.cgi?id=723659
We weren't using the open flags on the other locations signal, which
makes impossible for applications like nautilus to act in the same
way that for any other location where the user can choose between
opening in the current view, in a new window or in a new tab.
Add the signal missing parameter in order to allow it.
https://bugzilla.gnome.org/show_bug.cgi?id=754743
Previously we just checked the first character. And if that was a "-" as
in "-gtk-some-special-value", we assumed it was a number. Which it
clearly wasn't.
Test included
Containers with RESIZE_MODE_PARENT should never request layout and those
with RESIZE_MODE_IMMEDIATE should only request it for updating CSS.
Fixes clutter embeds (like the tray icon embed in gnome-shell)
continuously requesting relayout when all they want to do is relegate
relayout to Clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=758893
On Visual Studio, unlike MinGW, manifest files are embedded via
including the manifest file as a resource file in the projects, not
via the .rc file. This means that the line in the .rc file that
specifies the manifest file would cause trouble, so that line gets
removed when the full gtk3-win32.rc is generated on Visual Studio builds,
otherwise 2010+ Visual Studio will complain when compiling the .rc file.
Also, the inclusion of winuser.h will cause warnings during the
compilation of the .rc file.
Fix this by isolating the Win32 resource portions of gtk-win32.rc.in to
gtk-win32.rc.body.in and:
-On MinGW, construct the full gtk-win32.rc by doing the winver.h and
winuser.h inclusion first, then append the contents of gtk-win32.rc.body,
and then appending the line to embed the manifest file.
-On Visual Studio, simply copy the gtk-win32.rc.body to gtk-win32.rc,
and generate the full libgtk3.manifest file.
https://bugzilla.gnome.org/show_bug.cgi?id=762311
The first check was the wrong way around.
The second check made the function look wrong. Invalid ID is actually
the special case that should be handled first, so write the function
like that.
We were forcing the size to be at least min-height, but we left the
baselines as they were, which had the effect of making text e.g
in entries 'stick to the top'.
With this change, we adjust the baseline to keep the ratio of
baseline to height unchanged.
The code for adjusting the center widget allocation in case
of uneven sides never worked right in RTL. This was finally
noticed for tabs with close button, which commonly use a
centered label.
The significant change here is a memory leak fix in init_xrandr15.
The rest of the changes makes init_xrandr13 and init_xrandr15 more
parallel, and simplifies init_multihead.
GdTaggedEntry needs that. Though there's probably a bunch of work left
inside GdTaggedEntry to make it look cute again (like storing the area
it reserves for itself to allocate tags in).
Add a gtk_shell.set_startup_id request, so the application can communicate
to the compositor the startup id that it received through the
DESKTOP_STARTUP_ID envvar, or other means.
When running with a Wayland compositor which doesn't support the
xdg_shell interface, gtk+ will segfault while trying to access the
corresponding wl proxy.
Check for xdg_shell support and do not use Wayland if not present, so
that it can fallback to X11, hoping that Xwayland is usable.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762258
we use to animate "all" in the transition, this seems to trigger
some weird gtk sizing issue, restricting the transition to just
the needed properties fixes.
We were notifying when an unmount operation was performed. However,
creating notifications from the gtk+ library is not that expected, and
makes notification handling difficult to do from the application point
of view since we cannot dismiss those notifications.
This cause issues like notifications of unmount drives stay there after
a system reboot, which confuses the user.
Instead of that, remove the notification handling for mount operations
on gtk+ and instead create a new signal on the gtkplacessidebar in order
to inform applications using it about an operation about to start.
Only drawback about this is that the GtkFileChooser loses its
notifications when unmounting, that although we could use the new signal
to do it, we actually don't want to notify from any part of gtk+ for
now.
https://bugzilla.gnome.org/show_bug.cgi?id=753351
Some of the translated strings in the cups printbackend are short
and generic and might occur in other contexts. Give them disambiguating
message contexts to avoid translation problems.
There is no point in attaching and then committing the same buffer if
there was no damage. This will also make us do less unnecessary backfill
read backs, for the cases where we paint with an empty paint region.
https://bugzilla.gnome.org/show_bug.cgi?id=762120
If a after-paint was scheduled but nothing was painted, for example when
the it was scheduled by a subsurface wanting to update its position,
we'd still try to read back from the backfill cairo surface and update
the committed cairo surface reference even though no buffer was
attached.
Fix this by adding a new state, 'pending_buffer_attached', which is only
true if a buffer was attached during frame. Only when this is true will
the backfill be read back and the committed cairo surface reference be
updated.
https://bugzilla.gnome.org/show_bug.cgi?id=762120
The following changes were done to (hopefully) achieve backwards
compatibility while allowing themes to change the size of the indicator.
(1) Deprecate the property.
(2) Change the default value of the property to 0. If it is not 0,
use the property's value for the indicator size. This should make
all programs that actually set it keep the size they set it to.
(3) If set to other values than 0, use min-width/min-height of the
check/radio node to size the indicator. This allows themes to change
the size.
(4) Fall back to the previous default size of 16px. This way themes that
do not set the size keep the same behavior.
...the sizing is still off, waiting for Benjamin to add the magic,
probably the icon shadow is missing, not sure since it's blurry.
This needs to be reverted in case the sizing won't get fixed.
That way we can let ::cancel callers to override the visual
result of the operation (eg. when detaching notebook tabs on
NO_TARGET).
Also, document gdk_drag_drop_done() so it is mentioned that
this is a one-shot call.
https://bugzilla.gnome.org/show_bug.cgi?id=761954
We should conform to a minimal set of reasons for the gtk side to emit
a better GtkDragResult than GTK_DRAG_RESULT_ERROR. This fixes the notebook
tab DnD feature, where we rely on GTK_DRAG_RESULT_NO_TARGET.
In the wayland side, unfortunately we can't honor either NO_TARGET nor
USER_CANCELLED, we don't know of the latter, so we could return false
positives on the former.
https://bugzilla.gnome.org/show_bug.cgi?id=761954
Sometimes default tab labels ("Page <n>") get created on-demand,
and in that case, we were forgetting to put them below the tab
node in the CSS node tree. The visible result of this is that the
heuristics for when to give notebooks background in Adwaita fail
in some cases. So, make sure to always place the label below the
tab node.
Instead of drawing them as the background, use -gtk-icon-source.
Also size the marks properly.
Because Windows doesn't have indeterminate radio buttons, use a
cross-fade between checked and unchecked radiomark instead. But
unlike previously, use CSS cross-fade() syntax to draw it.
Padding adds up. A selector like "actionbar box" matches any box
inside an actionbar, so nested boxes accumulate more and more
padding. The intention clearly was to just give padding to the
topmost box that is the direct child of the actionbar's revealer.
https://bugzilla.gnome.org/show_bug.cgi?id=762036
Clip children to their window's size. That way no overdraw happens for
these widgets. But don't clip the handle.
We might in the future consider not clipping un-shrinkable children.
https://bugzilla.gnome.org/show_bug.cgi?id=762021
This requires adding code to do math on number values:
gtk_css_number_value_multiply()
and
gtk_css_number_value_try_add()
were added to achieve that.
Some tests are included.
GtkCssNumberValue is now a base class for numbers.
Actual numbers are now implemented in GtkCssDimensionValue. The name is
borrowed from the CSS spec, so there.
This is in preparation for calc(), as calc(50% - 5px) is valid CSS
but has 2 units. Instead, add a function to query a value's dimension
(so we can differentiate lengths from numbers) and add a function to
query if the value contains percentages.
Margins can be negative, and if we are not careful, then
content+padding+margin can end up with negative dimensions,
which can upset pixman and others. This commit ensures
that a gadget will not request or draw boxes with negative
dimensions, and get_border_allocation and get_content_allocation
will not return boxes with negative dimensions.
This fixes a crash in the paned separator drawing code that
can be reproduced by setting separator padding to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=759657
With the location entry up in the header bar in save mode, we can
end up with the search model being in use when the user types in
the location entry. In this case, we don't make the Save button
sensitive as we should.
Having two entries in the dialog is somewhat confusing anyway,
so just stop the search when the user starts typing in the location
entry.
https://bugzilla.gnome.org/show_bug.cgi?id=761757
This reverts commit 572e9a0402.
_gtk_box_get_children was not doing exactly the same than
gtk_container_get_children does, because the latter uses the forall
implementation of GtkBox that takes into account the children pack mode while
the former just iterated the list of children. This broke the order of
the buttons in a GtkButtonBox when they were packaged with PACK_END.
Entries in treeviews and similar embedded situations don't really
work well if their height is forced to be big. Take out the min-height
for these.
https://bugzilla.gnome.org/show_bug.cgi?id=761686
It does no good to iterate through a series of mime types to call a
function when the eventually-called function,
_gtk_quartz_get_selection_data_from_pasteboard() in this case, gives the
wrong answer and stops the iteration on all but one especially if that
one isn't first.
The one is "image/tiff" and the quartz pasteboard function will return
any image type Quartz knows about for it, so lose the iteration and use
only "image/tiff".
A problem that has been observed in polari is that links in tags
are clickable all the way into the margin. This problem is caused
by gtk_text_view_get_iter_at_position ignoring the return value
of pango_layout_xy_to_index. Instead, pass it back as a boolean
return value. This is technically an API break, but we've allowed
ourselves to change return types from void to gboolean before.
Always have Since: annotations at the very bottom, use the correct
ClassName::signal-name/ClassName:property-name syntax, fix a few typos
in type names, wrong function names, non-existing type names, etc.
The first time a window is shown we should always call SW_SHOWNORMAL.
Understand whether to call SW_SHOW or SW_SHOWNORMAL and the specific
ones for the temporary windows depending on IsWindowVisible.
This also fixes the problem when calling gtk_window_present and
the window is snapped to the left or right of the screen.
This patch is based on the patches provided by Yevgen Muntyan
and Aleksander Morgado.
https://bugzilla.gnome.org/show_bug.cgi?id=698652
If the window is iconified we want to restore the window
to get the proper size instead of showing it normal which
would change the size of the window.
https://bugzilla.gnome.org/show_bug.cgi?id=698652
Things like color affect symbolic icons, but not colored icons, while
other css properties like -gtk-icon-effect affect colored icons, but not
symbolic ones.
If the theme has rounded corners for fullscreen, we don't tell the
window manager that we are now fully opaque, which then makes things
less efficient than they should be.
https://bugzilla.gnome.org//show_bug.cgi?id=761571
When we don't get a baseline passed in, we want to basically
center the children inside the allocation. There was an attempt
in the code to do 'internal baseline alignment', but it had the
side effect of moving the contents to the top when we don't get
a baseline passed in. Remove it for now, this needs some more
infrastructure to do properly.
https://bugzilla.gnome.org/show_bug.cgi?id=761363
These were affected by the recent change to level offset handling.
At the same time, make the test files more realistic by updating
the level offsets when we set a custom range.
We had some odd special-casing for the lowest and highest offset
that did not quite work. The new rule is simple: If the value
is between offset n-1 and n, it gets the style for offset n.
https://bugzilla.gnome.org/show_bug.cgi?id=761416
There are a couple of issues with the way that buffers are handled in
wayland in right. These issues mean that:
- buffers can get leaked at a fairly fast clip under the right
conditions. This leads to the OOM killer kicking in and
gnome-shell and gnome-terminal (for instance) showing memory
usage in the high gigabytes range.
- drawing can happen to a shared memory buffer at the same time
the compositor is reading out the pixels. This can lead to
glitching in drawing and other undefined behavior by the compositor.
This changeset reworks how buffer management is done in the code to try
to address both problems.
The first change (commit 2c300081) addresses the leak by dropping code
that has an unchecked cairo_surface_reference call. The code is dropped
rather than fixed, because it has a more serious issue: it's overarching
purpose is to deal with shared memory buffer contention with the
compositor, but it does it in a racy way and so fails at that mission.
The second change (commit 40e91195a) moves what layer of the code buffer
release events are handled. This is an organizational change in the
code, with no functional changes, but it's important for the last change
in the changeset.
The last change (commit c80dd549) adds back code for dealing with shared
member buffer contention in a race free way. The new code is careful to
never reuse a buffer that hasn't been explicitly released by the
compositor.
Right now we use one buffer for both staged changes (freshly painted
changes waiting for the frame clock to send to the compositor) and
committed changes (changes actively being read by the compositor
process). This creates a problem in the event we need to stage updates
at the same time the compositor is processing committed updates: we
can't change what the compositor is actively processing.
The current solution for handling this contention is to allocate a
temporary buffer on the spot at the time the updates are staged, and to
copy that buffer back to the shared buffer later. The problem, though,
is that the copy to the shared buffer currently happens as soon as
the updates are finished being staged, not when the shared buffer is
done being processed by the compositor.
In order to address that problem, this commit changes the code to always
stage changes to a dedicated staging buffer. The staging buffer is
used exclusively by the client until the client is done with it, and then
once that staging buffer is committed, the client never writes to that
buffer again. If the client needs to stage new updates, it allocates a
brand new staging buffer, draws to it, and back fills the undrawn parts
of the buffer from a copy of the contents of the committed buffer.
As an optimization, the compositor has the option of releasing the
committed buffer back to the client. If it does so before the client
needs to stage new updates, then the client will reuse the buffer
for staging future updates. This optimization prevents having to allocate
a new staging buffer and the associated cost of back filling
that new buffer with a readback of the committed buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
Right now we handle buffer releases coming from the
compositor in a central place. We add a listener when
first creating the shared buffers.
This is problematic because a buffer can only have
one listener on it at once so users of the buffer
can't get notified when it's released.
This commit moves the buffer listener code from the
centrally managed display code to the cursor and window
code.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
The client and compositor share access to the window
pixel buffers. After the client hands off (commits)
the buffer to the compositor it's not supposed to write
to it again until it's released by the compositor.
The code tries to deal with this contention by allocating
a temporary buffer and using that in the mean time. This
temporary buffer is allocated by a higher layer of the code
when begin_paint returns TRUE. Unfortunately, that layer of
the code has no idea when the buffer is released, so it ends
up blitting the temporary buffer back to the shared buffer
prematurely.
This commit changes begin_paint to always return FALSE.
A future commit will address the contention problem in
a different way.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
There are a few places where we destroy a cairo surface and
then nullify it. This commit changes those to use
g_clear_pointer instead.
It also drops a cairo_surface_finish call that is unnecessary
https://bugzilla.gnome.org/show_bug.cgi?id=761312
The name surface is really overloaded when dealing
with wayland windows.
To alleviate ambiguity, this commit changes the name
of the "surface" and "subsurface" members to have
a wl_ prefix.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
Don't allow syntax like
at top left circle
but follow the spec about requiring the at <position> right before the
comma.
This is porbably because
circle at 10px 10px
could be interpreted as
circle 10px at 10px
with the now disallowed syntax, too.
Test included.
Don't hardcode 96 for dpi, but instead use the value of the -gtk-dpi
property (that mirrors the GdkScreen's dpi if it wasn't set explicitly).
This makes these values scale when the large font setting in
control-center is enabled.
During the gadget conversion, the drawing of discrete levelbars
was unintentionally changed to draw a wide trough but narrow
blocks, which does not look great. So go back to the previous
way of drawing things.
https://bugzilla.gnome.org/show_bug.cgi?id=761428
Now selecting a widget by class name no longer works.
This is probably most relevant for users outside of GTK that want to
style their own widgets. Those widgets should now either add their own
style classes (if they want to adjust existing CSS) or use
gtk_widget_class_set_css_name() themselves (if they want to get rid of
all "upstream" styling).
And reset the grab_location in the ::released handler of the multipress
gesture.
Previously, when leaving fine-tune mode, the ::released handler of the
multipress gesture would call stop_scrolling, which calls
range_grab_remove and resets the grab_location. The ::drag-end handler
is executed after that, and only unsets priv->in_drag if the
grab_location is MOUSE_OUTSIDE, which it never was, since the ::released
handler already reset it. This lead to priv->in_drag being set even
though no dragging was in progress anymore, which e.g. made shift
pressed after leaving the fine-tune mode entering it again.
https://bugzilla.gnome.org/show_bug.cgi?id=761402
The fallback behaviour of get_work_area () divides the
screen width and height by the window scaling factor, but
those values are already scaled down.
https://bugzilla.gnome.org/show_bug.cgi?id=761474
Calling _gtk_file_consider_as_remote() with a NULL argument
results in warnings being thrown.
Note that query->priv->location being NULL is a state that does
not seem to be invalid by itself.
This could happen if you do search-as-you-type in a filechooser,
which has a filter that does not match anything *and* the current
"place" selected is "Recent".
https://bugzilla.gnome.org/show_bug.cgi?id=761552
Instead of
/org/gtk/libgtk/theme/$THEME-$VARIANT.css
look at
/org/gtk/libgtk/theme/$THEME/gtk-$VARIANT.css
and that way mirror the directory layout of real themes.
Set _GTK_THEME_VARIANT to empty string when default theme variant
is used. This will allow to understand whether _GTK_THEME_VARIANT
is not supported or default variant is requested.
https://bugzilla.gnome.org/show_bug.cgi?id=761476
This test was failing in continuous, where the tests are running
in a VM with disabled animations. Make the test adapt to that
situation by changing the rui on the fly if we find that animations
are disabled.
This test was failing in continuous, where the tests are running
in a VM with disabled animations. Make the test adapt to that
situation by changing the reference ui on the fly if we find
that animations are disabled.
Make the preview command parse options properly, turn the ID into
an --id=ID option, and add a --css=FILE option that allows to
specify a css file to use for previewing.
This is useful for e.g. previewing the reftest .ui files with
their corresponding .css.
Since 39c2d12330,
priv->operation_mode == OPERATION_MODE_BROWSE no longer
guarantees that priv->browse_files_model is the current
model of the list - we are only switching the models after
loading the new directory. Avoid triggering the assertion
in show_and_select_files by checking if we have right model
before calling it.
https://bugzilla.gnome.org/show_bug.cgi?id=761209
Temp windows without parent are used frequently in our testsuite;
using g_warning on them causes the tests to fail, which is not
useful. Reduce the warning to a g_message.
This lets us do fallback in case an image format is not
supported, and also lets us provide solid-color images.
We don't support image fragment notations.
See ttps://www.w3.org/TR/css3-images/#image-notation
https://bugzilla.gnome.org/show_bug.cgi?id=761318
Instead of spamming stderr with g_warning, use the new
emit_error method of the GtkStyleProviderPrivate interface
to emit an error if loading an image fails.
Currently, GtkCssProvider can emit ::parsing-error only during
the actual parsing, although the documentation hints that it might
happen at other times.
This commit adds a emit_error method to the GtkStyleProviderPrivate
interface that will let us emit errors from the compute() implementations
as well, which can be useful (e.g. if an image fails to load).
In some situations (no header bar, save mode), hitting Escape
would not do anything because the entry ate the key event.
Fix this by telling the entry to only handle Escape when there
is something to do, such as switching back to the path bar.
https://bugzilla.gnome.org/show_bug.cgi?id=761026
We should not hardcode a scale of 1, this leads to
pixellated upscaled images at scale=2, even if the source
is an svg. By passing the proper scale, we can load the
svg at the correct size.
When creating icon info objects for unthemed files, we don't
really have a nominal size, so we pass 0 to mean 'load at
original size'. However, this is not what was happening.
To make this possible, add variants of some pixbuf loading
functions that take a scale factor instead of a desired size,
and use those when we don't have a nominal size.
Eventually, we should probably remove the examples that rely
on geometry support, since they probably don't work correctly
anymore. For now, just disable the warnings.
Grabbing must stay a bit longer until all other backends than x11/wayland
catch up with GDK DnD, so ignore deprecation flags are used on those. The
uses of GdkDeviceManager can be entirely avoided though.
People might put all sorts of gunk in their .XCompose file, in
the hope that XLib makes sense of it. Even if we don't make sense
of it, we shouldn't abort, but instead ignore the lines we can't
understand. Pointed out in
https://bugzilla.redhat.com/show_bug.cgi?id=1301254
We connect to the titlebar widgets change notification regardless
whether it is internally created or not, so don't make the signal
handler disconnection conditional on that either.
We need to unset the titlebar manually before chaining up
in destroy, otherwise we trigger the template invariant
checking - GtkWindow would eventually unset it, but too late
for the invariants checking code in gtk_widget_destroy.
Presently, Gtk will only send a startup notification completion message
for the first window that is shown. This is not good for the case of
GtkApplication, where we are expected to participate in
startup-notification for all windows.
We have avoided this problem by manually emitting the startup complete
message from after_emit in GtkApplication.
Unfortunately, this causes problems for windows that are shown with a
delay. It is also a dirty hack.
The reason for the original behaviour is simple: there is a static
boolean in gtkwindow.c which controls it. We remove this.
Instead, clear the startup notification ID stored in GDK when sending
the completion message. GtkApplication will re-set this the next time
an event comes in which needs startup-notification handling. In the
non-GtkApplication case, newly shown windows will still not send the
message, since the cookie will have been cleared.
Finally, we remove the hack from GtkApplication's after_emit.
This will probably cause some regressions in terms of lingering startup
notification messages. The correct solution here is to always use
gtk_window_present(), including when merely opening a new document (with
a new tab, for example).
https://bugzilla.gnome.org/show_bug.cgi?id=690791
gtk_editable_get_selection_bounds() returns UTF-8 character offsets,
but gdk_pango_layout_get_clip_region() wants byte ranges, so convert
from one to the other.
With English, this is especially visible for passwords, which use ●
as the invisible character.
https://bugzilla.gnome.org/show_bug.cgi?id=761128
This was a thinko - what we sometimes do for signal names is to
use I_() to intern them (to avoid a strdup), but I_() is not
currently available in gdk, so lets just skip this
microoptimization for now.
When the spinbutton grows larger, distribute horizontal size to the
entry and vertical size to the buttons.
Obviously, horizontal size only matters for horizontal spinbuttons and
vertical for vertical spinbuttons.
The font features demo started calling the Harfbuzz API directly
starting from commit 9de3b24c20. Harfbuzz
is an implicit dependency of Pango on some platforms, but it's not part
of the public dependencies; this means that we cannot expect to link to
Pango and automatically get Harfbuzz symbols to link against —
especially when things like --as-needed are in play.
This change triggered build failures on non-Unix platforms, fixed by
commit 2a9967731a, as well as build
failures in Continuous, with this error message:
/usr/lib/gcc/x86_64-gnomeostree-linux/4.9.3/../../../../x86_64-gnomeostree-linux/bin/ld:
font_features.o: undefined reference to symbol 'hb_tag_to_string'
//lib/libharfbuzz.so.0: error adding symbols: DSO missing from command
line
collect2: error: ld returned 1 exit status
In order to get the font features demo to build everywhere we should
take an explicit, though optional, check on Harfbuzz, and conditionally
build the font features demo with the right compiler and linker flags.
The fonts features demo now uses fontconfig APIs via PangoFT2, which makes
the code not build on non-Linux, so only include this demo in the build
on UNIX.
Add more features to the list, allow selecting script/language
from the set that is supported by the font, indicate which
features are present in the font for the selected script/language,
and expand the default specimen to cover latin, cyrillic and
greek.
It looks like the gnome-continuous headers haven't quite
caught up yet, so try __NR_memfd_create instead.
If that doesn't work, i'll likely just add in a fallback
code path.
The tmpdir is used for a wide assortment of things, and
can easily fill up. If it fills then desktop will start
crashing with SIGBUS errors.
This commit changes the shm pool allocation code, to use
memfd_create, instead, so the shared memory files will
be anonymous and not associated with /tmp
https://bugzilla.gnome.org/show_bug.cgi?id=761095
(1) Keep priv->text_allocation for the area used by the text
(2) Compute all text coordinates with the help of priv->text_allocation
As a side effect the get_text_area_size and get_frame_size vfuncs are
now unused. If we wanted them back, they should get a single use durig
size_allocate() and then their results should be stored for further
processing.
This complicates refactorings, so remove that feature. It's not used
anywhere and doesn't play well with nodes the way it's implemented.
If we want it back, we can add it back later.
Changing the visibility of child widgets in size-allocate does
not work well with out current allocation and layout machinery.
To avoid the visual fallout, just keep the arrow buttons visible
and only change their sensitivity.
https://bugzilla.gnome.org/show_bug.cgi?id=754868
We don't want to let baseline adjustment shift the child
out of the original allocation. This is purely a sanity
measure - in practice, the baseline should always be bigger
than the child_baseline.
We were adjusting the allocation to line up baselines before
calling gtk_widget_size_allocate_with_baseline, but that function
is doing this alignment internally anyway and expects to be given
a 'fill' allocation.
Move the allocation adjustment code down into
gtk_box_gadget_allocate_child where it only affects child gadgets,
not child widgets.
Make the theme follow our documentation for the various .csd and
.ssd style classes: They all go on the window node. For now, just
add the new selector; the old one will be removed when mutter has
been updated.
https://bugzilla.gnome.org/show_bug.cgi?id=760714
When measuring children while distributing a given height,
we must measure them for the given width that goes with
the height. Otherwise, things will go wrong if some of the
children do actual width-for-height. This was showing up
as misaligned images in anaconda.
https://bugzilla.gnome.org/show_bug.cgi?id=760967
The pointer position is queried to properly trigger the prelight
updates on the new row below it. We store the last coordinates
though, and track crossing events to unset these, so it's safe
to just update_prelight() here on these.
Check that non-native window are indeed children of the event window and
only then confirm that they should be drawn.
Fixes Glade thinking that it's okay to have the draw function do
different things depending on what window to draw. (This should really
be fixed in Glade.)
There's no reason to insta-crash when something goes wrong. Just don't
do anything stupid.
Also, remove the SPCIAL_CONTAINER() exception. Every case where special
containers needed this, it is wrong and made containers draw children
multiple times.
The text view draw function was leaving its cairo context
with a transformation after drawing to all the border windows,
which lead mis-drawing in gitg. Avoid this by moving the
gtk_cairo_transform_to_window call inside the existing
cairo_save/restore calls.
https://bugzilla.gnome.org/show_bug.cgi?id=760942
Add a query implementation to opacity property. Also fix the assert in
gtk_css_style_property_register() to allow registering properties with
query but without assign function.
https://bugzilla.gnome.org/show_bug.cgi?id=760933
The build glue for collecting all the assets in Adwaita as
resources was assuming that they are all pngs, and tried to
preprocess them into embedded GdkPixbufs.
Fix it to leave svgs unmolested, so they can be recolored
at runtime.
If we fail to load the image for a -gtk-recolor() expression,
fall back to using the image-missing icon instead of crashing,
and include more details in the warning message.
Previously, we were only showing the size of the allocation
and clip area. But there is no good reason to hide the position
of these rectangles, so add them, in the traditional format
of X geometry strings: wxh+x+y
GtkShortcutsWindow is among the 'cheating' containers that iterate
over indirect children in forall, and this is now triggering
an assertion in gtk_container_propagate_draw.
For now, just exclude the cheating containers from the assertion.
Eventually, this needs a better solution.
create_shm_pool doesn't need the width or height, it just needs
the total size. By passing it in, we're requiring it to redo
stride calculation unnecessarily.
This commit drops the width and height parameters and makes the
function just take the total size directly.
https://bugzilla.gnome.org/show_bug.cgi?id=760897
Right now, we assume the stride for the image surface needs to
be 4 byte aligned. This is, in fact, true, but it's better to
ask cairo for the alignment requirement directly rather than
assume we know the alignment rules.
This commit changes the code to use cairo_format_stride_for_width
to calculate a suitable rowstride for pixman.
https://bugzilla.gnome.org/show_bug.cgi?id=760897
create_shm_pool unlinks the temporary file a little,
too late. It should be unlinked before ftruncate()
is called for two reasons:
1) if ftruncate fails, the file is currently not
getting cleaned up at all
2) in theory, if the file is public some other process
could muck with it
This commit just moves the unlink call a little higher
up.
https://bugzilla.gnome.org/show_bug.cgi?id=760897
Button state was being kept in two separate variables, which lead
to slight confusions in DnD that caused the notebook to ignore the
first click after DnD happened from (within) it. Unify these two
into one, which helps us keep better track of the really pressed
buttons.
gdk_rectangle_union will happily add all the worlds pixels
to the union if the initial rectangle is initialized to all
zeros. Therefore, explicitly check for an empty rectangle
before calling it.
This function does not ignore empty rectangles. Since this
is a fairly subtle point about the behavior, it is worth
spelling this out in the documentation. We've had a bug
open about this for a long time:
https://bugzilla.gnome.org/show_bug.cgi?id=464528
Move code to properly reinsert the tab label to where it belongs.
The if has the distinction between reparented-to-dnd-window and
just-changed-the-gdk-window-to-draw-to right there.
https://bugzilla.gnome.org/show_bug.cgi?id=760754
The new function, gtk_render_background_get_clip answers the
question: what pixels are affected if I call gtk_render_background ?
The long-term goal is to have APIs that answer this question for
all rendering primitives.
Commit 8e975b2 (Bug 753969) introduced check of parent accessibility.
Consequently it is not possible to save file if executable attribute
is not set, which might happen for some gvfs backends. Let's assume
that the folder is accessible even if the attribute is not set.
https://bugzilla.gnome.org/show_bug.cgi?id=760881
The viewport itself doesn't move, so we cannot use it as the pixel
cache's background. Use the bottommost using element instead, which is
the viewport's child.
This might need adaptations in themes as we want the backgroud to be
opaque to speed up pixel cache performance.
Use gtk_box_gadget_reverse_children and gtk_css_node_reverse_children
to flip the children of the header_gadget and the tabs_gadget when
appropriate.
Add new CSS node tests to verify that the node order is updated
as expected in all cases.
These functions will be automatically called by the windowing backend.
The usual hooks to run this from in gtk/ shouldn't even happen, but
it is worth to document which calls are expected and which aren't.
If the grab window is destroyed the grab will be implicitly removed,
although we won't get GdkSeat:ungrab called in order to clear our
internal window<->seat relation entirely. Setting a weak ref will
nullify the pointer we keep on the seat to the window, avoiding the
expected crashes.
Due to implicit grabs, we basically can guarantee that the pointer
won't have any buttons pressed at the time of wl_pointer.enter.
Seems like a good place to unset any button modifiers that might
have been left stale by compositor grabs.
When this is in use, there's essentially a bunch of dead code here.
When all backends are ported, we'll be able to remove grab/cursor
management plus a bunch of source-side event handlers.
This includes managing input events and source-side DND events,
as well as setting the appropriate cursor and emitting the signals
that are expected in this mode of operation.
This function (most similar to gtk_drag_get_cursor() helps figure out
the right cursor that applies to a given action. To be used by the
various backends.
We've traditionally left GTK+ to handle the input side of things,
letting GDK only manage the windowing-specific messaging. This
way of splitting responsibilities is not compatible however with
some backends, we must fold then input management at the DnD stage
into GDK (and backends) domain.
The gdk_drag_context_manage_dnd() call is meant to be the entry
point for this mode of operation, if the drag and drop operation
becomes managed, the caller (i.e. gtkdnd.c) doesn't need to perform
grabs, nor manage input events itself.
As a consequence of this, different aspects now belong to the
backend GdkDragContext implementation:
- Because the caller doesn't see keyboard events anymore,
keyboard navigation must be managed in GDK, so is the decision
of the current action based on modifiers/button pressed.
- Because the caller won't see input events in general, the lifetime
of the drag and drop operation is now communicated through the
::drop-performed, ::dnd-finished and ::cancel events
- Because the caller doesn't participate anymore on the action
being chosen, the pointer cursor must be set by the backend.
The caller is rather notified of the final action through the
::action signal.
The caller is still responsible of dealing with the corresponding
GdkSelection, ensuring its ownership and communicating the supported
mimetypes.
... and remove the also forgotten void function that lingered around
with it.
Fixes opacity=0 parts like inactive spinners or sort indicators in
treeview headers being drawn since last commit.
Oops.
Previously, we had a special cae to draw subwindows of widgets.
This is not necessary as conformant widgets should be able to properly
render themselves when all windows need to be painted.
From now on assume that is the case.
We therefore paint nonnative GDK windows "inline" by just returning TRUE
for gtk_cairo_should_draw_window() for those windows.
This speeds up hilighting different rows in the listbox gtk-demo example
tremendously (by a factor of 10 or more) as the previous code was
O(<number of non-window subwidgets> *
<number of subwindows>) which in the listbox example were ~15,000 and
~2,000 respectively.
When using forall(), only list the revealer, which lists the box
containing all the children. When using foreach(), bypass revealer and
box and list all children added to the box.
Derived classes like GtkSourceView with their own ::key-event
handler need access to this, in order to make their keynav
as nice as the builtin one, wrt to caret visibility.
https://bugzilla.gnome.org/show_bug.cgi?id=760748
And use it to handle kinetic scrolling in the GtkScrolledWindow.
However, dropping the delta check causes the X11-based kinetic
scroll to break since we don't have the stop event here. Correct handling of
xf86-input-libinput-based scroll events is still being discussed.
https://bugzilla.gnome.org/show_bug.cgi?id=756729
This adds support for the new wl_pointer events available in v5.
The wl_pointer.axis_source events can be ignored for the purposes here, the
main reason they exist is so that the combination of axis_source=finger and
axis_stop triggers kinetic scrolling. We don't need to care about the source,
axis_stop is enough for us to tell us when we're scrolling.
The wl_pointer.frame events group events together and is intended as a
mechanism to coalesce events together. This for example allows us to now
send a single GTK scroll event for a diagonal scroll. Previously, the two
wl_pointer.axis events had to be handled separately.
The wl_pointer.axis_discrete event sends mouse wheel clicks where
appropriate, and is translated into up/down/left/right scroll events.
https://bugzilla.gnome.org/show_bug.cgi?id=756729
Since a41f02f9b1, GtkIMContextSimple
uses threads to load X Compose files. It does that every time a new
im context object is initialized, so we can easily end up with multiple
threads accessing the shared global_tables list at the same time.
Use a lock to prevent that.
https://bugzilla.redhat.com/show_bug.cgi?id=1276432
To ensure that the title moves to the other side as expected
in RTL, use GTK_ALIGN_START/END instead of GTK_ALIGN_FILL
when packing the title gadget into the vertical box, and
flip the alignment when the text direction changes.
This is mostly search and replace ala
GtkButton => button
GtkWindow => window
.button => button
or removing style properties that aren't used anymore like
-GtkButton-default-border: 0
Most uses of builtin icons (check and radio buttons,
expanders, etc) are placed next to labels, so they should
be properly positioned wrt to the baseline. Lacking anything
better, give the builtin icons a baseline that places the
center of the icon at the strikethrough position.
The 'mad hack' that GtkAccelLabel used to affect the GtkLabel
draw function broke with the introduction of gadgets, since
the positioning is no longer relative to the widgets' allocation
at the time of the call, but rather to the gadgets allocation.
Instead of coming up with an even madder hack to keep this
working, give the GtkLabel draw function knowledge about accel
labels.
https://bugzilla.gnome.org/show_bug.cgi?id=760663
Previously this setting would just invalidate the whole CSS tree and
thereby hopefully avoid all cache usage.
Now, we actually don't cause extra invalidations anymore, but instead
avoid ever inserting anything into the cache when this setting is set.
This essentially copies the previous cache implementation. With one
caveat: It is now attached to and maintained by the CssNode, not by the
CssStyle.
And this is important because styles may be reused in incompatible
situations which would cause cache collisions and lead to broken CSS in
weird situations.
For now, the split out style cache doesn't cache anything. This is
mostly to make sure that bisections of wrong caching behavior will
bisect down to the commit that actually adds caching.
Use a vertical box gadget for the overall expander, and a
horizontal one for the title row. This lets us get rid of
all the custom allocation code here.
So far, the box gadget is always allocating all children the
full size in the cross axis. This behavior corresponds to the
align-items: stretch behavior in
https://www.w3.org/TR/css-flexbox-1/#align-items-property
This commit implements the other modes described there.
While widgets have halign/valign properties that we can use for
this, the API for inserting gadgets has to change to take an
extra align parameter. All callers have been updated to pass
GTK_ALIGN_FILL, since that corresponds to the previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=760668
From gtk_widget_path_iter_set_object_name documentation:
"When set, the object name overrides the object type when matching CSS"
Update gtk_widget_path_to_string to match this behaviour.
This is sometimes needed, and calling into actual icon theme
code just for it is confusing - the resulting icon does not
depend on the icon theme at all.
https://bugzilla.gnome.org/show_bug.cgi?id=760536
This prevents WM from drawing shadows around tooltip windows,
which, in Adwaita, should have no shadow and are CSD-ish (which means
that tooltip window is larger than it looks, and WM draws the shadow
only on the outside, leaving a gap between the visible tooltip edge and
the shadow).
https://bugzilla.gnome.org/show_bug.cgi?id=759898
With Mingw-w64 fstat() can be an inline function that
calls _fstat32() or _fstat64(), depending on some macros.
And if LFS is enabled, fstat() is defined to turn into
_fstat32i64() or _fstat64(). And some/all of the above
might also be macros as well. Side-step all that mess
and excplicitly re-define fstat as _fstat32, which is
guaranteed to use a version of "stat" struct that
has 32-bit size and time fields, which is what we want.
https://bugzilla.gnome.org/show_bug.cgi?id=760615
While rescanning the object tree, we were emitting ::object-selected
signals, possibly causing wild blinking in the application window.
Don't do that.
https://bugzilla.gnome.org/show_bug.cgi?id=760572
Commit 0b96b8a1 set margins via css, but accidentally changed the
semantics of margins for separators in popovers so that any separator
in a gtkpopover had a margin. This meant that the separators in
GtkListBoxes in popovers also had a margin around their separators, and
this is not what we want because it doesn't match separators in
listboxes not in popovers.
https://bugzilla.gnome.org/show_bug.cgi?id=760427
If a GtkGestureSingle is set as touch-only, pointer events would be
discarded without giving an opportunity to the regular GtkGesture
handler to manage those.
Because the pointer events weren't actually managed by the gesture,
gtk_gesture_get_sequence_state() (rather unhelpfully here) will resort
to returning GTK_EVENT_SEQUENCE_NONE, which is in turn interpreted
by _gtk_widget_consumes_motion() as "may be handling the events for
this sequence", because gestures in this state presumably handle
the events, just that it's not "claimed" yet.
Instead, use gtk_gesture_handles_sequence(), which will perform the
expected check on the event sequence being managed, as we expect
here.
When a tab drag starts, we need to move the tab label into the drag
window via gtk_widget_set_parent_window().
If we don't unparent, but just unrealize the widget, we don't lose the
cssnode position.
GtkNotebook does not switch the current page if all pages are hidden. So
it may be that no visible page exsits, but there still is a current
page set.
We culd clear the current page, but I'm unsure about backwards
compatibility.
So instead, this new function handles that case.
This allows reworking the content node to do real height-for-width.
The content node also takes care of border width, but we might want to
have the toplevel do it or just get rid of it.
Deprecate initial-gap, tab-curvature and tab-overlap properties. All
their features can be achieved using CSS.
This CSS achieves the same effect as a 10px initial gap:
notebook header {
margin-left: 10px;
margin-right: 10px;
}
A tab overlap of 10px can be achieved via:
notebook tabs {
margin-left: 10px;
}
notebook tab {
margin-left: -10px;
}
And tab curvature is essentially the same as padding or border on a tab.
We skip sides with 0 border width in render_border, but when
we collect sides with the same style, we may pass the 0 width
down to render_frame_stroke anyway. So skip width 0 sides
there as well.
Instead of taking the border and manually removing it from the
allocation, render our background over all the border allocation box, as
that's more correct and does not take padding into account twice.
The GtkGesturePan behavior of locking onto certain orientations may
come across as confusing, and is not strictly necessary for mice and
other pointing devices.
As GtkGesturePan is also a GtkGestureDrag, we just use the same
callbacks on both gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=759670
When a cursor is specified in gdk_seat_grab(), the cursor is reverted as
soon as the pointer enters or leaves another window.
To avoid this issue, store the grab cursor separately, so we force-apply
it in ::set_window_cursor(). Also, unset early the seat info from the
window on gdk_seat_ungrab(), so the next time switch_to_pointer_grab()
happens we end up picking the cursor set for the window underneath the
pointer window.
Based on a patch by Olivier Fourdan <ofourdan@redhat.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=760213
the vertical padding from the headerbar has been removed, now the
sizing is done with min-height, this avoids title and subtitle
labels making the headbar.
We are getting the mime data destroy notify called when we
destroy the surface in finalize. Trying to set the XSync counters
at this time is a) pointless and b) yielding an X error because
the counters have already been destroyed.
To avoid this, unhook the damage tracking before destroying
the surface.
https://bugzilla.gnome.org/show_bug.cgi?id=760188
We are setting mime data with a destroy notify on the cairo
surface to get notified when cairo registers damage for the
surface (in that case, it clears the mime data, calling the
destroy notify). Unfortunately, the destroy notify is also
called when we remove the mime data ourselves, which was
not intentional.
Use a flag in the window impl struct to ignore the callback
when we are clearing the hook.
The assumption that MIN() takes care of all infinities here
turns out to be wrong. We were getting inf and -nan for some
combinations of 0 width/height and corners, leading to invalid
matrices and cairo errors.
https://bugzilla.gnome.org/show_bug.cgi?id=759668
Instead of creating an intermediate pixbuf, just render
the window surface onto the new surface. Doing things this
way lets us avoid the cairo_surface_mark_dirty() call in
gdk_pixbuf_get_from_window(), which is not generally safe
to call on 'random' surfaces - it asserts that the surface
has no mime data attached, and the X11 backend uses mime
data for damage tracking purposes...
We destroy the widget that is wrapped around the drag window
when the object data on the drag context gets cleared. Destroying
the window before that happens leads to unpleasantries. E.g. we may
try to access the frame clock, which doesn't exist anymore, and
things go downhill from there. So, keep the window alive for
a little longer.
We destroy the widget that is wrapped around the drag window
when the object data on the drag context gets cleared. Destroying
the window before that happens leads to unpleasantries. E.g. we may
try to access the frame clock, which doesn't exist anymore, and
things go downhill from there. So, keep the window alive for
a little longer.
Renaming the files from -dark to -inverse makes it more obvious
that this is not a dark variant in the sense of the 'prefer-dark'
setting, but rather a separate theme (sharing the same CSS).
Replace the cursor-color and secondary-cursor-color style
properties with the caret-color and -gtk-secondary-caret-color
CSS properties.
For the 'auto' value of these properties, we keep the same
behavior that we used to have when the style properties are
not explicitly set.
This property is defined in http://www.w3.org/TR/css3-ui/#caret-color.
We also add a -gtk-secondary-caret-color property, since GTK+ has
supported differently colored split cursors in the past. Unlike
CSS, we don't support the weakly defined auto keyword, and just
use currentColor as the initial value.
X11 has the notions of "transient for group", and while it's an ICCCM
violation, it's commonly used and documented that a window manager
would treat a window with transient_for set to None to transient for all
windows of its group.
gtk uses this when an application sets a dialog type window but does not
specify an explicit transient.
While this works on X11, there is no such thing as groups in Wayland and
the closest equivalent which is set_parent() in xdg-shell takes only one
parent. This is what is used for modal dialogs.
To get something similar in behavior to what is available on X11, a
solution is to update the parent() of the dialogs without transient when
the active surface changes.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=759161
Quite a few applications use GTK_WINDOW_POPUP to create various
temporary windows and place then on screen. That works fine on X11 but
on Wayland there is no global coordinate system for regular surfaces.
If the application is using a gdk temp window and set a parent with
gtk_window_transient_for(), the gdk wayland backend has all it needs to
create a subsurface that can be placed at will by the application.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=759738
If the background is transparent, we can't use it for the input shape,
since that will be empty. Draw a box with rounded corners irectly
instead, in fully opaque black.
https://bugzilla.gnome.org/show_bug.cgi?id=759905
I misunderstood what the overlay is good for: We need to allocate
it the full size of the widget. since we are using it to render
a background gradient *over* the application-rendered color.
At the same time, save some 100 lines of code by using an icon
helper as gadget, instead of handling the icon manually.
gtk_render_content_path is expecting the full box dimensions,
not just the content area. So, add the border before calling it.
Note it is still possible to have some separation between the
color and the border, by setting padding.
Recent gettext has a feature to allow consumer projects to supply their
own string extraction rules for XML files, in ITS format.
Gettext still ships the rule for *.ui, but it would be better
maintained in the upstream project.
https://bugzilla.gnome.org/show_bug.cgi?id=760202
Transitioning between linear gradients like
linear-gradient(to top, yellow, green) and
linear-gradient(to left, yellow, green) was yielding
nonsensical results, with the gradient line jumping around
wildly. Fix this by falling back to stupid image interpolation
for these cases.
Always returning a left_ptr if we can't find anything better
broke firefox application-specific fallback for missing cursors.
Keep that working by only doing the fallback for the CSS cursor
names, not for things like hashes.
https://bugzilla.gnome.org/show_bug.cgi?id=760141
Always returning a left_ptr if we can't find anything better
broke firefox application-specific fallback for missing cursors.
Keep that working by only doing the fallback for the CSS cursor
names, not for things like hashes.
https://bugzilla.gnome.org/show_bug.cgi?id=760141
This tests that horizontal boxes flip their child nodes
according to text direction to maintain the left-to-right
ordering of child nodes for both text directions.
CSS nodes have a linear sibling relationship; this is supposed
to correspond to left-to-right placement in horizontal arrangements.
This commit explicitly sets the text direction to rtl if the
filename ends in .rtl.ui, so we can test differences in node
tree layout between text directions.
Follow the generally white background we use everywhere else.
This is not perfect, we get double borders when the search bar
is shown, as can be seen in gtk3-widget-factory.
Gadgets don't connect to style-changed for widget nodes, and
GtkImage uses its widget node for the icon helper. The visible
effect of this is that symbolic icons don't change color when
switching to the dark variant of Adwaita.
Fix this by manually invalidating the icon helper.
Instead of the weird PathElt struct, generate a quick-n-dirty parser
that parses CSS selectors into GtkWidgetPath elements.
Based on a patch by Benjamin Otte.
In https://bugzilla.gnome.org/show_bug.cgi?id=601425 the annotations
were changed to int as they not only take the predefined enum values
but also user defined values registered through gtk_icon_size_register()
As a result the typelib doesn't contain any information about
GtkIconSize for those arguments and the Python docstring only
shows the corresponding Python type "int".
This changes the argument docs to mention the type explicitly
so the Python doc generator can add a link to Gtk.IconSize
which contains the most useful predefined values.
https://bugzilla.gnome.org/show_bug.cgi?id=757411
The Visual Studio versions that we support supports locking functions in
their CRT, so support that to optimize things a bit. Also update the
config.h.win32.in so that its entries are more in line with the ones in
the autootols builds, and make sure that we use UNIX line endings.
Use a custom, empty theme and stop importing reset-to-defaults.css.
This avoids overwriting initial values, so our initial value
filtering works better.
Drop the custom style printing implementation in gtkcssnode.c and
instead reuse the existing gtk_css_style_print function, extending
it a bit to suit our needs.
Instead of computing values, just recognize initial values by
having no CSS section. Also do away with the show-initial flag, and
just always filter out initial values. The flag can come back when
it is needed.
The node declaration has all the information we are printing
here (except for visibility). At the same time, redo the format
to print the information in selector format, and indicate
(in)visibility by enclosing the selector in square brackets.
The previous way of manually juggling the visibility of the
labels doesn't work anymore, now that gadgets of invisible
widgets don't allocate space anymore.
This uses the same function for dumping CSS nodes and styles
as the CSS node test. It can be used to test aspects of inheritance
and matching, as well as initial values.
No actual tests yet.
Add a gtk_style_context_to_string function that can serialize
a CSS node or tree of nodes, optionally including CSS properties
as well.
This will be useful in writing tests.
It turns out we don't really need to use a separate gadget for the
infobar, if all we do is chaining up to the parent GtkBox which already
uses a gadget.
Just remove all the boilerplate.
The notion of a separator being wide or not does not make sense when a
theme can set any CSS property on it, and
separator-width/separator-height are on their way out for
min-width/min-height.
Instead, just rely on the CSS gadget; we can stop using wide-separators,
separator-height and separator-width, and at the same time deprecate the
space-size style property of GtkToolbar.
67ab00e01e removed the fake configure code in gtk_window_show() and
replaced it with a simple gtk_widget_realize(). The initial allocation
code in realize() only allocates the natural size or the last requested
size which now no longer is set, resulting in a too small first allocation.
This builds a configure request to compute the allocation size instead
which includes default size, CSD etc..
This problem could be seen in case of a GtkPaned in a GtkWindow with a
default size set and the pane position set as well. The first allocation
would be the natural size of the GtkPaned which would clamp the pane
position if too larg. Only the second allocation would fill the parent
window using the now wrong pane position.
https://bugzilla.gnome.org/show_bug.cgi?id=759705
In that case, code expects an arrow gadget to be present but we're not
creating it in every occurrence.
Fix it by ensuring there will be an arrow gadget when reserve_indicator
is TRUE.
GtkViewport currently tries to draw a background over the bin window.
The feature is a bit broken at the moment, as it does not take into
account padding that might have been set on the GtkViewport, but in
general it does not seem very useful, and goes somewhat against the CSS
box model where every widget/gadget is responsible to draw its own
background. For a fix, we could either have the viewport gain a "bin"
gadget, or we could stop drawing the background.
As it isn't clear that there are any users of this feature, stop drawing
the background; a client can achieve the same effect by drawing the
background on the widget inside the viewport itself.
As GtkCssNode has the visibility concept, it makes sense to mirror it in
gadgets.
Do what visibility does in widgets: Hidden gadgets can't be drawn or
allocated and request a 0x0 size.
Note that just like widgets, gadget visibility must not be changed in
size request, allocate or draw handlers.
GtkWidget::child-visible has no equivalent yet, code will have to
emulate that manually.
Previously, the ID was only set on the CSS node as a side-effect
of calling gtk_widget_get_style_context. This was showing up
in CSS style tests as nodes lacking their IDs.
The test needs to be updated for the renamed :dnd pseudo class.
We also need to add a .errors file for the deprecation errors
that we are now producing.
Putting the deprecated class behind the official variant does
not work for the case of :focus and :focused - we were matching
:focus and leave a dangling 'ed'. So, put the deprecated classes
before the official variant, and explicitly mark them as deprecated.
Split the CSS docs off from the GtkCssProvider docs and
give them their own chapter. Among other things, this commit
introduces more or less complete definitions of the syntax for
the supported selectors, a complete list of all supported
properties, and definitions for their values. This includes
documentation for GTK+-specific properties such as -gtk-icon-source.
I hadn't noticed the :drop() pseudo state in the CSS4 Selectors
spec when I added this a while ago. This commit renames
GTK_STATE_FLAG_DND to GTK_STATE_FLAG_DROP_ACTIVE and adds
:drop(active) as equivalent to the :dnd pseudo state.
We don't actually do anything when the label is not selectable
except for consuming the event, which breaks for instance titlebar
drags with labels that contain links. Simply deny the gesture in
that case to allow the event to bubble up normally.
https://bugzilla.gnome.org/show_bug.cgi?id=759798
... on older Visual Studio versions, where isinf() is not available, and
copy the isinf() implementation from gdk/fallback-c89.c to
gtk/fallback-c89.c.
gdk_widget_get_frame_clock can return NULL. In particular,
this can happen when the drag window is destroyed at the end
of a DND operation. Handle this gracefully when it happens.
This adds tests for animation-name, animation-duration,
animation-timing-function, animation-iteration-count,
animation-direction, animation-play-state, animation-delay
and animation-fill-mode.
we have to do some assumptions for css selectors limits for this
particular case, so for split headerbars to work correctly the
actual haderbars need not to have the titlebar class applied.
The gtk_builtin_icon_get_default_size_property returns a const char *,
in a way such that some compilers insist that something that is of a
pointer value be returned, so fix that by replacing 0 with NULL.
When clicking "Cancel" on the "Do you want to use GTK+ Inspector?"
dialog, unregister the update_debugging idle handler. Also, steal
reference to 'inspector_window' while gtk_destroy_widget(), to make
further gtk_window_update_debugging() calls as a no-op.
https://bugzilla.gnome.org/show_bug.cgi?id=759764
The GetSize callback *can* assume that minimum and natural are
non-NULL. Buy minimum_baseline and natural_baseline can and
will be NULL, so handle that. This was causing crashes e.g. in
pavucontrol.
applications with split headerbars has a container in the titlebar
slot so the .titlebar style there needs to be reset. Since we can't
go backward with selectors I assumed that any csd application
sports a headerbar hence relying on that styling and resetting
the .titlebar styleclass.
Move the gtk_css_gadget_allocate call before the
gtk_label_update_layout_width call. This fixes the
statusbar label in widget-factory page 2 coming
up fully ellipsized.
Transient nodes should not propagate style-changed signals
that can cause widgets to get reallocated. This was causing
treeviews and iconviews with pixbuf cells to be constantly
resized and redrawn.
Clearing the icon doesn't appear to be necessary with
todays code, and it has the unfortunate side-effect of
temoorarily hiding the icon's window, which breaks grabs
and makes us miss the button release event when the icon
is changed from a button press handler.
We're going to add back the original struct definition removed by
a6e4de28, because using the typedef breaks all sorts of things like
gtkmm and WebKit, and having separate struct definitions allows us to
change the types in GdkBorder from gint16s to gints without breaking
ABI.
Functions requiring CoInitialize are called just in two places:
- the filechooser thread which calls its own CoInitializeEx
- the dnd code
Moving CoInitialize in the dnd specific init is cleaner and
we can pair it with the corresponding CoUninitialize since
CoUninitialize should be called as many times as CoInitialize.
Note that it is ok to call this function multiple times, so it
will not break if another codepath will need it in the future.
The patch also replaces the deprecated CoInitialize with the
equivalent call to CoInitializeEx (already used in the filechooser).
Empty boxes end up setting the clip to { 0, 0, 0, 0}, so warning
for a width or height of 0 triggers false positives. Instead,
initialize the clip to clearly invalid values.
As part of this conversion, remove the hardcoded padding around
the label.
Unfortunately, we cannot use the main gadget for drawing the frame
decoration, since we want to draw a custom border instead of the
stock css border that gadgets insist on drawing for us. Therefore,
add an extra gadget with name border and use it just for rendering
the frame.
Otherwise the gtk_grab_remove() calls on widget destruction will happen
on the default window group, which may leave the real window group
of the popover with a dangling pointer if it is not the default one.
This could be seen on the inspector, open a popover in the properties
list and close the window with alt-F4.
Invisible nodes don't change the first/last-child status of the nodes
after/before them. That means we don't have to just check the state of
the adjacent node when modifying this state, but all their siblings
until we hit a visible node.
The same way, a node is not the first child if it has no previous
sibling, it is the first child if it has no previous visible sibling.
This is important for caching in the global lookup cache.
CSS min-width and min-height on the slider node fit this
perfectly. We still fall back to the slider-width and
slider-height style properties if the CSS properties are
not set.
In most places, we can do with the pointer/keyboard of the default seat
instead of the client pointer. We can also remove some code from
gdk_input_init() because we know for sure there's no floating devices to
care about here.
There's places where we still need to deal with floating devices, which are
unseen by seats. Ignore deprecations and keep using GdkDeviceManager until
we can forget about floating devices.
There's places where we still need to deal with floating devices, which are
unseen by seats. Ignore deprecations and keep using GdkDeviceManager until
we can forget about floating devices.
There's places where we still need to deal with floating devices, which are
unseen by seats. Ignore deprecations and keep using GdkDeviceManager until
we can forget about floating devices.
There's places where we don't set a seat yet, plus the places
outside GTK+ where events are created, we should warn and fall
back to the master device seat with these.
1e1064398c broke the build.
When I run make, I should make sure to run it in the right directory.
And not in the gtk/ subdirectory that will never build widget-factory...
The clipboard emit events after the button we connected it to was
already destroyed (on application close for example), so make sure we
don't try to use that dead button.
Gdk Wayland backend walks up the transient windows tree, but does not
check for cycles when doing so.
As a result, if two or more windows are transient to each other, the
Wayland gdk backend will enter an infinite loop.
While this is clearly a bug in the application, gtk+/gdk should be more
robust and handle such errors more gracefully.
To avoid looping infinitely at various point in the code, check for a
possible loop when setting the transient relationship and deny the
request to set a window transient for another if that would create a
loop.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=759299
gdk_pixbuf_get_from_window() paints the given window onto a new cairo
surface. Create that new surface with the same device scale as the
window so that the result is not scaled down on hidpi screens.
This is similar to 657a43e (which was reverted), but doesn't modify the
behavior of gdk_pixbuf_get_from_surface().
https://bugzilla.gnome.org/show_bug.cgi?id=757147
When doing a gtk_widget_show_all() on the shortcuts window,
accelerators for both RTL and LTR directions are being shown.
Make sure that no-show-all is set by default on hidden shortcuts, and
updated if the widget direction changes.
https://bugzilla.gnome.org/show_bug.cgi?id=759541
This was causing problems in the case when only one of the paned
children is visible - we would use uninitialized memory, leading
to invalide clip regions. Concretely, the signal tab in the inspector
would sometimes not render at all.
Make min-width/height have preference over the set default size. This
allows shrinking the widget. The default size is only used if min-width
is not set (or explicitly set to 0.
Drop the margin misuse and use the border allocation of the
handle gadget. We use negative margins to make the border allocation
larger without pushing the paned children out.
Size of the progress element now grows also when it's close to 0 size.
Previously the size was clamped to the minimum size, now it starts
growing from the minimum size.
So for a 100px trough with a 10px min size progress, the sizes of the
progress element change like this:
old new
0% 10 10
5% 10 14
10% 10 19
20% 20 28
50% 50 55
100% 100 100
Our actions on ::device-removed only actually applied to master
pointers, so listening to GdkDisplay::seat-removed and operating
on the seat pointer is equivalent.
We were not supporting plural form of the available space, which
is a problem in some languages.
However in this case is kind of a difficult matter, since we use a
formatted string from glib with g_format_size.
To fix it, use the same behavior as g_format_size to decide when
it should be used a plural form or not.
https://bugzilla.gnome.org/show_bug.cgi?id=759491
gtk_css_node_insert_before/after can easily create cycles
which later lead to stack overflows. Even if we're not
catching all cycles here, at least we can detect obviously
invalid arguments, such as inserting a node next to itself.
This was already mostly done by inheritance from GtkCheckButton.
To complete it, stop using the draw_indicator vfunc for radio
buttons, and instead make the indicator gadget draw either a
check or radio.
Use a gadget for the button, and for the indicator.
A complication here is that GtkCheckButton (and
GtkRadioButton) have a totally different appearance
depending on the ::draw-indicator property. If an
indicator is not required, we just reuse the
GtkButton gadget.
This mostly works; some minor sizing issues left, e.g. cranking
up the indicator-size causes the checkbutton grid in testgtk
to overlap.
This removes some hairy code handling with borders and padding,
which may or may not be correct. The examples in testheightforwidth
all continue to work, and min-width now works for labels.
This gives us min-width/height support. Currently, the spinner
still has a hardcoded minimum size of 16 and doesn't grow beyond
32. We may want to revisit that at some point.
When things change in the iconhelper, queue a resize on the owner widget
so that it automatically resizes.
Only do this for iconhelpers that are used as gadgets though, not for
temporary helpers - and to check this, check if the node is transient.
A gadget is halfway between a widget and a CSS node. It's supposed to
provide the minimum convenicence around CSS nodes until we've figured
out how to integrate them with widgets.
Build the gtk-update-icon-cache, gtk-builder-tool and gtk-query-settings
tools and run gtk-update-icon-cache as part of the post-build
"installation" process.
Pointed out (and reminded) by Paolo Borelli in bug 759436 that we should
build, "install" and run gtk-update-icon-cache in the MSVC builds as well.
Constructing GtkCssStyleChange objects without styles is forbidden, so
don't do it. Instead untangle the callback from the actual update
function and call that untangled function directly.
When we reuse styles that didn't change across changes to the source
CSS, make sure we clear the caches. Otherwise child nodes will pick up
styles from the old source CSS.
We no longer need a grabbed seat, instead we'll just use the default
seat if this happens, not without first warning and recommending
gdk_seat_grab() for the operation.
https://bugzilla.gnome.org/show_bug.cgi?id=759309
This allows GDK to unset the grab itself. Also, make sure we unset
the "pointer emulating" touch on the device if this is the
pointer emulating sequence.
https://bugzilla.gnome.org/show_bug.cgi?id=759309
GdkWaylandDeviceData conceptually gathers the data that belongs to
a seat, so it's been renamed (although the old typedef stays, plenty
of refactoring is due here...).
The methods in GdkSeatClass have also been implemented, the most
remarkable is ::grab, which ensures the grab is performed on all
the relevant "master" devices.
https://bugzilla.gnome.org/show_bug.cgi?id=759309
On some systems, the gtk settings are not used properly for wayland.
Indeed, g_settings_schema_source_get_default is used, and as the docs says it,
"all lookups performed against the default source should probably be done
recursively.".
https://bugzilla.gnome.org/show_bug.cgi?id=759409
Remove some now unused includes and dead code, and rename
gtk_drag_set_icon_window to gtk_drag_set_icon_widget_internal,
since it is no longer restricted to toplevel windows.
Under Wayland, the compositor does it, so there is no need
for us to move the window ourselves. For X11, we are now
doing the animation from the X11 backend. Trigger that by
calling gdk_drag_drop_done().
What changes here is that we have to keep the icon_window
alive for as long as the drag context exists. Use a weak
reference to do so.
Showing the drag cancel animation can be done in the X11
drag context implementation now that we hold the drag
window there, and have the start coordinates.
Since we can't control if and when the application destroys
the drag widget, we take a snapshot of the window contents
and display that during the animation. This should be good
enough for all practical purposes.
Add a variant of gdk_drag_begin that takes the start position
in addition to the device. All backend implementation have been
updated to accept (and ignore) the new arguments.
Subsequent commits will make use of the data in some backends.
In commit 2c61316677 we avoided emitting
the style-changed signal if no CSS property changed.
Unfortunately, this also caused CSS styles to not be updated when
animations started if those animations did not change any CSS value
immediately. In those cases the animation would just never start.
The obvious example was the spinner.
Catch the case where a CSS style did not change and don't emit the
style-changed signal in that case.
This saves not only the emission of the signal, but also doesn't cause
invalidation in child nodes, which would previously get a PARENT_STYLE
Instead of having old and new style, now have a GtkCssStyleChange opaque
object that will compute the changes you are interested in for you.
This simplifies change signal handlers quite a bit and avoids lots of
repeated computation in every signal handler.
We were only storing the dialog size on unmap, but resetting to the
stored default value more often, e.g. on focus-out. This was causing
the dialog to 'jump back' to its remembered size after the user
manually resized it, leading to frustration and bug reports.
Instead, save the dialog size on every ::size-allocate of the toplevel.
To avoid needlessly spamming dconf, only write the new value if it
changed.
In Wayland, the hotspot of a DND icon is set using the buffer offset in
wl_buffer.attach. To implement this, add a private API to cause the
next wl_surface.attach to offset the new buffer with a given offset.
Setting a DND icon hotspot sets this offset while also queuing a redraw
of the window to trigger the wl_surface.attach.
https://bugzilla.gnome.org/show_bug.cgi?id=759168
...in the process simplified the touch-selection styling, check
and radios not fixed there since I'm going to add proper osd assets
for those (istead of forcing the dark variant assets there as before).
The name gtk_text_*_begins_* was used only for begins_tag(). All other
similar functions use "starts": starts_line(), starts_word(), etc.
So for consistency, add gtk_text_iter_starts_tag() and deprecate
gtk_text_iter_begins_tag().
Also change (allow-none) to (nullable), to use the new annotation.
https://bugzilla.gnome.org/show_bug.cgi?id=759092
In Wayland, the hotspot of a DND icon is set using the buffer offset in
wl_buffer.attach. To implement this, add a private API to cause the
next wl_surface.attach to offset the new buffer with a given offset.
Setting a DND icon hotspot sets this offset while also queuing a redraw
of the window to trigger the wl_surface.attach.
https://bugzilla.gnome.org/show_bug.cgi?id=759168
Otherwise rounding errors fool the "tab under coordinates" checks on
crossing events, which will be triggered close enough to the window
rectangle if the pointer moves slowly enough.
With this, the tab_prelight() function correctly figures out we've
moved the pointer outside the tab area when called in
gtk_notebook_leave_notify().
https://bugzilla.gnome.org/show_bug.cgi?id=759091
After removal of the selectable header and separator from the combo box,
the method to update the menu sensitivity must be changed as it assumes
at least two items within each sub menu and contains special handling
for the separator. Removing this fixes bug #759079.
Since we're no longer doing geometry widgets, don't send
base size and increments to the window manager anymore either.
This avoids an ugly 2 pixel gap to the right and bottom of half-tiled
terminals under gnome-shell.
We were getting the "New Accelerator" text mixed with the
content of the underlying cell, since plain labels don't
have a background. Go back to putting the label in selected
state, and fix the theme to render that white-on-blue. This
was lost when we switched to using a selection sub-node.
Showing two lists in a paned was a bit awkward, and space was
getting too limited. Go back to showing just the node list at
first, and make the CSS properties available via a stack. At
the same time, add a right-click context menu to the node list
to make the name and class editing more easily available.
The gesture functionality was taken over by GtkShortcutsShortcut,
so this widget is no longer needed, and it never was in a stable
release, so lets get rid of it.
GtkFontChooserWidget is using a GThemedIcon in its template,
so we need to ensure that the type is registered before
loading it. This was causing the defaultvalue test to fail.
GtkStatusIcon tests don't work well under xwayland either, so just
skip them unconditionally.
GtkEntry now fails because the update of the im-module is no longer
deferred to an idle, and (gtk-im-simple) is not a valid module
name, so skip this property.
The subscript was affecting the vertical alignment too much,
so tweak the rendering of the L/R markers to avoid that. Also,
mark these as translatable.
Instead of creating an icon source, making sure no state is set and
therefore the icon-effect will be applied and then rendering that icon
source, just call the icon-effect apply function.
Also, the new way isn't deprecated.
On Wayland, for tooltips to work as expected, the type hint must be set
to tooltips, otherwise the popup window won't be translated as a
subsurface.
Fix the test do work as expected under Wayland.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=759018
In Gdk, a GdkOffscreenWindow parent has to be the root window. This is
problematic on Wayland because the root window doesn't necessary have the
right information with regard to scale factor.
This patch proposes to rely on the embedder, if available, to derive
surfaces as well as getting the scale factor.
https://bugzilla.gnome.org/show_bug.cgi?id=758936
Applying the client-side decorations in the configure routine greatly
increases the chances of having the right size for the GtkHEaderBar and
border shadows.
Yet, it may be possible that these sizes change at a later point in
time, if for example the GtkHeaderBar grows in height while adding new
controls.
Mention this possible pitfall in the documentation for
gtk_window_resize().
https://bugzilla.gnome.org/show_bug.cgi?id=756618
The entry code passes GTK_DEST_DEFAULT_HIGHLIGHT when setting
up the drop target, but that is ineffective because of the
custom drag_motion implementation. Instead, call
gtk_drag_[un]hightlight ourselves.
This borrows heavily from the CSS4 fonts draft's font-palette, currently
found at https://drafts.csswg.org/css-fonts-4/#font-palette-control
The palette is mainly meant to trigger invalidations when colors used for
symbolic icons change, to potentially allow extending supported colors
in symbolic icons and to recolor all colors of a symbolic icon, not just
the main one.
The syntax for the property goes like this:
Name: -gtk-icon-palette
Value: default | name <color> [ , name <color> ]*
Initial: default
Applies to: all elements with icons
Inherited: yes
Animatable: yes, each color animated separately
The property defines a list of named colors to be used when looking up
icons. If a name is not defined, the value of the current "color"
property is used. Which names are relevant depends on the icons in use.
Currently symbolic icons make use of the names "success", "warning" and
"error".
"default" is the current behavior of the GTK when coloring symbolic
icons and is equal to the string
success @success_color, warning @warning_color, error @error_color
Animation is crudely implemented by animating colors that are in both
palettes that are animated and otherwise keeping the color from the
palette that defined it. Note that this can cause a sharp cut at the
beginning or end of the animation when the color goes away and will
therefore be replaced with the color property.
You can see an example of animations at
http://gfycat.com/CautiousPeacefulIaerismetalmark
When we start a drag cancel animation, we can just keep the existing
window. The reset was only necessary to convert from cursor icon to
window and we removed the cursor handling.
Just like we did for the default size, that reduces the chances of
having the headerbar missing or wrongly sized when computing the client
side decorations controls.
https://bugzilla.gnome.org/show_bug.cgi?id=756618
The Wayland dnd surface must remain in place until the drag
is over. Setting it directly as the hardcoded window of the
widget we construct carries the danger that it might get
destroyed prematurely, e.g. when the application calls
gtk_drag_set_icon_name more than once and we recreate the
widget.
Instead, create a dedicated toplevel, and reparent the widget
into it. To keep the code simple, we use the same approach
under X11 as well, and make it the responsibility of the
GDK dnd code to keep the window position updated. We already
pass the current pointer position to gdk_drag_motion, which
makes this very easy.
As a side-effect of these changes, it is now possible to use
non-toplevel widgets as drag icons.
https://bugzilla.gnome.org/show_bug.cgi?id=748763
If that sounds confusing, it's because GTK and CSS can sometimes not
agree on naming.
:active for CSS means that a button is currently pressed on an element.
And that is clearly not the case for spinning spinners.
This removes the dependency on state, which should be used for selection
CSS styles, not for actually applying them.
And image-effect does exactly what we want already, so we can start
using it.
The size of icons is a property that is relevant to who is rendering the
icon, not to the icon itself.
Example: Starting a DND operation from an entry icon should cause the
icon to resize (from the entr icon's size to the DND icon size).
Make gtk_icon_helper_ensure_surface() a private function that just
ensures the surface was loaded.
Add gtk_icon_helper_load_surface() that is called by the above function
and the dnd code to actually load the surface.
Just do the invalidation check once, there's no need to do it in every
branch of the switch.
Also remove useless checks: These functions will not be called if we
already have a rendered surface.
Just do the invalidation check once, there's no need to do it in every
branch of the switch.
Also remove useless checks: These functions will not be called if we
already have a rendered surface.
It seems this branch is not needed anymore. It was originally added in
1999 to support gtk_widget_realize(), but all those reasons seem
obsolete today.
Instead just call gtk_widget_realize().
If you end up at this commit when bisecting:
There is no bug that made me remove this code, it was purely meant to be
cleanup / dead code removal. I seem to have introduced a new bug or
bisecting wouldn't have let you here. So it seems we should just revert
this commit.
Under X11, popovers are always constrained to the toplevel
window. Under Wayland, they aren't. This commit adds a
property that allows to explicitly constrain popovers to
the toplevel, giving them the same behavior under Wayland
as under X11.
https://bugzilla.gnome.org/show_bug.cgi?id=757474
Widgets such as gtkfilechooser may be saving their size and position on
the unmap callback, if the client-side decoration header bar is removed
first, the reported size will be wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=756618
gdk-wayland backend would not re-configure a surface when its size and
scale match the known size and scale.
But there might be a pending xdg_surface_configure() that would revert
this change so we should re-configure even if the currently known
size/scale match, otherwise we may end up with a wrong size after the
xdg_surface_configure() is received.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=758901
If we "release" the button first, the drag will be eventually cancelled,
we must first signal GDK_DROP_FINISHED, and then release the button so
the success status prevails.
It doesn't make a lot of sense to have this stored as data offer data,
rather together with the source_targets array, which is what we're
poking here in the end.
https://bugzilla.gnome.org/show_bug.cgi?id=758713
Dissociate ownership from our maintenance of wl_data_source objects.
The only place where ownership must be updated together is
data_source.cancelled, for the other places GDK should take care of
setting up the right ownership, even if at a different order than
we'd expect here.
This fixes GTK+ apps on wayland being locally confused about the
current selection ownership. Because gtk_selection_add_targets()
results in a wl_data_source being created, and ownership being
updated right away, early callers of this will change the ownership
even if the widget it's being called on didn't explicitly request
the selection ownership yet.
https://bugzilla.gnome.org/show_bug.cgi?id=758660
'win.lines' contains the same content as the GtkTextBuffer, so to find
@match_start, forward_chars_with_skipping() is called with
skip_decomp=FALSE (the last parameter). So far so good.
On the other hand, the content 'lines' (the needle split in lines) is
casefolded and normalized for a case insensitive search. So,
forward_chars_with_skipping(..., skip_decomp=TRUE) must be called only
for the portion of text containing the needle.
Since 'start_tmp' contains the location at the start of the match, we
can simply begin at that location to find the end of the match.
Unit tests are added.
https://bugzilla.gnome.org/show_bug.cgi?id=758698
Doing things the other way around seems to cause problems in
some cases where children want to do different things depending
on the window position.
https://bugzilla.gnome.org/show_bug.cgi?id=758563
Instead of just listing the return type of get_plus_button() and
get_minus_button() in the documentation, we can use the (type)
annotation to ensure that the introspection data reflects the actual
type of the returned widget.
Fix a regression introduced by:
commit 6866d1c widget: Make gtk_widget_queue_allocate() not resize
Where the dropdown menu in Firefox would not be relocated after the
toplevel window is moved.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=758609
While searching for the cause of bug 746745 it was discovered that one could
not set WS_EX_TOPMOST extended window style with SetWindowLong(),
but must use SetWindowPos() for that purpose.
This was never a problem most likely because it is highly unlikely for windows
to acquire/lose WS_EX_TOPMOST after they are created, by means other
than SetWindowPos() (which GTK does use to raise/lower windows and
set/remove keep_above), and because trying to set/unset WS_EX_TOPMOST with
SetWindowLong() results in WS_EX_TOPMOST merely not being set/unset (that is,
other styles are still set/unset within the same call and no error is
signalled).
https://bugzilla.gnome.org/show_bug.cgi?id=758483
Instead of having our own copy of the pointer gestures XML file, use
the one installed by wayland-protocols.
Since pointer gestures is an unstable protocol, it went through the
unstable protocol naming convention changes, which is reflected in this
commit.
https://bugzilla.gnome.org/show_bug.cgi?id=758634
Just like it happens for window dragging, we're likely to not see the
matching button release for this event, so we must reset the controller
manually here.
https://bugzilla.gnome.org/show_bug.cgi?id=758661
Before calling gdk_window_move_resize(), store the full configure
request, not just width and height.
Fixes firefox randomly losing position of its dropdown windows.
https://bugzilla.gnome.org/show_bug.cgi?id=758609
After the grab is finished, we would expect an enter event, and
GDK updating internally the cursor for that window and device.
This means there is no need at all to store it separately in the
backend.
As a side effect, animated cursors are now also possible on grab
icons.
https://bugzilla.gnome.org/show_bug.cgi?id=735847
The way master devices detach from their other master counterpart is
vulnerable to infinite recursion due to the way we first recurse on
the other device before clearing the pointer, this may happen if
that last reference to the other master device is held by the
device->associated field.
https://bugzilla.gnome.org/show_bug.cgi?id=732742
Other backends take care of the cairo surface destruction in
GdkWindow::destroy. We must do the same here, or the cairo_surface
and its corresponding wl_buffer are left dangling.
https://bugzilla.gnome.org/show_bug.cgi?id=747295
tracker:uri-is-descendant/parent has the unfortunate side effect of
rendering the collation mechanisms in the database useless, so those
require full table scans to be validated.
Performing these as pure string comparisons will perform much better,
as those allow the underlying sqlite to rely on its own collation
to perform the search, which can be significantly faster with many
elements in the database.
https://bugzilla.gnome.org/show_bug.cgi?id=758407
It turns out that it is nicer in glade to have just a single
widget that can show either a shortcut or a gesture, so make
GtkShortcutsShortcut do it both.
GtkShortcutsGesture is now redundant and will be removed before
the next stable release.
The current code in gtkshortcutswindow.c is good enough to
construct a widget once from a .ui file, but fails to handle
changes at runtime, as happen e.g. in glade. Fix this by
listening for changes to section-name and title.
This prevents normal application windows (and other kinds of windows)
from being moved up in Z-order to be above windows that have the
always-on-top bit set. Doing so would make the previously-normal windows
in question also always-on-top implicitly.
Windows that are already always-on-top will be restacked on top of other
always-on-top windows too.
https://bugzilla.gnome.org/show_bug.cgi?id=746745
Empty underlines are hard to make out. Since we get somewhat
unreliable section information from the CSS parser, we just
make sure that we always underline at least one character.
The builder syntax for tags was invalid here (why did this not
get flagged as error ?!). While we're at it, give the warning
underline a nice, orange color.
If the buffer of a cursor is NULL, for example if its an empty cursor,
just set the cursor surface to NULL as well. Not doing this we'll use
uninitialized hotspot coordinates, dimensions and scales.
https://bugzilla.gnome.org/show_bug.cgi?id=758025
We can't use up_panel and down_panel as differentiators for the buttons,
because these window system resources don't exist before realize().
Just use a one-off enum for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=758094
This GdkDragContext should be created even if we don't have pointer
capabilities. Make it created on add_seat(), and only set the device
on wl_seat.capabilities, so it can be set to either master pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=741066
This is wrong by all accounts there, as we can do no tricks there to show
a "drag failed" animation, which is performed by the compositor itself
on wayland.
We use the high-level gdk_device_get_window_at_position() to figure
out the window, although this one actually tries to find out the
current window under the device coordinates, which might well fall
outside the window, so NULL is returned in those cases.
Fix this by using the lower level _gdk_device_window_at_position()
that will return the toplevel without further lookups, so is more
desirable here.
https://bugzilla.gnome.org/show_bug.cgi?id=758250
Now that we have multiple master pointers, this call may pick the wrong one.
Instead, pick the GdkWaylandDeviceData from the first device, and pick the
master pointer from there.
The common GDK code accounts for "pointer emulating" touch sequences to be
synchronized with the pointer position by the windowing system.
However on Wayland pointer and touch are completely independent, the backend
attempts to implement pointer emulation, but doesn't account for the
possible crossing events happening when the user switches from pointer to
touch or the opposite.
In order to fix this, and to ensure we don't have to interact with the
master pointer (which backs the wl_pointer), separate the touch interface
to have its own master pointer, and ensure crossing events are emitted on
it, so the picture of an "emulated pointer" is complete above the backend.
Inspired in a former patch by Jonny Lamb <jonnylamb@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=750845
The window button setup depends on properties of the toplevel window.
Instead of updating the setup on realize, do it when the toplevel
changes.
This makes sure that when a GtkHeaderBar is added to a window
all the widgets are present and get_preferred_height() will return
the height the widget will have when finally shown. This allows
the logic in gtkwindow to select the right window size so that
the content size will match the requested default size.
https://bugzilla.gnome.org/show_bug.cgi?id=756618
Before the resulting window size would differ if the default size was set
before adding a headerbar vs after. Now the saved state is again the actual
requested size and it is adjusted at the time we request a window size.
https://bugzilla.gnome.org/show_bug.cgi?id=756618
GtkHeaderBar will not show the maximize button if the window in not of
type normal or not resizeable.
Use the same restriction for double-click actions as well.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=757530
Currently GtkStack has some G_PARAM_CONSTRUCT properties. That means,
the properties are set with its default value after the initializacion
of the object.
When using GtkBuilder to build objects, GtkBuilder creates them and
after that sets the properties found on the xml definition.
However, this is not true for templates because the template is initialized
in the init() function of the actual object, and after that, the construct
properties will be set.
This is a problem when someone wants to use templates with GtkStack and
set those properties, since they will be set on the tempalt initialization
and set again to its default values afterwards.
To fix this, make those properties not G_PARAM_CONSTRUCT.
https://bugzilla.gnome.org/show_bug.cgi?id=758086
There is no GNU Lesser General Public License version 2; it's either GNU
Library General Public License version 2, or GNU Lesser General Public
License version 2.1.
Copy-pasta from GPL instead of LGPL.
Also, there is no GNU Lesser General Public License version 2; either
it's the GNU Library General Public License version 2, or it's the GNU
Lesser General Public License version 2.1.
If the window has not yet been created, then we can't set the invisible
cursor yet. This can happen in situations where the widget is in a
revealer with type-to-search functionality.
An application may use gtk_window_get_size() to retrieve the current
window size and later reuse that size with
gtk_window_set_default_size().
gtk_window_set_default_size() and gtk_window_get_default_size() should
also take client side decorations offset into account.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
We were using that range for the extra buttons after left/right/middle,
while this is harmless for clients not handling extra buttons (we
used to translate those button events into scroll events in x11 anyway)
this will be unexpected for clients that do handle additional mouse
buttons themselves (eg. back/forward buttons present in some mice).
In order to remain compatible with X11, those need to be assigned from
button 8 onwards.
Also, include input.h, and stop using magic numbers here.
https://bugzilla.gnome.org/show_bug.cgi?id=758072
Commit 1266d15c4 also broke Xwayland, as it does the same trick
than VMWare pointers. Let's extend the heuristic to check for "pointer"
in the device name, what can possibly go wrong...
https://bugzilla.gnome.org/show_bug.cgi?id=757358
We currently just look for a master device with input source MOUSE.
After recent changes to the way input devices are classified, xwayland
on my system comes up with a virtual core pointer that has input
source TOUCHSCREEN. This was causing assertion failures. Be a little
more careful and accept a touchscreen as core pointer, if there is
no mouse.
Use G_PARAM_DEPRECATED with deprecated style properties.
This will make it easier to identify and remove such stale
properties from css, since it will now trigger warnings.
When loading a nonexisting CSS file using
gtk_css_provider_load_from_file() or gtk_css_provider_load_from_path()
we would emit the error using a NULL scanner. Don't do that, because
we'll have a NULL section in that case and error handlers don't like
that.
Testcase attached.
https://bugzilla.redhat.com/show_bug.cgi?id=1277959
VMWare seems to create mouse devices with abs axes which confuses
our detection of single-touch touchscreens. Those have though a
name we can match on ("VirtualPS/2 VMware VMMouse"), it should
be pretty safe to assume that no real touchscreens have "mouse"
in their name...
https://bugzilla.gnome.org/show_bug.cgi?id=757358
The prime example for direction-dependent shortcuts is using
<Alt>Left or <Alt>Right to go back. Support this by adding a
direction property to GtkShortcutsShortcut, and filtering by
the current text direction.
https://bugzilla.gnome.org/show_bug.cgi?id=757888
Getting the shadow width must not call gtk_style_context_set_state()
because that will invalidate the node and cause a style-updated emission
which can cause gtk_widget_queue_resize() calls.
And calling queue_resize() from get_preferred_size() essentially means
the size is permanently invalid because you invalidate it while
querying it.
This causes flickering of windows when going from/to backdrop state. To
avoid this we either need to fix the theme to not have different shadow
sizes in those cases or we need to ensure the window doesn't flicker in
the first place.
Only use the hard-coded build-time path given by X11_PREFIX on X11 and
Wayland where a X11 package is normally available. On other platforms,
get the datadir of the running system and mimic the behavior by
constructing the path dynamically. This avoids hardcoding the path for
searching for compose tables where we want to have relocatability.
This fixes the build on Windows/MSVC as well, where we don't normally have
any X11 packages available.
https://bugzilla.gnome.org/show_bug.cgi?id=757984
Since we are now interpreting button press events and
make our own double-click determination, we should not
handle double-click events that are generated by GDK.
https://bugzilla.gnome.org/show_bug.cgi?id=757950
A follow up on the previous patch. We should use DestroyWindow
directly since it has a different calling convention than
the expected callback for g_clear_pointer
Adapt to the changes in the previous commit. In particular, fix
the handling of low and high offsets. Anything below the low offset
gets warning color, anything below high gets selected background,
and anything below the new full offset gets success color.
Avoid crashes when passing an invalid location to a
gtk_text_buffer_get_iter_at_*() function.
A first attempt added boolean return values to know if @iter has been set to
the exact location, but it breaks Python and JS bindings because the out
parameter is already a return value in those languages.
Unit tests are added.
https://bugzilla.gnome.org/show_bug.cgi?id=735341
This reverts commit a9a1c00cc9.
Unfortunately, adding the boolean return broke both the python
and javascript bindings, since they now return a tuple consisting
of the boolean and the out argument.
glib-compile-resources have been updated to ensure that the symbols
generated are referred to, so that they will not be optimized out by the
linker in release builds. We can change from /opt:noref to /opt:ref,
which should improve optimization a bit.
This partially reverts de16a4e.
As we now ensure that items using GResources and GConstructors are always
referenced so that the linker does not optimize them out in a default
Release build, we no longer need to enforce the use of /LTCG, so
/LTCG:incremental will work as well.
Its very easy to get extra references to the NativeDialog so that
when you release your last reference any visible dialog is not
hidden. We handle this by adding a destroy method similar to how
you destroy regular toplevels.
It's not a hugely complicated file, but it's easier to deal with some of
the details of tooltip windows styling if we have a UI file to edit,
instead of source code.
Use the text CSS node for rendering text, and the selection node
for rendering selected text, avoid gtk_style_context_save, update
states of all CSS nodes, and use the proper states when querying
style properties.
Use a CSS node with name selection, like we do for entries
and labels. Unlike those widgets, we currently don't user
gtk_render_background, but just use the background color.
That will require more effort.
Calling gtk_render_background for each rectangle in the region
leads to suboptimal and sometimes weird results. Getting this
right requires more work in Pango first. Go back to just rendering
a single background, and clip it to the selection region. This
matches what GtkLabel does.
At the time gtk_window_move() or gtk_window_resize() get called, there
is no way to predict if a popup window will actually draw its shadow, so
applying an offset in this case may end up with a wrong size or
positioning for such windows.
Changing the logic in gtk_window_should_use_csd() as previously done to
address that issue will cause some other breakage as popup windows may
not draw a shadow but still need CSD.
So best is to actually apply client side decorations offset for regular,
top level windows only. This is actually a lot simpler and safer and
less likely to cause additional breakage.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
Adapt to the changes in the previous commit. Note that tooltip
appearance is currently affected by tooltips having lost their
csd nature, due to a regression.
* Cover letter
Having a single header file for all autocleanups definitions was a
reasonable stop-gap measure, but now GTK+ is starting to use G_DECLARE_*
macros. This means that every class using a G_DECLARE_* macro will need
to include "gtk.h" to avoid compiler warnings, which is not acceptable.
By moving the G_DEFINE_AUTO* use to the header that defines the type we
allow using the G_DECLARE_* macros without sacrificing the ability to
include only the needed files when deriving from a class.
* Commit
This commit changes all includes relative to GtkWindow to define their
own autocleanup macros.
When I added the draw_layer vfunc it accidentally got passed a cairo_t
that was configured with to draw in the viewport coordinate space (rather
than the buffer coordinate space). This makes things unnecessary complex,
because you have to convert between the two.
The pixel cache is shared between the text and the layers, so there is
no way to use draw_layer to get a stationary overlay effect. Thus it makes
much more sense for the draw_layer vfunc to draw in the buffer space.
Just changing this would break ABI for existing code, so this is fixed
by adding new layer types and deprecating the old ones.
Also, we use the new layer types to fix gtk3-widget-factory.
https://bugzilla.gnome.org/show_bug.cgi?id=757856
When moving/scrolling a child window we can't use the current clip
region to limit what is invalidated, because there may be a pixel
cache that listens for changes outside the clip region. Instead
invalidate the entire area and rely on the invalidation code to limit
the repaint to the actually visible area.
git commit a5b1cdd0 introduced a regression where CSD windows are not
resizable with metacity.
Reason being that metacity does not support "_GTK_FRAME_EXTENTS" and
therefore gtk_window_supports_client_shadow() would always return FALSE.
This explains why it works with window managers which support
"_GTK_FRAME_EXTENTS" such as mutter/gnome-shell or xfwm4.
Partially revert commit a5b1cdd0 to reinstate the logic in
get_shadow_width().
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=757805
It is not necessary for the users of this API, and causes things
to not work as intended. Without this transient node, styling
"notebook header tabs arrow" has the desired effect on notebook
arrows.
We were just catching the previous sibling before. Now we properly
invalidate all previous siblings (and also all other wiblings, but we
can think about optimizing that later).
# YourProject_HEADERS_EXCLUDES = ... # <list of headers to exclude from installation, separated by '|', wildcards allowed; use random unsed value if none>
#
# dist-hook: \ # (or add to it if it is already there, note the vs9 items will also call the vs10 items in the process)
if exist ..\..\..\MSVC_$(Configuration) goto DONE_GDKCONFIG_H
if exist ..\..\..\gdk\gdkconfig.h del ..\..\..\gdk\gdkconfig.h
if exist ..\..\..\GDK_BROADWAY_BUILD del ..\..\..\GDK_BROADWAY_BUILD
if exist ..\..\..\MSVC_$(Configuration)_Broadway del ..\..\..\MSVC_$(Configuration)_Broadway
if exist $(Configuration)\$(Platform)\bin\$(GtkDllPrefix)gdk$(GtkDllSuffix).dll del $(Configuration)\$(Platform)\bin\$(GtkDllPrefix)gdk$(GtkDllSuffix).dll
if exist $(Configuration)\$(Platform)\bin\gdk-$(ApiVersion).lib del $(Configuration)\$(Platform)\bin\gdk-$(ApiVersion).lib
if "$(Configuration)" == "Release" del ..\..\..\MSVC_Debug
if "$(Configuration)" == "Debug" del ..\..\..\MSVC_Release
if exist ..\..\..\MSVC_$(ConfigurationName) goto DONE_GDKCONFIG_H

if exist ..\..\..\gdk\gdkconfig.h del ..\..\..\gdk\gdkconfig.h

if exist ..\..\..\GDK_BROADWAY_BUILD del ..\..\..\GDK_BROADWAY_BUILD

if exist ..\..\..\MSVC_$(ConfigurationName)_Broadway del ..\..\..\MSVC_$(ConfigurationName)_Broadway

if exist $(ConfigurationName)\$(PlatformName)\bin\$(GtkDllPrefix)gdk$(GtkDllSuffix).dll del $(ConfigurationName)\$(PlatformName)\bin\$(GtkDllPrefix)gdk$(GtkDllSuffix).dll

if exist $(ConfigurationName)\$(PlatformName)\bin\gdk-$(ApiVersion).lib del $(ConfigurationName)\$(PlatformName)\bin\gdk-$(ApiVersion).lib

if "$(ConfigurationName)" == "Release" del ..\..\..\MSVC_Debug

if "$(ConfigurationName)" == "Debug" del ..\..\..\MSVC_Release

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.
