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
Otherwise, builds that include the Wayland backend fail.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=789630
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
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 has no practical effect on Adwaita, but might fix some
third-party themes that were broken by GTK+ 3.22.23.
Signed-off-by: Simon McVittie <smcv@debian.org>
https://bugzilla.gnome.org/show_bug.cgi?id=789357
