Adapt the Visual Studio project files to output the introspection files
in the same directories where the built binaries are located from the
previous patch.
Also, make the gtk3-introspect project dependent on the gdk-3 and gtk-3
projects only, so that we can build the introspection files without
needing to finish the whole build process. In order to "install" the
built introspection files, the gtk3-install project is now where this is
being done. Note that the introspection builds is still not built by
default at this point.
To avoid confusion, have the NMake Makefiles output the built introspection
files in the same location where the binaries are built for the project
files, according to the Visual Studio version, platform and configuration
where the build is carried out.
Also make generating the introspection NMake snippet portion more robust to
source additions and removals by checking on Makefile changes too.
When a popup is placed using move_to_rect(), it'll get feedback about
the position and size it got assigned. We use this feedback to update
the scroll offset, but while doing so, if the visibility of the arrow
changed, we didn't adapt the offset accordingly.
Fix this by offsetting the provided offset by the height of the arrow,
if it was made visible as a side effect of the scroll offset change
triggered by the feedback.
Related: mutter#105
Closes: #1463
A menu will be clamped to the work area as a side effect of the
move_to_rect() logic if the resize anchor flags was set. For it to work
a second time, the initial size needs to be the actual menu size before
being clamped again. Achieve this by forcing a size recalculation before
showing the menu.
Don't constrain the initial menu size by the work area of some monitor;
instead let the move_to_rect() logic in the backend do the constraining.
This fixes two things:
1) The anchor delta provided to the backend will not be invalid. The
delta is calculated by looking at the active menu item, calculating the
offset given that, but since we clamped the window size before showing
the window, the delta became invalid. This caused visible issues when
the delta was large enough to make the initially calculated popup window
geometry to be placed outside the geometry of the parent window, which
is a violation of the Wayland protocol.
2) The scroll offset to be correct when receiving the positioning
feedback. While the scroll offset was based on the pre-clamped window
size, the feedback, which was used to calculate the new offset, was not,
causing the scroll offset to be clamped as well.
If the size was constrained by the xdg_positioner mechanisms, we handle
the resize by resizing the popup window. What we shouldn't do is
hide/show the popup window so avoid that.
We need to tell the portal what filter is supposed to be selected by
default, or it will just pick the first one, which could be wrong and
annoying.
This will require updated xdg-desktop-portal and xdg-desktop-portal-gtk
to work properly.
Fixes#1492
While the IEC power symbols have been part of Unicode since version 9.0,
released in 2016, not every font supports them.
We can use the old symbols as a fallback, as they seem to have the
better coverage, if not the best appearance.
gtk_file_chooser_set_filter() doesn't work for GtkFileChooserNative. The
code forwards added and removed filters to the delegate dialog, but
doesn't do anything to set the selected one, so the wrong one gets
chosen. So fix that.
This only fixes the fallback dialog. The portal will be fixed in a
subsequent commit.
Partial fix for #1492
Instead of from the IMContextQuartz's client window because the former
is the event window where the text will be inserted. In some cases
they're different and the text may be discarded (because the client
window isn't editable) or misplaced.
Fixes Bug 707945.
The cache key is just the name of the cursor, so if a previously added
cursor had e.g. scale == 1, if we ask for a new cursor with scale == 2,
we might still fetch the scale == 1 cursor from the cache. Avoid this by
making sure the scale of the cached one is correct.
If it isn't, load the cursor as normal, and update the cache entry with
the new properly scaled cursor.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1183
When creating the motion controller, we know the widget that is of interest
based on gtk_event_controller_motion_new(). However, not all incoming
events are guaranteed to be of the GdkWindow associated to that widget.
They may also be for a descendant. Therefore, it is useful to translate
those coordinates into the target widget coordinate space as that is
likely what they care about.
We shouldn't give the icons here the same fg colour as the bg... which
makes them disappear and the buttons look like meaningless flat squares.
Fix by just using the same colour the same as foreground disabled. Note:
insensitive_fg_color is more prominent than !disabled, so clearly wrong.
The +/- buttons are meant to be transparent, showing the base_color,
but when backdropped they were picking up background-image from the base
button, meaning they suddenly became more like theme_bg_color instead,
and jumped out of the spinbutton when in backdrop unlike the rest of it.
This looks strange and achieves nothing (especially not indicating that
they are disabled, which is already served fine by their dim fg colour).
Fix this by explicitly saying we don't want any background-image there.
CGDisplayModeGetWidth returns 0 if mode is NULL; that happens if the
CGDisplay is offline or mirroring another monitor and it leads to a
divide-by-zero crash.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1565
iter_init_common() is used on uninitialized GtkTextIter, and since neither it
nor its callers initiliaze its padding fields, they contain garbage.
This is a problem for Go - which checks that structs passed to C functions do
not contain pointers to Go-allocated memory - when the garbage happens to be
such a pointer. Although Go zero-fills all GtkTextIter that it allocates, this
does not help when GTK functions such as insert_pixbuf_or_widget_segment called
for gtk_text_buffer_create_child_anchor copy garbage from their stack-allocated
GtkTextIter into a clean iter. To work around this a GtkTextIter has to be
discraded after use in text buffer anchor inserting functions:
https://github.com/gotk3/gotk3/pull/307
So it's able to operate properly with the DnD gesture set by
gtk_drag_source_set(). We usually just react on button release,
that's the right time to claim the gesture.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1557
Signal emittion was added in 6f857f87dc commit and it seems that
this is only place where selected_row is set after emitting signal.
Because of this gtk_list_box_get_selected_row currently returns NULL
as selected row if selection mode is set to GTK_SELECTION_BROWSE.
...since one of the "fixes" there was wrong, at least cosmetically:
.get_position() is declared as returning a gboolean, which is in fact an
int in practice, but we should say what we mean, like we already did.
Make sure that the return types of the vfuncs match the ones that are
specified for post-atk-2.11.x AtkTableCellIface, since we already
require atk-2.15.1 and later.
icontheme: Recolor <polygon> elements in SVGs too
See merge request GNOME/gtk!443
(cherry picked from commit 5b049364dc)
284d9093 icontheme: Recolor <polygon> elements in SVGs too
If the revealer is told do animate and then unrealize itself, we do
(correctly) stop the animation, but used to do a shortcut where we
just set the target state as current.
Other things are dependent on the animation properly finishing though,
like the contained widget child visibility. This may lead to inconsistent
state where gtk_revealer_get_child_revealed() returns TRUE but the child
widget is unmapped, or vice-versa.
Fully finish the animation here, so the child state is coherent the next
time the revealer is mapped. We can also skip notifying on the property
since it will be handled by gtk_revealer_set_position().
Closes: https://gitlab.gnome.org/GNOME/gnome-control-center/issues/316
If the child is not (partly) revealed, don’t allocate it, or we spam the
console with warnings about giving negative width to children’s gadgets.
We can check :child-visible, which is FALSE if (current&target)_pos == 0
Close https://gitlab.gnome.org/GNOME/gtk/issues/1057
Tools on the same physical item have the same serial number, so the eraser
and the pen part of a single pen share that serial number. With the current
lookup code, we'll always return whichever tool comes first into proximity.
Change the code to use the hw id in addition to the serial number, this way we
can differ between two tools.
Generic tools (Bamboo, built-in tablets) always have the same serial number
assigned by the wacom driver. This includes the touch tool when the wacom
driver handles the touch evdev node (common where users require the wacom
gestures to work).
When the first device is the touch device, a tool is created with that serial.
All future tools now return the touch tool on lookup since they all share the
same serial number. Worse, this happens *across* devices, so the pen
event node gets assigned the touch tool because they all have the same serial.
Since we don't actually care about the touch as a tool, let's skip any unknown
tool. This captures pads as well.
Any wacom device currently sets the tool type to UNKNOWN. The wacom driver has
a property that exports the tool type as one of stylus, eraser, cursor, pad or
touch. Only three of those are useful here but that's better than having all
of them as unknown.
* We don't output spaces anywhere in the code, unlike the doc suggested.
* CSS explicitly forbids whitespace between function names and lparens:
https://stackoverflow.com/questions/13877198
Calling the accessibility function `grab_focus()` on a `GtkCell` under
Wayland will cause the client to crash.
This is another case of `gdk_x11_get_server_time()` being called
regardless of the actual windowing backend used.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1507
We need to call g_strdup() on the name that we pass in for notifying the
GDK_SETTING event so that when we do gdk_event_free() later we will not
get a crash (stack corruption) that results from attempting to g_free()
something that is not dynamically allocated.
and convertPointFromScreen:, making them handle all MacOS versions
so that all of the if-deffing happens in the function definitions.
This happens to fix issue 1518 because it turns out that contrary
to the annotation in the 10.14 nNSWindow.h, convertPointToScreen and
convertPointFromScreen originate in 10.14, not 10.12.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1518
G_GNUC_END_IGNORE_DEPRECATIONS terminates the if statement and does not
consider the following block to be part of the if. So that block was
always taken irregardless of the pattern.
Fixes#1280
We don't want to set ParentRelative when:
- the parent window is NULL
In that case we are unsure about the depth, so better err on the side
of caution and avoid a BadMatch by accepting ugly output.
- the cairo pattern is in an error status
This should never happen - unless you start up in OOM - but better
be safe than sorry.
Might help with the spurious crashes in #1280.
This reverts commit 5aedfe048b.
It had a typo that broke the build, only replaced half of the uses, and
replaced them with other functions that are also deprecated anyway.
Surface returned from gtk_icon_helper_load_surface can be smaller
then requested pixel size. This happens when icon is embedded in
panel that has bigger size then loaded pixbuf.
Fixes#1280, tray icons not drawing background. This is a magic pattern only
usable for gdk_window_set_background_pattern() that sets the underlying
X window's background to ParentRelative.
`gtk_widget_accessible_grab_focus()` code checks that X11 isenabled at
build time and uses X11 specific functions such as
`gdk_x11_get_server_time()` regardless of the actual backend being used.
Check that we are using an X11 display when X11 is backend enabled, so
we do not crash when running on Wayland
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1507
- based on a patch by frederik.feichtmeier <frederik.feichtmeier@gmail.com>
I'm certain this is something we had initially, but can't recall
why we got rid of it for the more visually distracting dashed line.
We can always revert when Lapo shows up and slams us with that broken
use case. I'm guessing non-white bgs.
- So far it looks way less distracting than the dashed line
Handling more flags, handling them correctly, and emitting the requisite
signals.
Change screen layout to use CGGetActiveDisplayList instead of NSScreens,
eliminating the latency between updating screens and recomputing the
root window.
Moving the initialization of the GdkQuartzMonitors to GdkQuartzDisplay from
the now-obsolete GdkQuartzScreen. Use QuartzDisplayServices for
monitor enumeration and to populate the GdkMonitor properties. This is
better aligned with acting on the Quartz Services callbacks for monitor
changes and with Cairo which also uses CoreGraphics for drawing.
gtk_internal_return_val_if_fail operates only in debug mode,
quartz can call this with a NULL that crashes in
GTK_STYLE_PROVIDER_PRIVATE_GET_INTERFACE.
This makes apps use "Segoe UI 9" by default instead of whatever matches "Sans 10".
It also cleans up the code and uses some new pango API while at it.
This was previously disabled in 9e686d1fb5 because it led to a poor glyph coverage
on certain versions of Windows which don't default to "Segoe UI 9" (Chinese, Korean, ..)
because the font fallback list was missing in pango.
This is about to get fixed in https://gitlab.gnome.org/GNOME/pango/merge_requests/34
so enable it again when we detect a new enough pango version.
- introduce $menu_radius
- use it for menus and context-menus
- use the popover box-shadow also for menus
- use padding for menus to avoid edge overlapping
- remove the background for menus to avoid bleeding out of the round edges
Issue #1495 showed that the docs of GtkGrid retain outdated implications
that (as was once, but is no longer, the case) it is intended to replace
GtkBox, by discussing HfW and widget properties in a way that suggests
GtkBox can't handle them. But of course it does, and it's preferable for
simple single-row/column cases. Worse, we said GtkGrid “provides exactly
the same functionality” for the latter case, but the original point of
that Issues was that it doesn’t, at least for CSS positional selectors!
Box:
• Use an actually meaningful @Short_description.
• Remove unhelpful @See_also references to unrelated containers.
• Remove references to “rectangular area”: it might be another shape
via CSS, or “rectangular” might falsely imply 2 dimensions of children.
• Mention Orientable:orientation.
• Emphasise usefulness of :[hv]align for allocating in the other axis.
• Don’t say that Grid “provides exactly the same functionality” for a
single row or column, since (A) it is overkill for that case and (B)
said Issue proved that it *doesn’t* for CSS child order, for example.
• Note in the child properties that are remove in master that we have
better, preferred alternatives available now in GtkWidget/CSS props.
There’s no nice way to deprecate these, though they’re gone in GTK+ 4.
• Correct a copy-paste-o from the blurb of :expand to :fill.
Grid:
• Remove references to deprecated widgets: GtkTable and Gtk[HV]Box.
• Don’t dwell on widget properties and height-for-width in a way that
wrongly implies that Box can’t handle those (or Grid can better). In
fact, just get rid of that bit altogether: Box handles them fine, and
Table is so old as to be not worth mentioning (in anything except the
2 => 3 migration guide) and points to Grid in its deprecation notice.
• Point to GtkBox as being preferred for the simple row/column use case.
Enables hinting, antialiasing and set the subpixel orientation according to the
active clear type setting. This ensures that font rendering with the fontconfig backend
looks similar to the win32 backend, at least with the default system font.
Append a variation selector to the Emoji sequences,
to force Emoji presentation. Without this, some
Emoji come out with text presentation by default.
Closes: Pango #334
- step back on toning down the borders. Flatness !> legibility.
- darker active state for light
- draw gradinets from bottom up, to keep px sized shading regardless
of button size.
We wrap SVG data from icons within another SVG with extra styling
information. The wrapped SVG may contain characters that cannot be
part of a data: URL (https://fetch.spec.whatwg.org/#data-urls).
Librsvg 2.45 got more strict in its parsing of data: URLs; whereas
previously it ignored '#' characters in them, now it considers them to
be the start of a fragment identifier, which is not allowed in data:
URLs anyway.
To avoid unallowed characters, we now create a data: URL with a
base-64 encoded SVG.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1471
We display a list of supported protocols in the server_addresses_popover.
However, this curated list contains protocols which may or may not be
available, depending on the respective gvfs backend being installed.
So, populate the list only with protocols which are available.
https://gitlab.gnome.org/GNOME/gtk/issues/1476
When the user types an address with a schema that is not supported,
the Connect button doesn't become sensitive, but there is no visible
feedback at all.
This feels unresponsive and leaves the user clueless.
While it doesn't help explain why the address doesn't work, this will
provide a hint that the input was acknowledged but doesn't work.
https://gitlab.gnome.org/GNOME/gtk/issues/1476
GTK widgets expect the scroll deltas to be 1 or -1 and calculate a scroll value from that.
Multiplying the delta by the Windows scroll line setting (which defaults to 3) results
in a much larger delta and vastly different behaviour for running a GTK app on Windows
vs on Linux. For example text view and tree view scroll by 9 lines per scroll wheel tick
per default this way while on Linux it is around 3.
Remove the multiplication for now.
It is permissable to remove a widget using gtk_container_remove from the
gtk_container_foreach callback handler. Document this fact to make it
more discoverable.
Fixes#1461
Gives the same background color to all separators descending from a
title bar than to its direct childrens.
This prevents separators which are in a titlebar but not direct children
from the widget with the titlebar style class from being almost
transparent and hence it prevent them from revealing the clear color of
the window's titlebar (black).
https://gitlab.gnome.org/GNOME/gtk/issues/1231
This is better than nothing at all. The wording is taken from Carlos's
commit message when he added this shortly before 3.12, so add Since too.
Skip the bit from his commit message explaining what this replaced; we
don't need to say all the less good things our convenience API replaces.
Under Wayland, we are currently directly using GSettings
for desktop settings. But in a sandbox, we may not have
access to dconf, so this may fail. Use the new settings
portal instead.
- Selection mode does not get the special devel styling.
- removed teh last-child() selector for it doesn't work anymore.
Better style all section of the headerbar than none. Proper fix pending.
By returning a default surface. The situation where there's no
currentContext arises when GtkCSS is trying to determine the
layout sizes so no actual display is necessary.
Closes: #1411
Commit 1c96b703 changed the way icon
information is given to DnD. Previously an icon helper was kept at
the drag source site. Now an image definition is stored there.
The difference is that icon helper is an object that changes its
state in response to an icon being set, thus the object survived
multiple icon changes. Whereas image definition is destroyed and
re-created from scratch every time a drag icon is changed.
This created a problem where gtk_drag_begin_internal() would receive
the value of site->image_def when a drag just began, then it emits
"drag-begin" signal, in response to which an application can
set drag icon, changing the value of site->image_def. However,
gtk_drag_begin_internal() is unable to know about that change and
continues to use the old value it received from up the stack.
Not only does it prevent drag icon from being set from "drag-begin",
it also can induce a crash, since the old image_def value used
by gtk_drag_begin_internal() points to a freed memory region.
Fix this by only setting a default icon (which is created in-place)
in gtk_drag_begin_internal() if the caller does not care about icons.
Otherwise gtk_drag_begin_internal() will return a boolean that indicates
whether an icon needs to be set. Then the caller can invoke
gtk_drag_set_icon_definition() to set the icon, if needed.
Fixes#1407.
Before this patch, imwayland would assume that text-input enter and leave events follow the general (wl_keyboard) focus, and was unable to handle the situation where they would not be provided at the same time.
gtk_drag_clear_source_info() immediately unrefs the info attached
to the context (the very same info we're in the process of destroying
in gtk_drag_source_info_free()). If that reference was the last one,
then accessing the info object after that is a use-after-free error.
Also, change the order a bit to first free the event, and only then
unref the context.
Fix this by copying all the fields of the info that we need, and
then working with these copies.
According to the XEmbed specification, a window should be created
"elsewhere" and then reparented into the target parent window. Instead,
GTK+ creates the window directly in desired target parent window. This
allows some races to occur.
Another program that does not follow XEmbed is tabbed. XEmbed requires
an _XEMBED_INFO property on the to-be-embedded window, but tabbed does
not check for this property. Thus, as soon as GTK+ creates its window,
tabbed starts managing this window and now GTK+ setting up the window
races with tabbed starting to manage the window.
If tabbed is fast enough to map the window, GTK+ never sees a MapNotify
event, because it did not yet select StructureNotifyMask on its window.
This results in a black window inside of tabbed.
Note that this cannot really be fixed in tabbed, since XEmbed says that
the _XEMBED_INFO property must be already present when the window
appears. Thus, patching tabbed to wait for _XEMBED_INFO to appear is not
something that the spec requires/allows.
Instead, this commit changes GTK+ so that it directly sets the right
event mask when the window is created. This means that there is no more
race between tabbed mapping the window and GTK+ selecting
StructureNotifyMask.
Note that the proper fix would be to do as XEmbed requires: Create the
window elsewhere and then reparent it into the target window. However,
that would require a more invasive patch, so this commit only takes the
"easy approach" of fixing this one race. Hopefully, all the other races
that can occur during window setup are harmless, because the
embedder/socket will hopefully watch for PropertyNotify events as
needed.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/757
See-also: https://github.com/awesomeWM/awesome/issues/2385
Signed-off-by: Uli Schlachter <psychon@znc.in>
This was noticed in Firefox and demonstrated using a GtkBuilder ui file.
buildable_add_child() calls set_tab_label(), but the latter did nothing
to update the menu_label corresponding to that tab with the new text.
Using Builder to populate the tab child, only tabs other than last got
the right non-default labels, and even that was mostly coincidental, as
adding the main child called update_labels() via real_insert_page(), so
it took effect when the 2nd last main child is added, updating the rest
but leaving the last with the default label, not that given in Builder.
Fix by factoring out the code from child_reordered() to a new helper
menu_item_recreate() and calling that in set_tab_label(), so that
whenever the tab_label is updated, so is its corresponding menu_label.
This fixes the reported case and presumably others that we could write.
fixes https://gitlab.gnome.org/GNOME/gtk/issues/1397
Comments matched to reassure the compiler that fallthrough is
intentional are supposed to precede the case or default keywords, at
least in GCC, so the one here did not suppress the warning with GCC. We
can just the if condition and put the comment at the end to solve that.
https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/
Instead we just cache the monitor number and get
out of it the nsscreen when it is needed. This is
a requirement since it nsscreen it is not supposed
to be cached.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1312
Commit c255ba68 inadvertently introduced a regression that broke Korean
text input because the changes there resulted that only the last input
string that we have from ImmGetCompositionStringW() for each time the
commit signal is emitted is kept, and also as a result the final Korean
character that is input by hitting space is also lost as a result, as we
didn't check for whether we are done with preediting.
Fix these issues by doing the following when we receive the
WM_IME_COMPOSITION message with GCS_RESULTSTR from Windows:
-Do not emit the commit signal during WM_IME_ENDCOMPOSITION, and...
-Emit the commit signal anyways, as we did before, c255ba68, however...
-We still save up the string to commit, because we need to re-compute
the cursor position when we do ->get_preedit_string(), which needs to
take the GCS_RESULTSTR string we get from WM_IME_COMPOSITION into
account as well, so that we avoid getting the Pango criticals that
occur during Chinese (and most likely Japanese) input as the cursor
position is out-of-range.
Fixes issue #1350.
The gtk_stack_snapshot_slide() function dereferences the
last_visible_child pointer without proper != NULL ckeck. This might
result in NULL pointer dereference and crash if last_visible_child is
invalid.
Add a != NULL check before dereferencing the pointer.
cherry-picked from https://gitlab.gnome.org/GNOME/gtk/merge_requests/361
Before the recent rework of positioning in GtkTooltip, the widget always
used the cursor_size of the GdkDisplay. That work redid this to instead
take GtkSettings::gtk-cursor-theme-size. But that property's doc says:
> Size to use for cursors, or 0 to use the default size.
and has 0 as its default. This is quite a likely scenario for anyone
whose desktop or settings.ini does not explicitly provide a cursor size,
which is the case for XFCE and win32, to name just two common platforms.
Then, it seems getting a cursor_size of 0 causes GtkTooltip to freak out
and hide/show itself at a very rapid speed, thus making it unusable.
So, we should check whether the Settings return 0 and, if so, still use
gdk_display_get_default_cursor_size (display) to ensure we get a size.
https://gitlab.gnome.org/GNOME/gtk/issues/1371
Do not lie to W32 about the formats that we provide or accept.
Originally the logic behind such lies was that GdkPixbuf allows
us to convert any supported image to BMP or PNG, and therefore
we should announce that we always provide/accept BMP and PNG along
with other formats.
But that's not how it works. The conversion between formats happens
at GTK level in GtkClipboard or, if GtkClipboard is not used, with
gtk_target_list_add_image_targets() to announce all supported image
formats, and with gtk_selection_data_set_pixbuf() to convert from
any GdkPixbuf formats to the format requested by the selection, and
with gtk_selection_data_get_pixbuf() to convert from the selection
format to GdkPixbuf, if supported.
GDK simply does not play any role in this. Therefore W32 GDK backend
should only offer formats that it can actually do conversion for
by itself (such as image/bmp <-> CF_DIB,
or text/uri-list <-> CFSTR_SHELLIDLIST).
This leverages the normal input module switching mechanism in GTK
by making it think that the gtk-im-module setting changed.
The backend returns gtk-im-module value as "ime" if W32
IME API says that an IME is in use. Otherwise it returns
and empty string - this still triggers an input module
loading code, which, not being able to load the desired module
(which is and empty string), falls back to looking at current
keyboard layout.
Paired with the code that signals gtk-im-module change on keyboard layout
switches, this is sufficient to make GTK capable of loading appropriate
input modules at runtime. At least, the kinds of modules that specify
languages for which they are loaded automatically by default, and the
IME module.
Loading other kinds of input modules might still work via specifying
the gtk-im-module setting in gtk ini file, but doing so will likely
make GTK incapable of loading the IME input module that is used
for Korean, Chinese and Japanese (and some other languages).
Until someone figures out a way to actually change gtk-im-module
setting on Windows at runtime with meaningful values, the behaviour
introduced by this commit seems like a sufficient workaround.
GNOME Shell 3.32 will remove support for the app menu
so we need to move its contents to the primary (hamburger)
menu.
widget-factory already had a primary menu.
The only item in the app menu was About.
https://gitlab.gnome.org/GNOME/Initiatives/issues/4
gtk_entry_event's goal is to detect if a specific event concerns one of the two
entry icons. It can happen that this function is called during initialization
and/or before the entry is realized. In this case the entry icons (and the
event) will not yet have an associated window. The code should consider the
aforementioned situation and avoid matching a icon and an event with no
associated windows.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1366
Suggested by Garnacho. Hopefully fixes#1349.
Note: I'm riskily committing this via web UI not because I'm lazy
(though I am :) but because I'm seeing a weird host key when I try to
push or pull from GitLab.
All the other conditionally visible child widgets have this. Without it,
it seems some cases can wrongly reveal it, with a nonsensical home icon.
https://gitlab.gnome.org/GNOME/gtk/issues/1345
There’s a short-path done for focus rectangles, but it can be taken in other conditions, and then fail occasionally to render a dashed line if the border-width is too big.
Commit 359df028be changed the
code to send GDK_SCROLL_SMOOTH with deltas instead of
GDK_SCROLL_(UP|DOWN|LEFT|RIGHT).
Windows defines deltas inversed for vertical direction
(positive values mean the wheel was turned forward)
but not for horizontal direction
(positive values mean the wheel was turned towards the right).
This commit fixes behavior as both axes were inverted previously.
Commit 359df028be changed the
code to send GDK_SCROLL_SMOOTH with deltas instead of
GDK_SCROLL_(UP|DOWN|LEFT|RIGHT). Change it again, to send
both the GDK_SCROLL_SMOOTH and the GDK_SCROLL_(UP|DOWN|LEFT|RIGHT)
event separately (with the discrete event marked as emulated),
as this is what other backends (such as wayland) do.
Fixes terminal emulator misbehaviour as outlined in https://gitlab.gnome.org/GNOME/gtk/issues/1316, which was introduced in 49b17e6c. The original commit cleared preedit text by setting it to an empty string, which still counted as existing preedit. The fix sets preedit string to null, which is correctly understood as not present.
For building the introspection dumper program on Visual Studio, leave out
the G_LOG_DOMAIN as g-ir-scanner does not like it when it constructs the
compiler command line for Visual Studio.
Also ensure that we are looking for the freshly-built libraries by looking
for the .lib's from the output directories of the Visual Studio project files.
Simplify the styling of sidebar separators by not setting their borders
and margins rather than trying to drop it afterward, which was actually
not working anyway.
Make the selector less greedy to not remove the background on
non-titlebar headerbars contained in non-headerbar titlebars and only to
the ones contained in headerbar titlebars. This avoid issues in some
applications.
Also make dropping the background more agressive to actually remove it.
There may be situations where this might get called while the
currently focused context just went away (eg. after setting the
text widget unsensitive).
Closes: #1317
This is needed to work around headerbar sliding animation issues without
refactoring Adwaita's support of titlebars and headerbars as it may
break applications.
https://gitlab.gnome.org/GNOME/gtk/issues/1264
Let separators be declared as sidebars to have the same style as those
drawn by GtkStackSidebar. This also let them handle the selection-mode
class, whether they are assigned it or they descend from something in
selection mode.
This is convenient when building a custom sidebar using a GtkSeparator
and to extend a sidebar to the title bar.
A number of applications want to track the state of the screensaver.
Make this information available as a boolean property. We only listen
for state changes when ::register-session is set to TRUE.
This is implemented for unsandboxed D-Bus access by talking
directly to org.gnome.ScreenSaver or org.freedesktop.ScreenSaver,
and for sandboxed D-Bus by using a (new) portal API.
A Quartz implementation is missing.
After discussions on IRC, the conclusion was reached that deprecations
only make sense if an action can be taken to not use the deprecated code
that makes the code more current and simplifies a later port to a newer
GTK version.
In this particular case, the suitable action would be adding
gtk_widget_show() calls whenever a widget is created, so that a call to
show_all() is not necessary.
However, in GTK4 these calls would not be necessary and end up just
bloating the codebase unnecessarily.
So it was decided the better solution would be to not deprecate the API
and instead leave this work to be done during potential GTK4 ports of
applications.
This reverts commit 4d71d2303d.
Fixes!1282
When calling PickColor on org.gnome.Shell, we get back an "a{sv}", which
GDBus provides to us as "(a{sv})".
At the minute we're not unpacking this tuple, and so picking fails with
messages like:
GLib-CRITICAL **: 13:38:19.439: g_variant_lookup_value: assertion 'g_variant_is_of_type (dictionary, G_VARIANT_TYPE ("a{s*}")) || g_variant_is_of_type (dictionary, G_VARIANT_TYPE ("a{o*}"))' failed
Gtk-WARNING **: 13:38:19.439: Picking color failed: No color received
Let's unpack it.
In order to make tooltip positioning portable, make use of the
move_to_rect API. Some semantical changes are made, as identical
semantics cannot be implemented using the move-to-rect API.
Primarily the implemented semantics are:
Position the tooltip in the center pixels slightly below (defaults to 4
units below) the tooltipped widget. This is always the case for keyboard
driven tooltips; the case where it tries to avoid the pointer cursor is
not implemented.
For pointer position triggered tooltips, implement the following
additional semantics:
Use the current cursor size to determine the padding used to enlarge the
anchor rectangle. This is to try to avoid the cursor overlapping the
tooltip.
If the anchor rectangle is too tall (meaning if we'd be constrained
and flip on the Y axis, it'd flip too far away from the originally
intended position), rely only on the pointer position to position the
tooltip. The approximate pointer cursor rectangle is used as a anchor
rectangle. Ideally we should use the actual pointer cursor rectangle
(image used as well as hotspot coordinate), but we don't have API to
get that information.
If the anchor rectangle isn't to tall, just make sure the tooltip isn't
too far away from the pointer position on the X axis.
Closes: #134Closes: #432Closes: #574Closes: #579Closes: #878
Let's just use the fact that a window was mapped as a subsurface to
remap it above another transient parent instead of relying on the more
complicated 'should-map-as-subsurface' helper function.
Set delta_x or delta_y for GdkScrollEvent.
HIWORD (wParam) in WM_MOUSE(H)WHEEL is the scroll delta.
A delta value of WHEEL_DELTA (which is 120) means scrolling
one full unit of something (for example, a line).
The delta should also be multiplied by the value that the
SystemParametersInfo (SPI_GETWHEELSCROLL(LINES|CHARS), 0, &value, 0)
call gives back, unless it gives back 0xffffffff, in which case
it indicates that scrolling is page- or screen-based, not line-based
(GDK doesn't support that at the moment).
Also, all deltas should be inverted, since MS sends negative deltas
when scrolling down (rotating the wheel back, in the direction of
the user).
With deltas set the mode should be set to GDK_SCROLL_SMOOTH.
Fixes issue 1263.
If we detect HarfBuzz and PangoFT2, GtkFontChooserWidget uses them. So
we need to add CFLAGS and LIBS of them to GTK_DEP_CFLAGS/LIBS. If we
don't add them, MinGW build fails to link.
CSD titlebar are included in the focus-chain. The logic used makes sure that the
initial focus avoids the titlebar, but tabbing around will eventually get there.
This logic fails in case the window has no other focusable widgets apart from
the ones in the header-bar. If this happens keynav focus will be lost. To handle
the above scenario, we need to fallback to focus the header-bar (if any).
Fixes: https://gitlab.gnome.org/GNOME/gnome-software/issues/404
This fixes a potential leak of a PangoAttrList that is set when chaining
up to the parent get_preedit_string(). We check to see if the attr list
was created and reuse it instead of leaking the previous value.
gdk_win32_window_set_transient_for() behaves incorrectly when
called in sequence with the same arguments. This fix ensures it
always operates correctly.
In some cases this function gets called multiple times with the
same arguments, e.g. when tooltips are shown.
See issue #1214
The functions as below are deprecated
- gdk_screen_get_monitor_geometry
- gdk_screen_get_primary_monitor
Instead of them, use functions below
- gdk_monitor_get_geometry
- gdk_display_get_primary_monitor
This is a GtkGesture done to deal with stylus events from drawing tablets.
Those have a special number of characteristics that extend a regular
pointer, so it makes sense to wrap that.
This event controller is meant to replace usage from key-press/release-event
handlers all through. Optionally it can be set a GtkIMContext, so interaction
is carried by the controller.
There is a gtk_event_controller_scroll_set_flags() call that's meant
to be called after construction (eg. due to scrolledwindow relayouts
hiding/showing scrollbars). The property shouldn't be construct-only
for consistence.
This is a GtkEventController implementation to handle mouse
scrolling. It handles both smooth and discrete events and
offers a way for callers to tell their preference too, so
smooth events shall be accumulated and coalesced on request.
On capable devices, it can also emit ::scroll-begin and
::scroll-end enclosing all ::scroll events for a scroll
operation.
It also has builtin kinetic scrolling capabilities, reporting
the initial velocity for both axes after ::scroll-end if
requested.
The opaque region is only set when the background color is opaque. So
we need to do something about it when the background color changes.
However, in the case where a size allocation is going to happen, we
already do this update in size_allocate(), so in that case avoid doing
it twice.
Reverts part of Commit 25b67af3
The 'width' part of the commit is the cause of #628: requisition->width
is first set to priv->layout->width, which already includes
priv->left_border + priv->right_border. It's a bit labyrinthine, but
essentially:
* layout->width is set in update_layout_size() (gtktextlayout.c line 992)
as the maximum line width, and
* the line width is set to display->width in gtk_text_layout_real_wrap()
(gtktextlayout.c line 1183), and
* display->width is set to text_pixel_width + h_margin + h_padding in
gtk_text_layout_get_line_display() (gtktextlayout.c line 2584), and
* h_margin + h_padding is the same as priv->left_border +
priv->right_border.
Adding it again leads to an increase in the size-request, which
results in wider lines; rinse and repeat.
Expanders used to be 16px high. With the move from the gtk2 rendering
to gtk3 rendering they shrunk to 12px, making them hard to see, because
it's now the icon which is 16px high and the icon contains transparent
borders.
This makes the HighContrast theme use 24px icons instead, to restore
16px expanders. This may expander some containers a bit.
Closes#1046
(A) Put a space in "scrolled window" like the other doc comments
(B) Say "i.e." rather than "ie."
(C) Fix grammar from "makes [...] exactly reaches" to "exactly reach"
@open_flags was not documented, and so:
jhbuild/checkout/gnome/gtk+-3/gtk/gtkplacessidebar.c:4743: Warning: Gtk:
incorrect number of parameters in comment block, parameter annotations
will be ignored.
Binds this property to the button's label, allowing a model button to
have text with markup.
This will be convenient for buttons like 'Online Accounts <sup>↗</sup>'.
It has been extremely broken since the move to CSS gadgets/nodes, so
clearly no one is depending on it; nor does anyone seem to want to
resurrect it, and writing a Raleigh-inspired theme from scratch would be
faster if they did. So let's drop the dead weight from the build and lib
Now that we don't have Raleigh, the defaultvalue test has to be changed
to set Adwaita before checking the default values of style properties -
some of which Adwaita overrides in its CSS, meaning those would fail.
Not that it passed before anyway! But it does now after my other commit.
Note that I leave the last reference in gtk-zip.sh.in alone since that
hasn't been touched in 8 years and probably has plenty other problems...
Close https://gitlab.gnome.org/GNOME/gtk/issues/1187
The enum is duplicated in the spec for the manager and the decoration
object. We should be using the right ones. In practice they have the
same value, so this bug didn't cause any issues.
The wl_surface is destroyed and recreated when the window is
mapped/unmapped. As we have a new wl_surface we need to create a new
server_decoration object for that surface.
According to the spec compositors were to assume surfaces are CSD until
told otherwise. This means we need to send
org_kde_kwin_server_decoration_request_mode in both cases.
This fixes libreoffice under kwin, which would remove it's own headers
as per the manager's request but not inform kwin leaving it in the even
more broken state of having none.
Cursor surfaces didn't listen for output scale changes, meaning they
didn't adapt their scale when an output changed scale, which could
happen for example when changing the monitor scale via Settings.
We also need to invalidate the OpenGL/ES window when we resize the
window via a mouse drag operation, so that we don't get glitches in such
situations, because they are not covered in GdkWindow's
impl_class->move_resize().
Make sure that we only force the invalidation when necessary (as it is
expensive), and clean up the gdkevents-win32.c code so that we include
gdkglcontext-win32.h in the right place instead of using an extern, as
we need to invalidate the window accordingly.
We need to force redraws of the whole window when we are using EGL/ANGLE
during maximize, restore and Aerosnap ops so that we do not get glitches
in the resulting window.
This is for adding a EGL-based renderer which is done via the ANGLE
project, which translate EGL calls to Direct3D 9/11. This is done as a
possible solution to issue #105, especially for cases where the needed
full GL extensions to map OpenGL to Direc3D is unavailable or
unreliable, or when the OpenGL implementation from the graphics drivers
are problematic.
To enable this, do the following:
-Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are
available. A sufficiently-recent ANGLE is needed for things to
work correctly--note that the copy of ANGLE that is included in
qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause
license. Note also that Visual Studio 2013 or later is required to
build ANGLE from QT-5.10.1, but the 2013-built ANGLE DLLs can work
without without problems for GTK+ that is built with Visual Studio
2008 or later.
-Build libepoxy on Windows with EGL support enabled.
-Define GDK_WIN32_ENABLE_EGL when building gdk-win32.lib when building
with Visual Studio, or pass in --enable-win32-gles during configure
when building with MinGW/mingw-w64.
-Prior to running GTK+ programs, the GDK_GL envvar needs to contain
gles.
Known issues:
-Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed
extensions, notably GL_OES_vertex_array_object, but its ES 3 support is
sufficient.
-There is no autodetection or fallback mechanism to enable using
EGL/Angle automatically yet. There is no plans to do this in this
commit.
Thanks to LRN for pointing out that we should #include
"win32/gdkwin32.h" instead of #include "gdkwin32.h" for gdkgl.c. LRN
also did the autotools portion of this patch.
Further notes about the autotools --enable-win32-gles option, fom LRN:
This adds --enable-win32-gles option, which enables the
code for GLES renderer. This commit also adds tests for WGL and
EGL in epoxy. The absence of WGL is highly unlikely (it's enabled
by default), but checking for EGL when GLES is enabled is necessary,
as EGL is disabled in Windows builds of epoxy by default.
...in place of math.h, as we are using round(), which is possibly not
provided by the compiler since we don't require a C99 compiler in
GTK+-3.x and gtk/fallback-c89.c does include math.h anyways.
On Windows HarfBuzz and PangoFT2 are optional, so we need to ensure that
we only build the bits that require HarfBuzz and PangoFT2 when needed.
We may need to see later whether we can get the needed functionality in
gtkfontchooserwidget.c with the Windows APIs without the need of
HarfBuzz nor PangoFT2 (and starting programs on Windows using FontConfig
is very slow).
Reinstate code that was accidentally deleted during the port to
GtkProgressTracker in commit d57ebe2de7.
Without that code, pulsing the progressbar will stop doing anything
after 3 iterations.
If the parent get_preedit_string implementation returns a nonnull
zero-length string, then we ignore it, which is almost fine. We have to
free it, though.
Fixes#1174
This adds a preprocess step to the .ui files to strip them of blank
characters. It also removes the compressed='true' from the .ui files since
that involves creating lots of decompressor objects when creating widgets.
Doing so has runtime overhead and slows down the creation of initial
application windows.
The .ui files are left compressed for the Inspector, since that is not in
the core performance path of application startup.
border-spacing was not backported (yet?). If it won't be, then a
suitable replacement is needed. Until then, avoid the runtime error that
can result from using a nonexistent property in our theme.
https://gitlab.gnome.org/GNOME/gtk/issues/1166
Selected rows in tree views in HighContrast have a background colour the
same or nearly as the normal text colour, so we cannot let entries in
such rows have transparent backgrounds, or the text inside the entry
becomes nearly or totally impossible to see.
Dodge this by giving entry.flat inside treeview and with :focus the
$base_color, which is different from the text & so lets that be seen.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/125
The else case was wrongly resetting the accessible description on the
primary icon, which might not exist and can therefore cause a crash.
https://gitlab.gnome.org/GNOME/gtk/issues/1160
This functionality is similar to Linux's memfd. It creates anonymous shared memory without touching the filesystem, which allows it to work in Capsicum capability mode (sandbox).
Remove g_auto*() usage from these sources and use the traditional
g_free(), as g_auto*() are GCCisms (or CLangisms).
Also, don't include unistd.h unconditionally and stop including
langinfo.h and dirent.h, since they seem to be unused.
Partially cherry-picked from a4c0395343https://bugzilla.gnome.org/show_bug.cgi?id=773299
In 01455399e8 ("gdk: do not deactivate surface on keyboard grabs"), we
made gdk avoid deactivating surfaces when another application takes a
keyboard grab, by using has_focus_window instead of has_focus. That however
broke activating surfaces when the gdk application acquired a grab itself,
in which case has_focus_window is false but has_focus is true.
We thus actually need to use both: surfaces should be activated either
because we have normal keyboard focus, or because we grabbed the keyboard.
This also renames HAS_FOCUS to APPEARS_FOCUSED to better reflect its
role.
Fixes#85
(cherry picked from commit 3287ac96e02ff236d74db10164c5b0c1e7b2b0bf)
There is no reason why we shouldn't pass this flag every time
Z-order changes. We have separate routines that are used to
maintain relative Z-order, so it should be completely OK to
pass SWP_NOOWNERZORDER to let the OS know that it shouldn't try
to maintain relative Z-order of the windows when raising them.
Pass SWP_NOOWNERZORDER when rising TEMP surfaces to the top. This ensures that
they don't drag anything else to the top with them. The use-case for this is
a tooltip (which must be on top) appearing for a non-foreground surface,
causing said surface to rise above other surfaces, some of which may
be foreground at the moment.
https://bugzilla.gnome.org/show_bug.cgi?id=784766
Fixes issue #852
For very small page sizes of < 1.0, the effect of pow() is the
opposite of what's intended and the scroll steps become unusably
large, make sure we never get a scroll_unit larger than page_size /
2.0, which used to be the default before the pow() magic was
introduced.
Otherwise, requesting a min size in em where the equivalent in px had a
fractional part would lead to the gadget getting allocated 1 too few px.
You could see this in the CSS property vs. allocation in the Inspector.
Note that margin/border/padding are left alone: the rationale is that we
do as browsers do, and Benjamin said we already do that for those,
whereas his tests on min-(width|height) showed otherwise. My subsequent
analysis indicated it to be far less clear-cut than that, but he remains
unconvinced that we should ceil() all the things! So just do these ones.
https://gitlab.gnome.org/GNOME/gtk/issues/1088
This is the API used by GtkMenu to properly position menus on the screen
without requiring GTK to query the menu window's position or the work
area of where the window is positioned. It makes it possible to position
popup windows properly when using Wayland.
Make this API available to external users so custom popup windows can be
positioned properly as well.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/997
This is meant as an input to the font chooser.
We don't want the user to select a language, but
rather have fonts presented as they would work for
the current language. Therefore, do away with the
lang/script combo on the tweak page.
For some font features, we can figure out affected
glyphs, and show before/after. For some others, we
hardcode typical sequences.
Still to do: figure out how to find ligatures and
show them.
Without enforcement to the expander-size, we can end up rendering icons
rather fuzzy. This uses the expander-size style property to determine
the square for the icon, centered on what was the calculated space for
the expander.
The 'gtk-fontconfig-timestamp' and 'gtk-modules' settings are
currently not available at all on Wayland. On X11, they are
implemented through xsettings maintained up-to-date by
gnome-settings-daemon.
This patch implements both GtkSettings for Wayland using a
new dbus interface also provided by gnome-settings-daemon.
Closes#886
:climb-rate is not about what you get when you single-click on a button,
as this implied: it's what happens if you hold down a button or a key.
Fix the description of @climb_rate to new(), and while here, mention the
key in the blurb of :climb-rate itself.
gdk_wayland_*_grab()/ungrab() would emit crossing events which translate
as focus_in/focus_out events for keyboard.
However, the ungrab() functions compare the native toplevel as this is
what gets the Wayland pointer enter/leave events with the grab window,
so if the grab is issued on a child gdk window, those won't match and we
would emit more focus_out events than focus_in events.
This means that a widget such as spice-gtk which issues a keyboard grab
whenever the pointer enters the window and releases the grab when it
leaves the window would get uneven numbers of focus_in/focus_out events.
Also, gdk_wayland_seat_ungrab() would not emit crossing events for
keyboard devices, whereas gdk_wayland_device_ungrab() does, which adds
even more potential discrepancies between focus_in/focus_out events.
To solve this problem, introduce two new helper functions which check
the relevant native windows to emit crossing events when needed that get
called evenly from both gdk_wayland_seat_grab()/ungrab() and gdk_Wayland
_device_grab()/ungrab() APIs.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=780422
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/792
We've had it for a long time, and it hasn't really made
a difference. And I don't think we are prepared to turn
this into a hard error. So just drop it.
The last round of patches to get the desired direction of value move in
response to scrolls/keypresses on scales had the inadvertent side effect
of giving the opposite direction on scrollbars. Seeing as gtkrange.c is
already a collection of hacks, add another so that fix only holds if the
instance is a GtkScale, since that is what those patches were aimed at.
Close https://gitlab.gnome.org/GNOME/gtk/issues/1065
The last round of patches to get the desired direction of value move in
response to scrolls/keypresses on scales had the inadvertent side effect
of giving the opposite direction on scrollbars. Seeing as gtkrange.c is
already a collection of hacks, add another so that fix only holds if the
instance is a GtkScale, since that is what those patches were aimed at.
Close https://gitlab.gnome.org/GNOME/gtk/issues/1065
These can't be returned as part of the font description,
so we need new api for them. For now, this is just readonly
properties. Maybe these should be writable too, eventually.
GtkTextView scrolls to the insertion point when the text
buffer signals a paste is done. This is wrong when there
are multiple views on the same buffer, and the paste
happened in another view.
To fix this, flip the handling of the scroll_after_paste
boolean to only be TRUE if we know that we want to scroll.
The gtk_app_chooser_dialog_set_heading() function do emit
notify::heading. Since the setter simply calls the function,
the setter itself shouldn't emit a notify signal by itself.
This is the updates to the Visual Studio 2008 projects to generate
gtk/gtktypefuncs.c using the preprocessor and the gentypefuncs.py that
was adapted from master.
Unfortunately we could not clean up the projects as we did for the 201x
ones due to the differences in project file format.
Combine repetitive parts, and unify using $(PythonDir) for all builds,
which the paths set in the property sheets are now based on the Visual
Studio version and platform combination.
Not that it will make a difference, but to be consistent with the
autotools builds. Include gtkx.h instead of gtk.h when we generate the
source to feed to the preprocessor.
We now need to generate gtktypefuncs.c by ourselves, so modify the
gentypefuncs.py script from master, and add a custom build step in the
projects to generate gtktypefuncs.c. The custom build step for the 2008
projects will be added later.
When an animated cursor was set and the previous cursor animation delay
happened to be the same, we wouldn't restart the animation timeout and
just return G_SOURCE_CONTINUE assuming the timer would continue. This
assumption is however only valid if the function was called from the
timeout, which is not the case.
Instead also arm the timer also if there is no previous timer active.
gdk_wayland_*_grab()/ungrab() would emit crossing events which translate
as focus_in/focus_out events for keyboard.
However, the ungrab() functions compare the native toplevel as this is
what gets the Wayland pointer enter/leave events with the grab window,
so if the grab is issued on a child gdk window, those won't match and we
would emit more focus_out events than focus_in events.
This means that a widget such as spice-gtk which issues a keyboard grab
whenever the pointer enters the window and releases the grab when it
leaves the window would get uneven numbers of focus_in/focus_out events.
Also, gdk_wayland_seat_ungrab() would not emit crossing events for
keyboard devices, whereas gdk_wayland_device_ungrab() does, which adds
even more potential discrepancies between focus_in/focus_out events.
To solve this problem, introduce two new helper functions which check
the relevant native windows to emit crossing events when needed that get
called evenly from both gdk_wayland_seat_grab()/ungrab() and gdk_Wayland
_device_grab()/ungrab() APIs.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=780422
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/792
In scroll_event(), there is no need to check whether we are realized
before emitting ::change-value, as we must be when receiving an event.
Git-formatted/rebased/cleaned up by Daniel Boles <dboles.src@gmail.com>
Close https://gitlab.gnome.org/GNOME/gtk/issues/292
• #include <math.h> for the new uses of floor()
• Move the new ints and popdown_data into the scopes where they are used
• Don’t pointlessly init other ints to 0 as they always get reassigned
• Burninate gint
This issue was caused when mouse coordinates were changed to floating
point values in commit e8b38fedbd.
This patch floors the event->x_root and event->y_root values when
setting the navigation region, so the previous behaviour is restored.
https://gitlab.gnome.org/GNOME/gtk/issues/450
The header linux/input.h used by GDK is specific to Linux. It is
possible to get a few Linux headers on FreeBSD by installing v4l_compat,
but it is usually better to use the one shipped with FreeBSD.
We prefer dev/evdev/input.h to linux/input.h here, so it will always use
dev/evdev/input.h on FreeBSD regardless of v4l_compat.
https://svnweb.freebsd.org/changeset/ports/465644
When pressing e.g. a window manager shortcut, which acquires keyboard grab,
Xorg would send FocusOut NotifyGrab then FocusIn NotifyUngrab. Currently
gdk would then deactivate the current surface, which makes accessibility
screen readers think that we have switched to a non-accessible application
and came back again, and thus reannounce the application frame etc. which we
don't want when e.g. just raising volume.
And actually, receiving FocusOut NotifyGrab does not mean losing the
X focus, it only means an application aqcuired a grab, i.e. it is
temporarily stealing keyboard events. On Wayland, this isn't even
notified actually.
This commit makes gdk only deactivate surfaces when there was an actual
focus switch to another window, as determined by has_focus_window (instead
of just has_focus), which happens either normally through FocusOut with
NotifyNormal, or during grabs through FocusOut with NotifyWhileGrabbed.
Fixes#85
(cherry picked from commit 01455399e8)
gdk_win32_keymap_check_compose() shouldn't be called for
non-W32 displays (i.e. when using broadway or other backends
that could be made to run on Windows).
The shortcuts inhibitors hash table is created when we create a
GdkWaylandWindow implementation for a GdkWindow, and it's destroyed once
we finalize the instance. The fake "root" window we create for the
Wayland display does not have a backing native window, so the shortcuts
inhibitors hash table is set to NULL; this causes a critical error
message when calling g_hash_table_destroy() on it. The finalization of
the root window happens when we close a display connection.
We should use g_clear_pointer(), instead, as it's NULL safe.
Without this change, the displayclose test fails, as all warnings are
considered fatal.
We expect these files to be regenerated even when building GTK+ from a
release tarball, so there's no point in distributing them if they are
going to be ignored.
Epoxy 1.4 has new ad hoc API that we can use to check whether GLX is
available on the current system.
If we didn't use this API, we'd have to manually dlopen libGL (or its
equivalent on different OSes) and check if it had GLX symbols; since
Epoxy already does all of this internally, we can simply ask it instead.
https://bugzilla.gnome.org/show_bug.cgi?id=775279
(cherry picked from commit 02eb344950)
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
.linked assumes the container is a GtkBox, which is documented as never
flipping children in RTL, so :first-child is always the left child, etc.
GtkBox does that by reordering its CSS nodes when the direction changes.
But most widgets don’t do that, so :first|last-child are 1st/last ADDED
and swap sides in RTL. GtkPathBar is so, and ignoring that in our themes
meant that in RTL, its left/right buttons got each other’s borders. Yuk!
This patch adds the groundwork for supporting widgets like that, via the
%linked_flippable placeholder, and applies that to override buttons in
filechooser .path-bar.linked > button
so that the correct borders get applied to those buttons when using RTL.
Note that I select only PathBars within a FileChooser because we also
have NautilusPathBar, which also uses widget.path-bar – but *does* flip
its nodes for RTL already, so letting that get affected broke it again!
https://bugzilla.gnome.org/show_bug.cgi?id=772817
Otherwise, if the Popover is destroyed before the MenuButton, the latter
still had a non-NULL but invalid instance and tried to use it in dispose
https://gitlab.gnome.org/GNOME/gtk/issues/199
A user in #gtk+ was confused what to do instead of creating a Button via
gtk_button_new_from_stock(). Our docs could stand to be clearer on this
point; it only costs a few lines. So, link from that constructor* to the
GtkStock doc, and add a banner there telling folk they shouldn’t use it.
* not that most [of these][links] even work right now…
Use g_signal_connect_data() instead of g_signal_connect_object()
to make sure the callback gets disconnected when the data object
is destroyed. This avoids problems in garbage-collected bindings.
https://bugzilla.gnome.org/show_bug.cgi?id=789215
The GVariant we are getting here might not be coming
from GTK+, but rather from some other source. Best to
be forgiving and deal with missing data without crashing.
This was causing the GTK+ portal backends to crash on
print requests from Qt.
Gtkplacesview finalization fixes
See merge request GNOME/gtk!119
(cherry picked from commit e30176a522)
f9452957 gtkplacesview: unset entry_pulse_timeout_id before removing it
4900c3eb gtkplacesview: disconnect from server list monitor changes on destroy
This will be used in subsequent commits to fix the sign by which the
value is changed in response to directional scroll or keypress events.
The idea is: you have a movement to make – in the form of a delta that
follows widget directions, i.e. −1 means left or up, +1 means right or
down – and you want to know whether that delta needs to be inverted in
order to produce the intuitively expected directional change of :value.
The existing should_invert() is not sufficient: it just determines
whether to invert visually, but we need more nuance than that for input.
To answer that – while not doubling up the work for scrolls and keys – I
add a helper should_invert_move(), which considers other relevant state:
• A parallel movement on priv->orientation should just use the existing
should_invert(), which already worked OK for this case (not others).
• Movements on the other orientation now depend on priv->orientation:
◦ For a horizontal Range, always invert, so up (i.e. −ve in terms of
widget coords) always means increase value & vice-versa. This was
done in get_wheel_delta(), but move it here for use with keys too.
◦ For a vertical Range, ignore :invert as it’s only relevant to the
parallel orientation. Do not care about text direction here either
as RTL locales do not invert number lines, Cartesian plots, etc.
This returns TRUE if the delta should be inverted before applying to the
value, and we can now use this function in both scroll and key handlers.
https://bugzilla.gnome.org/show_bug.cgi?id=407242https://bugzilla.gnome.org/show_bug.cgi?id=791802
.set_accel_path(): Use (nullable) instead of (allow-none), and explain
what a NULL means (albeit very briefly)
.set_title(): Annotate @title as (nullable), and explain NULL’s meaning
...from CellRenderer::start-editing, to point people in the direction of
info about the lifecycle of the Editable and how to do generic setup.
https://gitlab.gnome.org/GNOME/gtk/issues/154
Drop the line copied from .activate(), replace it with a description of
what this method actually does, and explain what a NULL result means.
https://gitlab.gnome.org/GNOME/gtk/issues/154
* Note in the intro that we're really thinking about temporary widgets
* Mention a gotcha regarding GtkEntry and how ::focus-out stops editing
* Give some examples of what you'd want to do in ::editing-done
* Be a bit more precise about what ::remove-widget represents
* Summarise the lifecycle between Renderer/Editable in .start_editing()
* Emphasise again there that this should be viewed as a temporary widget
https://gitlab.gnome.org/GNOME/gtk/issues/154
... and use it to not connect anything to the frameclock if it isn't
set.
This gets around the problem that the frame clock is disconnected before
GtkWidgetClass.unrealize() is called but the widget is still marked as
realized and the frame clock is available during the vfunc, which makes
calls like gtk_widget_queue_resize() reconnect to the frame clock.
Closes#168
The links to the repository's web UI still refer to the old
git.gnome.org cgit UI, and to the master branch; we should be using
GitLab and the gtk-3-22 branch instead.
When asked for a nonexistent (positive) monitor number,
gdk_x11_display_get_monitor would (at best) return an uninitialized pointer,
instead of returning NULL.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/107
Redrawing is insufficient: when :role changes to/from NORMAL, the
indicator gadget reallocates, but we didn't reflect that in the widget.
https://gitlab.gnome.org/GNOME/gtk/issues/163
When a project has a bundled copy of our macro included in tarball
source releases, typically in a m4/ or aclocal/ directory, aclocal
uses the serial number to determine whether the system copy in
/usr/share/aclocal is newer or older than the bundled copy. Without
a serial number, the bundled copy will always be used and will not
be overwritten, even if it is outdated.
Signed-off-by: Simon McVittie <smcv@debian.org>
delete_range_cb is set to be called before the text suppression done by
the gtktextlayout (otherwise it does not work properly). But at that
point the cursor position is not yet up to date. We thus need to move
the accessibility cursor notification to after the actual text
suppression, by using another callback.
This fixes cursor position in brltty screen reading.
The second parameter of the text-changed::delete event is to be the length,
not the end position. This fixes spurious text removals in brltty
screen reading.
The stable xdg_shell port (5c8bb51a) introduced an error in
gdk_wayland_window_set_geometry_hints which would set the minimum size
to the maximum size, if provided.
This resulted in various wxWidgets apps (FileZilla, Audacity, Veracrypt)
crashing because they attempted to allocate a ginormous surface.
Fixes#157.
Like other widgets, this returns a floating reference, so
(transfer full) is wrong. Just omit the annotation as others do,
thus implying (transfer none).
Close https://gitlab.gnome.org/GNOME/gtk/issues/156
If GtkExpander:sensitive was FALSE, the arrow still got the normal fg
colour, which made it look clickable, in contrast to the adjacent label.
Fix this by adding selectors to catch the applicable :disabled states.
Note: Needing these may indicate an oops in generic styles elsewhere,
but I couldn’t see any, so let’s just get it looking right for now.
https://gitlab.gnome.org/GNOME/gtk/issues/146
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
<GenerateGtkDbusBuiltSources>cd ..\..\..\gtk & $(PythonDir)\python $(GDbusCodeGenCmd) & cd $(SolutionDir)</GenerateGtkDbusBuiltSources>
<GenerateGtkDbusBuiltSourcesX64>cd ..\..\..\gtk & $(PythonDirX64)\python $(GDbusCodeGenCmd) & cd $(SolutionDir)</GenerateGtkDbusBuiltSourcesX64>
GtkWidget*w=gtk_label_new("pLorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.");
<para>You may have noticed that we used the <literal>_from_resource(<!---->)</literal> variant
of the function that sets a template. Now we need to use GLib's resource
functionality to include the ui file in the binary. This is commonly
done by listing all resources in a .gresource.xml file, such as this:
of the function that sets a template. Now we need to use <ulinkurl="https://developer.gnome.org/gio/stable/GResource.html">GLib's resource functionality</ulink>
to include the ui file in the binary. This is commonly done by listing
all resources in a .gresource.xml file, such as this:
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.
