AM_PATH_GTK_3_0 uses AC_PATH_PROG for finding pkg-config. Unfortunately,
that will find the build architecture pkg-config which in turn will miss
the host architecture gtk+3.0. What must be used here is the host
architecture pkg-config and that is found with AC_PATH_TOOL.
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894069
Reviewed-by: Simon McVittie <smcv@debian.org>
Fixes: #133
Fixes two things: 1) As GTK+ can be coerced into using the wayland IM
module despite the compositor not implementing the interface, all paths
not checking for global state before sending requests are prone to
crashes, this one fell hit this pitfall.
And 2) ensures the tap gesture only triggers TOGGLE_INPUT_PANEL if the
widget IM is focused. This is a possibility on eg. WebKit pages, where
its IM is only focused as long as a form element in the page is focused.
Tapping elsewhere shouldn't toggle the OSK.
https://gitlab.gnome.org/GNOME/gtk/issues/114Closes: #114
…the wayland registry.
Wnen _gtk_im_module_get_default_context_id calls
match_backend (context_id) and the default GdkDisplay
is wayland, match_backend() should return TRUE only if
gdk_wayland_display_query_registry (display, "gtk_text_input_manager")
returns TRUE.
When the widget gets finalized it clears the widgetnode and gtk_css_widget_node_get_widget
returns NULL. Guard against gtk_css_widget_node_get_widget() returning NULL like in other
places.
See https://gitlab.gnome.org/GNOME/pygobject/issues/28#note_82862
Since the Cairo build files for Visual Studio does not really generate
the pkg-config files for us, and we stopped making makeshift ones in
gobject-introspection, stop making the .pc files we generate here refer
to the Cairo .pc's, and instead make them link directly to
cairo-gobject.lib and cairo.lib.
If @menu_label == NULL, we create a default page->menu_label. This took
@tab_label.get_label() and passed that to page->menu_label.set_text().
This is wrong because we set the plain text of the menu_label from the
rich text of @tab_label. So, if @tab_label used mnemonics or markup, our
menu_label got the raw underline or markup tags shown in it as raw text.
As we call set_text() on the menu Label, the fix is to be symmetric: use
@tab_label’s get_text() as source, as that strips underlines and markup.
It’s not worth making the default Label ‘inherit’ :use-underline/markup;
that’s a slippery slope, and users wanting such things can just create a
fully fledged GtkLabel to pass as @menu_label to suppress the default.
https://bugzilla.gnome.org/show_bug.cgi?id=705509
If a window is unmapped by the client while gdk is processing updates,
(for example Firefox un-mapping its window on Expose events), the
windowing backend resources might be lost (for example with Wayland)
which can cause a crash in end_paint().
Make sure we drop the cairo surfaces as well when hiding the surface,
that will avoid the crash in gdk_window_impl_wayland_end_paint() when
trying to attach the staging cairo surface to a released wl_surface,
these will be recreated when needed when the surface becomes visible
again and there is no need to keep such buffers around for a surface
which is not visible anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=793062
This commit adds support the stable version of the xdg-shell protocol.
Support for the last version of the unstable series is left intact, but
will not receive new features.
The stable version is prioritized above the older version.
https://bugzilla.gnome.org/show_bug.cgi?id=791939
Otherwise, the + or - button might change sensitivity based on whether
it can be used to wrap, but without ensuring we update its state, the
ability to :wrap isn't reflected until something else triggers a draw.
https://gitlab.gnome.org/GNOME/gtk/issues/88
Realization is done as a side effect of calling
_gtk_entry_completion_resize_popup(), but if this is done before the
GdkScreen of the GtkWindow is set up correctly, it may result in the
widget being unrealized when the screen is updated. This may happen
when the file dialog parent window is not using the default GdkDisplay.
To avoid this issue, realize the popup after the screen has been
properly set up.
Fixes#83 in gtk3
This was not needed before, but now it seems to be necessary for
some reason. The code is just an adjusted copy of the appropriate
piece of the OLE2 protocol code, sending GDK_SELECTION_REQUEST.
The rest is just fixing the fallout, allowing LOCAL protocol to pass
the functions it wasn't supposed to pass before.
Closes#82
Now that subtitle's default value "Searching" for OPERATION_MODE_SEARCH
is duplicated as it should be, we cannot reassign other strings to it
anymore, as that resulted in the original dupe of "Searching" leaking.
Fix this by only assigning the dup'd "Searching" after trying to get
more specific values, not before. We therefore need to set it to NULL
during its declaration, and that means we needn't in the final else.
Having a FileChooserDialog in location-entry mode then pressing
<primary>f to move to search mode would crash with an invalid free().
In that case, FileChooserWidget.get_subtitle() returned a static string
straight from gettext. This crashed when the GBinding from :subtitle to
FileChooserDialog’s HeaderBar:subtitle shortly tried to free the string.
Fix by duplicating the string before returning it, like all other paths.
https://bugzilla.gnome.org/show_bug.cgi?id=791004
Match "box" instead of "*", as already done for the search bar GTK4 and
for the action box in GTK3. Also clarify which widget property is
causing the margin which needs to be undone.
Includes applications like GNOME Software and GNOME Documents. The
search bar is a composite widget with a revealer inside it, and when the
content of the revealer is hidden, the border lingers. Changed the CSS
to add style to the content of the revealer instead of the search bar
widget itself.
We can't use gtk_widget_get_allocation for either non-anchored widgets
(which happens with the child widget when the expander is unexpanded)
nor toplevel windows since that will include the window decorations.
Fixes#70 in gtk3
When using type annotations, the ABI of type being annotated and a new
type introduced from annotation should match.
In case of enumerations, the most common ABI, and probably the only one
currently used in practice with gtk, corresponds to -fno-short-enums
compiler option. It uses int as the underlying type of enum, bumping it
up to unsigned int, long int or unsigned long int, in that order, when
necessary.
Thus, when annotating a field of integer type with an enum type, it is
never correct to annotate field smaller than int, because it changes the
ABI from perspective on introspection.
The gint8 phase field in GdkEventTouchpadSwipe and GdkEventTouchpadPinch
structures have been previously annotated in such a way, and this change
removes this annotation to restore ABI compatibility.
Size of structures before (which does not match C):
```
>>> Gdk.EventTouchpadPinch.__info__.get_size()
104
>>> Gdk.EventTouchpadSwipe.__info__.get_size()
88
```
Size of structures after (which does match C):
```
>>> Gdk.EventTouchpadPinch.__info__.get_size()
96
>>> Gdk.EventTouchpadSwipe.__info__.get_size()
80
```
Fixes issue #57.
Include gtk/gtk.h and gtk/gtk-a11y.h unconditionally,
and gtk/gtkx.h when building with X11. Ensures that
introspection data contains complete set required
headers, which is useful when generating C code based
on introspection data.
Diff for generated gir (when using X11):
```diff
<include name="xlib" version="2.0"/>
<package name="gtk+-3.0"/>
+ <c:include name="gtk/gtk-a11y.h"/>
+ <c:include name="gtk/gtk.h"/>
+ <c:include name="gtk/gtkx.h"/>
<namespace name="Gtk"
version="3.0"
```
Fixes issue #56.
This reverts commit fb0a13b7f0.
It's already reverted in master via
c8a6a1138b, so let's not leave subtle
behavior changes that would make a gtk3->gtk4 migration. And just like
the commit message of the revert already mentions: it didn't really make
anybody happy anyway.
Calling gtk_menu_item_get_label on a GtkSeparatorMenuItem would
otherwise create a GtkLabel child, increasing the vertical size request
to that of the child label.
The header got included without config.h being included first which resulted in the
wrong _GDK_EXTERN macro being used. As a result some symbols weren't exported
and starting a DnD action would crash in the linker.
This patch adds config.h includes in all places where clang complained about
_GDK_EXTERN redefinitions.
See #32 for more info.
In PyGObject gdk_init() is called before gtk_init() and thus there is
already a default display open when gtk_init() is called.
The code assigning the display to the debug_flags struct gets only
called when the default display changes, which never happens
when there already is one. As a result GTK_DEBUG=interactive
doesn't do anyting with Python apps.
This makes it call the change callback in case a display is already
there.
See https://gitlab.gnome.org/GNOME/pygobject/issues/166
When we found an icon with exactly the requested size, we'd stop
searching immediately (good), but we'd neglect to set the returned
min_difference to 0 (bad). This caused theme_lookup_icon() to
prefer other, potentially much worse, matches over the exact one.
We link to the HowDoI for GNotification in the class description, but we
should be more verbose in the deprecation notices for each function of
the GtkStatusIcon class.
https://bugzilla.gnome.org/show_bug.cgi?id=743975
The a11y tests complain that org.gtk.Settings schemas are missing
and fail. This copies the code to build and include the schemas from
the reftests testsuite.
This IM context implementation goes through the gtk-text-input protocol,
leaving up to the compositor the actual interaction with IM engines. If
the protocol is not offered by the compositor, GTK+ will fallback to the
IMs as specified through GtkSettings.
The internal known_globals hashtable is used to carry accounting for
interfaces that depend on others (as ordering is not guaranteed), extend
its usage so it also keeps track of unimplemented interfaces (here at
least).
The API call will then use this to allow querying the globals offered by
the compositor, it will be useful to determine whether we can use
text-input protocols or should fallback to other IMs.
This fixes stuttering in animations that rely on the regularity of
gdk_frame_clock_get_frame_time.
https://bugzilla.gnome.org/show_bug.cgi?id=787665
BEFORE
gdkgears:
58 FPS and visibly stuttering
gnome-maps on a 59.95Hz monitor:
"paint" g_get_monotonic_time +17278μs, gdk_frame_clock_get_frame_time +17278μs
"paint" g_get_monotonic_time +17449μs, gdk_frame_clock_get_frame_time +17426μs
"paint" g_get_monotonic_time +17620μs, gdk_frame_clock_get_frame_time +17600μs
AFTER
gdkgears:
60 FPS and smoother
gnome-maps on a 59.95Hz monitor:
"paint" g_get_monotonic_time +18228μs, gdk_frame_clock_get_frame_time +16680μs
"paint" g_get_monotonic_time +15010μs, gdk_frame_clock_get_frame_time +16680μs
"paint" g_get_monotonic_time +17134μs, gdk_frame_clock_get_frame_time +16680μs
The annotation (allow-none) is wrong. Since
gtk_tree_view_is_blank_at_pos() also calls
gtk_tree_view_get_path_at_pos(), the same fields should have the same
annotations.
Due to the recent changes introduced in glibc 2.27 "%OB" is the
correct format to obtain a month name as used in the calendar
header. The same rule has been working in BSD family (including
OS X) since 1990s. This simple hack checks whether "%OB" is supported
at runtime and uses it if it is, falls back to the old "%B" otherwise.
Closes: #9
We are using a lot of deprecated API, and we know it.
Since the selection code is going to be replaced in GTK 4.0, there's no
real point in keeping the warnings enabled in 3.22.
Functional revert of commit 9c4892f291.
Fixes introspection scanner warnings like:
Warning: Gtk: gtk_drag_finish: Methods must belong to the same
namespace as the class they belong to
That is, the gtk_drag_* functions cannot be methods as they have a
"GdkDragContext" as the instance parameter, and that is not a valid
type for the Gtk namespace.
This is not an introspected ABI change, as the generated introspection
data ignores the annotation.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=692152
g_input_stream_read_bytes() roughly provides the same guarantees
than g_input_stream_read() wrt the number of bytes being possibly
read (i.e. it being a best effort, but no real guarantees).
Instead, rely on the 0-len read that we'd get at the end of the
transfer.
Fixes clipboard/DnD transfers possibly being cut short, resulting
on "Broken pipe" errors on the other side.
https://gitlab.gnome.org/GNOME/gtk/issues/1Closes: #1
The problem here is that the CSS machinery expects font sizes to be in
pixels, but gtk_widget_override_font() provides a value in point and the
CSS machinery has no ability to query the DPI and convert.
This patch changes the dconversion DPI we use from a hardcoded 96 to the
default screen's DPI, which should work better than before.
This will of course not listen to changes in the default screen's DPI,
but that shouldn't be a problem.
People who want to workaround this should use gtk_widget_override_font()
with a font that has an absolute size set via
pango_font_description_set_absolute_size (size * PANGO_SCALE *
gdk_screen_get_resolution (screen));
https://bugzilla.gnome.org/show_bug.cgi?id=774248
After commit ffef28a7e8,
gtk-icon-browser was spewing critical warnings when
changing sections. Avoid that by respecting the return
value of gtk_tree_model_get_iter.
BTN_STYLUS3 is defined by the Linux 4.15 kernel and is sent when the
third button on a stylus is pressed. At the moment, only Wacom's "Pro
Pen 3D" has three stylus buttons. Pressing this button triggers a button
8 event to be sent under X11, so we use the same mapping here.
https://bugzilla.gnome.org/show_bug.cgi?id=790033
GtkGesture is a GtkEventController. gtk_event_controller_dispose() calls
_gtk_widget_remove_controller(). That NULLs the pointer-to-Controller in
our EventControllerData but does not delete said ECData from our GList.
Subsequently, if that same Widget gets unparent()ed, that method calls
unset_state_flags(), which leads to doing reset_controllers() if we are
insensitive. Now, unlike most most other loops over the GList of ECData,
reset_controllers() does not skip nodes whose pointer-to-Controller is
NULL. So, we call gtk_event_controller_reset(NULL) and get a CRITICAL.
This surfaced in a gtkmm program. The Gesture is destroyed before the
Widget. The Widget then gets dispose()d, which calls unparent()… boom.
I didn’t find an MCVE yet but would hope this logic is correct anyway:
The simplest fix is to make the loop in gtk_widget_reset_controllers()
skip GList nodes with a NULL Controller pointer, like most other such
loops, so we avoid passing the NULL to gtk_event_controller_reset().
In other, live cases, _gtk_widget_run_controllers() loops over the GList
and removes/frees nodes having NULL Controllers, so that should suffice.
But this clearly was not getting a chance to happen in the failing case.
https://bugzilla.gnome.org/show_bug.cgi?id=792624
Filter models rely on views taking a ref on every node
they care about. GtkIconView was not doing that. Amazingly,
this has never shown up in a bug so far, until I spotted
the fallout in gnome-font-viewer.
Test that filter models propagate ::row-changed if there is
an external reference on the node, and not otherwise. This
is showing up in buggy icon view behaviour, where the icon
view is not redrawing if the content changes in a model that
is below a filter model.
We must notify the font and font-desc properties when the
list selection changes, and return NULL values for them
when there is no selection in the list.
We were failing to change the sort order for the
default sort column in some cases. Fix that, and
add a testcase for this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=792459
Add a testcase for the previous fix
Some emoji fonts (such as Emoji One), render Emoji sequences
such as some of the family variations using multiple individual
glyphs. This rendering is too wide and breaks our grid layout.
Therefore, we will just skip any sequence whose rendering is
more than twice as wide as a simple smiley.
Both AC_TRY_COMPILE and AC_LANG_PROGRAM put code passed to their second
arguments to the body of the main function. This means that we cannot
and should not declare functions there, or we end up checking whether
the compiler support nested functions instead of whether a compiler or
linker flag is supported.
GCC supports nested functions and tests succeed. Clang doesn't support
nested functions, so tests fail and -fvisibility=hidden won't be used.
This means that functions which are not intended to be used by other
programs, such as gtk_menu_tracker*, gtk_action_observ*,
gtk_menu_muxer_*, become global symbols with default visibility.
GNOME Shell has a private library libgnome-shell-menu.so, which also has
symbols gtk_menu_tracker*, gtk_action_observ*, gtk_menu_muxer_* that are
intended to be used by GNOME Shell itself. When GNOME Shell still used
Autotools build system, the executable gnome-shell explicitly linked to
libgnome-shell-menu.so, so the linker loaded libgnome-shell-menu.so
before libgtk-3.so.0 and GNOME Shell used correct symbols from its
private library.
However, after GNOME Shell switched to Meson build system, gnome-shell
executable no longer lists libgnome-shell-menu.so as its dependency.
Even if we adds it to the build file, it won't be listed in DT_NEEDED of
gnome-shell because Meson uses -Wl,--as-needed by default. This causes
the runtime linker to load libgtk-3.so.0 before libgnome-shell-menu.so
and symbols gtk_menu_tracker*, gtk_action_observ*, gtk_menu_muxer_* are
bound to libgtk-3.so.0 instead of libgnome-shell-menu.so. GNOME Shell
hangs when opening more than one window because it uses functions from
the wrong library.
This problem is already fixed in OpenBSD ports. The article describing
it can be found on OpenBSD Journal with this link:
https://undeadly.org/cgi?action=article;sid=20170930133438https://bugzilla.gnome.org/show_bug.cgi?id=791943
meta-pick of commit c1573a1fda: the
variable gdk_window is used in a check, but we may as well use it again
to avoid calling _gtk_widget_get_window() again unnecessarily.
Putting a combobox in an expander was causing the combo arrow
to go sideways. Increase the specificity with which we address
the expander arrow to avoid that.
Users expect, & previous patches have tried to assure, that scrolling up
over a horizontal Range will cause the value to increase & vice-versa.
But the path using directions was still negating the delta & decreasing
the value on scrolling up. This could be seen on Win32 or X without XI2.
So, only negate the delta when scrolling down (or left), not up, so that
scrolling up (or right) will make the value increase for any event type.
https://bugzilla.gnome.org/show_bug.cgi?id=737175#c5
The only time a style-updated indicates we need
to reload fonts is when it is synthesized by GtkSettings
in response to a fontconfig timestamp change, but
we are listening to those already, anyway.
The code was asserting something that was not always holding
true. We can hit row == NULL here on page-up too. Handle that
case by moving to the first row.
https://bugzilla.gnome.org/show_bug.cgi?id=791549
_gdk_win32_data_to_string() is only available when G_ENABLE_DEBUG is
defined, so as in gdkproperty-win32.c, use GDK_NOTE on the parts where
we assemble and output the debug messages.
We need to notify ATK the description changed when the tooltip text associated
with the widget changes and gtk_widget_accessible_get_description() would use
it as the description.
https://bugzilla.gnome.org/show_bug.cgi?id=779009
It was used to mark css properties that affect widgets with text, but it
caused unnecessary invalidations. E.g. 'color' was marked as
AFFECTS_TEXT but changing just the color of a label should not
automatically queue a resize, which is what the code in
gtk_widget_real_style_updated does.
Replace this flag with GTK_CSS_AFFECTS_TEXT_SIZE and
GTK_CSS_AFFECTS_TEXT_CLIP, which GtkWidget can use only if the widget
actually has text.
https://bugzilla.gnome.org/show_bug.cgi?id=791281
In order to map a window with the correct initial parent-child
relationship when a modal dialog is set up to be a child of an imported
foreign window, the relationship must be set up before the window is
mapped.
In order to do this, if a window is not yet mapped, postpone the
relationship setup until when the window is eventually mapped.
https://bugzilla.gnome.org/show_bug.cgi?id=791062
The documentation about gtk_file_chooser_set_local_only() states
that "non-native files may still be available using the native
filesystem via a userspace filesystem (FUSE)."
The code that made this possible in GTK+2 was missing from GTK+3 and
that represented a regression for Linux users in numerous applications
(Firefox, Thunderbird, Chromium, ...)
https://bugzilla.gnome.org/show_bug.cgi?id=787128
As the summary says, this allows using g_autoptr(GtkTreePath). This is
useful for API that uses out parameters for GtkTreePath that need to be
freed.
https://bugzilla.gnome.org/show_bug.cgi?id=791234
After a pointer emulating GDK_TOUCH_END event triggering a fake leave
notify with GDK_CROSSING_TOUCH_END mode, pointer_under_window will be
unset, which will make the next motion/touch_update event to trigger
an enter notify event again.
Up till there, that's fine, however the motion event is just consumed
in favor of the just synthesized enter notify event. This is unexpected
to clients like spice-gtk that will only update coordinates from motion
events, sending both enter and motion is more consistent with X11 and
will make them happy.
https://bugzilla.gnome.org/show_bug.cgi?id=791039
It is unlikely that popup windows will contain anything that requires this
(popup menus being more interested in redirecting keyboard focus to
themselves). OTOH popup implementations that just grab the keyboard are
commonplace enough, it makes sense not to trigger inhibition for these.
https://bugzilla.gnome.org/show_bug.cgi?id=789268
No idea why it's here, the hash table can store any kind of data,
there's no reason why it wouldn't be able to store an old X string type.
Might be a holdout from the old days, when strings were handled in
a special way (stored directly in the clipboard?).
https://bugzilla.gnome.org/show_bug.cgi?id=786509
This prevents GTK from throwing a bunch of warnings when it tries
to get drag source window -> screen of that window -> ipc widget for that screen,
and then tries to attach a signal handler to that widget.
Specifically, this happens when we get a DnD move from another
application.
https://bugzilla.gnome.org/show_bug.cgi?id=786509
1) Ensure that any DELETE requests from the target are sent to GDK, even if
both the source and the target are in the same process and it
is therefore possible to use a shortcut and call the handler directly
in GTK layer
2) Ensure that target GDK doesn't do anything when GTK asks it to send
a DELETE request, just report back immediately (the code up the stack
does not check for successfullness when request is DELETE, so not giving
it any data is OK).
The source code already synthesizes a DELETE request, so that side is
also taken care of.
https://bugzilla.gnome.org/show_bug.cgi?id=786509
We need to know the target atom value to know when we need to
do something with side-effects (since side-effects are expressed via
special target values). Previously, the code side-stepped that by looking
at the data type (which was rather unique for the one side-effect
target that we supported, signalled by the TARGETS target),
but for the DELETE target that seems to be no longer an option, hence the new
field to carry this information past the convert_selection() routine.
This prevents GDK from throwing a warning when trying to convert
a DELETE target, which has no format or data objects set.
The side-effects for the DELETE target happen earlier, in GTK layer.
By the point it gets to change_property(), it's a no-op.
https://bugzilla.gnome.org/show_bug.cgi?id=786509
The wayland backend currently never emits GDK_SELECTION_CLEAR events.
GtkClipboard uses this signal in order to clear the clipboard owner when
the selection is set to something outside the application.
This commit ensures the wayland backend emits GDK_SELECTION_CLEAR before
setting the clipboard owner to NULL, as this means we lost the
selection.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790031
To do that, run the message loop for one second or until the side-effect
of running the selection request handler is achieved (as opposed to
running it until the event is no longer queued).
The disavantage of this method is that if the event handling is
somehow missed (due to a variety of reasons - after all, it's not
a straight path from an event being queued to property_change()
being called), this will loop for one second. Since we do process
events during that time, this will not hang the application, but
might still restrict some of the functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=786509
Handle WM_CANCELMODE and do nothing in response to it when DnD is
active. Otherwise pass it to DefWindowProc, which will call ReleaseCapture()
on our behalf.
This prevents us from losing mouse capture when alt-tabbing during DnD
(this includes the feature of Windows Explorer where dragging stuff over
a window button in the taskbar causes that window to receive focus, i.e.
keyboardless alt-tabbing).
https://bugzilla.gnome.org/show_bug.cgi?id=786509
Without this patch layered windows are only updated when they are moved
by the user or then their contents changes. This patch adds opacity
changes to the list of things that make GDK update a window. Without this
windows that don't redraw and are not moved by the used (DnD drag indicator
windows, for example) don't change their opacity.
https://bugzilla.gnome.org/show_bug.cgi?id=786509
Massive changes to OLE2 DnD protocol, which was completely broken before:
* Keep GdkDragContext and OLE2 objects separate (don't ref/unref them
together, don't necessarily create them together).
* Keep IDataObject formats in the object itself, not in a global variable.
* Fix getdata() to look up the request target in its format list, not in the
global hash table
* Create target GdkDragContext on each drag_enter, destroy it on drag_leave,
whereas IDropTarget is created when a window becomes a drag destination
and is re-used indefinitely.
* Query the source IDataObject for its supported types, cache them in the
target (!) context. This is how GTK+ works, honestly.
* Remember current_src_object when we initiate a drag, to be able
to detect later on that the data object is ours and use a
shortcut when querying targets
* Make sure GDK_DRAG_MOTION is only sent when something changes
* Support GTK drag cursors
* Ensure that exotic GTK clipboard formats are registered
(but try to avoid registering formats that can't be used between applications).
* Don't enumerate internal formats
* Ensure that DnD indicator window can't accept drags or receive any kind of input
(use WS_EX_TRANSPARENT).
* Remove unneeded indentation in _gdk_win32_dnd_do_dragdrop()
* Fix indentation in gdk_win32_drag_context_drop_finish()
* Remove obsolete comments in _gdk_win32_window_register_dnd()
* Check for DnD in progress when processing WM_KILLFOCUS, don't emit a grab
break event in such cases (this allows alt-tabbing while DnD is in progress,
though there may be lingering issues with focus after dropping...)
* Support Shell ID List -> text/uri-list conversion, now it's possible
to drop files (dragged from Explorer) on GTK+ applications
* Explicitly use RegisterClipboardFormatA() when we know that the string
is not in unicode. Otherwise explicitly use RegisterClipboardFormatW()
with a UTF8->UTF16 converted string
* Fix _gdk_win32_display_get_selection_owner() to correctly bail
when selection owner HWND is NULL (looking up GdkWindow for NULL
HWND always succeeds and returns the root window - not the intended
effect)
* More logging
* Send DROP_FINISHED event after DnD loop ends
* Send STATUS event on feedback
* Move GetKeyboardState() and related code into _gdk_win32_window_drag_begin(),
so that it's closer to the point where last_pt and start_pt are set
* Use & 0x80 to check for the key being pressed. Windows will set low-order bit
to 1 for all mouse buttons to indicate that they are toggled, so simply
checking for the value not being 0 is not enough anymore.
This is probably a new thing in modern W32 that didn't exist before
(OLE2 DnD code is old).
* Fixed (hopefully) and simplified HiDPI parts of the code.
Also adds managed DnD implementation for W32 GDK backend (for both
OLE2 and LOCAL protocols). Mostly a copy of the X11 backend code, but
there are some minor differences:
* doesn't use drag_window field in GdkDragContext,
uses the one in GdkWin32DragContext exclusively
* subtracts hotspot offset from the window coordinates when showing
the dragback animation
* tries to consistently support scaling and caches the scale
in the context
* Some keynav code is removed (places where grabbing/ungrabbing should
happen is marked with TODOs), and the rest is probably inert.
Also significantly changes the way selection (and clipboard) is handled
(as MSDN rightly notes, the handling for DnD and Clipboard
formats is virtually the same, so it makes sense to handle
both with the same code):
* Don't spam GDK_OWNER_CHANGE, send them only when owner
actually changes
* Open clipboard when our process becomes the clipboard owner
(we are doing it anyway, to empty the clipboard and *become* the owner),
and then don't close it until a scheduled selection request event
(with TARGETS target) is received. Process that event by announcing
all of our supported formats (by that time add_targets() should have
been called up the stack, thus the formats are known; just in case,
add_targets() will also schedule a selection request, if one isn't
scheduled already, so that late-coming formats can still be announced).
* Allow clipboard opening for selection_convert() to be delayed if it
fails initially.
* The last two points above should fix all the bugs about GTK+ rising
too much ruckus over OpenClipboard() failures, as owner change
*is allowed* to fail (though not all callers currently handle
that case), and selection_convert() is asynchronous to begin with.
Still, this is somewhat risky, as there's a possibility that the
code will work in unexpected ways and the clipboard will remain open.
There's now logging to track the clipboard being opened and closed,
and a number of failsafes that try to ensure that it isn't kept open
for no reason.
* Added copious notes on the way clipboard works on X11, Windows and GDK-W32,
also removed old comments in DnD implementation, replaced some of them
with the new ones
* A lot of crufty module-global variables are stuffed into a singleton
object, GdkWin32Selection. It's technically possible to make it a
sub-object of the Display object (the way Wayland backend does),
but since Display object on W32 is a singleton anyway... why bother?
* Fixed the send_change_events() a bit (was slightly broken in one of the
previous iterations)
* Ensure that there's no confusion between selection conversion (an artifact
term from X11) and selection transmutation (changing the data to be W32-compatible)
* Put all the transmutation code and format-target-matching code into gdkselection-win32.c,
now this code isn't spread across multiple files.
* Consequently, moved some code away from gdkproperty-win32.c and gdkdnd-win32.c
* Extensive format transmutation checks for OLE2 DnD and clipboard.
We now keep track of which format mappings are for transmutations,
and which aren't (for example, when formats are passed as-is, or when
a registered name is just an alias)
* Put transmutation code into separate functions
* Ensure that drop target keeps a format->target map for supported formats,
this is useful when selection_convert() is called, as it only receives a
single target and no hints on the format from which the data should
be transmuted into this target.
* Add clear_targets() on W32, to de called by GTK
* Use g_set_object() instead of g_ref_object() where it is allowed.
* Fix indentation (and convert tabs to spaces), remove unused variables
https://bugzilla.gnome.org/show_bug.cgi?id=786509
application/x-rootwindow-drop is not useful anywhere else,
so put it under #ifdef GDK_WINDOWING_X11
On W32 this prevents toplevels from automatically becoming valid
drop targets with a useless drop type.
https://bugzilla.gnome.org/show_bug.cgi?id=786509
Instead of using a boolean to indicate a modal operation being in progress,
use a set of flags, and allow these to be set and unset independently.
Specifically, this allows WM_CAPTURECHANGED handler to only act when a drag-move or
drag-resize modal operation is in progress, and ignore DND (which can also cause
WM_CAPTURECHANGED to be posted). This avoids a crash due to assertion failure when
OLE2 DND code tries to end a modal operation that was already ended by the WM_CAPTURECHANGED
handler.
https://bugzilla.gnome.org/show_bug.cgi?id=786121
Similar to GtkEntry, add an "Insert Emoji" context
menu item, and add the same keybindings. We don't
add the icon here, since it is not clear where it
would go.
https://bugzilla.gnome.org/show_bug.cgi?id=790029
Add Since annotations for the stock-* properties.
Add a doc comment for :stock-size in order to link to GtkIconSize.
Document :stock-detail as deprecated. It does nothing & is gone in GTK+4
Whereever we handle long-press for touch, it makes sense to handle
right-click as a faster alternative for mouse-based interaction.
This commit makes right-click work to bring up the variation
selector for Emojis.
g_resources_enumerate_children expects the path to end
in a '/' (even though thats not stated in the docs), and
will copy it if that isn't the case. Avoid the copy
by putting a '/' there to begin with.
g_resources_enumerate_children expects the path to end
in a '/' (even though thats not stated in the docs), and
will copy it if that isn't the case. Avoid the copy
by putting a '/' there to begin with.
It wasn't taking into account whether the sidebar had support for them
or not, resulting in a file chooser with open in new tab/window menu
items when it's not supported.
To fix it, do as with the other menus and check for the availability of
new tab/window flags.
https://bugzilla.gnome.org/show_bug.cgi?id=786123
To avoid copying data from gresources to the heap, we can use
the newly added gtk_file_load_bytes(). That function will check
for resource:// URIs and access their internal data directly.
Other URI schemes will read the contents into memory and return
a GBytes as normal.
https://bugzilla.gnome.org/show_bug.cgi?id=790270
When the duration is set to 0, clamp it to 1us. This way we're almost
correct: We should really instantly finish, but we don't. But we do
respect the delay.
Doing this properly would require some refactoring of how the progress
tracker actually maintains progress, and this is just a quick fix.
commit 475d916eb9 added various paths that
use theme-name for this, but the existing path already used THEME, with
a subsequent description referring to the latter. So use that everywhere
Since on Windows we need to use a good amount of temporary GL contexts,
we need to switch back to the original GL contexts we were using when
we are done with the temporary GL contexts, otherwise multi-GL windows
will cause confusions causing display artifacts and crashes.
Also, use the GdkWin32GLContext::gl_hdc consistently throughout
the code and remove the GdkWin32Display::gl_hdc as Lukas K pointed out
that GdkWin32Display::gl_hdc becomes out-of-date and so the HDC that the
GL context is bound to becomes incorrect in sceanarios using multiple
windows with GtkGLArea/GdkGLArea items (which would cause the artifacts in
programs that use multiple windows with GtkGLArea/GdkGLArea items, and it
turns out that GdkWin32Display::gl_hdc is actually not necessary to help
keep track of the HDCs we use for our GL contexts.
Partly based on patch from Lukas K <lu@0x83.eu>
https://bugzilla.gnome.org/show_bug.cgi?id=789213
• Remove the box-shadow at the top when the entry is in the foreground
• Bump precedence so that :disabled entries do not have .flat overridden
• Also add :backdrop to stop HCInverse getting a lighter BG in :backdrop
https://bugzilla.gnome.org/show_bug.cgi?id=789733
Move the default pos of the Paned handle to 400px from the left, i.e.
50% of the default width of the window. The previous position at 300px
from left meant the node treeview was too narrow & could easily result
in the (useful) State column not being visible in the case of many
apps. The properties pane doesn't need to be as big as it was anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=788898
This patch moves the "Copy to Clipboard" button into the same container
as the description label, to centre the button regardless of the number
of icons shown in the grid.
https://bugzilla.gnome.org/show_bug.cgi?id=789134
On Windows, when IME is used, each keystroke results in the
WM_IME_COMPOSITION event being sent first. This means that in our case
when one decides on to accept the input that is in the preedit buffer,
we first get from Windows the WM_IME_COMPOSITION event
(where we emit the commit signal), followed by the WM_IME_ENDCOMPOSITION
event (where we emit the pair of preedit-changed and preedit-end
signals).
Since commit f11f989 (GtkEntry: Remove recompute idle), we do the input
recomputation directly, this will cause a pair of "Pango-WARNING:
Assertion failed: (index >= 0 && index <= layout->length)" being shown,
as gtkentry.c's priv->preedit_length and priv->preedit_cursor was unable
to be reset to 0 in time as a result of the recomputation triggered by
the commit being done before the reset of priv->preedit_length and
priv->preedit_cursor (which are no longer valid as we essentially say
that we are done with the preedit buffer).
As we could only acquire the final string that was entered in this
preedit session when we handle the WM_IME_COMPOSITION event, fix this by
saving up the final string we acquire from Windows IME in UTF-8 when we
handle the WM_IME_COMPOSITION event from Windows, and emit the commit
signal with that string after we emit the preedit-changed and
preedit-end signals when we handle the WM_IME_ENDCOMPOSITION event from
Windows, which comes afterwards.
Also fix the formatting of the code around the parts of the files that
was changed.
https://bugzilla.gnome.org/show_bug.cgi?id=787142
The path bar would crash if we disposed it before all pending I/O
operations had finished. Now we remember all the outstanding
operations directly in the GtkPathBarPrivate, and deal with them
consistently.
According to the documentation, gdk_monitor_get_geometry() reports the
monitor geometry in ”application pixels”, not in ”device pixels”,
meaning that the actual device resolution needs to be scaled down by the
scale factor of the output.
x11 backend does that downscaling, whereas Wayland backend did not,
causing a discrepancy depending on the backend used.
https://bugzilla.gnome.org/show_bug.cgi?id=783995
This state flag is used in several places in GTK+, for example to
ignore RESIZE_INC hints if tiled. Setting it is also necessary for
backwards compatibility with applications that changed their behaviour
when tiled, such as GNOME Terminal and its MATE fork.
Signed-off-by: Simon McVittie <smcv@debian.org>
https://bugzilla.gnome.org/show_bug.cgi?id=789357
If the compositor prefers server-side decorations and the client doesn't
customize the title bar, we disable client-side decorations and let the
compositor know. Otherwise, we continue to use client-side decorations.
Signed-off-by: Drew DeVault <sir@cmpwn.com>
https://bugzilla.gnome.org/show_bug.cgi?id=781909
Under Wayland, an xdg_surface.configure with size 0x0 means it's up to
the client to set its size.
When transitioning from maximized state to un-maximized, the Wayland
compositor will send such an 0x0 configure so that the client can
restore its original size.
However, the original size was already constrained, so re-applying
size constrains can lead to a smaller size when using size increments.
Avoid this caveat by not applying size constrains when we are restoring
the original size.
https://bugzilla.gnome.org/show_bug.cgi?id=777072
As documented, GtkAppChooser is "typically [used] for the purpose of
opening a file". However given that applications that support neither
opening files nor URLs are filtered out, the chooser is not actual
useful for any other (atypical) usage. Change that by only applying
the filtering if a content-type was set, and use the full unfiltered
list otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=789327
We were unnecessarily spewing warnings when blank cursors
were getting a new scale set. Standardize on "none" as the
name for blank cursors, and avoid the warning.
https://bugzilla.gnome.org/show_bug.cgi?id=775217
Some clients (e.g. gnome-online-accounts) quickly unmap and map
a window. With some backends the backend surface will be replaced
causing the application to crash because the GL context is still
using the old surface. Clearing the GL context when a window is
withdrawn fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=789141
Ensure that the /DYNAMICBASE linker option (which is actually the
default) is enabled for all of our Visual Studio project builds, as the
gtk3-demo projects inadvertly disabled it.
Also, for x64 builds on MSVC 2012 or later, enable /HIGHENTROPYVA to
enhance the security of our binaries as well.
Pointed out by Ignacio Casal Quinteiro.
The code has been shuffled so GDK_TOUCH_BEGIN results in a
GDK_MOTION_NOTIFY to the new position and a GDK_BUTTON_PRESS on that same
place. This makes pointer emulation consistent with what X11 does. Even
though button presses have x/y arguments, there's code out there relying
on getting prior motion events.
When making mockups for GNOME apps in Inkscape, looking for symbolic
icons is a common task. Searching for icons in the file system is clumsy,
and icon-browser provides a much better interface for finding them.
However, currently there is no way to insert the symbolic icons as SVG
directly from icon-browser, so right now it is only useful for finding
the name.
This patch adds a sixth column to the modal window that appears when
clicking a symbolic icon. The icon in this column is labeled "scalable",
and dragging it onto another window results in the vector icon URI being
inserted.
This enables a much simpler workflow when designing with symbolic icons.
https://bugzilla.gnome.org/show_bug.cgi?id=778930
What is missing is the "allocation" part of x/y coordinates. Since
gtk_entry_realize doesn't call gtk_widget_set_window(priv->text_area),
the coordinates returned by gdk_window_get_origin don't include it.
This patch fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=784509
Bug 737175 aimed to ensure that scrolling up on a horizontal range would
result in its value increasing, as that’s what users intuitively expect.
However, its commit 416c370da1 meant that,
if the event gives scroll deltas, we inverted our delta unconditionally.
So it broke horizontal scrolling: scrolling left moved the slider right…
We must only invert if using dy as delta. dx already has the right sign,
so inverting it was wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=788905
If the call to set_parent() failed, we were still adding the child to
the internal list of children, despite that it was not really added.
That meant we could later try to do invalid stuff with that non-child.
Fix that by asserting and giving up if the child that the user is
attempting to add is already parented.
https://bugzilla.gnome.org/show_bug.cgi?id=701296
The language is useful for parsing tools, such as that of gtkmm, which
otherwise assumes these are C snippets and elides them from its
generated documentation.
The old GtkBlah node names are just plain obsolete.
It does not hurt us to keep middle clicks doing the same
as shift-primary clicks. This makes the transition from gtk2
less painful in terms of muscle memory.
https://bugzilla.gnome.org/show_bug.cgi?id=787669
~Company ╡ so TL;DR: we put the static style in the cache, but then
⤷ ╡ compute a child style from the animated style in the cache
⤷ ╡ and we put the child style also in the cache (because
⤷ ╡ it's not animated)
⤷ ╡ then we run the animation, but reuse the cache every time
⤷ ╡ for both child and parent
⤷ ╡ so after the animation is done, we end up with a cache that
⤷ ╡ has the correct static style for the parent but an
⤷ ╡ incorrect static style for the child
⤷ ╡ because that static style was computed from the
⤷ ╡ initial animated style
This fixes https://bugzilla.gnome.org/show_bug.cgi?id=763517
Check UUID for printers obtained via DNSSD whether
they are already installed on local CUPS server.
Don't show such printers.
Not all printers published via DNSSD have UUID entry though.
https://bugzilla.gnome.org/show_bug.cgi?id=786794
We moved from the Ruby compiler to sassc in
commit 67953e9cfb, so this copies across
the updated info about building from GTK+ 4.
Also, explain the purpose of parse-sass.sh, since while that is not
mentioned in GTK+ 4 – and perhaps does not need to be, thanks to Meson –
we are still on Autotools here, and rebuilding the entirety of GTK+ 3 if
you only edited the CSS is a lot of waiting for no good reason.
GtkMenu’s own keynav code, which actually bothers to account for the
layout of items, only happens if columns > 1. So, adding items to 1
column using a reverse loop meant they were placed in the Menu’s list of
children in that order, and because we only have 1 column, Menu passes
keynav up to MenuShell, which doesn’t adjust for the items’ positions.
‘Fix’ that here by adding items in the same order they’ll have when laid
out in the Menu, so keynav does what you’d expect, not the opposite. For
that, it’s simpler just to use gtk_container_add().
Let’s presume users are using add(), attach() with a non-inverted loop,
or attach() with arguments that create 2+ columns and so GtkMenu keynav.
It was selecting paned separator, which means any separator at any level
of descent within a paned, including the toplevel container in GEdit.
We need to be more specific and only select the relevant separator that
is the direct child of the paned. This is what Adwaita does.
https://bugzilla.gnome.org/show_bug.cgi?id=788573
Nulling priv->button in _unset_tree_view() is asymmetrical: we create
it via init(), not _set_tree_view(), so we shouldn’t null in the latter.
Worse, doing so manifests in criticals + a SEGV easily with basic use of
testtreecolumns, removing the TVC from a TV then trying to add it to one
Finally, the wrong null-out meant dispose() failed to unref the button,
so it leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=728452https://bugzilla.gnome.org/show_bug.cgi?id=788614
It was in both [general] with a description and [other] with none.
Leave it in [other] with the other folder- icons, + the description.
bonus: this makes all of [general] fit in our default window size!
The border and icon highlight are useful feedback that was defeated by
CSS precedence. It worked for .titlebuttons due to their implementation,
but the same was not true for custom .flat buttons. This makes it so.
https://bugzilla.gnome.org/show_bug.cgi?id=788580
When the window was backdropped, they suddenly regained their border.
This was clearly not intentional or of any practical use to anyone.
Shuffle around some selectors so that the backdrop ones do not override
the flat ones and make the borders magically reappear when backdropped.
Note that, whereas standard titlebuttons get the border on :hover, other
.flat buttons in the headerbar do not. That should probably be fixed too
https://bugzilla.gnome.org/show_bug.cgi?id=788580
…from priv->button. My refactor to g_signal_disconnect_by_data()
included this widget, when I shouldn’t have as both modes use it.
This e.g. broke opening a CB by keyboard that was currently in menu
mode, if it had been in list mode initially (e.g. due to the theme).
Fix by moving to disconnect_by_func() and only removing in each mode’s
destroy() method the signals that it set on the button in its setup().
https://bugzilla.gnome.org/show_bug.cgi?id=788577
They were hard-coded to a transparent black, but that is our bg colour
in HC Inverse, so windows stacked on top of each other or a dark
background blended together into a mush.
Fix this by making the $_wm_border* colours relative to the fg colour,
so that HighContrastInverse gets borders that are transparentised white.
https://bugzilla.gnome.org/show_bug.cgi?id=788575
A missing decoration selector meant that we got a solid black background
behind the rounded corners of the dialog.
Copy the equivalent code from Adwaita, including nicely rounding the
focus outline too (& sorry, but this needs more newlines to be readable)
https://bugzilla.gnome.org/show_bug.cgi?id=788574
by migrating the relevant code from Adwaita, to dodge unwanted doubling
up of the bottom border and such.
It also hopefully still encompasses whatever commit
b4371728de was trying to do; certainly, it
retains the resolution of the main bug/patch that one was attached with.
https://bugzilla.gnome.org/show_bug.cgi?id=769877
There were various problems, like only selecting on .tooltip and not the
widget node tooltip, not being specific enough for tooltip.csd, etc. So,
specific theming was absent, and default popup window styles got applied
This commit copies in the better working tooltip CSS from Adwaita, but
applies a couple of changes to make it work better in the HC themes:
• Reduce the transparency of the tooltip, so we achieve higher contrast
• Drop the black text-shadow, as it is not useful on this more black bg
Note: we may then need to re-add some of this to the .tooltip class. But
it is unclear what needs done there. While Adwaita is not doing it, we
are better not to confuse by keeping it in HC only; we should try to be
as close as possible, to make it easier for HC to keep up with Adwaita.
https://bugzilla.gnome.org/show_bug.cgi?id=769879
We need
.window-classes decoration
but within the decoration parent selector, we were doing
&.window-classes, which gave us
decoration.window classes
We need to fix this by selecting on .window-classes &
https://bugzilla.gnome.org/show_bug.cgi?id=788496
n_attach_points is the result of g_strv_length(): the index at which the
string vector ends in NULL. So by definition, when i == n_attach_points,
string[i] == NULL, and there is no need to check for the latter. The
fact that we did appears to confuse static analysers, as the dereference
and index check were inverted from what would normally be safe. We could
reverse them, but we may as well just remove the unnecessary NULL check.
https://bugzilla.gnome.org/show_bug.cgi?id=788458
This gives consistent behavior with e.g. Qt, Mozilla's suites and
LibreOffice (with non-truly native backends like "gen" and "gtk",
but unlike "gtk2" and "gtk3" ones that probably use true GTK menus).
This behavior is expected by at least some accessibility users, and
it seems good to behave like other common applications and toolkits
in this area. There should be no issue in doing so either for current
users, as it only enters the submenu instead of not doing anything.
https://bugzilla.gnome.org/show_bug.cgi?id=778811
This reverts commit 1301723905.
This only appeared to fix the two bugs it linked because, rather than
being superfluous, the GTK+ grabs resulted in effectively having *none*,
or something, and could cause a critical when closing during a scroll.
This also reverts commit b9989e554b, which
depended on the above.
See next commit, which *should* properly fix what this one claimed to…
https://bugzilla.gnome.org/show_bug.cgi?id=787274
On clicking release, we call TreeView.get_path_at_pos() &, if we hit a
row, select it (if sensitive) & close the popup. But this alone does
not account for clicks on the expanders within the TreeView, so in
addition to expanding/collapsing, clicking them would close the list.
Check if the click is in the cell_area() & thus “excluding surrounding
borders and the tree expander area” but still including the background
(which TreeView.is_blank_at_pos() doesn’t); if TRUE, don’t select/close.
The popup doesn’t always resize enough… so there’s still breakage here.
The XXX comment on TreeView requests in list_position() may be relevant
to this. But at least this drags such CBs one step closer to adequacy:
expanding by mouse now works ~no worse~ than by keyboard already did.
https://bugzilla.gnome.org/show_bug.cgi?id=788505
Commit c415bef5de introduced support for the new _GTK_EDGE_CONSTRAINTS
atom. If the compositor supports that atom, however, we were always
setting the tiled state, even if no actual tiling information is
available, where the correct action is to completely remove any traces
of the tiled state.
Fix that by correctly removing the tiled state when compositor supports
_GTK_EDGE_CONSTRAINTS Xatom.
https://bugzilla.gnome.org/show_bug.cgi?id=788516
Ditch two items that were white and so weren’t visible on our standard
theme anyway, and use the new space to test extra grid-mode properties.
Note that if we do this then, as before, we set the ListStore on the
ComboBox before appending to it, that produced runtime warnings like:
Gtk-CRITICAL **: gtk_menu_attach: assertion 'left_attach < right_attach' failed
I didn’t look into that yet, but it may indicate that attaching items
vs. recognising their spans don’t occur in the correct order. For the
purposes of testing this, I just create the CB after filling its model.
ComboBox and TreeMenu warned in the doc for :row-span-column that the
value must not exceed :wrap-width, but :wrap-width does not interact
with the number of rows; it’s the :column-span-column that’s relevant.
Also: Warn that spans must be > 0 for rows too, and that column spans <=
:wrap-width are also not useful for items at menu column positions > 0.
Finally, refer to items having spans, not values, as we were already
talking about values in the model (and rows in the menu).
The last touch on this patch series is making GtkWindow able to
selectively adjust various UI details based on the different
tiled edges. The main driver here is that we don't want to show
shadows on edges that are constrained.
This patch adds the necessary code to do that, while still
maintaining compatibility with the old ways.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
Following the previous patch, where edge constraints support
was added to the Wayland backend, this patch introduces the
necessary code to handle the _GTK_EDGE_CONSTRAINTS atom from
X11 backend.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
Now that GTK windows have the ability to properly handle
per-edge tiling constraints, this patch extends GTK's
internal Wayland protocol to have a proper enum with the
relevant edge data.
Once this approach is validated, we can think of upstreaming
this work as an official Wayland protocol extension.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
GTK windows don't have their tiling states really
hooked into the client-side decoration code, and
the only effect it has is disabling the resizing
edges.
With the introduction of per-edge tiling information,
we are backed by much more precise data on how the
window manager wants the app to behave.
This patch, then, fixes GtkWindow to take into account
per-edge tiling information. For compatibility purposes,
the previous tiled field was kept, and thing will just
continue working if no edge information is supplied.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
These states will be consumed by GtkWindow in order to
have better edge management on tiling situations. Their
values are supplied by the compositor, and will be send
through and X11 Atom or a Wayland protocol extension.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
This reverts commit 15a3747406.
There is a way to get different kinds of borders: it's CSS. It's better
to keep the 4 Frames and demo the different styles we can do using CSS.
The GtkFlowBoxCreateWidgetFunc type lacked GObject Introspection
annotations for its arguments. This made gtk_flow_box_bind_model()
unusable from Python as the callback function would be passed useless
values.
The annotations that I've added match those of the similar callback
type GtkListBoxCreateWidgetFunc.
https://bugzilla.gnome.org/show_bug.cgi?id=780758
gdk_seat_default_grab() grabs POINTER_EVENTS if the capability is
GDK_SEAT_CAPABILITY_ALL_POINTING. But that enumerator is a union that
includes GDK_SEAT_CAPABILITY_TOUCH, but we never grabbed TOUCH_EVENTS,
an unused macro that was presumably created with this purpose in mind.
So, check which of the ALL_POINTING capabilities we have, and set the
right mask of POINTER_EVENTS and/or TOUCH_EVENTS as required.
As part of this, explicitly let TABLET_STYLUS take over pointer events,
as this is the intended behaviour and was the effective result before.
This should fix touch events being lost in migrating from Device.grab()
to Seat.grab(GDK_SEAT_CAPABILITY_ALL_POINTING), as found by Inkscape.
https://bugzilla.gnome.org/show_bug.cgi?id=781757
Clarify that ::destroy, not ::hide*, removes a window from its app, by
replacing the mention of open windows with the blurb on destruction from
:application, completing commit 7db4bee4b6
Also link to the equivalent gtk_application_(add|remove)_window() calls,
since Application.add_window() already links back to Window:application.
* unless you use gtkmm…
https://bugzilla.gnome.org/show_bug.cgi?id=639931
It was never unref()d, either when replacing the existing GObject in
set_property(), cleaning up in finalize(), or becoming a placeholder.
Fix by using g_set_object() and g_clear_object() to unref as needed.
This also drops the check that the newly set object is a valid cloud
provider account, as we don’t do the equivalent for any of the other
object-typed properties, and Carlos didn’t think this was important.
https://bugzilla.gnome.org/show_bug.cgi?id=787600
The focus outline disappeared as the colour of the swatch got close to
the normal focus outline colour, which is alpha(currentColor, 0.3).
Fix by making the outline an alpha’d version of the tick colour, but
more opaque than normal outlines. 0.6 seems good enough; feel free to
improve it, but at least this ensures the outline can’t vanish anymore.
HighContrast achieves this already because it applies the color property
to the main node, not the overlay. Doing that means the outline is fully
opaque, which is fine for HC obviously but was excessive for Adwaita.
https://bugzilla.gnome.org/show_bug.cgi?id=787757
It used $text_color unconditionally, but in :dark, text is white, so we
overlaid a white tick on any light colours, all the way to white itself.
Using these named colours doesn’t make practical or semantic sense.
Instead, use white/black over dark/light swatches, as in HC, so all
variant–swatch combos work. Light looks the same, & :dark works now.
For backdrop, use alpha 0.5, unlike 0.7 in HC, as that seemed excessive
& different from the current effect. 0.5 is almost identical to how
$backdrop_fg_colour is a 50% mix of $fg_color, & matches backdrop text.
https://bugzilla.gnome.org/show_bug.cgi?id=787531
This class is not added by any widgets nor themed by Adwaita/HC.
However, it is presented here as if it does something. It doesn’t.
But we changed the 2 buttons with the .raised class to use symbolic
icons, unlike their ‘unraised’ counterparts, which is unnecessarily
confusing and might make people think .raised affects icons somehow.
So, make them use the same icons in all cases; that way, if .raised is
ever made to do anything, 6 years later, what it does will be clear.
https://bugzilla.gnome.org/show_bug.cgi?id=644248
Instead of showing the 4 types except for GTK_SHADOW_NONE, which are all
treated identically and provide no way for themes to differentiate, just
keep 2 Frames, and make one of them GTK_SHADOW_NONE to demo a flat Frame
along the orthogonal orientation. It seems a FlowBox on its own can only
handle being shrunk along its main orientation. The orthogonal requests
a huge min size – reserving what it would need if the main orientation
got its min size, which would flow all children in 1 line orthogonally.
Adding it to a ScrolledWindow (any policy) enables free shrinking, so
size_allocate() can reflow how users in this situation probably expect.
https://bugzilla.gnome.org/show_bug.cgi?id=787021
Without specifically connecting ::delete-event to something, the dialog
will be destroyed when it is closed, for example by pressing Esc. This
meant that when dismissing it this way, unlike by pressing Cancel, any
custom palette would be lost when the dialog was next opened, and so on.
Resolve this by making ::delete-event just do GTK_RESPONSE_CANCEL, so
closing the dialog has the same effect as clicking its Cancel button.
https://bugzilla.gnome.org/show_bug.cgi?id=787444
As reported in https://github.com/ibus/ibus/issues/1944,
typing u201e while holding Ctrl+Shift used to give a „
when letting go of Ctrl+Shift. This broke when we introduced
Ctrl+Shift+e to start Emoji sequences. Fix this by only
looking for Ctrl+Shift+e if we are not already in a hex
sequence.
Only HighContrast has a clear problem, and this avoids some probably
unwanted changes of certain colours in the weird greyscale emoji I have
available to test here.
On button release, we were popping down if the event widget was anything
but priv->button. This broke scrolling by clicking a mouse button, i.e.
when releasing a click in the trough or finishing a drag of either bar.
That’s unexpected, inconvenient, and pointless. So, let’s stop doing it.
https://bugzilla.gnome.org/show_bug.cgi?id=738893
We were only selecting a section’s button if the adjustment y coord was
within its heading, so scrolling slightly into it unchecked all buttons.
This also fixes how we could end up with the first 2 selected, somehow.
https://bugzilla.gnome.org/show_bug.cgi?id=787172
Nice try, but size groups don't work with invisible widgets anyway.
Invisible widgets request 0×0.
[reapplying after accidental reintroduction in the cloudproviders patch;
see https://bugzilla.gnome.org/show_bug.cgi?id=786123#c39]
Use opacity to differentiate unselected/hovered/selected buttons. It had
assumed bg < border < fg colours, which may be false, as in Adwaita:dark
This also means we do not need to special-case for the backdrop state.
https://bugzilla.gnome.org/show_bug.cgi?id=786956
in a specific case, which was applying .slider as a class on the parent
switch, instead of correctly selecting on its child node named slider.
This makes the border on the outside of a switch in a selected listbox
row look better in the light variant. Since the code was never removed,
it was clearly meant to work, and making it work is a clear improvement.
Using this produced warnings about the Pango syntax of <Family> <size>
being deprecated, and the size being invalid due to no unit specified.
Also, that multi-word font family presumably wouldn’t work as expected.
This reverts commit d09bc2b108.
As an English-speaker, I know nothing about complex grammar, and it’s
been brought to my attention that some languages might differ in the
translation of the same command depending on where it appears.
So, I’d better assume everyone else knows better than me. Apologies!
The emoji chooser gets disposed already, because it is attached
to the toplevel as a popover. Doing it again when the object data
is cleared is leading to a crash.
https://bugzilla.gnome.org/show_bug.cgi?id=787103
• Use disconnect_by_data() to catch both _adjustment_changed() and now
_adjustment_value_changed(), as the latter had been missed until now.
• Also disconnect from indicator_value_changed(), which was not done in
destroy() due to indicator_reset() and remove_indicator() disagreeing.
https://bugzilla.gnome.org/show_bug.cgi?id=775074
Do not connect to get_settings_for_screen() if we have no screen…
Use g_signal_connect(), not connect_object(), to match how set_screen()
makes these same connections, and how finalize() already disconnects.
https://bugzilla.gnome.org/show_bug.cgi?id=705640
Since the move from button-press to gesture events, Shift-clicking did
not work to start a selection (from none) or truncate an existing one.
This was due to the code being copy-pasted around and some logic being
broken in the process. This makes both of those work as they should, by
shuffling it again so the end result is the same as before. Highlights:
(1) ::button-press if extending due to a single press would call
set_positions(tmp_pos, tmp_pos), which is what made the Shift+click to
create a selection work. That was lost. Add it back to make that work.
(2) ::button-press in the “Truncate current selection” branch would not
execute all the stuff around “extend_to_left”, as that was the else
case. So, set extend_selection = FALSE so we skip over that later on.
(3) BUT! This Truncate case never fired because it was in the else
branch of if (in_selection())! Of course, it must be in the true branch.
(4) The IM context was not reset if the Shift-click occurred within an
existing selection, only if it did not. In ::button-press this was the
first thing done if extending a selection, regardless. Make it so again.
https://bugzilla.gnome.org/show_bug.cgi?id=780750
The new menu items were not marked for translation, had no mnemonics,
and were not title-cased. Reuse the strings that we already had for the
buttons shortly down the file, and mark these for translation.
https://bugzilla.gnome.org/show_bug.cgi?id=786123
realize() gave the event_window the allocation of the whole widget. This
was wrong; it should be that of the title_gadget, as in size_allocate().
This broke expanders in which :expanded is TRUE before showing: Input
over the entire widget was sent to the title, making the child unable to
receive it. Clicking the child unexpectedly collapsed it. Once expanded
again, things fixed themselves as size_allocate() fixed the event_window
alloc. So, queuing a reallocate or resize after show() was a workaround.
Fix by giving event_window the allocation of the title_gadget, to match
what size_allocate() does. That is symmetrical and just plain correct.
https://bugzilla.gnome.org/show_bug.cgi?id=774134
Themes should not enforce min sizes on blocks in continuous mode; in
this case, the filled block should be as large as it needs to be to
reflect the current value, and no larger or smaller than that. So, the
fact that the minimal size was selected on just levelbar block is wrong:
we should also require the levelbar.discrete class to apply min sizes.
The widget should enforce whatever correct minimum size results from the
above fix, by reapplying commit 78b4885fe8
Except: we should not allocate/draw the filled block if the value is 0,
as in this case, the LevelBar should be empty, not have a min-size fill.
https://bugzilla.gnome.org/show_bug.cgi?id=783649
Container:border-width caused the x/y coords converted to iters to be
offset inwards by that width, breaking positioning/selecting by gesture.
So, subtract :border-width in widget_to_text_window_coords(). This fixes
gesture positions, & plays fine with :margin & CSS margin/border/padding
N.B.: This is not to endorse :border-width. It’s gone in GTK+ 4 & weird
on a TextView: it’d be more intuitive to – if you must! – set it on the
TV parent. Really, please just use CSS instead. Still, it’s easy to fix.
https://bugzilla.gnome.org/show_bug.cgi?id=759725
Various disconnections had the wrong flags and/or data, so we failed to
disconnect a pile of signals, shown by 0 returned by the disconnect_*()
functions. Fix this, and use the nicer disconnect_by_*() while here.
set_transient_for(toplevel) was only called in list_setup(). It was easy
to make a test showing a NULL :transient-for instead of the correct one.
So, move the call from list_setup() to popup_for_device(). Also do that
for window_group_add_window(), which means not calling it redundantly.
(I tried using a ComboBox:parent-set handler, but the Inspector’s CB
didn’t like that: it calls popup_for_device() twice and closes on button
release. Anyway, using popup() is much more concise than a new handler.)
The screen for the list-mode popup_window was only being set in
set_popup_widget(), i.e. when changing modes, so if the ComboBox was
moved to a different screen later, the popup would appear on the
original one, which is wrong.
Worse, this (somehow) broke opening some combos in the Inspector.
Fix this by moving the call to set_screen() to popup_for_device(), so
the popup_window is put on the correct screen each time around.
https://bugzilla.gnome.org/show_bug.cgi?id=468868https://bugzilla.gnome.org/show_bug.cgi?id=786771
This is so that it is easier for one building GTK+ with Visual Studio to
build the introspection files as well in one shot. Note that this is
not built by default, so one needs to select the gtk3-introspect
explicitly to build (and clean up) the introspection files.
For this to work, one needs to ensure the following:
-A complete build of GObject-Introspection in $(GlibEtcInstallRoot),
that is built with the same installation of the Python interpretor that
is used here (see PythonDir and PythonDirX64 in
gtk3-version-paths.[vsprops|props]).
-Introspection files for ATK, GDK-Pixbuf and Pango, also in their proper
locations under $(GlibEtcInstallRoot), which should be built with the
same G-I installation.
The build/win32/detectenv-msvc.mak needs to be updated for Visual Studio
2017, and we ought to add quotes to surround the copy destination path
for the introspection files, so that we do not bail out in the copy
process (cmd.exe's copy command does not like '+' in them that are not
quoted).
This is to make this more in-line with what is in the G-I projects, so
that we could use this to build the introspection files for GTK+-3.22.x
directly from the project files. This is intended to follow the MSVC
versions used to build the official CPython Windows binaries, i.e.:
-3.3.x, 3.4.x: for MSVC 2010, 2012, 2013, which is built with 2010
-3.5.x, 3.6.x: for 2015 and 2017, which is built with 2015.
Under X, we were not setting the right drag cursor initially,
because at current_action == action == 0, initially. Fix this
by explicitly using the right cursor when grabbing.
Add integration of the libcloudproviders DBus API to the
GtkPlacesSidebar by showing name and sync status of the cloud providers.
The exported menu is rendered as a GtkPopover.
The sidebar will be updated if the list of cloudproviders changes e.g.
by adding or removing an account. If any cloud provider changes detailed
information like sync status only the individual sidebar row gets
updated.
Co-authored-by: Carlos Soriano <csoriano@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=786123
Bad actors, such as our very own FileChooserButton, may connect to the
:popped-up property and alter the model as the menu becomes in/visible.
We were getting an iter to the model while popped-up, then doing
popdown(), then using the iter, which may have just been invalidated by
the errant notify::popped-up handler. If so, we quickly crash fatally.
This is clearly bonkers, but until such patterns are removed, we have to
work around them. So, set_active() from the clicked item while it is
known to be valid, by moving the call to set_active() before popdown().
While here, change set_active_iter(iter) to set_active_internal(path) to
avoid pointlessly going through the iter to get the path we already have
https://bugzilla.gnome.org/show_bug.cgi?id=729651
Just adding/removing to/from the BoxGadget is not sufficient; that
leaves the GdkWindow hanging around, taking input, changing the cursor,
and all sorts of other nefarious shenanigans.
Resolve by ensuring the child’s GdkWindow is unmapped if collapsed.
Note: the reflexive solution is just to set_visible(child, expanded),
but it is best to avoid messing with the child’s :visible property.
https://bugzilla.gnome.org/show_bug.cgi?id=776937
.update_position() enforces that non-Wayland platforms must position a
Popover within its parent Window. We use the allocation of the Window
to translate the position and check for overshoot on each of its sides.
Calling Widget.get_allocation() of a CSD Window includes its shadows.
But shadows were not excluded from the area in which we can position.
Thus, Popovers could get positioned in the shadow of CSD windows, where,
at least on X11, no input is received. Therefore, positioning a Popover
over a shadow meant its child widgets within that area became unusable.
Fix by calling Window.get_shadow() and including it in the overshoot on
each side. This adjusts for how the allocation includes shadows, making
overshoots with and without shadows the same. Thus, we avoid considering
shadows as viable for positioning, favouring a side where input works.
https://bugzilla.gnome.org/show_bug.cgi?id=786209
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
Seems to be there for the sole purpose of ensuring the button
shall receive the key release on keyboard-triggered activation.
For the cases where this makes sense (eg. comboboxes, menubuttons,
...) gtk+ already does ensure the menu is popup after key release.
This makes the grab pretty useless, and there's many other cases
where it doesn't make sense (eg. button being activated
programmatically from an event handler in another widget).
Fixes button activation unintendedly triggering shortcut inhibition
on wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=786480
Commit 1d0fad3 revealed that there were some assumptions made that were
actually to compensate for the bug fixed by that commit, so we need to
remove those assumptions as they would result in AerSnap to not work
properly on HiDPI screens.
Also re-do how we set the x and y positions of our GdkWindow, so that we
are more consistent across the board when we go between a GDK window
coordinate and a Windows API window cooredinate.
This would also simplify the code a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=785999
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
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.
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
A recent commit for emoji also updated seemingly unrelated parts of the
generated CSS files, presumably due to other things that changed in
master. The CSS files should be kept in sync with their SASS sources.
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
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 returns 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
caught 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
This fixes a fallout from 8a7d0ab481 where the error wasn't being
set when a display couldn't be opened right after parsing the
commandline.
It also fixes an older bug where the error would be left unset if the
commandline had already been parsed before (ie. when gtk_initialized
is TRUE).
https://bugzilla.gnome.org/show_bug.cgi?id=771959
The existing documentation seems to suggest that gtk_init_check will
ignore any failure to parse the commandline arguments, and that its
return value only depends on its ability to initialize the windowing
system. That's not true.
Be more explicit to avoid misunderstandings.
https://bugzilla.gnome.org/show_bug.cgi?id=771959
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
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
This was comparing the input position, which is documented as being
relative to the top-left of the Entry allocation, to icon allocations
that were not adjusted accordingly. This could result in tooltips for
icons not being shown in various conditions, since the ::query-tooltip
handler uses get_icon_at_pos() to check whether to show an icon tooltip.
The fix is to compare to the icon border box, not border allocation, as
CssGadget::get_border_box() adjusts relative to the widget. Better yet:
we can just make CssGadget::border_box_contains_point() compare for us.
Delegating to Entry::get_icon_area(), which manually reimplements
CssGadget::get_border_box(), would also work, but this is simpler.
https://bugzilla.gnome.org/show_bug.cgi?id=780938
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
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().
https://bugzilla.gnome.org/show_bug.cgi?id=785255
There's GDK grab situations (eg. pointer motion outside the grab window
in combination with a GTK+ grab) where a gesture may receive events from
windows that are not the widget's.
The _update_widget_coordinates() still does work for those situations, so
just let these events go through instead of ignoring them.
https://bugzilla.gnome.org/show_bug.cgi?id=782870
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
Setting the cursor on the widget window (i.e. the parent widget's) is
finicky because the cursor needs to be updated on crossing events, and
will yield the wrong result for other master devices that happen to be
in other areas of the same parent widget's window.
Just set it always on the event window created by the GtkButton parent
class. That window was causing the crossing events, so the rectangle
that gets the hand cursor set will be the same size, and we don't need
to track pointer crossing state that way.
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
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
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
Pixdata is deprecated but some software already use GtkImage widgets
with image data loaded from GResource-backed pixdata. As the
security-problem ridden pixdata loader was removed, we need to manually
check whether the GResource data is pixdata, and load it manually.
https://bugzilla.gnome.org/show_bug.cgi?id=781583
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
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
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
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 712a8adbd9. 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
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 GTK_TEXT_WINDOW_PRIVATE enumeration value is really *not* private.
Internally, it's used as a simple "invalid value" marker, and
application and library developers are supposed to use it as such in
their own code.
Let's just document it, and since the GtkTextView documentation and
internals go a long way to state the fact that it should not be used as
an argument value, let's add some pre-condition checks as well.
This commit fixes GtkSourceView's use of GTK_TEXT_WINDOW_PRIVATE as
default value for a GObject property that was broken by the change in
glib-mkenums to honor the `/*< public >*/` and `/*< private >*/`
trigraphs.
Add a test for exporting a handle. There are no GTK+ API for this, but
only per backend GDK API, and so far only Wayland is supported. There
is a private GdkWindow API but it's not exposed externally.
https://bugzilla.gnome.org/show_bug.cgi?id=782325
Allow getting the same export handle multiple times by calling
gdk_wayland_window_export_handle() multiple times. For each time
export() is called, a unexport() must be called to unexport.
When the window is already exported, the exported callback is called
via a idle handler. If there are multiple export() calls, they are
invoked in order either when the handle is received by the display
server, or when the idle callback is invoked.
Calling unexport() will not affect future invokations of the exported
callback, unless all export() calls have their unexport() call count
matched.
https://bugzilla.gnome.org/show_bug.cgi?id=782325
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.
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.
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.
We can't make the placeholder a non-internal child as that breaks
applications that previously relied on foreach() to only return
GtkListBoxRow instances. Instead, unparent the placeholder manually in
dispose.
https://bugzilla.gnome.org/show_bug.cgi?id=782494
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.
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
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.
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
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
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
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
This is a backport from 16bce17168. Thing is Nautilus pulled the
code from master until now, so right now gtk-3-22 and Nautilus 3.24
differ.
Would be great to have them share the same code, and at the same time
have this small string helper issue fixed.
https://bugzilla.gnome.org/show_bug.cgi?id=781622
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
GdkWindow's before_process_all_updates() and after_process_all_updates()
wrongly assume that all displays are from the same class, which is not
the case if for example a client open different displays with different
backends such as X11 and Wayland.
Use the actual class for each display in the display list to avoid a
crash when mixing displays from different classes.
Fix suggested by Christian Persch <chpe@gnome.org> in bug #776472.
https://bugzilla.gnome.org/show_bug.cgi?id=776472
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.
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
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.
The CSS was targeting node GtkFrame, which is wrong: it is called frame.
This commit also assumes the interesting padding is that between the
border and the child widget, not the padding around the entire Frame.
Some additional hoops must be jumped through to preserve padding values
not being changed in either callback. However, the way this is done
means I must set the initial paddings to 0, which simplifies main().
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.
Changing code to agree with docs, which said frame.flat, was backwards.
Mea culpa. Theme authors ran with the actual behaviour, not the docs. As
stability is more important, let’s go back to frame > border.flat, and
fix the docs to reflect what the code does and how to set .flat in code.
N.B. This retains the change in HighContrast of "frame border" to "frame
> border". Not using the direct child selector contradicted Adwaita &
could conceivably have unwanted results on nested nodes named border.
https://bugzilla.gnome.org/show_bug.cgi?id=778905
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
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_effective_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
This reverts commit 367e021652.
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.
Commit 0c20604932 changed the theme to expect the .flat class on
the frame node rather than the border one, but didn't update the
code that applies the style according to the :shadow-type property.
https://bugzilla.gnome.org/show_bug.cgi?id=779005
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
The docs say that this class should be put on the frame node, and that’s
all we can do from C code, but the CSS was selecting on the border node.
The result was that adding .flat did not disable the border as expected.
https://bugzilla.gnome.org/show_bug.cgi?id=778905
Some drivers don't do that (not sure whether that is the correct behaviour
or not). Remember each WT_PROXIMITY with LOWORD(lParam) != 0 that we get,
then look for a WT_CSRCHANGE. If WT_CSRCHANGE doesn't come, but a WT_PACKET
does, assume that this device is the one that sent WT_PROXIMITY.
Also include fallback code to ensure that WT_PACKETs for an enabled device
disable the system pointer, because WT_PROXIMITY handler might have
enabled it by mistake, since it's not possible to know which device left
the proximity (it might have been a disabled device).
https://bugzilla.gnome.org/show_bug.cgi?id=778328
Previously HiDPI scale was retrieved and applied too late in the initialization
process to affect monitor size and monitor workarea size, but the code that
initializes these sizes *did* try to use the scale, even though it was always
getting scale=1.
To fix this, move the too-late code into monitor enumeration routine.
This also fixes a probable semantic bug where width and height were divided
by scale, again.
Now monitor and workarea should be in application pixels (i.e. divided by scale),
as intended.
https://bugzilla.gnome.org/show_bug.cgi?id=778835
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.
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.
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
Update the autotools scripts so that we can support Visual Studio 2017
by copying the 2010 projects and updating items as needed to obtain
the 2017 projects.
Note that since the toolset version string changed for Visual Studio
2017, so allow the use of a custom toolset version string, otherwise
just generate the toolset version string as we did before.
Also, note that Visual Studio 2017 aims to be compatible with 2015
on the CRT level, so there should not be any problems using 2017-compiled
binaries with 2015-compiled ones.
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
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
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
This is a workaround for a regression in updating scrollbars in
some applications; notably eog. We haven't fully tracked down yet
why a queue_allocation is not sufficient here, it should.
https://bugzilla.gnome.org/show_bug.cgi?id=765410
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
combo_box_popdown() of course doesn’t popdown 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.
Previously GDK only made up monitors when it initially found none. Now it
also makes up monitors when it initially finds some, but later fails to get
their informatin in a normal way and finally prunes them out, being left with
zero monitors.
Having zero-length monitor array is unexpected and causes a number
of critical warnings and some critical functionality (such as displaying
drop-down menus) fails in such cases.
Ideally, there might be such a way to interrogate W32 API that produces the
information about non-real (but active) monitors out of it so that it isn't
necessary for us to make stuff up. However, this code is already complicated,
and i am not prepared to dig W32 API to find a way to do this.
This fixes the issues people had when they accessed a Windows desktop via RDP.
https://bugzilla.gnome.org/show_bug.cgi?id=777527
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)
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
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.
Windows WM handles AeroSnap for normal windows on keydown. We did this
on keyup only because we do not get a keydown message, even if Windows WM
does nothing with a combination. However, in some specific cases it DOES
do something - and we have no way to detect that. Specifically, winkey+downarrow
causes maximized window to be restored by WM, and GDK fails to detect that. Then
GDK gets a keyup message, figures that winkey+downarrow was pressed and released,
and handles the combination - by minimizing the window.
To overcome this, install a low-level keyboard hook (high-level ones have
the same problem as normal message loop - they don't get messages when
Windows WM handles combinations) and use it to detect interesting key combinations
before Windows WM has a chance to block them from being processed.
Once an interesting combination is detected, post a message to the window, which
will be handled in due order.
It should be noted that this code handles key repetitions in a very crude manner.
The downside is that AeroSnap will not work if hook installation function call fails.
Also, this is a global hook, and if the hook procedure does something wrong, bad things
can happen.
https://bugzilla.gnome.org/show_bug.cgi?id=776031
Instead of using some kind of flawed logic about modifying a keypress result
when CapsLock is toggled, just add a CapsLock shift level (and all derived
shift levels, i.e. Shift+CapsLock and CapsLock+AltGr and Shift+CapsLock+AltGr)
and query Windows keyboard layout API about the result of keypresses involving
CapsLock.
Keysym table is going to be (roughly) twice as large now, but CapsLock'ed
keypresses will give correct results for some keyboard layouts (such as
Czech keyboard layout, which without this change produces lowercase letters
for CapsLock->[0,2,3,4...] instead of uppercase ones).
Keymap update time also increases accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=165385
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.
We have a frame clock that ensures rendering is done as per the
output vsync. There is no need to have Mesa do the same for us.
This, most notably, ensures Mesa doesn't schedule frame callbacks
that will be left unattended if the compositor stops throttling
frames for its surface, this is eg. the case if the toplevel is
moved to another workspace.
Also, given a SwapInterval!=0 will always bring these unexpected
side effects, check that it's possible to disable it, and spew
a debug message if that isn't the case.
https://bugzilla.gnome.org/show_bug.cgi?id=769835
drag-data-delete is emitted based on the interchange of the
DELETE atom, which may well be set or bypassed locally by
the app. As such emitting it here is not right, the other
paths handling the DELETE atom interchange are still valid
and there.
https://bugzilla.gnome.org/show_bug.cgi?id=774726
If there are no targets, DnD is probably intended to be local,
add a mimetype for matching then. The wayland protocol requires
at least one wl_data_offer.target call with the mimetype selected
for transfer.
Instead of checking for window state and giving it extra styles that
fit, just give it all styles that it is missing. It turned out that
otherwise it is impossible to, for example, restore a maximized window
via sysmenu. Also, be more flexible towards GDK/WM window state mismatches
and consider the window minimized/maximized if *either* GDK or WM thinks so.
https://bugzilla.gnome.org/show_bug.cgi?id=776485
Just set check_for_dpi_awareness = TRUE and eventually it will be handled
correctly, even if setDpiAwareFunc() returns E_ACCESSDENIED or shcore functions
are NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=777031
When 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
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
...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.
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.
When primary monitor is smaller than the actual monitor on which the
window is being maximized, the WM will do widnow size adjustments
that will completely screw the window size if we try to make it
smaller than 100% fullscreen (to account for taskbar size, for example).
Fix this by overriding maximized window size during WM_WINDOWPOSCHANGING.
https://bugzilla.gnome.org/show_bug.cgi?id=775808
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
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
We check when we realize the GdkGLContext, but we never use the check
before using the API, and it breaks on drivers that do not implement the
extension, or on drivers that only support OpenGL ES 2.0.
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.
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
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
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
The recent Wintab testing revealed an interesting edge case: we cannot
for certain say that windowing system messages will not be received
while the default display and its device manager are still being set up.
We've ruled out the Wintab case now, but cannot rule out some future bit
of runtime DLL code doing stuff at this critical time.
This commit detects and avoids a potential null pointer dereference in
the message handling code while detecting grabs. Grabs don't really
exist yet, if the default display and/or its device manager are not yet
globally known.
https://bugzilla.gnome.org/show_bug.cgi?id=774379
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.
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 into
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
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
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
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
After building GDK with broadway, we need to copy the GDK DLL from
[Release|Debug]_Broadway\bin to [Release|Debug]\bin, so that the
introspection builds can be done normally with CFG=[Release|Debug]. As we
renamed the projects, we needed to update the property sheets that does
the copying, which was accidently missed. Fix that.
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
We want to look for the gdk-pixbuf-2.0 package, and we should leave a space
between -ldwmapi and -lzlib1 when we enable Broadway.
Also copy the generated gdk-3.0.pc and gtk+-3.0.pc as gdk-win32-3.0.pc and
gtk+-win32-3.0.pc respectively, to be in-line with the autotools builds.
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
The monitors are already in scaled pixels, so scaling again when retrieving
the screen size is wrong.
With GDK_SCALE unset, the initial monitor sizes are unscaled, and when the
xsettings client sets a scale > 1, the monitor sizes should be updated.
The end result is that the monitor sizes start out wrong, and get
corrected on the first xrandr event, while the screen size starts out
right and becomes wrong after the event.
This patch fixes Firefox misplacing menus and popovers when the xrandr
configuration changes while it is running.
Fix for the X11 side of
https://bugzilla.gnome.org/show_bug.cgi?id=772202
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
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.
-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
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
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
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 are 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
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
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.
(cherry picked from commit 31c05771e9)
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
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.
(cherry picked from commit 8e85f55240)
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
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
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.
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.
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
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
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
These functions don't work well on backends without global
coordinates (such as Wayland or Mir), and the gtk_menu_popup_at_
variants are better alternatives.
https://bugzilla.gnome.org/show_bug.cgi?id=772552
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).
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
<GenerateGtkDbusBuiltSources>cd ..\..\..\gtk & $(PythonDir)\python $(GDbusCodeGenCmd) & cd $(SolutionDir)</GenerateGtkDbusBuiltSources>
<GenerateGtkDbusBuiltSourcesX64>cd ..\..\..\gtk & $(PythonDirX64)\python $(GDbusCodeGenCmd) & cd $(SolutionDir)</GenerateGtkDbusBuiltSourcesX64>
for %%s in (16 22 24 32 48 256) do ((mkdir $(CopyDir)\share\icons\hicolor\%%sx%%s\apps) & (copy /b ..\..\..\demos\gtk-demo\data\%%sx%%s\gtk3-demo.png $(CopyDir)\share\icons\hicolor\%%sx%%s\apps))
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.
